Warning:
This wiki has been archived and is now read-only.

CommentResponse:GR-4

From SPARQL Working Group
Jump to: navigation, search

Gregg,

Thank you for your comments. See our response inline below

> Suggestion: replace all uses of "data" with "resource". The obvious reason is to maintain consistency with other W3C docs; the less obvious reason is that it really is about resources.

I scanned the current text for all uses of "data" (I could only find 3 - besides those used in SPARQL Update, etc.) and none of them seemed appropriate to replace with "resource". Can you give an example of which of these you felt are inconsistent with other W3C docs?

> I see no essential distinction between dataset and data store. Somewhere a text points out that data stores but not datasets can be updated .

It might be that recent changes addressed this, but I can't find text (in the Graph Store protocol) that makes an explicit distinction between Graph Store's and Datasets. The current draft delegates that definition and distinction to the SPARQL Update specification.

> That gets it backwards. It's the language that allows update expressions or not; the capabilities of graph database implementations are out of scope. Or to put it another way, a query/update language definition is supposed to define a language, not a database. If your implementation understands update operations, then it can update its datastore, which may be the same "dataset" used in query operations. Using two terms is likely to lead to confusion and uncertainty.

The current text explicitly only uses the term Graph Store.

> - Suggestion: replace both with "RDF graph region".

Is your suggestion to replace Graph Store with "RDF graph region"? If so, such a change would be needed in both the Graph Store protocol as well as the SPARQL Update protocol and both have settled on this term. If this is not the replacement you had in mind, could you please specify the change you had in mind with respect to the current text?

We'd appreciate if you could indicate whether this response adequately addresses your comment.

Chime Ogbuji

(On behalf of the SPARQL Working Group)