How To
Preliminary Requirements
Luzzu is an open-source Java based framework. We are currently using JDK Version 1.7.0_51. In order to run Luzzu on your system, the only two pre-requisites are:Downloading the Framework
There are two options that one could use to download Luzzu, either by downloading the source or executable, or by cloning the GIT Repository.
. Then download a local clone of the forked repository. For more information visit Git User Documentation.
Building the Framework
This is only required if you cloned the repository or downloaded the source. Building the Luzzu framework is an easy job with Maven. Maven will handle all required dependencies and ensures a successful build. The framework will be compiled into a single JAR file. An inbuilt Jersey RESTFul web service will also be downloaded by maven, thus the framework does not require tools such as Apache or Tomcat to be installed. The following steps are required to build and compile Luzzu on your system:
$ cd your_repositories_directory/Luzzu
$ mvn clean install
your_repositories_directory/Luzzu/target directory.
The
clean directive ensures that the target folder has its contents removed prior to the compilation of Luzzu. If you already have your custom metrics and vocabulary installed and you need to re-compile Luzzu (say for example after an update of the framework or after a custom modification), then you can leave out the clean directive.
Executing the Framework
Maven handles the execution and initialisation of the web service and any external metrics added to Luzzu. After locating the luzzu directory, continue the following:
Luzzu/$ cd luzzu-communications/
luzzu-communications $ mvn exec:java -X
Web Service Invocation
The Luzzu web service can be invoked (by default) by the URI http://localhost:8080/luzzu/compute_quality. The compute_quality module accepts as input an instance of a DIACHRON dataset (an HTTP URI or FILE URI), a list of metrics required to be assessed and if a quality problem report is required. Port number and domain can be changed via the webservices.properties file. Changing the properties file would require a new build.
| Post | HTTP Method |
|---|---|
| Dataset - An instance of a DIACHRON dataset URI. QualityReportRequired - A boolean indicating whether a quality report is required. MetricsConfiguration - an object with a list of metrics in JSON-LD format |
Parameters |
| If QualityReportRequired is true, this method returns a quality report (e.g.a set of DIACHRON triple instances violating quality metrics). An empty model (which is not realistic) means that a model passed all the metrics and contain no metric violation. If QualityReportRequired is false, then the method would return only the dataset URI. | Returns |
|
Input Message Format and Example |
|
Output Message Format and Example |
Creating Custom Metrics
The Luzzu framework enables knowledge engineers without Java expertise to create quality metrics in a declarative manner. This is attributable to the fact that LQML caters for varying linked data quality metrics, which can be as basic as matching a particular triple pattern. An LQML rule is made up of METRIC, LABEL, DESCRIPTION, MATCH, and ACTION. Click here for LQML Documentation.
def{SubClassCounter}:
metric{<http://www.example.org/ebi/qm#SubClassCountingMetric>};
label{"SubClassCountingMetric"};
description{"Provides a measure for counting the number of resources that are defined as sub-classes"};
match{(?p == rdfs:subClassOf)};
action{count}.
The Luzzu framework's purpose is to allow third parties to create their own domain-specific quality metrics and then assess Linked Open Datasets using the framework itself. In order to create your own metrics, luzzu-assessment.jar has to be part of the build path (or adding the maven dependencies). The mentioned library consists of two main interfaces - de.unibonn.iai.eis.luzzu.assessment.QualityMetric and de.unibonn.iai.eis.luzzu.assessment.ComplexQualityMetric. The former allows developers to create simple metrics whilst the latter allows developers to define more complex quality metrics that might require pre-processing or post-processing.
When implementing the QualityMetric interface, the following methods need to be defined:
void compute(com.hp.hpl.jena.sparql.core.Quad quad);- This method should compute the metric. The processor automatically passes objects of type quad to the quality metric.double metricValue();- Returns the value of the Quality Metric.com.hp.hpl.jena.rdf.model.Resource getMetricURI()- Returns the URI of the Quality Metric.ProblemList<?> getQualityProblems();- Returns a typed ProblemList that will be used to create a problem report of the computed metric.
void before(Object ... args);- Pre-processing data before metric assessment.void after(Object ... args);- Post-processing data after metric assessment.
<repository>
<id>dropbox</id>
<url>http://dl.dropboxusercontent.com/u/5895290/mvn-repo</url>
</repository>
...
...
<dependency>
<groupId>de.unibonn.iai.eis</groupId>
<artifactId>luzzu-assessment</artifactId>
<version>1.0.1-RELEASE</version>
</dependency>Installing Custom Metrics
LQML metrics should be copied to a subfolder in the Luzzu/luzzu-communications/externals/metrics folder, with th extension .lmi. The external vocabulary should be copied to Luzzu/luzzu-communications/externals/vocabs.
Custom Java implemented metrics should be packaged as a JAR and copied together with the metrics.trig to Luzzu/luzzu-communications/externals/metrics, whilst the external vocabulary should be copied to Luzzu/luzzu-communications/externals/vocab.
The metrics.trig file should contain a list of all custom implemented metrics available in the packaged jar. The java metrics should be described using the Luzzu Metric Implementation ontology (see luzzu-semantics library/dependency).
A typical metric.trig configuration file can be viewed here.
Title
body