W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > August 2012

Fw: Dataset, Graph Store, etc.

From: Chime Ogbuji <chimezie@gmail.com>
Date: Tue, 7 Aug 2012 09:40:49 -0400
To: Gregg Reynolds <dev@mobileink.com>, public-rdf-dawg-comments@w3.org
Message-ID: <624B63CCB5A74F668E28AE45E5196A55@gmail.com>
Sorry, I sent this to just Gregg, rather than the comments list.  Gregg, please respond to this email and not the previous one. 

-- 
Chime Ogbuji
Sent with Sparrow (http://www.sparrowmailapp.com)


Forwarded message:

> From: Chime Ogbuji <chimezie@gmail.com>
> To: Gregg Reynolds <dev@mobileink.com>
> Date: Tuesday, August 7, 2012 9:30:12 AM
> Subject: Re: Dataset, Graph Store, etc.
> 
> Gregg, my apologies, but it seems this comment was never responded to. See the response inline below
> 
> On Wed, 26 Jan 2011, Gregg Reynolds wrote:
> 
> > Hi WG, Just a quick note regarding some concepts and terminology. I'll leave detailed pros and cons for later; for now I'd just like to suggest the following to put it on your radar: 
> > - RDF data, data content, etc. Suggestion: replace all uses of "data" with "resource". 
> 
> 
> 
> 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?
> 
> 
> > The obvious reason is to maintain consistency with other W3C docs; the less obvious reason is that it really is about resources. 
> 
> > - RDF data store and dataset. - 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". - "Graph region" captures the essential semantics necessary for the language definition, and has a nice clean real-world analog: the piece of paper upon which one sketches one or more graphs. The paper itself, as well as any chunk of space on the paper, can be considered a region. - The graph region addressed by an expression in a query/update language is independent of any notion of server; but at the same time it admits of a simple analog: the graph region controlled by a server is the piece of paper it uses to inscribe graphs. Multiple servers may address the same region, etc.; the nice thing about "region" is that it allows us to disregard such implementation issues for the language definition, yet it also works for talking about implementation issues. - Alternative: graph space. I prefer "region" for some reason, maybe because "space" is too big; I think the intended meaning is something less than the entire RDF graph space
. 
> 
> 
> 
> 
> 
> 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) 
Received on Tuesday, 7 August 2012 13:41:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 August 2012 13:41:20 GMT