I’m not sure I see a big overlap between Resource Maps and Named Graphs. Resource Maps are an RDF resource that describes an aggregation of other resources, whereas a Named Graph provides context to a set of triples. I suppose in a loose sense, the Resource Map is also providing “context”, but I don’t think the implementation or use cases really overlap. We might use one Named Graph for each Resource Map, but we could just as easily store several of them in a Named Graph.

I did wonder if a Resource Map could be considered as a serialization of a Named Graph, but I don’t think that makes a lot of sense. One could probably implement a means to populate a collection of Named Graphs from a set of Resource Maps, but I think this would be messing with the semantics of both.

For me Resource Maps are just extra assertions, describing additional relationships between resources, whereas Named Graphs contextualise data in a different, more “out of band” way.

Regarding subgraphs: http://www.w3.org/2004/03/trix/rdfg-1/ has a predicate for just that. But I wonder if explicitly stating this relationship is the best way of doing it. You can either associate statements with one graph only and then group those graphs together into larger graphs which don’t actually have any statements associated with them in the store but are just linked to the subgraphs with this predicate. Or you can add statements to several graphs at once where some graphs contain fewer statements and are for more fine-grained purposes. The store could still store this efficiently by using statement IDs and associating those with different graph URIs instead of storing the statement multiple times. I’m sure that’s what some stores do anyway.

Basically namespacing is a mechanism that allows for a simple modularization so that two separate peer entities (or structures) can be managed within a common application space.

In that sense I do see think that “namespacing” is exactly what the “named” qualifier in “Named Graphs” is bringing to the party. It allows for seperate RDF graphs to be “named” (hence “namespaced”) and to coexist within a single application.

How that “namespace” is applied – i.e. the semantic overtones attributed to it – is another matter.

But just as XML were namespaces developed subsequently to XML 1.0 and that XML 1.0 had no namespaces, so RDF namespaces (or Named Graphs) are not represented in RDF 1.0. (aka RDF).

Tony

Great feedback thanks. The issue of how easy it is to support the different styles on the client, server, and implications for proxy servers (e.g. for caching) is definitely something that needs closer attention.

The ?graph= is easier to handle on the client side if you’re using curl, wget, or HTML forms. These clients wil more readily handle the escaping if the graph uri is in a parameter. If you’re coding something up then I’d argue that using a query string or constructing a complete URI is just as easy either way. Depending on your HTTP client library, you might not need to care about encoding of parameters, so the code *may* be slightly cleaner, but thats clearly debatable.

On the server side, I’m not sure I see much of a distinction either. In my experience its just as easy (and in some cases easier) to pull out a parameter from a request than split up the request URI. This is with both Ruby and Java frameworks. In the latter case I’ve not used Restlet, but I’m pretty sure that Jersey handles this OK. You mention that “routing based on query parameter” is slightly harder, and I agree, although I think most frameworks are leaning towards supporting binding to all aspects of the URI? I’ll have to do some more digging.

Your comments lead me to dig into the public-rdf-dawg mailing list to see how the Working Group have been discussing this issue. There is some interesting, related discussion on this thread about REST and HTTP Update and these suggestions for HTTP updates. Haven’t digested it all yet, but the main issues seem to be support for PUT with parameters in web frameworks, and impact of parameters on caching of requests.

Cheers,

L.

I’ll do my best to answer your questions.

1. Is TriX compatible with RDF/XML?

TriX is a completely separate XML serialization for RDF. As an extension it includes supports for grouping triples into graphs. There are some examples here: http://sw.nokia.com/trix/examples.xml

So from a syntax point of view, the two are incompatible. From an RDF model point of you, TriX can encode things (like named graphs) that you can’t encode in RDF/XML.

2. how to include the same triple to several different named graphs (syntax in RDF/XML is prefered)

As RDF/XML doesn’t allow you to indicate that a triple is included in a specific graph, then there’s no way I can provide an example using that syntax I’m afraid!

Using TriG notation (which I prefer) you could write:


@prefix: <http://www.example.org/doc#> .
@foaf: <http://xmlns.com/foaf/0.1/>.

:G1 { foaf:name "Leigh Dodds". }
:G2 { foaf:name "Leigh Dodds". }


This asserts the same triple in two different graphs. If we had a synthetic graph which was the RDF merge of these two, then it would contain a single triple.

3. is it possible to declare that a graph includes other graphs? (i.e a kind of supergraph – subgraphs)

I don’t think either TriG or TriX address this, but then I’m not sure I’d expect them to as they’re primarily a serialization format. I think what you’re asking here is how we can associate metadata with graphs, e.g. to indicate that they have some relationship. I’m sure there has been work done on this, but I’m not aware of it.

Metadata about named graphs, and how to manage that separately from the graphs themselves is something I can to cover in my next posting.

I’m *very* wary about using the word “namespace” in conjunction with Named Graphs

In the sense that they provide some context, then yes, they I suppose they are similar.

But XML namespaces typically indicate some collection of elements and attributes that have been defined by a specific source. So the closest analogy to a namespace in the RDF world is a schema or vocabulary. There’s no implication for named graphs that the data in the graph is all from one source, or uses one vocabulary, or is about one thing. There are many ways they can be used.

Would it be fair to characterize Named Graphs as nothing more (or less) than namespacing for RDF?

Cheers,

Tony