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

Re: some GRAPHS strawpolls for today (agenda?)

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 26 Apr 2012 10:44:33 -0400
Message-ID: <4F995F51.5030900@gmail.com>
To: Sandro Hawke <sandro@w3.org>, "public-rdf-wg@w3.org >> public-rdf-wg" <public-rdf-wg@w3.org>


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 Thursday, 26 April 2012 14:45:10 UTC

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