-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a standardized extension of SPARQL Query Results XML format #12
Labels
sparql-star
About SPARQL-star
Comments
abrokenjester
added a commit
to metaphacts/rdf-star
that referenced
this issue
Nov 19, 2020
abrokenjester
added a commit
to metaphacts/rdf-star
that referenced
this issue
Nov 20, 2020
abrokenjester
added a commit
to metaphacts/rdf-star
that referenced
this issue
Nov 20, 2020
abrokenjester
added a commit
to metaphacts/rdf-star
that referenced
this issue
Nov 21, 2020
pchampin
pushed a commit
that referenced
this issue
Dec 11, 2020
pchampin
pushed a commit
that referenced
this issue
Dec 11, 2020
This was solved a while ago by #39 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The result of a SPARQL SELECT query is serialized in XML using the SPARQL Query Results XML format. This format will need to be extended to deal with the RDF* triple being a new possible value type for a binding. For example, the result of a query where variable
?a
is bound to an RDF* triple:<<<http://example.org/bob> <http://xmlns.com/foaf/0.1/age> 23>>
<http://example.org/certainty>
0.9
Currently, different implementations all have their own, slightly diverging, extensions. For example, in Eclipse RDF4J, the extension looks as follows:
In Apache Jena, the extension is almost identical, except for the choice to name the middle element
property
(where RDF4J usespredicate
):In Stardog, the implemented extension currently looks as follows:
In summary, RDF4J, Jena and Stardog all differ in the element names used (
triple
vsstatement
,property
vspredicate
,subject
vss
, etc).Other implementations may have yet other, slightly deviant variants. This makes it difficult to process query results from different endpoint implementations. A single recommended extension would be a benefit for parser implementors and users alike.
The text was updated successfully, but these errors were encountered: