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
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).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.