W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: [Graphs] Proposal for Named Graph Semantics

From: Alex Hall <alexhall@revelytix.com>
Date: Fri, 8 Apr 2011 10:03:18 -0400
Message-ID: <BANLkTikagSfrVe413rSW=kvB4W4SdJTZNg@mail.gmail.com>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: RDF WG <public-rdf-wg@w3.org>
On Fri, Apr 8, 2011 at 7:17 AM, Richard Cyganiak <richard@cyganiak.de>wrote:

> Hi Alex,
> Thanks once more, this is very helpful for understanding where you're
> coming from.
> On 7 Apr 2011, at 21:56, Alex Hall wrote:
> >> Why do you want a formal semantics?
> >
> > In short, to help me sleep better at night.
> :-)
> >> How does it help addressing the multigraph use cases [1]?
> >
> > Taking a quick look through that doc, I'll admit that for most of the use
> cases it doesn't address any issues that aren't addressed with the use of
> the abstract syntax.  There is, however, a section titled "Providing a
> standard foundation for the W3C specs" [2] and a sub-section on the
> alignment of Linked Data principles with RDF and AWWW which specifically
> states:
> >
> > 'A formal definition of a concept such as "RDF Dataset", "Set of Named
> Graphs", and the g-box/g-snap/g-text distinction in a core RDF spec would
> make it easier to formally define such a model, tying together the Linked
> Data principles and practices, Architecture of the World Wide Web, and the
> REST model of information resources and representations, in a formal way.'
> >
> > I make no claims that this proposal advances that goal in any particular
> way, I just highlight that section as an illustration that at least some
> people seem to want a more formal semantics.
> It was me who wrote that use case.
> I tried to get this onto the agenda of the WG at the workshop in Stanford:
> http://www.w3.org/2001/sw/wiki/RDF_Core_Work_Items#Codify_the_follow-your-nose_approach_to_using_URIs_in_RDF
> In the Future of RDF Standards survey, this work item got the second
> highest ranking of all (second to multigraphs):
> http://www.w3.org/2002/09/wbs/1/rdf-2010/results#xg8
> Nevertheless, the work item does not show up in the charter, except a note
> to the effect that something regarding linked data may be added to the
> Primer. I don't know how or why that decision was made.
> Anyway, using multigraphs to codify the follow-your-nose approach is only
> *one* use case for multigraphs, and there are others that don't require and
> don't want to connect graphs to HTTP dereferenceability and web
> architecture. If we get just an abstract syntax out of this WG, then that
> would already be a great enabler for describing how RDF can work on the Web,
> together with AWWW and REST. So I don't really see a formal semantics for
> multigraphs as a requirement.

To be perfectly clear, it was never my intent to require multigraph
semantics to be connected to HTTP dereferenceability and web architecture.
 My background is almost exclusively with quad stores and SPARQL services,
so I often don't care about the dereferenceability of IRIs.  It may be
useful to describe, in a primer or some other informative doc, "If a named
graph IRI is dereferenceable then this is how the resulting document
might/can/should be interpreted..." but I wouldn't go any farther than that.

The use cases that I saw this proposal as most useful for addressing were:
1. Giving guidance for the merging of datasets or multigraph documents,
although looking back I see that the RDF Dataset abstract syntax is
sufficient for defining a merge.

2. Addressing the fact that it's difficult to represent a named empty graph
in a quad store, by stating that it doesn't matter because it's not a useful
assertion to make anyways, and hoping that nobody got up in arms about that

3. Having a coherent story to tell when a newcomer to RDF and SPARQL asks,
"what does that IRI in this FROM clause mean?"  That may not have much
practical implication, but I find that not having a ready answer here does
us a disservice when it comes to adoption by non-SW experts.  I've been
working in this space for 6 years and I had to do some hard thinking to come
up with an answer that I found satisfactory.  I've seen other, less
experienced people go off down a rat-hole and get completely and utterly
lost trying to figure this out on their own.


> Best,
> Richard
Received on Friday, 8 April 2011 14:03:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC