OWL ART API Command Line Utilities


In this page we provide a list of utilities embedded inside OWLART, which can be run from command line.


Please refer to the setup section of the usage documentation about OWLART. We just add here that you can either develop your own project and set its dependency to an OWLART implementation (as suggested in the setup), or you can just create a batch file, putting the owlart libraries and all their dependencies on the classpath, and then run the command line utilities as described below.

Packages containing OWLART, its sesame2 implementation, all related dependencies and some sample batch files are also available from the download page of the OWLART project site. They are exposed in the form: owlart-<version number>-dist

The following utilities have been made available from OWLART 2.1

Configuration files

OWLART 2.1 has a new load-through-configuration file modality which reduces the amount of code to write in order to bind a model to a certain configuration and to activate it. It is this dynamic configuration that made possible running these utilities via command line, without writing a single line of code.

We will soon document this more in detail. For now, we just provide an example of a configuration file:

#ModelFactory Implementation: required

#modelConfigClass Implementation: not required

#modelConfigFile : not required in Sesame2, though you may define an additional file for the specific model configuration



An example of the content of a <model configuration> config file (like the one referenced in the above configuration) is the following:

#inference settings are set to true by default. Better have them to false for using these utilities

OWL Utilities

These transformation utilities can be applied to OWL vocabularies

SubTree Extractor

This class implements a procedure to extract a subtree rooted on a given RDF resource. The tree may be represented by SKOS.BROADER for SKOS concept schemes or RDFS.SUBCLASSOF for OWL ontologies. The implementation here supposes that the input model has at least a hierarchy inference reasoner.

The class for this utility is: it.uniroma2.art.owlart.utilities.transform.SubTreeExtractor.

There is currently no main method for it, we will add it soon, however, it is possible to easily build an application with a main method invoking its doExtract() method.

SKOS Utilities

These utilities apply only to data modeled after the SKOS or SKOS-XL vocabularies.

SKOS <--> SKOS-XL Conversion

Two utilities in OWLART allow for conversion from SKOS to SKOS-XL and viceversa.

The class for converting from SKOS to SKOS-XL is: it.uniroma2.art.owlart.utilities.transform.SKOS2SKOSXLConverter. Here below we report the synopsis

it.uniroma2.art.owlart.utilities.transform.SKOS2SKOSXLConverter <config> <inputfilename> <outputfilename> <xLabelsAsURIs>


<config> is the path to the config file

<xLabelAsURIs> this may be either true or false. If true, URIs are generated for the skosxl:Labels, otherwise these are represented through bnodes.

The class for converting from SKOSXL to SKOS is: it.uniroma2.art.owlart.utilities.transform.SKOSXL2SKOSConverter. Here below we report the synopsis

it.uniroma2.art.owlart.utilities.transform.SKOSXL2SKOSConverter <config> <inputfilename> <outputfilename>

Flatten<-->Reified SKOS Definitions Converters

SKOS definitions can be represented in 3 differents ways, according to patterns described in the "Advanced Documentation Features" section of the SKOS Primer document). These utilities allow to switch between definitions as plain RDF literals (first pattern described in the above mentioned document) and reified definitions (second pattern).

Reification of flat skos:definitions

The class for reifying the values of skos:definitions is: it.uniroma2.art.owlart.utilities.transform.ReifiedSKOSDefinitionsConverter. Here below we report the synopsis

it.uniroma2.art.owlart.utilities.transform.ReifiedSKOSDefinitionsConverter <config> <inputfilename> <outputfilename> <createURIsForDefinitions> [groupLanguages] [copyALsoPlainDefinitions]


<config> is the path to the config file

<createURIsForDefinitions> this may be either true or false. If true, URIs are generated for the refied values, otherwise these are represented through bnodes.

The two last optional parameters (all default to false) are:

<groupLanguages>: if true, all the definitions in different languages for a same resource, are collapsed in the same reified definition

<copyAlsoPlainDefinitions>: if true, all the plain triples with skos:definition are maintained, coexisting with the reified ones

Flattening reified skos:definitions

The class for flattening reified skos:definitions (available from version 2.3 on) is: it.uniroma2.art.owlart.utilities.transform.ReifiedSKOSDefinitionsFlattener. Here below we report the synopsis

it.uniroma2.art.owlart.utilities.transform.ReifiedSKOSDefinitionsFlattener <config> <inputfilename> <outputfilename> [copyAlsoReifiedDefinitions]


<config> is the path to the config file

the optional parameter (which defaults to false) is:

[copyAlsoReifiedDefinitions] this may be either true or false. If true, the reified definitions are maintained in the output file


SKOS --> OWL Conversion

This rather unhortodox utility can be useful in some specific application scenarios. The rules used for this transformation are those adopted in the context of the OAEI 2012 Library Track.

The class for converting from SKOS to OWL is: it.uniroma2.art.owlart.utilities.transform.SKOS2OWLConverter. Here below we report the synopsis

it.uniroma2.art.owlart.utilities.transform.SKOS2OWLConverter ...
the main method for this class has yet to be written;
however, you can write an application exploiting the doConversion() method of this class

SKOS Fixing

Very often many tools for managing SKOS generate data which is not strictly adherent to the standard reference. This is also depending on the very informal specification of SKOS, which allows for many different choices, whereas this freedom often creates confusion.

In the class it.uniroma2.art.owlart.utilities.fix.SKOSFixing, we have collected utilities used to fix common mistakes in SKOS modeling.

The general synopsis is:

it.uniroma2.art.owlart.utilities.fix.SKOSFixing <config> <inputfilename> <outputfilename> <command> [other params]

where <command> represents the specific fixing utility which is being invoked.

The utility fixTopConceptOfOnlyDeclaration is used in those cases where only skos:topConceptOf declarations have been used to bind skos:Concepts to skos:ConceptSchemes, without adding the required (see skos specifications) skos:inScheme to their narrower concepts.

The synopsis for this utility is:

it.uniroma2.art.owlart.utilities.fix.SKOSFixing <config> <inputfilename> <outputfilename> <fixTopConceptOfOnlyDeclaration>


We have also provided two command line interfaces for running SPARQL queries through OWLART.

The class it.uniroma2.art.owlart.utilities.cli.SPARQLQueryCLI provides support for performing SPARQL queries via command line whille it.uniroma2.art.owlart.utilities.cli.SPARQLUpdateCLI does the same for SPARQL updates.

The synopsis for SPARQLQueryCLI is:

it.uniroma2.art.owlart.utilities.cli.SPARQLQueryCLI <config> <inputfilename> <queryFile> [outputfilename] [inference]

inference: true/false tells whether results should include inferred triples or not; defaults to false
all output format (both tuple and graph ones) are inferred from the output file extension or defaulted (tuple:xml; graph:ntriples)
Boolean queries always write to console");
if outputFileName has been specified, the output is written there, otherwise it is just prompted to console.

while the synopsis for SPARQLUpdateCLI is:

it.uniroma2.art.owlart.utilities.cli.SPARQLUpdateCLI <config> <inputfilename> <updateFile> <outputfilename> [inference]

inference: true/false tells whether results should include inferred triples or not; defaults to false
all output format (both tuple and graph ones) are inferred from the output file extension or defaulted (tuple:xml; graph:ntriples)

Note, there is a bug in OWLART 2.1 for which outputFileName is reported as optional in SPARQLUpdateCLI, while it must be provided. So providing 2 or less parameters results in a human understandable message on the console, reporting the synopsis of the command, while if 3 parameters are passed (so up to <updateFile> but excluding <outputFilename>) a null pointer exception will be returned.