Re: some GRAPHS strawpolls for today (agenda?)

On Apr 26, 2012, at 9:44 AM, 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.

Well, the original paper specified that if the graph G was named <u>, then all RDF interpretations I of any vocabulary containing <u> had I(<u>) = G. In other words, the name of a named graph is a rigid designator of the graph named. (Actually I think it specified that I(<u>) = < <u>, G> but I now think that was a mistake.) That doesnt seem unreasonable to me, I have to say: it seems like a minimal semantics for the very idea of 'naming'. 

>>> [...]
>>> 
>>>> 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.

For the record, I don't agree with any of this. I dont see anything wrong with considering entailment between datasets, and even between datasets and graphs, if we can get the semantics right. It is surely obvious that there is very little to meaningfully distinguish an RDF graph from a dataset with no named graphs and one default graph.  And scoping blank nodes is purely a syntactic matter, and we can do it any way we want. Document scoping makes perfect sense. (I think its a bad idea for other reasons, though.)

Pat

> 
> 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:37:33 UTC