Uploading RDF vocabularies (GRAILS, Virtuoso and Sesame)

If you need to upload an RDF vocabulary in Virtuoso, the easiest way to go is doing it through the Virtuoso Conductor. It is pretty straightforward, you define the graph name and the file to upload and that is it. When developing an application though, you may want to be able to upload the files programmatically (for instance for managing metadata associated to the vocabulary and creating a catalog).

The following snipped of code is a modified version of the one I found in the openrdf forum:

Repository myRepository = new VirtuosoRepository("jdbc:virtuoso://localhost:1111","dba","dba");
myRepository.initialize();
File file = new File("/Users/paolociccarese/Desktop/contact.rdf");
RepositoryConnection con = myRepository.getConnection();
URI context = new URIImpl("http://paolociccarese.info/contact");
con.add(file, null, RDFFormat.RDFXML, context);
con.close();

For running this code it is necessary to perform a bunch of imports:

import org.openrdf.model.URI;
import org.openrdf.model.impl.URIImpl;
import org.openrdf.rio.RDFFormat
import org.openrdf.repository.Repository
import org.openrdf.repository.RepositoryConnection

To make it work, if you use grails and ivy (ivy.xml), you should add at least the following dependencies:

<dependency org="org.openrdf" name="openrdf-repository-api" rev="2.0.1" conf="compile"/>
<dependency org="org.openrdf" name="openrdf-rio-rdfxml" rev="2.0.1" conf="compile"/>
<dependency org="org.openrdf" name="openrdf-model" rev="2.0.1" conf="compile"/>

and you also need to link to the maven repository for these in the ivysettings.xml file:

<ibiblio name="aduna" root="http://repository.aduna-software.org/maven2" m2compatible="true"/>

and finally run the command >grails get-dependencies again.

Grails: Multiple datasources without GORM

Who's playing around with Grails knows about GORM. GORM is Grails' object relational mapping (ORM) implementation. GORM is built on the top of Hibernate and enables persistence. The configuration of the database used for persistence is in the file grails-app/conf/DataSource.groovy. The application might need to access other databases for reasons other than persistence. It might be necessary to distinguish different sources for development, test or production (the Grails standard environments). In this case it is possible to leverage Spring creating the file grails-app/conf/srping/resources.groovy with a content similar to the following, which is setting up the connection to the Virtuoso triple store:

import org.apache.commons.dbcp.BasicDataSource

/*
* @author Paolo Ciccarese
*
* The virtuoso data source has been defined here to not
* interfere with the GORM datasource in the file
* grails-app/conf/DataSource.groovy
*/

beans = {
// Virtuoso triple store
virtuosoDataSourceDevelopment(BasicDataSource) {
   driverClassName = "virtuoso.jdbc3.Driver"
   url="jdbc:virtuoso://localhost:1111"
   username="dba"
   password="dba"
}
virtuosoDataSourceTest(BasicDataSource) {
   driverClassName = "virtuoso.jdbc3.Driver"
   url="jdbc:virtuoso://blah.org:1111"
   username="dba"
   password="dba"
}
virtuosoDataSourceProduction(BasicDataSource) {
    // Here the details of the production data source
}
}

BasicDataSource has been used as it guarantees connection pooling. In some examples, instead of that class you can find org.springframework.jdbc.datasource.DriverManagerDataSource . Reading the documentation: This class is not an actual connection pool; it does not actually pool Connections. It just serves as simple replacement for a full-blown connection pool, implementing the same standard interface, but creating new Connections on every call. This might create problems with Virtuoso in the case of numerous queries. Once we defined the data sources it is possible to define a service (> grails create-service) for providing the right one according to the current environment:

class SparqlService {

 def transactional = false

 def virtuosoDataSourceProduction
 def virtuosoDataSourceDevelopment
 def virtuosoDataSourceTest

 private static final String TEST = "test"

 def getDataSource() {
     if(grails.util.GrailsUtil.isDevelopmentEnv())
         return virtuosoDataSourceDevelopment
     else if(grails.util.GrailsUtil.getEnvironment()==TEST)
         return virtuosoDataSourceTest
     else
         return virtuosoDataSourceProduction
 }
}

Now it will be possible, for other services to use the one just defined. Something like:

class SparqlQueryService {
 
     def sparqlService

     boolean transactional = false
 
