Community Blogs
Community Blogs FeedIgnite slides
What is a content repository
Joint post of Henri Bergius and Michael Marth cross-posted here and here.
Web Content Repositories are more than just plain old relational databases. In fact, the requirements that arise when managing web content have led to a class of content repository implementations that are comparable on a conceptual level. During the IKS community workshop in Rome we got together to compare JCR (the Jackrabbit implementation) and Midgard's content repository. While in some cases the terminology might be different, many of the underlying ideas are identical. So we came up with a list of common traits and features of our content repositories. For comparison, there is also Apache CouchDB.
So, why use a Content Repository for your application instead of the old familiar RDBMS? Repositories provide several advantages:
-
Common rules for data access mean that multiple applications can work with same content without breaking consistency of the data
-
Signals about changes let applications know when another application using the repository modifies something, enabling collaborative data management between apps
-
Objects instead of SQL mean that developers can deal with data using APIs more compatible with the rest of their desktop programming environment, and without having to fear issues like SQL injection
-
Data model is scriptable when you use a content repository, meaning that users can easily write Python or PHP scripts to perform batch operations on their data without having to learn your storage format
-
Synchronization and sharing features can be implemented on the content repository level meaning that you gain these features without having to worry about them
| feature | JCR / Jackrabbit | Midgard | CouchDB |
| content type system | In JCR structured or unstructured nodes are supported and can be mixed at will in a content tree. | Content types are defined in MgdSchema types. All content must be stored to an MgdSchema type, but types can be extended on content instance level using the "parameter" triplets | Type-free |
| type hierarchy | Structured node types support inheritence of types, additional cross-cutting aspects can be added with "mixins". Node types can define allowed node types for child nodes in the content hierarchy. | MgdSchemas allow inheritance, and an extended type can be instantiated either using the extended type or the base type | Type-free |
| IDs |
Nodes with mixin "referenceable" have |
Every object has a GUID used for referencing. Objects located in trees that have a "name" property can also be referred to using the path | All objects can be accessed via a UUID |
| References | Nodes can reference each other with hard link (special property type) or soft link (by referring to the node path) | MgdSchema types can have properties linking to other objects of same or different type. A link of "parentfield" type places an MgdSchema type in a tree. | No reference support built-in |
| content hierarchy | All content is hierarchical / in a tree | Content can exist in tree, or independently of it depending on the MgdSchema type definition | flat structure |
| interesting property types | Multi-valued (like an array), binary properties (e.g. for files), nodes have an implicit sort-order | Binary properties stored using the Midgard Attachment system | Support for binary properties |
| transactions | Multiple content modifications are written in transactions. | Transactions can be used optionally. | |
| events | JCR Observers can register for content changes on different paths and/or for different node types and/or CRUD, receive notification of changes as serialized node | All transactions cause both process-internal GObject signals, and interprocess DBus signals | Support for one external event notification shell script |
| workspaces | Workspaces provide separate root trees. | No workspaces support in Midgard 9.03, coming in next version | Multiple databases within one CouchDB instance |
| import and export | nodes or parts of the repository (or the whole repo) can be imported or exported in XML. 2 formats: docview for human-frindly representation, sysview including all technical aspects | Objects can be exported and imported in XML format. There are tools supporting replication via HTTP, tarballs, XMPP, and the CouchDB replication protocol | JSON serialization is the standard way of accessing the repository. CouchDB replication protocol supports full synchronization between instances |
| versioning | Checkin/checkout model to create new versions of nodes, optionally versions complete sub-trees, supports branching of versions. | No versioning | All versions of content are stored and accessible separately, no branching |
| locking | Nodes can be locked and unlocked | Objects can be locked and unlocked | |
| object mapping | Not in standard, but implemented in Jackrabbit. Rarely used in practice. | Object mapping is the standard way of accessing the repository | All content is accessed via JSON objects |
| queries | In JCR1 Sql or XPath, in JCR2 also QueryBuilder. | Query Builder | Javascript map/reduce |
| access control | Done on repository level, i.e. all access control is independent of application. In Jackrabbit: pluggable authentication/authorization handlers. | No access control in Midgard repository, usually implemented on application level. Midgard proves a user authentication API | No access control |
| persistence | In Jackrabbit different Persistence Managers can be plugged in (RDBMS, tar file, ...) | libgda allows storage to different RDBMS like MySQL, SQLite and Postgres | CouchDB has its own storage |
| architecture | Jackrabbit: library (jar), JEE resource, OSGi bundle or standalone server | Library | Erlang-based daemon |
| APIs | Standard: Java-based, PHP coming up. In Jackrabbit: also WebDAV and HTTP-based API | C, Objective-C, PHP, Python | HTTP+JSON |
| full-text search | Included in repository. In Jackrabbit: Lucene bundled | No (SOLR used on application level) | Plugin for using Lucene, not installed by default |
| standard metadata | All nodes have access rights, jcr:primaryType and jcr:mixinTypes properties. JCR 2.0 standardizes a set of optional metadata properties. | All objects have a set of standard metadata including creator, revisor, timestamps etc | No standard properties |
[LOTD] IKS in the press
French IT mag LeMagIT has published an article about the IKS project including quotations from Bertrand Delacretaz. Bertrand emphasizes the need for concrete results:
pour décoller, les technologies sémantiques ont besoin de cas d'utilisateur concrets
In the comments section Bertrand mentions his tag line for semantic technologies that I can very well relate to:
La sémantique "sous le capot" oui, la sémantique "dans la figure", non
This roughly translates as: "semantics under the hood yes, semantics in your face, no".
In Computerworld UK open source blogger Glyn Moody has described his first hands impressions from the IKS workshop in Rome. He comes to a similar conclusion:
Paradoxically, semantic search will only ever really take off once it has receded so far into the fabric of computing that people aren't even aware it's there.
Update: The IKS semantic engine - a pragmatist's view
Update to "The IKS semantic engine - a pragmatist's view": here are the slides:
Title The IKS RESTful semantic engine - let's get
started!
more documents from bdelacretaz.
started!
more documents from bdelacretaz.
The presentation went well, and will hopefully lead to a sprint to actually implement something along these lines. The two demos that used UIMA at the workshop made me think that UIMA should be part of that picture, at least as a plugin for semantic lifting. And I did the presentation in less than 8 minutes out of the 10 that were allocated. Bonus points?
IKS Search Benchmark
CQ5 search comes with some improvements over JCR's search capabilities, e.g. adapting result rankings to what users choose or faceted search. Within the IKS project Bertrand and I have experimented with another possibility: link-based ranking, i.e. adjusting search results based on the content of link tags. For example: if page A links to page B with the link text "lorem ipsum" then page B should get a higher ranking when a user searches for "lorem ipsum". This is essentially what Google does, but we wanted to apply it to internal links (within the same site) only.
To give away the results right away: for many web sites the results will probably not improve dramatically, because there are not enough internal links. However, it might help for some projects so our implementation approach is described below in case you want to give it a try in your project.
In order to extract links from a node we opted for parsing the complete rendered HTML presentation of a node rather than looking only at the Rich Text properties of one node. In that way we could also catch programmatically generated links from templates. So we ended up by setting up a little spider on the publish server that retrieves HTML representations of all pages. The spider is deployed as an OSGi bundle within the server so it gets the locations of all pages from an internal repository query. For each page the HTML is retrieved and parsed. The found links are stored as child nodes below the page that is linked to. In the example from above: if page A links to page B with the link text "lorem ipsum" then page B gets a child node with properties source=A and text="lorem ipsum". Implemented in that way we could basically use the Jackrabbit indexer without further changes.
We have also implemented a JCR Observer that catches changes to pages and fixes the corresponding links. Template updates are not caught, yet.
The sources are attached to this post. The Java program can be used as a standalone application or deployed as an OSGi bundle. The standalone program takes a couple of optional arguments for running a full upfront spidering, deleting all found link nodes etc. In case you want to give it a try please be aware:
-
The standalone program requires RMI to be enabled on the repository which is not the case by default (in the code port 1235 is used).
-
The searches must take into account the new properties of the link nodes. One possibility is to re-configure the Jackrabbit indexing,
which in CQ5 is done in the
crx-quickstart/server/runtime/0/_crx/WEB-INF/classes/indexing_config.xml
file, by adding:linkedText
The boost factor in this configuration can be adjusted to give links a proper weight relative to the other properties of a node
For reindexing delete these directories:
crx-quickstart/repository/repository/index
crx-quickstart/repository/workspaces/crx.default/index
crx-quickstart/repository/workspaces/crx.system/index
Results
We tested the approach on the content of our corporate website (a rather small content corpus). Overall, the search results improved slightly, but not much (although we did not spend a lot of time on tweaking the boost factor). As stated above I believe that corporate websites in general will not benefit from link-based ranking very much as the majority of links in them are often reflecting the navigation (i.e. the hierarchical structure of the site) so they provide little additional information. Of course, on the other side there is no harm in using links for search relevance either.
Alternative approach
Marcel Reutegger (the MAN when it comes to JCR searches) gave a lot of great input to our experiment (thanks a lot for this). He also hinted how an alternative implementation could look like: using an output filter, which can process HTML content as it's being generated. In CQ5 the validity of links is already checked that way, so storing them would naturally fit there. Also, he suggested storing the links not below the pages themselves, but in a separate part of the repository. In a background processing job these links could be aggregated and the most relevant key words would eventually be written into the page nodes.
