URIs for SPARQL versions #242
Conversation
| sparql:version-1.1 | ||
| rdfs:label "1.1" ; | ||
| rdfs:comment "SPARQL 1.1" | ||
| . |
There was a problem hiding this comment.
This seems to duplicate what we have in service description. Not sure if it's a good thing.
There was a problem hiding this comment.
You mean sd:Language? That predates the version work.
As I read it, they are the URI for the whole language, not the version, and for use in the sd:Language where they are a subClassOf sd:Feature.
IMO The definition of the version URIs, if we have them at all, should be defined in the NS document and then referenced in service description.
There was a problem hiding this comment.
I am thinking about sd:SPARQL12Query for example. If I am not wrong it refers to the version.
There was a problem hiding this comment.
It would be good to precisely indicate the relationship between these versions and sd:Languages indeed.
To me, the difference is that what is added here are URLs that are implicitly connected to standard version labels.
These version labels are then a part of an sd:Language such as sd:SPARQL12Query.
We could consider connecting version URLs to language URLs using rdfs:isDefinedBy (perhaps there's a better predicate for this).
There was a problem hiding this comment.
I am thinking about
sd:SPARQL12Queryfor example. If I am not wrong it refers to the version.
A person is not their telephone number nor their social security number.
A version is an aspect of the language, not identical to it.
SPARQL 1.2 Query support the functions sparql:isTriple - versions do not support functions.
We could consider connecting version URLs to language URLs using rdfs:isDefinedBy (perhaps there's a better predicate for this).
Yes - version is an aspect of the abstract concept of a SPARQL query language.
There was a problem hiding this comment.
To touch on your example:
A person is not their telephone number nor their social security number.
A version is an aspect of the language, not identical to it.
I think it depends on how you look at it. I would argue SPARQL1.1 and SPARQL1.2 are two different query languages. It happens to be that the grammar of SPARQL1.2 is a superset of the grammar of SPARQL1.1 . To me there is no single SPARQL query language, there is a set of query languages that look much alike, and we call those SPARQL query languages.
There was a problem hiding this comment.
The service description seems to agree 1:
An instance of sd:Language represents one of the SPARQL languages
Footnotes
|
Is it also the intention to change the grammar so that the VERSION is defined by an IRI? In that case #240 can also be closed because the formatting will again be consistent with the rest of the grammar. |
No. |
|
To resolve @jitsedesmet's concern, we could consider writing somewhere in the SPARQL query spec that there's an implicit mapping between the version strings (e.g. in the query) and their corresponding URLs as added here in this PR. (this whole exercise can probably also be repeated at the RDF level) |
I am beginning to think the controlled vocabulary would be better in I had thought we might have separate versions we could have "SPARQL 1.3" without a round of new RDF. It isn't necessary to have two sets of definition if we say "here is a defined controlled vocabulary" in |
I agree that this would be better indeed. Then we can have languages such as |
See #241