Re: Attempt to provide semantics to Sandro's named graph design

On 10/04/12 15:35, Ivan Herman wrote:
>> "Subgraphs or Graphs"
>>>
>>> I don't think this is a local syntax issue. The parts of the
>>> labelling may be in different datasets, which are then brought
>>> together (actually, not possible by condition 3)
>>>
> Yep, another reason to remove this.
>
> But I am not absolutely sure what you are saying:-(
>
>>> Within one TriG file, several<u>  {} blocks may make one graph
>>> labelled<u>  overall -- that is a syntax issue.
>>>
>>> ((I don't see why the merge of datasets isn't the merge of their
>>> graphs with the same URI + the (IRI, graph) pairs for
>>> non-overlapping IRIs.))
>>>
> Well, that may be doable... but this seems to be one (maybe the only
> real?) open issue at the moment in the WG.
>
> Just thinking out loud: if (<u>,G) but<u>  is_not_  of type
> rdf:Graph, ie, it is only labeling, then I could imagine a much more
> lax attitude in terms of subgraph vs. graphs. However, if<u>
> rdf:type rdf:Graph, ie, it is really a URI that denotes the graph,
> then the situation may be different...

I'm OK with the idea that additional statements about <u> can, in 
effect, close the description by placing further restrictions on the 
relationship of <u> and G.

I haven't seen a reason to make the default be complete labelling - 
additional triples can't undo the base semantics.

e.g. Lee's example or Arnaud's "it depends" or simply concatenating two 
N-Quads or TriG files are reasonable UCs to me.

	Andy

Received on Tuesday, 10 April 2012 17:08:42 UTC