-
Notifications
You must be signed in to change notification settings - Fork 8
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
decide on the short names of the specifications #4
Comments
From email chain, I think we come up with the following shortnames:
and for SPARQL:
That's 21 documents! Although many may need only minimal editorial work. |
I like the suggested switches to I suggest that I'm happy with the other names as above. |
|
|
+1 to |
+1 to |
Updated proposal by @TallTed (via Zoom chat, in here for logging) RDF12-NEW SPARQL12-CONCEPTS |
RDF12-NEW SPARQL12-NEW |
(The argument made for "syntax-" was just the one case of "rdf12-xml" be coming "rdf12-rdfxml") I don't think the "syntax-" and "results-" adds much help to people They require more typing of a longer prefix for browser autocomplete to pick one URL. |
I prefer to remove the |
@afs said:
Does this mean you'd prefer the following for SPARQL result formats?
As for RDF/XML, my preference would be RDF12-XML followed by RDF12-RDFXML, but I think that's redundant. Lastly, RDF12-XML-SYNTAX, but don't favor adding SYNTAX to any other concrete format. Note that the JSON-LD group will likely end up publishing JSON-LD12, JSON-LD12-API, and JSON-LD12-FRAMING eventually. |
SPARQL already (for better or worse) has "results-" for 2 RECs : "json" and "csv-tsv". I don't mind so much on whether to leave because it 'just is' or remove "results-". "results" is the purpose of the REC. Now is a good time to sort out "XMLres". Adding "syntax-" was argued based on We need to decide whether there is a new the alias but that's not urgent - we do need the short names. We currently have "/turtle" (title "RDF 1.1 Turtle"), "/n-triples" /n-quads" and "/trig" which work fine and do not have syntax in the top level title. IFAIK this has not been a problem with these names. Adding "syntax-" does not solve an issue here. Adding "rdf12-" brings RECs together and the aliases remain. So let's solve naming for RDF/XML and not spill over to where there isn't a problem. In order: |
To avoid confusion for newcomers (understanding "RDF12" as "RDF twelve") and to open up the possibility to mint RDF version 12 in the (long-term?) future, I would suggest adding a dash between the "1" and "2".
|
@rubensworks -- I agree. I raised a similar issue on the SPARQL-12 repo (which I think should soon be renamed to SPARQL-next, as most of the content has an indeterminate version target, with whatever issues are being taken up for SPARQL-1-2 transferred to this, or a new, really SPARQL-1-2 repo).... |
As already publicly communicated, the SPARQL-1.2 repo will be renamed as |
The RDF 1.1 group established the RDF11- naming convention, as did SPARQL with SPARQL11-. JSON-LD has used this with JSON-LD11 as well, and I think there’s much more precedent in W3C short name conventions. Changing to RDF1-2- goes against this precedent, and I personally find it much more annoying. So 👎 for me. |
CSVW:
PROV:
Is temporal SPARQL out of scope, paste the due date?
|
|
It would be great if the sparql-dev group were to come up with something concrete on JSON-LD and CSVW based result formats. A hypothetical YAML-LD results format could follow on that, if/as/when YAML-LD moves onto the REC track. Definitely something that would come after the core deliverables for RDF-star are completed, and possibly after 1.2 RECs are finished. |
This is off topic here but ... JSON-LD and CSVW produce RDF graphs. (There is a vocabulary for this FWIW.) SPARQL already supports JSON-LD through content negotiation. |
@pgroth @lucmoreau (W3C PROV-O Overview) How should / are SPARQL queries modeled with PROV with maximal metadata? |
https://www.w3.org/TR/rdf-sparql-XMLres/#mime:
But that's obviously a different thing. |
@westurner - I'm not sure the context here? But I would do as a start:
I would also add start and endtimes and probably make the spraql and query result sets dereferencable urls. Umm, does that help? |
That helps thanks. There may be existing SPARQL w/ PROV Use Cases or Test Cases with more comprehensive examples that e.g. SPARQL12-RESULTS-CSVW, SPARQL12-RESULTS-JSONLD-CSVW might helpfully reference as optional additional schema in the interest of signed data quality. The Schema.org project has a system for RDFa/JSON-LD/ examples in text files in git - that could be improved - that could be useful for Integration Tests of some or all of the schema(s) referenced in this thread. |
IIRC, some time ago, there was discussion of a hypothetical result format that would borrow the context support from JSON-LD so that result set entries could include terms that would be expanded the way that JSON-LD expands values. This would create a result set that contained a more compact representation. For example, a result could look like the following: {
"@context": {
"book": {"@type": "@id"}
},
"head": { "vars": [ "book" , "title" ]
} ,
"results": {
"bindings": [
{
"book": "http://example.org/book/book6" ,
"title": "Harry Potter and the Half-Blood Prince"
} ,
{
"book": "http://example.org/book/book7" ,
"title": "Harry Potter and the Deathly Hallows"
} ,
{
"book": "http://example.org/book/book5" ,
"title": "Harry Potter and the Order of the Phoenix"
} ,
{
"book": "http://example.org/book/book4" ,
"title": "Harry Potter and the Goblet of Fire"
} ,
{
"book": "http://example.org/book/book2" ,
"title": "Harry Potter and the Chamber of Secrets"
} ,
{
"book": "http://example.org/book/book3" ,
"title": "Harry Potter and the Prisoner Of Azkaban"
} ,
{
"book": "http://example.org/book/book1" ,
"title": "Harry Potter and the Philosopher's Stone"
}
]
}
} This idea was never really explored. Presumably a CSVW-based result format would take advantage of the metadata described for CSV tables in https://www.w3.org/TR/tabular-metadata/, but to describe results rather than a dataset. To my knowledge, this hasn't been investigated, but seems like the idea would be similar to using a JSON-LD context for describing column values. Anyway, pretty off-topic, and something that should be initiated in the SPARQL Dev community. |
due 22 Dec 2022
The text was updated successfully, but these errors were encountered: