Re: some GRAPHS strawpolls for today (agenda?)

On Apr 27, 2012, at 7:02 AM, Peter F. Patel-Schneider wrote:

> Well, the information expressed in this trig file is:
> - the default rdf graph says that :a is related to :c via :b

OK

> - the graph named g says that :d is related to :f via :e
> That's *all*.

I think the opacity issue is, maybe it says even less than this. Maybe it says only, the graph named g has the triple ":d :f :e" in it. And *that* is all; the document does not even claim that when that graph says ":d" it means (what the rest of us mean when we say) :d .

Pat

> 
> peter
> 
> On 04/26/2012 11:53 AM, Sandro Hawke wrote:
>> I don't know how to make sense of how you're thinking about this.
>> 
>> Can you tell me in English what knowledge you have gained if you learn
>> whatever is expressed in the following trig file:
>> 
>>     @prefix :<http://example.com/>
>>     { :a :b :c }
>>     <g>  { :d :e :f }
>> 
>> ?
>> 
>>     -- Sandro
>> 
>> On Thu, 2012-04-26 at 10:44 -0400, Peter F. Patel-Schneider wrote:
>>> On 04/26/2012 09:48 AM, Sandro Hawke wrote:
>>>> On Thu, 2012-04-26 at 03:26 -0400, Peter F. Patel-Schneider wrote:
>>>>> On 04/25/2012 11:03 AM, Sandro Hawke wrote:
>>>>>> On Wed, 2012-04-25 at 10:38 -0400, Peter F. Patel-Schneider wrote:
>>>>>>> This is all predicated on named graphs participating in entailment, which I
>>>>>>> don't really agree with.
>>>>>> I don't understand how you're looking at this.   Do you have an
>>>>>> alternative solution in mind, and does it address many/most of the use
>>>>>> cases?
>>>>> Yes, the alternative solution is that RDF datasets are data structures, and
>>>>> that entailment is between RDF graphs only.  This does put more into
>>>>> application code, but I prefer that in this case.
>>>> So, trig would just be like JSON -- the meaning depends entirely on the
>>>> context.   No truth conditions.  If I hand you some JSON, it's
>>>> meaningless unless we have a prior arrangement.   If a trusted website
>>>> publishes some trig, there's nothing you can do with it without
>>>> out-of-band information.   Our spec is helpful in that we can share
>>>> parsing/serializing code and some data storage/indexing code.   Do I
>>>> have that right?
>>> No, I don't think so.   RDF would specify that an RDF dataset contains RDF
>>> graphs, and RDF graphs have certain meanings.  However, the relationships
>>> carried by the names would remain unspecified, which is essentially the same
>>> situation as is any of the proposals for named graphs that I have seen so far.
>>> 
>>>>> [...]
>>>>> 
>>>>>> 3. Named graphs are opaque
>>>>>> 
>>>>>>      "<u>     {<a>     <b>     <c>}"  does not entail "<u>     {<a>     <b>     _:x}"
>>>>>>> Absolutely NOT!
>>>>>> I can't tell if you're disagreeing with the entailment or the test case.
>>>>>> 
>>>>>> I think the entailment.
>>>>>> 
>>>>>>       -- Sandro
>>>>> Named graphs should not be opaque.
>>>> Let me ask the classic question, then.  How do we stop our system from
>>>> making a false conclusion from these two facts:
>>>>    - Lois knows Superman can Fly
>>>>    - Clark Kent is Superman
>>>> 
>>>> More formally, given this, which is true:
>>>> 
>>>>    :loisKnowledge { :obj1 a :FlyingThing; name "Superman".
>>>>                     :obj2 a :NonFlyingThing; name "Clark Kent". }
>>>> 
>>>> and this, which is also true:
>>>> 
>>>>     :obj1 owl:sameAs :obj2
>>>> 
>>>> what stops us from being licensed to conclude
>>>> 
>>>>     :loisKnowledge { :obj2 a :FlyingThing; }
>>>> 
>>>> ?
>>>> 
>>>> I suppose this whole question is malformed to you, because datasets to
>>>> you don't have truth conditions, we can't say it "is true" like I did.
>>>> We might just as well have said (give or take namespace expansion):
>>>> 
>>>>     { ":loisKnowledge" : ":obj1 a :FlyingThing; name 'Superman'.  :o, 2009},bj2
>>>> a :NonFlyingThing; name 'Clark Kent'." }
>>>> 
>>>> (that's JSON).   And what you do with that is totally up to you, and
>>>> you're own responsibility -- the spec gives you no license to do
>>>> anything but parse it.  If you want to do inference, you need to get
>>>> that license from elsewhere.
>>>> 
>>>> That strikes me as not nearly as useful as having semantics, but I
>>>> probably can't explain why before my next meeting.   I assume it's the
>>>> same reason as why RDF has semantics -- namely so that we can each
>>>> maintain our own bits of a global knowledge base and still be able to
>>>> merge it together, without billions of separate agreements.
>>>> 
>>>>       -- Sandro
>>>> 
>>> Well, actually your question didn't have anything to do with "opaque" or
>>> "transparent", which have to do with the relationship between names inside a
>>> context and those outside.  I thus probably should not have used "opaque" in
>>> my answer, instead simply saying that if you want to have entailments here
>>> then the entailment should hold.
>>> 
>>> Your example here has very little to do with your initial question, although
>>> it certainly has lots to do with opacity or transparency of contexts.
>>> 
>>> I think that your argument makes clear why I don't want entailment to consider
>>> RDF datasets.  Even if you want datasets to participate in entailments, the
>>> meaning of the relationship between contexts is what determines whether you
>>> want opacity or transparency.  This also is an argument against having bnodes
>>> with file scope - bnodes should remain scoped to an RDF graph.
>>> 
>>> peter
>>> 
>>> 
>> 
> 
> 

------------------------------------------------------------
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 Saturday, 28 April 2012 21:29:08 UTC