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

Re: some GRAPHS strawpolls for today (agenda?)

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 26 Apr 2012 09:48:55 -0400
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: public-rdf-wg <public-rdf-wg@w3.org>
Message-ID: <1335448135.9663.462.camel@waldron>
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?

> [...]
> 
> >
> > 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'.  :obj2
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
Received on Thursday, 26 April 2012 13:49:09 UTC

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