Make serialize() on a CONSTRUCT result act like normal g.serialize() #1834
Assignees
Labels
breaking change
This involves or proposes breaking RDFLib's public API.
enhancement
New feature or request
Comments
|
I'm encountering issues related to this now. I can easily (two word change) make the The documentation for
but the reults aren't real bool, Graph etc objects, as far as I can tell, they are all |
Indeed it should be, according to the SPARQL 1.1 spec - “The CONSTRUCT query form returns a single RDF graph specified by a graph template.” |
|
We are interested in this issue and are currently working on having a way to get the turtle format in the returned results for CONSTRUCT query. We looked into the xmlresults.py file in the reults directory of sparql. We realised that the serialize() function is being called in that file to actually serialize those results. We are planning to have a way to convert the generated xml statements into turtle and then result that. Another way could be to have a separate file like turtleresults.py and then call the serialize function there. In case you have any ideas we can go forward with this, please do share them. |
|
There was a PR for this before: |
|
aucampia
added a commit
to aucampia/rdflib
that referenced
this issue
Jul 31, 2022
…lize`
Change `{Graph,Result}.serialize` to only handle string destinations as URIs if
the schema is `file` and to treat it as operating system paths in all
other cases.
This is for the following reasons:
- `Result.serialize` was treating URI paths as OS paths which only works
for some cases, for special charachters and percentage encoding it
does not work.
- Many valid Unix and Windows paths parse using `urlparse` and have no netloc, e.g. `C:\some\path`
and `some:/path`, however they should be treated as paths and not as URIs.
- `Graph` and `Result` should behave consistently.
Some caveats in this change:
- non-file URIs will now be treated as OS paths which may result in
slightly confusing error messages, such as
`FileNotFoundError: [Errno 2] No such file or directory: 'http://example.com/'`
if http://example.com/ is passed.
- some valid file URIs (e.g. `file:/path/to/file` from https://datatracker.ietf.org/doc/html/rfc8089)
are also valid Posix paths but will be treated as file-URIs instead of
Posix paths. For `Graph.serialize` this ambiguity can be avoided by
using `pathlib.Path`, but for `Result.serialize` there is currently no
way to avoid it, though I will work on RDFLib#1834
soon and in that provide a way to avoid the ambiguity there also.
5 tasks
aucampia
added a commit
to aucampia/rdflib
that referenced
this issue
Jul 31, 2022
…lize`
Change `{Graph,Result}.serialize` to only handle string destinations as URIs if
the schema is `file` and to treat it as operating system paths in all
other cases.
This is for the following reasons:
- `Result.serialize` was treating URI paths as OS paths which only works
for some cases, for special charachters and percentage encoding it
does not work.
- Many valid Unix and Windows paths parse using `urlparse` and have no netloc, e.g. `C:\some\path`
and `some:/path`, however they should be treated as paths and not as URIs.
- `Graph` and `Result` should behave consistently.
Some caveats in this change:
- non-file URIs will now be treated as OS paths which may result in
slightly confusing error messages, such as
`FileNotFoundError: [Errno 2] No such file or directory: 'http://example.com/'`
if http://example.com/ is passed.
- some valid file URIs (e.g. `file:/path/to/file` from https://datatracker.ietf.org/doc/html/rfc8089)
are also valid Posix paths but will be treated as file-URIs instead of
Posix paths. For `Graph.serialize` this ambiguity can be avoided by
using `pathlib.Path`, but for `Result.serialize` there is currently no
way to avoid it, though I will work on RDFLib#1834
soon and in that provide a way to avoid the ambiguity there also.
aucampia
added a commit
to aucampia/rdflib
that referenced
this issue
Jul 31, 2022
…lize`
Change `{Graph,Result}.serialize` to only handle string destinations as URIs if
the schema is `file` and to treat it as operating system paths in all
other cases.
This is for the following reasons:
- `Result.serialize` was treating URI paths as OS paths which only works
for some cases, for special charachters and percentage encoding it
does not work.
- Many valid Unix and Windows paths parse using `urlparse` and have no netloc, e.g. `C:\some\path`
and `some:/path`, however they should be treated as paths and not as URIs.
- `Graph` and `Result` should behave consistently.
Some caveats in this change:
- non-file URIs will now be treated as OS paths which may result in
slightly confusing error messages, such as
`FileNotFoundError: [Errno 2] No such file or directory: 'http://example.com/'`
if http://example.com/ is passed.
- some valid file URIs (e.g. `file:/path/to/file` from https://datatracker.ietf.org/doc/html/rfc8089)
are also valid Posix paths but will be treated as file-URIs instead of
Posix paths. For `Graph.serialize` this ambiguity can be avoided by
using `pathlib.Path`, but for `Result.serialize` there is currently no
way to avoid it, though I will work on RDFLib#1834
soon and in that provide a way to avoid the ambiguity there also.
aucampia
added a commit
to aucampia/rdflib
that referenced
this issue
Jul 31, 2022
…lize`
Change `{Graph,Result}.serialize` to only handle string destinations as URIs if
the schema is `file` and to treat it as operating system paths in all
other cases.
This is for the following reasons:
- `Result.serialize` was treating URI paths as OS paths which only works
for some cases, for special charachters and percentage encoding it
does not work.
- Many valid Unix and Windows paths parse using `urlparse` and have no netloc, e.g. `C:\some\path`
and `some:/path`, however they should be treated as paths and not as URIs.
- `Graph` and `Result` should behave consistently.
Some caveats in this change:
- non-file URIs will now be treated as OS paths which may result in
slightly confusing error messages, such as
`FileNotFoundError: [Errno 2] No such file or directory: 'http://example.com/'`
if http://example.com/ is passed.
- some valid file URIs (e.g. `file:/path/to/file` from https://datatracker.ietf.org/doc/html/rfc8089)
are also valid Posix paths but will be treated as file-URIs instead of
Posix paths. For `Graph.serialize` this ambiguity can be avoided by
using `pathlib.Path`, but for `Result.serialize` there is currently no
way to avoid it, though I will work on RDFLib#1834
soon and in that provide a way to avoid the ambiguity there also.
aucampia
added a commit
to aucampia/rdflib
that referenced
this issue
Jul 31, 2022
…lize`
Change `{Graph,Result}.serialize` to only handle string destinations as URIs if
the schema is `file` and to treat it as operating system paths in all
other cases.
This is for the following reasons:
- `Result.serialize` was treating URI paths as OS paths which only works
for some cases, for special charachters and percentage encoding it
does not work.
- Many valid Unix and Windows paths parse using `urlparse` and have no netloc, e.g. `C:\some\path`
and `some:/path`, however they should be treated as paths and not as URIs.
- `Graph` and `Result` should behave consistently.
Some caveats in this change:
- non-file URIs will now be treated as OS paths which may result in
slightly confusing error messages, such as
`FileNotFoundError: [Errno 2] No such file or directory: 'http://example.com/'`
if http://example.com/ is passed.
- some valid file URIs (e.g. `file:/path/to/file` from https://datatracker.ietf.org/doc/html/rfc8089)
are also valid Posix paths but will be treated as file-URIs instead of
Posix paths. For `Graph.serialize` this ambiguity can be avoided by
using `pathlib.Path`, but for `Result.serialize` there is currently no
way to avoid it, though I will work on RDFLib#1834
soon and in that provide a way to avoid the ambiguity there also.
aucampia
added a commit
to aucampia/rdflib
that referenced
this issue
Jul 31, 2022
…lize`
Change `{Graph,Result}.serialize` to only handle string destinations as URIs if
the schema is `file` and to treat it as operating system paths in all
other cases.
This is for the following reasons:
- `Result.serialize` was treating URI paths as OS paths which only works
for some cases, for special charachters and percentage encoding it
does not work.
- Many valid Unix and Windows paths parse using `urlparse` and have no netloc, e.g. `C:\some\path`
and `some:/path`, however they should be treated as paths and not as URIs.
- `Graph` and `Result` should behave consistently.
Some caveats in this change:
- non-file URIs will now be treated as OS paths which may result in
slightly confusing error messages, such as
`FileNotFoundError: [Errno 2] No such file or directory: 'http://example.com/'`
if http://example.com/ is passed.
- some valid file URIs (e.g. `file:/path/to/file` from https://datatracker.ietf.org/doc/html/rfc8089)
are also valid Posix paths but will be treated as file-URIs instead of
Posix paths. For `Graph.serialize` this ambiguity can be avoided by
using `pathlib.Path`, but for `Result.serialize` there is currently no
way to avoid it, though I will work on RDFLib#1834
soon and in that provide a way to avoid the ambiguity there also.
aucampia
added a commit
that referenced
this issue
Aug 2, 2022
…lize` (#2065) Change `{Graph,Result}.serialize` to only handle string destinations as URIs if the schema is `file` and to treat it as operating system paths in all other cases. This is for the following reasons: - `Result.serialize` was treating URI paths as OS paths which only works for some cases, for special charachters and percentage encoding it does not work. - Many valid Unix and Windows paths parse using `urlparse` and have no netloc, e.g. `C:\some\path` and `some:/path`, however they should be treated as paths and not as URIs. - `Graph` and `Result` should behave consistently. Some caveats in this change: - non-file URIs will now be treated as OS paths which may result in slightly confusing error messages, such as `FileNotFoundError: [Errno 2] No such file or directory: 'http://example.com/'` if http://example.com/ is passed. - some valid file URIs (e.g. `file:/path/to/file` from https://datatracker.ietf.org/doc/html/rfc8089) are also valid Posix paths but will be treated as file-URIs instead of Posix paths. For `Graph.serialize` this ambiguity can be avoided by using `pathlib.Path`, but for `Result.serialize` there is currently no way to avoid it, though I will work on #1834 soon and in that provide a way to avoid the ambiguity there also.
aucampia
added
the
breaking change
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in #1612
Originally posted by nicholascar June 11, 2021
Currently (RDFlib 6.0.0a0 AKA
master),g.serialize()defaults to turtle format and is decoded, however callingserialize()on a SPARQLCONSTRUCTresult (i.e. on aResultobject) returns the RDFlib 5.0.0 form of an RDF/XML, UTF-8-encoded result.The old style
serialize()inResultshould be updated to match the mainGraph()serialize().The text was updated successfully, but these errors were encountered: