Re: some GRAPHS strawpolls for today (agenda?)

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 Thursday, 26 April 2012 15:53:35 UTC