Jena/ARQ: Difference between Model, Graph and DataSet

Question

I'm starting to work with the Jena Engine and I think I got a grasp of what semantics are. However I'm having a hard time understanding the different ways to represent a bunch of triples in Jena and ARQ:

• The first thing you stumble upon when starting is Model and the documentation says its Jenas name for RDF graphs.
• However there is also Graph which seemed to be the necessary tool when I want to query a union of models, however it does not seem to share a common interface with Model, although one can get the Graph out of a Model
• Then there is DataSet in ARQ, which also seems to be a collection of triples of some sort.

Sure, afer some looking around in the API, I found ways to somehow convert from one into another. However I suspect there is more to it than 3 different interfaces for the same thing.

So, question is: What are the key design differences between these three? When should I use which one ? Especially: When I want to hold individual bunches of triples but query them as one big bunch (union), which of these datastructures should I use (and why)? Also, do I "loose" anything when "converting" from one into another (e.g. does model.getGraph() contain less information in some way than model)?

Pyramidon

Answer 1

Jena is divided into an API, for application developers, and an SPI for systems developers, such as people making storage engines, reasoners etc.

DataSet, Model, Statement, Resource and Literal are API interfaces and provide many conveniences for application developers.

DataSetGraph, Graph, Triple, Node are SPI interfaces. They're pretty spartan and simple to implement (as you'd hope if you've got to implement the things).

The wide variety of API operations all resolve down to SPI calls. To give an example the Model interface has four different contains methods. Internally each results in a call:

Graph#contains(Node, Node, Node)

such as

graph.contains(nodeS, nodeP, nodeO); // model.contains(s, p, o) or model.contains(statement)
graph.contains(nodeS, nodeP, Node.ANY); // model.contains(s, p)

Concerning your question about losing information, with Model and Graph you don't (as far as I recall). The more interesting case is Resource versus Node. Resources know which model they belong to, so you can (in the api) write resource.addProperty(...) which becomes a Graph#add eventually. Node has no such convenience, and is not associated with a particular Graph. Hence Resource#asNode is lossy.

Finally:

When I want to hold individual bunches of triples but query them as one big bunch (union), which of these datastructures should I use (and why)?

You're clearly a normal user, so you want the API. You want to store triples, so use Model. Now you want to query the models as one union: You could:

• Model#union() everything, which will copy all the triples into a new model.
• ModelFactory.createUnion() everything, which will create a dynamic union (i.e. no copying).
• Store your models as named models in a TDB or SDB dataset store, and use the unionDefaultGraph option.

The last of these works best for large numbers of models, and large model, but is a little more involved to set up.

Unalienable

That clarified a lot, also I seem to have overlooked ModelFactory.createUnion() up to now, thanks :) – Pyramidon

A little bit more about this distinction: willware.blogspot.com/2010/02/jena-node-versus-rdfnode.html – Drilling

Also worth noting that neither Triple nor Node (or Quad) are actual interfaces, but classes. – Marquis

Answer 2

Short answer: Model is just a stateless wrapper with lots of convenience methods around a Graph. ModelFactory.createModelForGraph(Graph) wraps a graph in a model. Model.getGraph() gets the wrapped graph.

Most application programmers would use Model. Personally I prefer to use Graph because it's simpler. I have trouble remembering all the cruft on the Model class.

Dataset is a collection of several Models: one “default model” and zero or more “named models”. This corresponds to the notion of an “RDF dataset” in SPARQL. (Technically speaking, SPARQL is not a query language for “RDF graphs” but for “RDF datasets” which can be collections of named RDF graphs plus a default graph.)

Benton