W3C home > Mailing lists > Public > public-rdf-wg@w3.org > September 2012

Re: life without dataset semantics

From: David Wood <david@3roundstones.com>
Date: Wed, 19 Sep 2012 09:06:43 -0400
Cc: Sandro Hawke <sandro@w3.org>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "public-rdf-wg@w3.org Group WG" <public-rdf-wg@w3.org>
Message-Id: <9672FDDC-D1AE-46E3-822A-B9D1F097907B@3roundstones.com>
To: Steve Harris <steve.harris@garlik.com>
On Sep 19, 2012, at 05:37, Steve Harris <steve.harris@garlik.com> wrote:
> On 19 Sep 2012, at 00:22, Sandro Hawke wrote:
> 
>> So, elsewhere you're proposing we not have dataset semantics.   I think I'm okay with that, if I can still do what I'm trying to do here.      What I'm not entirely clear on is how I can do this without any semantics....
>> 
>> On 09/18/2012 02:10 PM, Peter F. Patel-Schneider wrote:
>>>> 
>>>> Here's a much better example, because it stays away from Web stuff:
>>>> 
>>>>   <g1> eg:sendCorrectionsTo <mailto:sandro@w3.org>.
>>>>   <g1> { w3c:group35462 rdfs:label "SPARQL Working Group" }.
>>>>   <g2> eg:sendCorrectionsTo <mailto:ivan@w3.org>.
>>>>   <g2> { w3c:group44350 rdfs:label "RDFa Working Group" }.
>>>> 
>>>> 
>>>> There's an obvious meaning to the predicate eg:sendCorrectionsTo, but how do I express that meaning? Something like:
>>>> 
>>>>   X eg:sendCorrectionsTo Y
>>>> 
>>>>       Note: only meaningful inside a dataset which has a named graph with
>>>>       the name X.
>>>> 
>>>>       Meaning: Y is a good email address for sending corrections to the
>>>>       information in the named graph X.
>>>> 
>>>> Are you comfortable with that?
>>> 
>>> I don't know if comfortable is the right word.  I don't have problems with anyone wanting to do that.
>> 
>> My question is really: do you think that definition/documentation means what I want it to and will work the way I want it to, if the RDF WG doesn't give Datasets any semantics?
>> 
>> That is, if the WG doesn't say anything about graph-name URIs connecting to URIs as used in the default graph, can I just spell all that out (as above) in the documentation of my predicate?
> 
> [slightly off-topic, sorry]
> 
> I'm intrigued about this fixation with the default graph… in practice we've not found it to be a useful place to store graph metadata, for a couple of reasons:
> 
> 1) it assumes you'll only have one source of metadata - this is often not the case, we have metadata from the harvesting process, the IE process, and the currency checking process. They live in different graphs. If that isn't the assumption, then it assumes that you don't care where the metadata came from, which seems strange.
> 
> 2) it more-or-less assumes you'll never update the graph (and hence metadata) otherwise it makes it very difficult to separate the metadata about one graph, from another. If your graph metadata is very, very regular,and you never change it's format over time then you could do it with a SPARQL Update, but that doesn't happen in real life very often. 
> 

Yes.  We treat the default graph as the union of all graphs for these reasons (and also because it is trivial to find/query).

Regards,
Dave


>> And if I can't, then what alternative do I have for sharing this kind of information structure?
>> 
>>> I can see that if this is the stance that someone wants to take with respect to named graphs, then one might want to have the relationship between IRIs and graphs work the way it works in the minimal semantics.
>>> 
>>> However,  I don't think that everyone wants to have this connection.
>> 
>> What I'm asking for is an extremely weak connection; it's hard for me to see how it would do any harm, since it would only come into play when someone ask for it.
> 
> But on the other hand, what good would it do?
> 
> - Steve
> 
> -- 
> Steve Harris, CTO
> Garlik, a part of Experian
> +44 7854 417 874  http://www.garlik.com/
> Registered in England and Wales 653331 VAT # 887 1335 93
> Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ
> 
Received on Wednesday, 19 September 2012 13:07:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:51 GMT