Re: complete vs partial graph semantics

Hi all,

On Apr 12, 2012, at 14:06, Pat Hayes wrote:

> On Apr 12, 2012, at 8:09 AM, Sandro Hawke wrote:
> 
>> 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.
> 
> OK, let me motivate it by providing a different intuition. You have been consistently thinking of the graph label as being an actual name for the graph (the one it is next to in the TriG document, that is), or at any rate for some graph or other which is closely related to the graph. That is, the graph name denotes a graph.  But going back to the intuitions built into Antoine's semantics, it is more natural there to think of the label as identifying not the graph itself, but a context within which to interpret the graph; and then, it is both natural and semantically valid to infer the merge of two graphs with the same label. 
> 
> I think that this may be a fundamental split between two intuitions about what the graph "name" really names, and that this split may be irreconcileable; and the test case is
> 
> <u> { <a> <b> <c> }
> <u> { <d> <e> <f> }
> 
> are consistent and together entail ??
> 
> <u> ( <a> <b> <c>
>           <d> <e> <f> }
> 
> A: No when <u> names the graph, yes when it names some kind of larger interpretation context. 

It seems to me that the motivation of partial semantics could be made by making a concrete example:

Trig Document 1 (D1):
   <u> { <#sandro> <foaf:knows> <#ivan> }

Trig Document 2 (D2):
   <u> { <#sandro> <foaf:knows> <#andy> }

So, using Pat's contexts (*without* using the term "graph" for anything, because it is still confusing), the union of the graphs makes sense to me:

<u> { <#sandro> <foaf:knows> <#ivan>, <#andy>) }

That's similar to what Andy wrote in [1], but maybe a bit stronger to make the point.

Now, one SHOULD NOT (in RFC 2119 sense) do that with:

<u> { <#measurement> <ex:equals> "7" }
and
<u> { <#measurement> <ex:equals> "4" }

...but the ability to be mistaken and lie like that is just the flexibility that we want in RDF.  Any greater attempt to enforce a version of the truth risks shackling the user community in ways that will both violate our use cases and restrict adoption.

Regards,
Dave

[1] http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0084.html


> 
> 
> Pat
> 
> 
> 
>