6. Next steps

While the vanilla release of Pinetree (assembly-pinetree-vanilla) offers a fully functional solution that works out of the box, Pinetree offers flexibility enough to be reconfigured according to the needs at hand. The present section covers some of the viable next steps for extending Pinetree.

6.1 Extending the component base

The vanilla release of Pinetree depends on the Sesame RDF framework (pinetree-sesame), binary files are stored directly on the file system (pinetree-file-simple) and the vanilla method for communicating with the system is via REST (pinetree-linkeddata, pinetree-forester). However, this combination of components is not carved in stone; implementations are defined in Spring context configuration files and can be completely replaced. Depending on the needs at hand, new component and assembly types can be created. As long as the components implement the required interfaces, replacing a component is just a matter of altering the Spring context files. Some ideas for new components include:

pinetree-file-jackrabbit

The pinetree-file simple implementation of pinetree-file stores binary files directly in a folder on the file system. A more sophisticated content storage mechanism, e.g. Apache Jackrabbit, should be considered.

pinetree-jena

Why settle with one data persistence mechanism? Through implementing pinetree-dao other data persistence alternatives can be used, e.g. Jena RDF framework.

6.2 Pinetree integration with existing systems

Another interesting path to investigate would be to use Pinetree vanilla as a way to expose data in existing systems as Linked Data. For example, data stored in Drupal, Moodle or any other system that offers a data API could technically be combined with Pinetree. The method would be to create a component that implements pinetree-dao, e.g. pinetree-drupal, which performs the data mapping. Then it is just a matter of replacing the pinetree-dao implementation in the Spring context files. A use case of this is goes as follows:

An instance of Moodle up and running in which students are registered on various courses. A pinetree-moodle component, that implements the pinetree-dao interface, uses Moodle as data source to expose students and their courses as Linked Data. The Moodle instance does not have any dependencies on the Pinetree instance, as the Pinetree instance constitute a stand alone service that rely on the Moodle instance’s API.

6.3 Linked Data as a common data model for system integration

The use case above shows how Pinetree can use existing systems as data source. As Linked Data specify how data should be formatted and exposed to be connected, Pinetree can be used as a data integration mechanism. Consider a similar use case as above, but this time we implement pinetree-dao by using the Drupal data API. Let’s call the component pinetree-drupal. The Moodle instance and the Drupal instance could then be connected via Linked Data by running instances of Pinetree alongside each of them: one that uses the pinetree-moodle implementation of pinetree-dao, and one that uses the pinetree-drupal implementation of pinetree-dao. Naturally, the use case is not limited to two systems.