Re: some GRAPHS strawpolls for today (agenda?)

Well, the information expressed in this trig file is:
- the default rdf graph says that :a is related to :c via :b
- the graph named g says that :d is related to :f via :e
That's *all*.

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
>>
>>
>

Received on Friday, 27 April 2012 12:03:17 UTC