Table of Contents
Relations in Nuxeo EP 5 follow concepts as described by the W3C Resource Description Framework (RDF).
The purpose is to provide content management relations (relations between documents of the site for instance) as well as being able to share this information with third party applications, by following the RDF standards.
There are a few jargon terms to understand when dealing with relations.
Let's consider a relation like "document A is a version of document B". This relation is described as a triplet or statement: it has a subject, "document A", a predicate, "is version of", and an object, "document B".
The statement elements are more generally referred to as nodes. More specific kinds of nodes are literals and resources. A subject and a predicate will always be resources, while the object may be also a literal. In a relation like "document A has title 'documentation'", the object will be the literal string 'documentation'.
Literals are simple nodes, holding information like a string or a date. Resources refer to uniquely identifiable objects, and often use a URI as identifier that looks like a URL. If this URI refers to an identified namespace, we can make a difference between resources using it.
For instance, we can use the dcterms namespace to identify predicates: "http://purl.org/dc/terms/References", "http://purl.org/dc/terms/IsBasedOn","label.relation.predicate.IsBasedOn",...
Documents in the Nuxeo default application use the following namespace: "http://www.nuxeo.org/document/uid/". A document URI would look like "http://www.nuxeo.org/document/uid/618e53c8-409e-40e8-9b73-5493f7e6de88" because we use the JackRabbit identifier to identify fully the resource. Imagine that we use custom unique identifiers for documents, we could use them too, but we should use a different namespace so that we do not mistake the JCR identifier and the custom identifier.
When defining a relation like "document A is a version of document B", we will then build a statement which subject is a resource representing document A, which predicate is a resource representing the "is a version of" information, and which object is a resource representing document B.
If we would like to state that this relation was created as a certain date, we will add a date property to the statement. This can be seen as a relation where the subject would be the statement itself, the predicate a resource representing the "was created at" information, and which object would be a literal representing the given date.
If you would only like to change the storage used for the default graph of Nuxeo EP 5, please refer to Section 43.4.2, “Relation service configuration”.
Relations are stored in a graph, that can also be called a model.
The graph definition is made though an extension point. It holds configuration about where and how to store relations. Here is an example contribution.
<?xml version="1.0" encoding="UTF-8"?>
<component name="MyJenaGraph">
<require>org.nuxeo.ecm.platform.relations.jena</require>
<extension target="org.nuxeo.ecm.platform.relations.services.RelationService"
point="graphs">
<graph name="default" type="jena">
<option name="backend">sql</option>
<option name="databaseType">PostgreSQL</option>
<option name="datasource">java:/nxrelations-default-jena</option>
<option name="databaseDoCompressUri">false</option>
<option name="databaseTransactionEnabled">false</option>
<namespaces>
<namespace name="rdf">
http://www.w3.org/1999/02/22-rdf-syntax-ns#
</namespace>
<namespace name="dcterms">http://purl.org/dc/terms/</namespace>
<namespace name="nuxeo">http://www.nuxeo.org/document/uid/</namespace>
</namespaces>
</graph>
</extension>
</component>
Example 24.1. Jena graph configuration for the Relation Service using PostgreSQL as storage
This graph uses a Jena graph. Jena is a RDF framework, a plugin has been developed to integrate it to the nuxeo platform. The graph definition requires the plugin to be registered to the application.
The graph is named "default" and declares its connection configuration.
The graph configuration includes namespaces used for some of the graph resources so that resources with a known namespace can be transformed into any kind of object.
For instance, the namespace "http://www.nuxeo.org/document/uid/" is used to identify documents using their JCR unique identifier. We can register an adapter so that the resource can be transformed into the actual document model it represents.
For example, the DocumentModelResourceAdapter class allows to get a DocumentModel object from a resource, build with a namespace and a local name.
Managing relations turns around the following actions:
adding a new relation to a graph
removing an existing relation from a graph
determining if a relation already exists
emptying a graph to remove all existing relations
The StatementInfo interface provides methods to maniulates data about statements. That way, you can retrieve informations to display relations and their properties: These tools are:
wrappers/getters, to recover information about a statement (subject, predicate, object, ...) or a node (type of node : literal, resource, QNameResource ...)
methods to get all statements or statements which are matching a given pattern: this can be useful to determine if a relation is incoming (document is the subject of the statement) or outgoing (the document is the object of the resource)
methods to get extra properties: for each relation, informations are added like creation date or the creator of the relation.
Another interesting interface is NodeInfo: it is useful to qualify the type of resource you are handling with. Some methods can determine if the node is a literal, a document, a blank node, etc ...