     public List<Map<String, Object>> getSparqlResultRowMaps(String query){
         log.info("Running query: " + query);
         JdbcTemplate jdbcTemplate = new JdbcTemplate(sparqlService.getDataSource())
        .....
         return results;
     }

....
}

Where the sparqlService is injected. Thus when a query is needed is sufficient to refer to sparqlQueryService, which will take care of selecting the right datasource.

The Grails plugin class

Image via Wikipedia

After creating the plugin structure one thing you can do is to edit the Grails plugin class. The grails plugin class, by default, looks something like this:

class UtilsGrailsPlugin {
// the plugin version
def version = "0.1"
// the version or versions of Grails the plugin is designed for
def grailsVersion = "1.1.1 > *"
// the other plugins this plugin depends on
def dependsOn = [:]
// resources that are excluded from plugin packaging
def pluginExcludes = ["grails-app/views/error.gsp"]

// TODO Fill in these fields
def author = "Your name"
def authorEmail = ""
def title = "Plugin summary/headline"
def description = '''\\
Brief description of the plugin.
'''

// URL to the plugin's documentation
def documentation = "http://grails.org/Utils+Plugin"

....
}

As we are writing our first plugin there are not dependencies we want to define. We will simply fill out some details:

def author = "Paolo Ciccarese"
def authorEmail = "paolo.ciccarese@gmail.com"
def title = "Utilities for vocabularies/ontologies management"
def description = '''\\
Utilities for vocabularies/ontologies management
'''

You might want also to define the location of the documentation. This file will be used to generate the plugin package when needed. It is sufficient to be in the root directory of the plugin and type:
> grails package-plugin

This will create a grails-utils-0.1.zip file that can be then installed by other grails plugins/applications. To install it will be sufficient to be in the new application/plugin root directory and to type
> grails install-plugin grails-utils-0.1.zip

But before doing this, you probably have to write some code that will provide actual utilities.

A few mins with Grails (Creating a plugin)

Image via Wikipedia

Lately I found myself playing around with Grails and I've been appreciating right away the plugins mechanism (Grails website: creating a Plugin).

With a simple:
> grails create-plugin Utils

or even with a simpler (the script will ask you to specify the name of the plugin later on):
> grails create-plugin

you will be able to generate the structure of a Grails plugin that you will notice is really similar to the structure of a Grails application (in italic the directories):

.classpath -> Eclipse .classpath file. It includes all the references to the folders in the project that are going to be in the classpath and all the references to the libraries for making your grails project run. The libraries are expressed through the GRAILS_HOME variable under the form GRAILS_HOME/dist/grails-web-1.1.1.jar. The directories that are included in the classpath are typically (you can detect them easily in Eclipse if you import the project just created as "existing project"):

• src/java
  
• src/groovy
• grails-app/conf
• grails-app/controllers
• grails-app/domain
• grails-app/services
• grails-app/taglib
• test/integration
• test/unit

.project -> Eclipse .project file
.settings -> Eclipse .settings directory

Utils-test.launch -> can be used to run the unit tests
Utils.launch -> can be used to run the application
Utils.tmproj

UtilsGrailsPlugin.groovy -> The plugin class defines the version of the plugin and optionally various hooks into plugin extension points.

application.properties -> Contains a few lines to describe the details of the plugin/application:

#utf-8
#Fri Sep 04 10:12:01 EDT 2009
app.version=0.1
app.servlet.version=2.4
app.grails.version=1.1.1
app.name=Utils

build.xml -> It is an Ant file that contains a set of targets, allowing to resolve dependencies declared in the Ivy file, to compile and run the sample code, produce a report of dependency resolution, and clean the cache or the project. Ivy is a subproject of Ant.
grails-app -> directory containing the main components of a Grails application/plugin: controllers, services... (see classpath)
ivy.xml -> Ivy file containing the description of the dependencies of a module. Ivy (Ivy website) supports dependency resolution (grails does not support Maven).
ivysettings.xml -> file for Ivy configuration
lib -> directory containing the list of libraries for running the application
scripts -> Grails scripts
src -> directory with the source codes in both java and groovy (see classpath)
test -> directory collecting all Grails unit tests: Grails supports the concepts of unit and integration testing. Unit testing is for small focused, fast loading tests that don't load supporting components. Integration testing is for tests that load the surrounding environment (it supports injection).
web-app -> contains the web components of the Grails project