Re: New Proposal (6.1) for GRAPHS

On Mon, 2012-04-02 at 21:46 +0100, Andy Seaborne wrote:
> Take 2:
> 
> (pressed "send",  not "save" ... sigh ...) try again:
> 
> On 02/04/12 16:36, Sandro Hawke wrote:
> > On Thu, 2012-03-29 at 09:25 -0700, Charles Greer wrote:
> >> I really like this solution and it seems to satisfy the use cases
> >> familiar to me from when I actually worked a lot with RDF in the wild.
> >>
> >> One thing I'm tripping over though --  The scope of a TRIG document or
> >> RDF dataset in effect 'closes the world.'  Is the idea of "merge" only
> >> within a TRIG document/dataset?
> >>
> >> I can only see two ways to really assert a graph literal -- either by
> >> sanctifying the boundaries of  a dataset, thereby making merges with
> >> external data problematic, or by signing bytes.  Am I missing something,
> >> as usual?
> >
> > There's some misunderstanding here, yes.   Maybe you can talk through
> > some particular thing you imagine doing, involving merging and TriG, and
> > I'll be able to pick it up.   From what you've written, I'm confused.
> >
> > Maybe I can clarifying by translating this TriG document:
> >
> >          <u1>   {<a>   <b>   <c>  }
> >
> > into this English declaration:
> >
> >          The URI 'u1' denotes something, and that thing has exactly one
> >          associated RDF Graph.   That associated RDF graph consists of
> >          one RDF triple, which we can write in turtle as "<a>  <b>  <c>".
> 
> 
> Clearer, but not what I would have expected.
> 
> Why "exactly one associated RDF Graph"?

My intuition is that there are important thing you can't do if you allow
more than one graph to be associated with the named object, but I
haven't really explored that because SPARQL datasets clearly allow only
one GRAPH for a given name, so I figured we'd stick with that.  That's
why I said hasGraph was a functional property.

(And just to be clear to people reading along, I mean the word
"functional" in the sense of maxCardinality 1, having at most one
distinct value.  cf
http://www.w3.org/TR/owl2-syntax/#Functional_Object_Properties )

> RDF is all about partial descriptions of things.
> 
> If
>    <u>  { <a>   <b>   <c> . <x>   <y>   <z> . }
> 
> then I'd have expected
>    <u>  { <a>   <b>   <c> }
> and also
>    <u>  { <x>   <y>   <z> . }

Several people have suggested that reading, but I think it's less
useful.

To rephrase your point, we could define it so 

        <u1>   {<a>   <b>   <c>  }
        
means:

        The URI 'u1' denotes something, and that thing has exactly one
        associated RDF Graph.   That associated RDF graph has a
        subgraph.  That subgraph consists of one RDF triple, which we
        can write in turtle as "<a> <b> <c>".
        
This is weaker, because it means we can't say what the associated graph
is, we can only say what subgraphs of it are.

With the stronger approach, you can always express that kind of subgraph
knowledge using a subgraph predicate.   Your example of a graph <u> that
contains at least { <a>   <b>   <c> .  <x>   <y>   <z> . } could be
written in the stronger semantics with a defined subGraphOf predicate:

  { _:x eg:subGraphOf <u> }
  _:x { <a>   <b>   <c> .  <x>   <y>   <z> . } 

So, _:x is exactly the graph of those two triples, and it's a subgraph
of <u>.   So, that says what your example said.

You can't go the other way, though.  If the syntax has the subGraphOf
semantics, I don't know how you could say "and only those triples".
That's why I propose the semantics of trig be the "exactly these
triples" semantics.

> I guess the concrete examples will help - the choice of URI scheme for
> <u> and it's scope becomes very important - it's be clearer to me 
> exactly what is being labelled and how.

Hrm.   I'm not following this bit.

> > So, perhaps it's more clear, now.  If you merged that with another TriG
> > document:
> >
> >          <u1>   {<a>   <b>   <d>  }
> >
> > Then, trying to accept both documents at onces, you'd be saying:
> >
> >          The URI 'u1' denotes something, and that thing has exactly one
> >          associated RDF graph.  In one document that associated graph is
> >          claimed to be the RDF triple "<a>  <b>  <c>", but in another
> >          document that graph is claimed to be the RDF triple "<a>  <b>
> >          <d>".
> >
> > So, in this case, you can try to merge the documents, but when you do,
> > you find there is a contradiction, since there is only allowed to be one
> > associated graph, but in this case there are two different ones.
> 
> Technical point: even if they are unique graphs, isn't the right conclusion:
> 
>     <c> owl:sameAs <d>  .

No, I don't think so...

> unless the "{ ... }" is and not a graph itself, but, say, a
> representation of a graph, or is it that, they are not equal as
> literals, considered as a set of triples with no interpretation.

Right.  The {...} expression evaluates to an RDF Graph, which is a
syntactic construct - a set of RDF triples.   Two graphs are equal if
those two sets contain the same elements.    Even if <c> owl:sameAs <d>,
the graphs you get from parsing the turtle documents "<a> <b> <c>" and
"<a> <b> <d>" are different.

> But if everything is quoted, nothing is ever equal.  Workable, but a
> completely different architecture from the ground up - it's like having
> only reified statements.

It's funny, that was my reaction to SPARQL when I first saw it.  I was
shocked that SPARQL graph matching was on the RDF abstract syntax
instead of being logical unification, where terms would match if they
were logically equal.

But I've come to see that it makes sense to have the bottom layer just
be direct manipulations of RDF graphs.  Then we can add various
entailment regimes later.

I should perhaps note that N3 explored all this.  log:semantics relates
a web Resource to the graph you get by parsing it.   log:includes is the
hasSubgraph relation.   log:conclusion relates a graph to the union of
the graphs it entails.

   -- Sandro

Received on Tuesday, 3 April 2012 00:27:28 UTC