REST and RDF, what's the representation strategy?

Your triplestore contains a lot of nodes, and you have to make accessible this database via a REST interface.

Now, my solution would be that every named (not-anonymous) node is exported as a resource, whose representation is:

1. all the triples having the node as a subject
2. all the triples having the node as an object
3. all the connected anonymous nodes.

I am a little reluctant on point number 2: this would basically give both incoming and outgoing triples.

What is your take on a REST sytle representation of a purely RDF-oriented data store ? Do yo开发者_高级运维u share my point of view or not, and if not, what is your take on it ?

Depends on what the the data is and what the interface users want to do with it. This question is similar to what the SPARQL DESCRIBE query form should return. (It's determined by the implementation.)

For the use cases I've had with RDF data, I'd go with 1 and 3, producing a blank node closure of the resource. Additionally, you could have a separate interface for case 2, returning the incoming arcs of the resource.

One easy way to make an RDF dataset REST traversible is to use URLs for all traversible elements.

When the URL is accessed, for example via HTTP GET, then result shows the connected nodes (connected as properties and/or inverse properties).

More formally the returned representation could be a Concise Bounded Description of the resource.

(disclaimer: this may not correspond exactly to the content of your question, but it corresponds to the title)

I think that about the topic of Rest representation of RDF data is a general problem of inverting the order of concepts. For me the normal would be to have a collection of Rest documents with RDF data and use a RDF database for indexing and making global querys.

In this situation you can organize your resources in the way you prefer.

Also (if you pretend to use the URI of the node as the exported resource) your approach will have subtle problems about what is the meaning of your resources: the Rest resources you propose here are "information resources" and then they cannot be abstract resources. There will be a conflict between information and meta-information.

I published an article here explaining this view in more detail.