W3C home > Mailing lists > Public > public-rdf-wg@w3.org > January 2012

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

From: Steve Harris <steve.harris@garlik.com>
Date: Fri, 27 Jan 2012 12:16:56 +0000
Cc: Sandro Hawke <sandro@w3.org>, public-rdf-wg@w3.org
Message-Id: <C688142A-BC12-47D8-8810-DF08CA8BB872@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
On 2012-01-27, at 09:33, Andy Seaborne wrote:
> 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.

Right, this is a tricky one, and the decision should really be based on minimum impact to existing systems, IHMO.

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 0535 7233 VAT # 849 0517 11
Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ
Received on Friday, 27 January 2012 12:17:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:11 UTC