3. Vanilla release

The assembly-pinetree-vanilla component is used to assemble the Vanilla release of Pinetree. The current page details how to configure and work with this release.

3.1 Setup

First you need to get a hold of the Pinetree maven project. As of now it is hosted Beanstalk in a private Git repository. Pinetree will be open source at some point close in time, but a lack of understanding how licensing works is delaying the process (i.e. it is more fun to program!). I will however write up how the installation works so I have it done for whenever the system is released in public.

1. You will need a recent version of Java. Pinetree has been developed and tested with version 6.
2. Install Maven on your machine.
3. Get a hold of the Pinetree sources.
4. In the root folder, i.e. where the pom.xml file for the pinetree-parent artifact resides, run the command:

   mvn package

5. After a while of compilation and testing the build is complete.
6. To access the Pinetree sesame packages, cd into the assembly-pinetree-vanilla/target directory, which contains the assembled WAR file and the standalone version (in a directory called assembly-pinetree-vanilla-${version}).
7. Have fun!

3.2 Configuration

Pinetree relies on the Java property pinetree.home to know where to store content, write to log files etc., and should contain the absolute path to the Pinetree application root directory. When running the standalone distribution of Pinetree, the pinetree.home property is usually resolved automatically. However, if Pinetree is deployed in a servlet container you must make sure that java property pinetree.home is set to a writable location, e.g. ${user.home}/pinetree. Moreover, it is advisable to run the WAR distribution of Pinetree in exploded mode, as you most probably want to alter the Spring context files within the WAR archive.

The default configuration in the vanilla release might (most probably) need some tweaking to make the system behave like you want to. Below we go through the various configuration files to highlight their purpose and contents:

• logback.xml
  Logback configuration file. Alter it to fulfil your logging needs. Default location for the log files are at ${pinetree.home}/logs
• jetty.xml (standalone only)
  Spring configuration for the embedded Jetty web server for running Pinetree as a standalone application.
• linkeddata-servlet.xml
  Spring configuration for servlet routes and autowiring.
• file-settings.xml
  Spring configuration for the pinetree-file implementation IoC, i.e. the pinetree-file-simple component.
• dao-settings.xml
  Spring configuration for data persistence and proxy settings. Alter this file if you want to change the sail implementation.
• binding-settings.xml
  Spring configuration for bindings.
• web.xml
  The grand ol’ web.xml.

3.3 Adding libraries

One common configuration change for the assembly-pinetree-vanilla is to switch out the default MemoryStore sail to a more efficient RDBMS sail. This is easily configurable in the Spring context configuration files as described above. To make this work you will need to add the missing libraries as well, e.g. a JDBC driver, to the lib directory in Pinetree and restart the server. The lib folder is in the application class path, so whatever you put in there should be referable from the Spring context configuration files.

3.4 Model <-> RDF mapping

This section describe the mapping between the pinetree-model interfaces and RDF vocabularies in the pinetree-sesame implementation included in the vanilla release. The RDF generated by the pinetree-sesame component all rely on well known types in existing Semantic Web vocabularies, such as FOAF and DCMI. The figure below illustrates the relation between the Pinetree domain model and the RDF representations generated by pinetree-sesame.

The Collection interface has been mapped directly to the dcmitypes:Collection RDF class, while Part does not have  a RDF type mapping. Instead, the property dc:hasPart allow the collection<->part relationship to be derived. If the below statements are declared:

X a dcmitypes:Collection ;
      dc:hasPart Y .

then Y is considered to be a part of the collection X. Hence, a specific “part” class is not necessary. Similarly, the need of a “content” class is not required; if the above statements are declared along with:

Y a foaf:Document .

then Y is considered to constitute a description of a digital resource that is a part of the collection X. As stated in the FOAF vocabulary documentation, foaf:Document can both refer to a digital resource or the description of a digital resource, where the latter is true in pinetree-sesame. A reference to the digital resource being described is automatically generated via the foaf:page predicate.

3.5 Gotchas

As pinetree-sesame supports any RDF statements to be added, it would in theory be possible to make resource types ambiguous and break the structure of collections and parts in the backend. To avoid this unpleasant scenario, statements that are generated when resources are created through the various DAO classes are stored in the pinetree:structure graph context, while statements that are created after that point are stored in the any other context but pinetree:structure. Problem solved.