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

Re: [GRAPH] graph deadlock?

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 21 Dec 2011 11:18:14 +0000
Message-ID: <4EF1C076.2060006@epimorphics.com>
To: public-rdf-wg@w3.org


On 21/12/11 08:53, Ivan Herman wrote:
>
> On Dec 20, 2011, at 19:45 , Pat Hayes wrote:
>
>>
>> On Dec 20, 2011, at 2:29 AM, Ivan Herman wrote:
>>
>>> Pat,
>>>
>>> On Dec 20, 2011, at 05:45 , Pat Hayes wrote:
>>>
>>> [skip]
>>>
>>>>
>>>> Now, consider the case where a URI  UUU is used as a graph
>>>> label in a dataset, and also occurs in the RDF inside a graph
>>>> in that same dataset, where it is interpreted as denoting, say,
>>>> a human being or a mailbox. OK so far. Now, however, add the
>>>> dataset some more RDF (perhaps in the default graph used to
>>>> express some metadata, for example) in which that same URI is
>>>> intended to be used to refer to the graph that it labels. There
>>>> are *no* RDF interpretations in which a single URIref can
>>>> denote two different things. So this dataset as a whole has no
>>>> satisfying interpretations. So it is formally inconsistent.
>>>> Moreover, the inconsistency arises directly, and obviously,
>>>> from this usage in which a URI is used to "name" something
>>>> other than what everyone agrees it is in fact interpreted to
>>>> mean (as, vividly, in Ivan's example using an email address).
>>>> And this is, surely, *obviously* at odds with the basic
>>>> assumption of the entire Web, that URIs, when considered as
>>>> names, identify *one* thing.
>>>>
>>>
>>> is 'labeling' and 'identifying' the same?
>>
>> Well, maybe not. But I suspect that if we try to say this, nobody
>> will take the slightest notice. They certainly sound like they
>> ought to be very closely related, so closely that only philosophers
>> could distinguish them, and then only when there is an R in the
>> month.
>
> :-)
>
>> And by the way, SPARQL talks about these URIs *naming* the graph,
>> which sounds even more like identifying.
>
> So we indeed have a naming (sic!) issue. Indeed, SPARQL uses the term
> 'naming' for what I referred to as datasets. That is mess that,
> unfortunately, we have to live with it:-(


Specifically, the SPARQL Query spec says about the FROM NAMED syntax
"""
The FROM NAMED syntax suggests that the IRI identifies the corresponding
graph, but the relationship between an IRI and a graph in an RDF dataset
is indirect. The IRI identifies a resource, and the resource is
represented by a graph (or, more precisely: by a document that
serializes a graph). For further details see [WEBARCH].
"""

The RDF dataset definition is more general.

"""
Definition: RDF Dataset

An RDF dataset is a set:

    { G, (<u1>, G1), (<u2>, G2), ... (<un>, Gn) }

where G and each Gi are graphs, and each <ui> is an IRI.
"""

It adds:
"""
Each <ui> is distinct.G is called the default graph. (<ui>, Gi) are 
called named graphs.
"""
which I'd prefer, in hindsight, to drop or at least move out of the 
definition.

It adds nothing that affects the rest of the definition of SPARQL.  I'd 
even argue that it was "editorial", not "substantial", to the definition 
of SPARQL so does not invalidate the last call.

> For the sake of the discussion we may have to use different terms,
> and let us forget about SPARQL for a while.

Oops :-)

