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

Re: opacity

From: David Wood <david@3roundstones.com>
Date: Wed, 29 Feb 2012 09:31:37 -0500
Cc: Pat Hayes <phayes@ihmc.us>, Andy Seaborne <andy.seaborne@epimorphics.com>, Ivan Herman <ivan@w3.org>, RDF-WG <public-rdf-wg@w3.org>
Message-Id: <3FEF9C9A-2DC5-4999-A56A-DF5C705E6A19@3roundstones.com>
To: Sandro Hawke <sandro@w3.org>
On Feb 29, 2012, at 08:14, Sandro Hawke wrote:

> On Tue, 2012-02-28 at 21:26 -0600, Pat Hayes wrote:
>> On Feb 28, 2012, at 4:26 PM, Sandro Hawke wrote:
>> 
>>> On Tue, 2012-02-28 at 12:52 -0600, Pat Hayes wrote:
>>>> On Feb 28, 2012, at 10:19 AM, Andy Seaborne wrote:
>>>> 
>>>>> Pat,
>>>>> 
>>>>> The fact you can have
>>>>> 
>>>>> :g1 { :Joe :age 10 }
>>>>> :g2 { :Joe :age 30 }
>>>>> :g3 { :age a :FunctionalProperty }
>>>>> 
>>>>> is the point.
>>>> 
>>>> No. Of course you CAN have this. (Just look: there it is, above.) The semantic issue is, is this *consistent*? 
>>> 
>>> I'm a big fan of logical consistency in RDF on the Web, and doing all
>>> the reasoning we can, ...   and I find this document to be logically
>>> consistent.  I read it as an assertion about three RDF graphs and some
>>> terms which are being used to label them.   Something like this, in FOL
>>> with equality and RDF-like terms:
>>> 
>>> graph(:g1) = :age(:Joe, 10)
>>> graph(:g2) = :age(:Joe, 30)
>>> graph(:g3) = :FunctionalProperty(:age)
>>> 
>>> or in English as:
>>> 
>>> There are three graphs, labeled g1, g2, and g3.  The first, g1, consists
>>> of a single triple, Joe age 10.  The second, g2, etc...    
>> 
>> OK, fine. That treats it as something rather like a compact way of writing a reification, ie as metadata. But then the interpretations of the RDF graphs are irrelevant and indeed play no role in the semantics of this (let me call it) meta-TriG. We could take this route, but its nothing at all like anything that has been suggested so far. So now we have three ideas floating around :-)
> 
> Yes, I thought it was in line with AZ's at the time I wrote it, but now
> I see he has a looser labeling connection.
> 
>>> It's like if I told you:   "Eric says the Earth is flat and Peter says
>>> the Earth is round."  
>> 
>> Sorry, but I have to ask, is that understood in a de dicto or a de re sense? Put into English, when you say "Eric says ....", are you using the words inside the "..." in Eric's way or in the publicly accepted way?  It matters (a lot) which you mean, when Eric's views of things are out of whack with the way other people use the language. (Maybe what Eric means by "flat" is what other people call a sphere, in which case they don't disagree about any matters of fact.) And we have to write the semantics differently depending which is the right way. (I feel tender about this. When we were doing the semantics for reification in RDF, I gave it a "de re" meaning, which assumes that the URIs inside the reified triples refer in the same way as those outside, and TimBL hauled me over the coals for getting that wrong.)
> 
> I'm not attached to either answer at this point.  I think there is a
> strong use case for de dicto functionality, but I think it can be
> provided with strings holding RDF graph serializations, if it's not
> provided by the multigraph syntax.


That's interesting.  I understood Andy's proposal to be strongly de re.

Regards,
Dave


> 
> FWIW, the term I'm used to for this is "referential opacity" or "opaque
> context", as in http://en.wikipedia.org/wiki/Opaque_context .  The
> example I see used most often is the Superman one, which we might write
> as:
> 
>    :Lois :believes { :Superman a :PersonWhoCanFly }
>    :Superman owl:sameAs :ClarkKent
> does-not-entail
>    :Lois :believes { :ClarkKent a :PersonWhoCanFly }
> 
> I do lean toward de dicto / opacity.  The encoding of RIF into RDF puts
> symbols into strings to make them opaque.  See
> http://www.w3.org/TR/rif-in-rdf/ .   For RDF reification it could be
> like:
> 
>    :Lois :believes [ a :Triple;
>                      :subjectURI "http://example.org/Superman";
>                      :predicateURI "http://www.w3.org/1999/02/22-rdf-syntax-ns#type";
> 		      :objectURI "http://example.org/PersonWhoCanFly". ].
> 
> 
> FWIW, I suppose RIF provides another candidate for solving the
> multigraph problem.   Since an RDF Graph is a kind of RIF Sentence, and
> RIF documents can hold multiple independent and identified-by-URI
> Sentences, one could just use a RIF document as an RDF multigraph
> document.   
> 
> It's a damn shame we never produced a Turtle-like syntax for RIF.   Both
> the XML syntax and the RDF encoding are too verbose for everyday use by
> humans.
> 
>>> Now, Eric's statement is not consistent with
>>> Peter's statement, but *my* statement is self-consistent.
>>> 
>>> I see a TriG document (or a dataset) as being almost entirely metadata.
>>> The given TriG example conveys data about some triples, not directly
>>> about Joe.
>>> 
>>> This is, of course, much clearer in N3, where we'd write it more like:
>>> 
>>> :g1 owl:sameAs { :Joe :age 10 }.
>>> :g2 owl:sameAs { :Joe :age 30 }.
>>> :g3 owl:sameAs { :age a :FunctionalProperty }.
>>> 
>>> (that's three RDF triples)
>> 
>> Yes, I like that too, but I thought (??) that we had formally decided that the "labels" in a SPARQL dataset do not necessarily actually denote the graphs they are the "name" of, so this won't work for us. (Do I have this right? At one time this was a very contentious point and I agreed to it reluctantly.) 
> 
> People have argued strongly about it, but I don't believe any decision
> has been made.
> 
> My position has been that we need to work back from a small and
> representative set of use cases to come up with one or more designs that
> make sense, not worrying much about backward compatibility during that
> process.  I'm fairly confident that when we have a design that makes
> sense for our use cases, there will be some reasonable way to make it
> co-exist with deployed SPARQL, eg by using some kind of flags in
> metadata or something.
> 
>    -- Sandro
> 
>> Pat
>> 
>> 
>>> 
>>> or
>>> 
>>> :g1 eg:labelFor { :Joe :age 10 }.
>>> :g2 eg:labelFor { :Joe :age 30 }.
>>> :g3 eg:labelFor { :age a :FunctionalProperty }.
>>> 
>>> depending how you want to read the label/graph relation in Trig
>>> 
>>>   -- Sandro
>>> 
>>>> Does it have a satisfying interpretation? And the  answer we want, surely, is no, it is not consistent. That does not mean that we have to do anything in particular about it, unless we want to restore consistency somehow, of course, but then we are presumably doing that because, in part, we know that there is an inconsistency there to be resolved.
>>>> 
>>>>> It's not about graph consistency until the app decides it wishes to apply RDF machinery to some combination of :g1 :g2 and :g3.
>>>> 
>>>> The semantics does not mandate what anyone actually does. Its only purpose is to specify what consistency, entailment, etc. *actually mean* in RDF. With the proposed semantics for datastores, this store is actually consistent, so there is nothing to resolve. Which, I submit, is ridiculous. 
>>>> 
>>>> I think what you mean is, you don't care about the inconsistency until some machinery decides it wants to combine these three statements into a single trusted source (and call that an RDF graph). Which is fine; but that doesnt mean the the inconsistency isn't there. Nor does it mean that these triples change their meaning when they are put into a single RDF graph. 
>>>> 
>>>>> How it does that is not spec'ed - it would be nice if it were, but given timescales, state of the art, etc, it's where the deployed semweb currently is.
>>>>> 
>>>>> Would you prefer it if we said that a TriG had no interpretation, that it was just a transport format?
>>>> 
>>>> Im realizing that datastores are being used for very different purposes. Some of them need a semantic extension, some of them dont need any semantics at all beyond the 2004 version. If this is right, then we ought to clearly distinguish these cases, and maybe TriG should be reserved for one of them and not the other. Details to follow shortly in another email.
>>>> 
>>>> Pat
>>>> 
>>>>> 
>>>>> 	Andy
>>>>> 
>>>>> On 28/02/12 15:36, Pat Hayes wrote:
>>>>>> 
>>>>>> On Feb 28, 2012, at 3:45 AM, Ivan Herman wrote:
>>>>>> 
>>>>>>> Pat,
>>>>>>> 
>>>>>>> I need explanation, 'cause I am lost, I am not ashamed to say that...
>>>>>>> 
>>>>>>> 
>>>>>>> On Feb 27, 2012, at 22:42 , Pat Hayes wrote:
>>>>>>> [snip]
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The use of a URI for a graph label in two different trig documents should mean the same thing but combining two datasets, like combining two graphs, will involve an application deciding that is can be done.
>>>>>>>> 
>>>>>>>> But how will it? ANY two graphs are semantically consistent, on this account,
>>>>>>> 
>>>>>>> If my understanding of [2] is correct, each graph must be, individually, consistent according to the RDF Semantics, ie, has to have a proper model. The models may be different for two different graphs with different labels, but I do not understand what you say...
>>>>>> 
>>>>>> I should have said, any two graphs are consistent *with one another*. Put another way, there cannot be an inconsistency between something said on one graph and something said in a different graph. For example, suppose one graph says that :Joe :age '10'^^xsd:number and another graph says that :Joe :age '33'^xsd:number and a third graph says (in OWL) that :age is a functional property. Something wrong here, right? But no, not according to the proposed semantics. Put these three graphs into a single trig document, and this document has an interpretation, so it is consistent. So there is no inconsistency to be resolved: everything is fine, according to this semantics.
>>>>>> 
>>>>>>>> and two graphs (with different labels) NEVER entail any graph larger than either of them (such as their merge, for example), according to the semantics in [2].
>>>>>>> 
>>>>>>> Again, I do not understand why. If two graphs have the same label, then their merge, with the same label, is entailed, again by [2].
>>>>>> 
>>>>>> With the same label, yes. I said, two graphs with different labels. If I put two copies of a graph into a single trig document with two different lables, one of the copies does not entail the other, even though they are the same graph.
>>>>>> 
>>>>>> Pat
>>>>>> 
>>>>>>> 
>>>>>>> Ivan
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> So all semantic relationships are reduced to triviality, so there can be no criteria available to check for acceptability on any semantic grounds. Remember, *every* URI might mean sometjhing completely different in another graph, so you can't say things like one graph says that x:joe is age 10 and the other says he is age 12: that URI might refer to Joe in one graph and Susan in the other, and the URI for the age property might mean age in one graph and being-a-handle-of in the other. Graphs become black holes of meaning, without any way for anything inside to influence or connect with anything outside.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Islands aren't named or formally recognized - and one apps view of "usable together" may not be the same as another apps.
>>>>>>>> 
>>>>>>>> Oh what a tangled Web we weave.... (Sorry, couldnt resist :-)
>>>>>>>> 
>>>>>>>> Pat
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 	Andy
>>>>>>>>> 
>>>>>>>>> [1] http://www.bbc.co.uk/doctorwho/dw
>>>>>>>>> [2] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------
>>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> ------------------------------------------------------------
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> ------------------------------------------------------------
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
Received on Wednesday, 29 February 2012 14:32:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:03 UTC