-
Notifications
You must be signed in to change notification settings - Fork 19
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
Datatype triple patterns #182
Comments
Isn't |
Semantically yes, but it is not written in the triple. Such a thing should be produced only from something like Specifically, I was aiming for |
This proposal would make working with typed strings better, so I appreciate it. Combined with Having Keeping Looking at other proposals, #34 suggest I think that would result in, for the following data, the bindings as in the following table: :s :p "Hello, world!"@en .
|
Why?
Presently, SPARQL triple syntax does not offer enough granularity when matching literals ‒ the object of a property can be specified in a triple pattern as (among others) a variable or a fixed literal, but it cannot be something in between. If you want to find triples based on the datatypes, you have to match all of them, and then filter:
A trivial SPARQL engine implementation would load all triples in existence into a set and then filter them based on the criteria.
It is possible, of course, to optimize this query and retrieve all matching triples as a single step, but not all engines might do that, and still this is something that could be expressed more concisely.
Proposed solution
I propose an extension of the node syntax like this:
Such a query would only match triples with the
xsd:integer
datatype, and bind?o
to the lexical value of the literal (as a simple literal/xsd:string
).Of course there are other options for the object:
I think this would add more expressiveness to the language, and a possibility for better optimizations to triple store that can index by the datatype and evaluate such queries efficiently.
Language-tagged literals
These are literals as well, but I am unsure whether they should be matched by a pattern like
?o^^?dt
. However, if they are allowed, I think the natural solution (if not deemed too convoluted) might be to bind?dt
to a literal with thexsd:language
datatype, essentially treating something like"hello world"@en
as ""hello world"^^"en"^^xsd:language
" (not a proposed syntax), binding?o
to"hello world"
and?dt
to"en"^^xsd:language
. After all, a language tag is the datatype of a language-tagged literal, at least syntactically.Other SPARQL functions, such as
STRDT
, could be modified to allow eitherIRI
orxsd:language
as the datatype.Considerations for backward compatibility
I don't think
^^
in this position could have been valid previously, so all existing valid queries should remain valid and unambiguous.The text was updated successfully, but these errors were encountered: