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

Re: [GRAPH] graph deadlock?

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 19 Dec 2011 20:28:40 +0000
Cc: Ivan Herman <ivan@w3.org>, W3C RDF WG <public-rdf-wg@w3.org>
Message-Id: <1E63FF96-FD31-442B-BDF5-2DC0A0EA898F@cyganiak.de>
To: Pat Hayes <phayes@ihmc.us>

On 17 Dec 2011, at 17:21, Pat Hayes 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
> Fine so far, but we get into a problem when we do the details. I personally have no problem (well, a kind of private horror, but thats just me) with datasets as you describe them here. The problem is, people apparently want to both have these AND use the URIs in them to refer to the associated graph in RDF triples (eg in 'metadata' graphs.) And that combination is simply illegal, according to the 2004 RDF specs.

You keep saying things like that.

I keep asking for quotations from the specs that back up these claims.

You never deliver, or deliver only a vague pseudo-arguments that rely on unstated assumptions not required by the specifications.

When you say “this is illegal in RDF” then I think this has to be read as “I don't like it”.

> We could simply declare that RDF has no semantics, and is simply to be used by programmers to mess around with in ways they find handy. Really, this might be the best way to move forward. But until we do this, we have to take the semantics seriously. 

Or we could just not bother giving any formal semantics to any new parts that are added to RDF. Several parts of RDF don't have a formal semantics and work pretty much fine anyways, e.g., RDF lists.

Received on Monday, 19 December 2011 20:29:19 UTC

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