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

Labelled graphs

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 13 Apr 2012 11:22:50 +0100
Message-ID: <4F87FE7A.1000102@epimorphics.com>
To: RDF-WG <public-rdf-wg@w3.org>
What I saw in the concept of "labelled graphs" was that it was a loose 
association of label and graph in a dataset.  Minimal, and something to 
build on top of.

There had, prior to "labelled graphs", been a conversation about what 
name graph semantics could be and we (I?) concluded there was going to 
be no single choice we could agree on.

So no fixed useful semantics as the base case and build on that with 
additional information to strengthen the meaning of the labelling in the 
dataset.  Juts make sure RDF-WG devised vocabularies don't conflict.


<u> { ... }

with no additional statements is a very weak relationship - either 
nothing, no implied RDF triples (in some extended RDF with graph 
literals), just the access to the graph in the dataset or a relationship 
that has null semantics.

<u> rdf:label { ... }

Read that as rdf:aaa to avoid natural language meaning.

Semantics are "caveat emptor".  It's up the client to decide what can 
and can't be done.


We had some discussion about the additional vocabulary - I have no 
opinion on class/property choice for that.

<u> { ... } .
<u> a rdf:staticGraphContainer .

means that {...} is the value of (g-snap) of URL <u>.

<u> { ... } .
<u> a rdf:Graph .

means that <u> denotes the graph {...}.

Ideally, I hope TriG files will have the addition information.  In the 
base case, which cover current practice, is that they don't and that all

<u> { ... }

says is that there is an association in this dataset.  Then build on top 
of that.

	Andy
Received on Friday, 13 April 2012 10:23:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:48 GMT