Re: some GRAPHS strawpolls for today (agenda?)

On Fri, 2012-04-27 at 08:02 -0400, Peter F. Patel-Schneider wrote:
...
> >      { :a :b :c }
> >      <g>  { :d :e :f }
...
> 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*.

So, modulo some details about what we mean by "graph", I agree, except
that I would add:

   - :a is related to :c via :b

(This is what I phrased as "the default graph is asserted")

I don't think this is inherent in TriG, but I think it's a reasonable
reading, and very practical.  Without this, how could you convey
maching-readable metadata in TriG?    I've thought about a few other
options, and came back to this.

Coming back to opacity-vs-transparency:

As you say:
  - the graph named g says that :d is related to :f via :e

If we also know, somehow, that :c = :d, does it follow that:
  - the graph named g says that :c is related to :f via :e
?

I don't think so, and that's what I mean when I say I think named
graphs are opaque.

    -- Sandro


> 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 14:28:48 UTC