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

Re: different Semantics proposals (Re: Agenda for 19 Sep 2012)

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 18 Sep 2012 13:46:22 -0400
Message-ID: <5058B36E.90304@w3.org>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
CC: David Wood <david@3roundstones.com>, "public-rdf-wg@w3.org Group WG" <public-rdf-wg@w3.org>
On 09/18/2012 12:00 PM, Peter F. Patel-Schneider wrote:
>
> On 09/18/2012 10:40 AM, Sandro Hawke wrote:
>> On 09/18/2012 09:27 AM, Peter F. Patel-Schneider wrote:
>>>
>>> On 09/18/2012 09:12 AM, Sandro Hawke wrote:
>>>> On 09/18/2012 09:05 AM, Peter F. Patel-Schneider wrote:
>>>>>
>>>>>
> [...]
>>>>
>>>> Sorry, I just meant the IRIs of the named graphs, the n's in the 
>>>> <n,g> pairs, being interpreted the same as IRIs the default graph.
>>>
>>> OK, so you are referring to the part of the semantics where it is 
>>> the denotation of the graph names in the default graph that is used 
>>> as the start of the mapping to the named graph itself. I am against 
>>> this because there can be strange bleeding from the default graph to 
>>> the identity of the named graphs, such as in example 2.16 in 
>>> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics
>>> although the analysis there is incorrect.
>>>
>>> if all you are dong is recording named graphs, then why should 
>>> information in the default graph potentially cause two named graphs 
>>> to be smushed together?
>>>
>>
>> How could it not?
>>
>> If I know
>>   <g1> { ... }
>>   <g2> { ... }
>>
>> and if I know, because of some metadata, that g1 and g2 are actually 
>> the same thing, doesn't that imply some kind of smushing or 
>> inconsistency?
>
> Only if you also want the denotations of the graph names to carry 
> meaning related to the named graphs.  I don't see that this is 
> necessary the case.
>

(I'm confused, but it should be cleared up below)

> [...]
>
>>
>> [...] The one thing I can argue for, I think, is that the graph names 
>> be strongly connected to those same names being used in the default 
>> graph.   For example, I think we need to be able to say things like 
>> this:
>>
>>     <http://example.org/d1> { <a> <b> 1 }.
>>     <http://example.org/d1> eg1:lastModified "Wed, 12 Sep 2012 
>> 11:42:31 GMT".
>>
>>
>> where eg1:lastModified is defined such that this dataset conveys the 
>> knowledge that (1) a dereference on URL "http://example.org/d1" was 
>> done; (2) it resulted in (at least?) the triple
>> { <a> <b> 1 }; and (3) the HTTP Last-Modified header returned during 
>> that dereference was the string "Wed, 12 Sep 2012 11:42:31 GMT".
>
> Yes, one might want to say that.  However, where in this is there a 
> need for the IRI to denote the graph?
>

No, not for the IRI to denote the graph -- just some kind of connection 
between the IRI (or whatever the IRI denotes) and the graph.    We just 
need to be able to refer to that connection in defining the metadata 
predicates.


> Further, the minimal semantics doesn't support this well, as its 
> semantics doesn't relate names to actual RDF graphs, only to 
> equivalence classes of RDF graphs.
>

Unhappily true.

> [...]
>
>
>>
>>> I also don't see why excluding useful private ways of doing things 
>>> (particularly ones that might already be in use) is moot.
>>>
>>
>> Well, I think these standards only apply between systems, not within 
>> systems.  Private communications are essentially system-internals, 
>> and none of our business.  Right?
>
> Correct, but if the semantics for RDF datasets rules out some useful 
> private methods then that's not good.
>
>>
>>> I didn't exclude using the default graph to record information about 
>>> the named graphs and their sources.  However, I didn't want 
>>> information in the default graph to affect the situation in the 
>>> named graphs.
>>>
>>
>> My concern/motivation is in my example above.   The semantics need to 
>> be strong enough that eg1:lastModified can be defined to make my 
>> example dataset mean to consumers what the producer wants it to mean.
>>
>> I leave any argument for more powerful semantics to others, who have 
>> other use cases in mind.
>>
>>      -- Sandro
>
> I still don't know what the minimal semantics has to support this use. 

I don't either.   I was kind of hoping you'd see an easy solution for my 
use case, though.  :-)

> If you really want this then don't you need a theory of web retrieval 
> and something in the semantics stating that named graphs are the 
> result of this retrieval?
>

That's for down-the-road, when someone actually wants to define 
eg1:lastModified.  For today, it seems to me we just need to define some 
way that someone CAN define/document an RDF predicate that involves the 
triples in the name graph.

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?

      -- Sandro

> peter
>
>
Received on Tuesday, 18 September 2012 17:46:32 GMT

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