Re: complete vs partial graph semantics

I'm having a lot of trouble understanding the motivation for
partial-graph semantics.   It seems to me like a kind-of-cool but
way-too-complicated idea.

It's like you're saying that any triple:

    <a> <b> 7.

is to be understood as saying that the value of the 'b' property of 'a'
is not just seven, but rather it is seven-or-more.

You see the analogy?    To me,

   <u>  { <a> <b> <c> }

looks like tagging the graph { <a> <b> <c> } with the label <u>; but now
I'm being told you're actually tagging some unknown graph that happens
to contain at least the triple { <a> <b> <c> }.   

So, back to the number analogy: it seems like the reason people want to
to do this is because they sometimes want to increase the value of this
property.   Later they might want to say it's ten-or-more.  There seems
to be some concern that this could be a problem if we said that it was
now exactly seven.

I'm starting to suspect that what people want for partial semantics is
actually:

   <u>  +=  { <a> <b> <c> }

That is, instead of saying the graph labeled <u> is some graph that
happens to contain <a> <b> <c>, they want to say the graph is hereby
modified to also include <a> <b> <c>.   In particular, I think I'm
hearing that kind of thinking in how Lee talks about it.   

There's not necessarily anything wrong with this -- it's a whole lot
simpler to understand and implement than partial-graph semantics, I
think.   But, by being imperative, it does have different properties
than a declarative design.

FWIW, I'm also reminded by this of open lists.   If you have an rdf List
with a first of 1, and a rest which isn't specified, then someone can
come along later and say what the second item is.  And they can close it
off, or still live it open --- all without changing/removing any
triples.  This technique is used in Prolog programming; I'm not sure
it's useful in RDF.

   -- Sandro





On Thu, 2012-04-12 at 12:49 +0100, Andy Seaborne wrote:
> >> The critical issue is what happens on the default case of no information.
> 
> Williams comments overtake this but anyway ...
> 
> > Put differently, as a test case:
> >
> > Trig Document 1 (D1):
> >      <u>  {<a>  <b>  1 }
> >
> > Trig Document 2 (D2):
> >      <u>  {<a>  <b>  2 }
> >
> > What is the merge/union of D1 and D2?
> >
> > OPTION 1:
> >
> >          It's a contradiction.  You can't merge D1 and D2.
> 
> Can't support.
> 
> (and there is a potential denial-of-service attack :-)
> 
> > OPTION 2:
> >
> >          Merge the graphs, producing Trig Document 3:
> >
> >          <u>  {<a>  <b>  1,2 }
> 
> +1
> 
> The current situation, or as close as we can determine it.
> 
> > OPTION 3:
> >
> >          It depends.  Use out-of-band information.   I argued against
> >          this in my email to Arnaud yesterday, and seemed to convince
> >          him.
> >          http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0054.html
> >
> > OPTION 4:
> >
> >          It's not defined, when asked like this.  We use something
> >          Trig-Like but different:
> >
> >            D1A<u>  {+<a>  <b>  1 }
> >            D2A<u>  {+<a>  <b>  2 }
> >          in which case the merge is:
> >            D3A<u>  {+<a>  <b>  1,2 }
> >
> >          ==or==
> >
> >        D1B<u>  {=<a>  <b>  1 }
> >        D2B<u>  {=<a>  <b>  2 }
> >      in which case there is no merge; they are inconsistent.
> 
> OPTION 5:
> 
> {= ...} is complete
> {...} is partial -- current situation is "partial"
> 
> As a general syntax comment though, it would be far better if the 
> additional information were in triples, not in specialised syntax.  It 
> means the facts can be passed onwards.
> 
> Where do they go?
> 
> The default graph is one possibility (but that might have other uses).
> 
> Another is a meta graph or manifest so a TriG file has a defailu graph, 
> a meta graph and labelled graphs.  The meta graph has the relationship 
> information.
> 
> {= ...} might be syntactic short-hand.
> 
> 
> (I think one aspect of the difficulties around HR14 is that the 
> information revealed by 200 vs 303 is not in the data.)
> 
>  Andy
> 
>

Received on Thursday, 12 April 2012 15:10:02 UTC