Re: Three solution designs to the first three Graphs use cases

On 27/01/12 03:45, Sandro Hawke wrote:
> On Thu, 2012-01-05 at 11:09 +0000, Andy Seaborne wrote:
>> On 04/01/12 19:23, David Wood wrote:
>>> Thanks, Sandro.  That's very helpful.
>>>
>>> It might be useful to consider augmenting TriG syntax to support your third solution (explicitly naming relations). I'd be quite happy with that.
>>
>> What would the data model be?
>
> I think: an RDF graph which can have other RDF graphs as values of its
> triples.  All these graphs would be subgraphs of some greater graph, so
> they can share b-nodes.
>
> (This is what cwm has had implemented since 2001, I think.)

I thought this WG wasn't going there (graph literals).

Personally, I see graph literals as the clean answer but it is RDF 2 
(+).  RDF 1.1 is, to me, incremental improvements within the current 
abstract data model.  Datatyped literals  (e.g. "<s> <p> 
<o>"^^rdf:graphNTriples) are unwieldy and might block doing graph 
literals properly in RDF 2+.

The use of explicit triples in another graph to indicate the 
relationship looks interesting for RDF 1.1.

Whether this should be the default graph or another "system/manifest/??" 
graph isn't clear to me.  For the dump "use case" it makes some sense to 
keep them separate.


[[
In the N3 model, a graph literal is not a subgraph of some single graph 
otherwise

   :s :p { :x :y :z }

would put
   triple :x :y :z

into the outer graph (subgraphs being subsets) and it's not quoted

]]

>
>>> We could also consider standardizing the existing TriG syntax to be a syntactic shorthand for TriG REST semantics; that is, a lack of explicitly declared relation infers log:semantics.
>>
>> I think we should not fix a semantics for undeclared relationships.
>>
>> Otherwise, it invalidates existing TriG documents which don't exactly
>> follow the TriG/ABC definition.
>>
>> Ditto N-Quads - in a quadstore/database dump or extract you don't
>> necessary know the semantics.
>
> Agreed.   If we settle on a syntax that's compatible with TriG, I think
> we probable need the TriG subset to have the current TriG semantics --
> roughly none.

Cool.

 Andy

Received on Friday, 27 January 2012 09:33:41 UTC