>  Although I do not have
> the Sandro's talent of finding nice terms, let us say that we speak
> about labelled graphs, i.e., datasets, and identified graphs. Let us
> not use the term named graphs for a while...
>
> - Labelled graphs are the minimal level, ie, just using URI-s
> labeling graphs. We may have to add a restriction that, within a
> dataset, labels are unique, ie, two different graphs must have two
> different labels. No further assumptions are used. And, to refer to
> an earlier quote of yours up there, the labels used that way would
> take no part in any form of RDF interpretation whatsoever.
>
> - Identified graphs are labelled graphs where there _is_ a relation,
> through HTTP GET, between the label and the graph.
>
> I fully understand your bad feeling about labelled graphs. I share
> it. But we have to accept that, out there, lots of applications are
> based on that notion, ie, they attach labels to graphs without any
> sort of further check and assumption. What I am saying is that
> documenting and making clear the limitation of those states have a
> value. And application may choose to stay on that level. We may (we
> probably should...) try to promote the notion of identified graphs as
> being more 'webby', hence we need to define them properly, but that
> is defining some sort of an ideal world...

This is a promising way forward.

>>
>>> My non-semantics dataset view talks about labeling only.
>>> 'Indexing' may be another term.
>>>
>>> I come back to the quad store example. I do not believe that quad
>>> stores make any assumption, by default, to the behaviour of the
>>> URI-s in the 4th column, they are just 'there'.
>>
>> Fine. But when they also occur in the (say) 3rd position, do they
>> or do they not then mean the same as they meant when they occur in
>> the fourth position? (Or maybe: does what they mean in the 3rd
>> position have any relationship at all to their role while
>> being-there in the fourth position?)
>
> If the quad store implements a labelled graph than the answer is no.
> More exactly, an application should have no assumption that they do.
>
>> The answer seems to be, sometimes they do (of course) and sometimes
>> they don't (of course), but nothing records which case is which.
>
> Right. A quad store, or an application thereof, might declare that it
> uses labelled or identified graphs. Well.. probably should/must and
> not might.
>
>
>> And I object to that situation, as it produces faux-RDF which is
>> designed to be systematically ambiguous in meaning.
>
> And I hear your objection. Today an application or a quad store has
> no means to say which way it goes. Hence the mess... That is the
> absolute minimal step that I would like to make to try to clarify
> things. That is all...
>
> Ivan
>
>
>> And we can blather about "contexts" for ever, but until this notion
>> is made reasonably precise, all such talk is indeed just blather. I
>> have been to several workshops on 'contexts' where *every single
>> speaker* had a different notion of what the word 'context' meant.
>>
>> Pat
>>
>>>
>>> Ivan
>>>
>>>
>>>
>>>
>>>>>
>>>>> When you say “this is illegal in RDF” then I think this has
>>>>> to be read as “I don't like it”.
>>>>
>>>> No, I mean it violates the semantic assumptions of the
>>>> (normative) RDF model. I might suggest that when you say "It
>>>> isnt illegal", this has to be read as "I havnt understood the
>>>> semantics spec."
>>>>
>>>>>> 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.
>>>>
>>>> They have no semantics because they dont need any semantics. If
>>>> a list had a semantics, it would describe the list. Those are
>>>> basically LISP S-expressions coded into RDF triples: they
>>>> *exhibit* the required structure rather than *describe* it.
>>>>
>>>> But I agree, we could indeed not give semantics to new parts.
>>>> The sticking point, however, is that this particular 'new' part
>>>> is already using the 2004 RDF semantics, but it is using it
>>>> incorrectly.
>>>>
>>>> Pat
>>>>
>>>>>
>>>>> Best, Richard
>>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> IHMC                                     (850)434 8903 or
>>>> (650)494 3973 40 South Alcaniz St.           (850)202 4416
>>>> office Pensacola                            (850)202 4440
>>>> fax FL 32502                              (850)291 0667
>>>> mobile phayesAT-SIGNihmc.us
>>>> http://www.ihmc.us/users/phayes
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
>>> http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF:
>>> http://www.ivan-herman.net/foaf.rdf
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------ IHMC
>> (850)434 8903 or (650)494 3973 40 South Alcaniz St.
>> (850)202 4416   office Pensacola
>> (850)202 4440   fax FL 32502                              (850)291
>> 0667   mobile phayesAT-SIGNihmc.us
>> http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>
>
> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
> http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF:
> http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>
Received on Wednesday, 21 December 2011 11:18:41 GMT

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