W3C home > Mailing lists > Public > www-archive@w3.org > September 2013

The Movie of the Book: Re: defn of Named Graph

From: Jeremy J Carroll <jjc@syapse.com>
Date: Tue, 24 Sep 2013 10:07:27 -0700
Cc: Pat Hayes <phayes@ihmc.us>, Dan Brickley <danbri@danbri.org>, Gregg Reynolds <dev@mobileink.com>, www-archive <www-archive@w3.org>
Message-Id: <C0B63F9E-DFA0-4492-B85F-7E73FAA3186C@syapse.com>
To: Sandro Hawke <sandro@w3.org>

On Sep 24, 2013, at 6:31 AM, Sandro Hawke <sandro@w3.org> wrote:

> I'm now confident that you and I (and Jeremy) agree the problem we're trying to solve in this thread is this: people seem to want to have different properties on one "graph" than on another, even when the "graphs" happen to have the same triples.


I am sorry, I actually don't agree.

The phrase '''even when the "graphs" happen to have the same triples.''' indicates that any actual example is likely to be contrived and artificial.
The point about these contrived and artificial examples is that they demonstrate that my use cases for graph naming (i.e. the use cases that matter to me) tend to be about referring to the graph as a representation of a resource, where there is one step of remove.


To totally abuse RDF we might agree a new mechanism for publishing novels.
A novel might be published as a single triple RDF graph with a blank subject, predicate being rdf:value and the object being the text of the novel.

The participants of this thread might each independently come up with the following earth-shattering great novel

[ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].

And once the movie of the book  grosses many millions, we all end up in court, arguing over who wrote the novel - contradicting the penultimate sentence.

Sandro produces his dataset with

eg:Sandro dc:creator "Sandro Hawke".

eg:Sandro [ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].


I produce mine with


eg:Jeremy dc:creator "Jeremy Carroll".

eg:Jeremy [ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].


etc., so that the court is presented with a merge of datasets:

eg:Jeremy dc:creator "Jeremy Carroll".
eg:Sandro dc:creator "Sandro Hawke".
eg:Dan dc:creator "Dan Brickley".
eg:Pat dc:creator "Pat Hayes".
eg:Gregg dc:creator "Gregg Reynolds".

eg:Jeremy [ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].

eg:Sandro [ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].

eg:Pat [ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].

eg:Gregg [ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].

eg:Dan [ rdf:value 
"""Once upon a time, there was a consortium, which agreed on a semantics for graph naming. And they all lived happily ever after. The END!"""
].

====

I really don't think there is any contradiction here, even if dc:creator is a functional property.
The court would have to fall back onto precedence, and I would produce this e-mail from www-archive and win the case!
http://lists.w3.org/Archives/Public/www-archive/2013Sep/0053.html

====

My point with this example is that the identity condition that Sandro is asking for is contrived; but my use case is of a publishing system where the data being published is in the form of an RDF graph, and there is metadata is data about that graph - but not really stuff about the graph itself but more about the pair - the naming of the graph.

Jeremy
Received on Tuesday, 24 September 2013 17:07:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:23 UTC