Re: An annotation specifying a relation

On Fri, Jul 20, 2012 at 4:12 PM, Robert Sanderson <> wrote:

>> c) Multiple targets, named graph as body (my recommendation):
> And mine, though by either embedding the graph resource using
> ContentAsText (most likely) or by referencing an external resource if
> it becomes complex.  The reasons being the same as in the extension
> document -- Named Graph serializations will break parsers expecting
> "regular" RDF.

Those parsers would break even more on ContentAs* - that would just be
a black blob. This is great for embedding small pictures, etc. However
I'm not sure how good it is for graphs that you might want to parse
and query. (That was your argument!)

Following links is a regular Linked Data approach, so just keeping
them as regular resources you could get with HTTP and retrieve RDF in
the negotiated format. In super-manual, users can copy-paste the URL
and open it in a browser, then save the file.  This should be the good
fallback solution. It has performance issues, but should be very

Any quad stores like 4store will let you load named graph formats like
TriG, or load multiple graphs from different resources, and then query
across them using SPARQL, which has had support for multiple graphs
for ages.

For 'embedded' bodies (ie graphs that exists only for being the body
of this annotation), I would suggested an approach like this:

<> is the annotation resource.

If you GET this with Accept: text/turtle or application/rdf+xml, you
will end up with the graph describing the annotation according to our
model. In there it might say:

<> a oa:Annotation ;
  oa:hasBody <> .

<> a rdfg:Graph .

If you GET with Accept:
text/turtle or application/rdf+xml you just get the annotation body
683 (what you would put in the ContentAsText).

If you GET (the annotation resource)
with Accept: application/x-trig or equivalent named graph
serialization, you get the same content as for Turtle within the
default graph, but also have the embedded the graph bodies like
<> as named graphs. Thus you
don't need to request <>
again to look inside it.

However, just to clear any doubt about if the graph really 'is'
- if you DO request <> with
the Accept: application/x-trig, then you get a 303 redirection to
<> - telling you that you can get the
resource as part of the a named graph serialization there.

(If the annotation body itself is to be a set of named graphs rather
than a single graph, then you would obviously have to do it as a
regular resource. However it would not be a problem to have a named
graph serialization (an "all annotations resource") with multiple
graphs having oa:Annotation's in them, that again point to other named
graphs. They could even overlap if the same graph is used in several
annoations. )

The RDF-NG working group at W3C is also working at clarifying some of
the semantics (like the graph named by an URI vs the representaton
retrieved from an URI) and bring named graphs fully into the RDF
family -

So named graphs are becoming very house hold.

Putting a particular RDF serialization in a ContentAsText or
ContestAsXML sounds a bit home brew to me - in particular with this
formatOf-relations you have suggested - I am not very positive about
that as a solution to embed graphs, as no-one will have heard about
it, and it would cause a lot of custom code to get it to work. I would
basically have to:

a) Load up your annotation graph
b) Query for any ContentAsText nodes that might be RDF (hopefully have
the mime type specified somehow) and which don't exist as a named
c) Save the string from the content as text to a variable or file.
Hope that it is not RDF/XML with the wrong <xml encoding>.
d) Send this to parse by the Triple store to add a new graph
e) Hopefully won't have to recurse to b) for ContentAsText graphs
within the ContentAsText's
f) Do my real query using named graphs

which sounds quite specific.

Following links and just retrieving them is something Linked Data
applications do regularly, and although it is a very similar process
to the above, it is often hidden because services put up a public
SPARQL end point letting you jump straight to step F) - remotely. You
can't (as far as I know) do step C) and D) with SPARQL alone.

In addition: even lets you
do federated SPARQL queries across multiple services using SERVICE. formalizes this. will let you use FROM and FROM
NAMED and it will fetch and load the graphs to be used in your query.
Other stores can also support this.

Using SPARQL 1.1 Update you can LOAD a graph from a URI.

None of those would work with ContentAsText.

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Friday, 27 July 2012 14:18:27 UTC