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

Re: [GRAPH] graph deadlock?

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Mon, 19 Dec 2011 17:40:50 -0800
Message-ID: <4EEFE7A2.1050605@topquadrant.com>
To: public-rdf-wg@w3.org
On 12/17/2011 7:37 AM, Ivan Herman wrote:
> (1) RDF Datasets. It consists of labelled graphs: (G, l), where l is an URI. (Some raised the possibility to use literals for 'l', but I think there is a consensus to use URI-s). There is no semantic relationship between 'G' and 'l', so something like (with an ad-hoc syntax here):
>     ( {a:b c:d e:f}, mailto:ivan@w3.org }
> is a perfectly o.k. labelled graph in an RDF Dataset
> It seems that most (all?) quad stores fall into this category as well as the datasets in SPARQL
> (2) Named Graphs. It is a special RDF dataset, where the label 'l' is a (HTTP?) URI with an additional behaviour: if that URI is poked (GET-d) then it results in the serialization of a Graph whose parsing yields an equivalent graph to 'G'. It is the right/good framework for, say, Linked Data, etc.

It seems to me that we can make a lot of progress by exploring the 
common ground between these as test cases:
e.g. do we allow the same URI twice.

I would have thought that most people would be unhappy with:


{ ( {a:b c:d e:f}, mailto:ivan@w3.org ), ( {}, mailto:ivan@w3.org ) }

and also with


{ ( {a:b c:d e:f}, http://example.org/consensus ), ( {}, http://example.org/consensus
  ) }

If that is the case, then we have moved forward (even if only by a little)
And so I would like to propose these two test cases for consideration at the telecon.

Proposal: the RDF 1.1 Recommendation will not recommend the use of either (A) or (B)

Once we have agreed on one test case, then we can try for a second - rather than the somewhat boring threads of conversation: running over the same old ground, and how we found the same old fears ...

Received on Tuesday, 20 December 2011 01:41:18 UTC

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