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

Re: [GRAPH] graph deadlock?

From: Steve Harris <steve.harris@garlik.com>
Date: Wed, 21 Dec 2011 23:42:30 +0000
Cc: W3C RDF WG <public-rdf-wg@w3.org>
Message-Id: <D1144D04-FBC7-4F94-9BFB-74D4FB6B2F40@garlik.com>
To: Pat Hayes <phayes@ihmc.us>
OK, that all seems reasonable, thanks.

- Steve


On 21 Dec 2011, at 01:51, Pat Hayes wrote:

> 
> On Dec 20, 2011, at 2:55 PM, Steve Harris wrote:
> 
>> On 20 Dec 2011, at 18: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. 
>>> 
>>>> 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?) The answer seems to be, sometimes they do (of course) and sometimes they don't (of course), but nothing records which case is which. And I object to that situation, as it produces faux-RDF which is designed to be systematically ambiguous in meaning. 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. 
>> 
>> Well, what if we say that URIs appearing in the 4th position should mean the same thing as ones appearing in the other positions, but then some people ignore it?
> 
> Fine by me. The spec can't change what people actually do, it can just make clear when they are disobeying the rules. What happens then is not defined and if its bad, then it is liable to be their fault (unless they work for a very large company).

OK, seems reasonable.

>> I think most(?) people agree that a URI should denote/name/something a graph, or some other entity, but not both at the same time. The problem is that people don't follow this rule in RDF now*, don't follow it in quads as implemented now, and I don't think they will follow it in the future.
>> 
>> So, does that break RDF, or does it break their applications?
> 
> Well, it apparently mis-uses RDF, but maybe that doesnt matter in their applications, and if so, then its not something that we as a WG need to be concerned with. 
> 
>> 
>> If it just breaks people's applications, then we can write what we would like to happen in the document, and people who do the Right Thing™ will be fine, and people who don't will suffer in some way.
> 
> Or not, as the case may be :-)
> 
>> 
>> If on the other hand it breaks RDF, it's probably already too late, and we have a problem.
>> 
>> - Steve
>> 
>> * e.g. http://blog.iandavis.com/2010/11/04/is-303-really-necessary/
>> 
>>>>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> -- 
>> Steve Harris, CTO, Garlik Limited
>> 1-3 Halford Road, Richmond, TW10 6AW, UK
>> +44 20 8439 8203  http://www.garlik.com/
>> Registered in England and Wales 535 7233 VAT # 849 0517 11
>> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
>> 
>> 
>> 
> 
> ------------------------------------------------------------
> 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
> 
> 
> 
> 
> 
> 

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Wednesday, 21 December 2011 23:43:01 GMT

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