The OntoLex W3C Community Group published its final report on the Lexicon Model for Ontologies (lemon) in May 2016, specifying a suite of vocabularies for the linguistic grounding of ontologies and RDF datasets in general. The Linguistic Metadata (LIME) vocabulary is the lemon module describing coarse-grained metadata about datasets as a whole, to represent resuming information at the level of ontology-lexicon interface. The purpose of this metadata is to support the understanding and exploitation of available lexical material, and in the first place to facilitate the discovery of datasets that may be of interest. Towards the realization of that vision, we propose an API that supports the manipulation of LIME metadata, as well as its automatic generation by means of a profiler. We discuss the architecture of the API, as well as the main design decisions, which can inform the development of APIs for other vocabularies.
The OntoLex W3C Community Group published its final report [
The realization of that grand vision clearly presupposes the adoption and consistent
use of the LIME vocabulary. As a first step in that direction, we propose an API for the
manipulation and generation of LIME metadata. This API is implemented in Java on
top of the RDF middleware RDF4J [
The paper is structured as follows: Section 2 motivates the need for a LIME API, which is then discussed thoroughly in Section 3. Section 4 evaluates our work. Section 5 discusses related works. Section 6 concludes the paper. 2
The OntoLex lemon specification is implemented as a collection of OWL ontologies, therefore RDF tools and libraries may be sufficient to manage OntoLex lemon data. However, they represent quite a low-level approach. While these RDF editors can be required to accomplish some tasks, tools dedicated to lemon can ease common tasks, and offer a simplified view even for non RDF-experts.
Our LIME API aims at achieving that simplification for the management of LIME metadata. On the one hand, the use of our API allows for detection of common errors at compile-time. On the other hand, composition allows expressing complex queries via the API in a type-safe manner. Conversely, writing a SPARQL query as a string in a computer program does not benefit from any check by the compiler (misspellings are quite common) nor from the possibility to compose and reuse existing fragments.
Finally, one of the greatest advantages of a widespread API for a given resource is the consistency it brings in accessing it, providing further semantics by means of common use. This aspect is mostly relevant in the LIME profiling component, which generates metadata about a dataset by inspecting it. An agreed implementation of the standard can thus guarantee that everybody computes the metadata in the same manner. 3
The LIME API consists of different layers providing assistance at progressively higher levels of abstraction. At the lowest level, a set of vocabulary classes define constants for the IRI defined by the OntoLex lemon specification, which can be used in a program in place of hardcoded strings (mitigating the risk of misspellings). Then a repository (connection) wrapper decorates the RDF4J API with operations tailored to the manipulation of LIME objects. At the highest level, the profiler disburdens the user from writing LIME metadata, by generating it automatically. 3.1
A first basic contribution of our API is a collection of vocabulary classes that provide constants for the IRIs defined by the OntoLex lemon specification. These vocabulary classes are alike the ones shipped by RDF4J for popular vocabularies.
The code in Fig. 1 provides an excerpt of the vocabulary class for the LIME module. These classes can be used in place of hand-written IRIs to manipulate RDF statements via RDF4J APIs such as the RepositoryConnection and Model APIs. In the fragment below we use the LIME vocabulary class for retrieving instances of the class lime:Lexicon: Set<Resource> lexicons = QueryResults.asModel(
conn.getStatements(null, RDF.TYPE, LIME.LEXICON)).subjects(); These vocabulary classes benefit developers with code completions and, to a limited extent, with static code checking: indeed, a misspelling in a constant identifier (e.g. LIME.LEXICON) is recognized as a compile-time error. Conversely, an error in a string literal (e.g. “http://www.w3.org/ns/lemon/lime#Lexicon”) does not produce a compile-time error, and usually manifests itself in the form of runtime failures (which have to be traced back to the causing defect in the source code). Regarding the last aspect, it is worth to notice that our vocabulary classes were generated automatically directly form the ontologies accompanying the OntoLex specification, by means of a small utility we developed for that purpose. 3.2
While discussing the vocabulary classes, we presented a small fragment of code for retrieving all lexicons described in a metadata file. Fragments such as that one clearly express some information need that is generic enough to be turned into a first-class operation of our API.
To that end we developed a connection wrapper that decorates a plain RDF4J connection to an RDF Repository with specific operations for the LIME vocabulary. public class LIME { public static final String NAMESPACE =
"http://www.w3.org/ns/lemon/lime#"; public static final String PREFIX = "lime"; public static final Namespace NS =
new SimpleNamespace(PREFIX, NAMESPACE); public static final IRI CONCEPTUALIZATION_SET; } // ... Additionally, we provided a repository wrapper that overrides the operation Repository#getConnection() to return a wrapper around a connection created by the delegate repository. The code fragment below demonstrates the creation of a repository wrapper, which is then used to obtain a connection wrapper.
LIMERepositoryWrapper repoWrapper =
new LIMERepositoryWrapper(repository); LIMERepositoryConnectionWrapper connWrapper = repoWrapper.getConnection();
The connection wrapper exposes an operation to retrieve all lexicons: Collection<Resource> lexicons =
QueryResults.asList(connWrapper.getLexicons());
Homogeneously with similar operators in RDF4J, the method getLexicons() returns an iterator-like object. The class QueryResults can be used to fetch all values from this iterator, and put them into an ordinary Java collection. We defined similar operations for retrieving lexicalization sets, concept sets, conceptualization sets and lexical linksets.
One advantage of APIs over the direct of use a query language such as SPARQL is their composability, in the sense that the result of an API invocation can be processed through other APIs. While useful for rapid prototyping, this approach has the known downside of performing badly as the size of the data increases. The reason is that the composition is performed by the client program, losing the optimizations implemented by a query engine.
Let us consider how the operations above can be used to retrieve lexicalization sets for a given reference dataset and language. Firstly, one would obtain an iterator over all lexicalization sets, and then for each one check (with a separate API invocation) its language and reference dataset. This algorithm clearly requires a number of API calls proportional to the number of available lexicalization sets. Moreover, when the repository connection is accessing a remote dataset, each invocation entails a network roundtrip-time and the transmission of potentially irrelevant data (i.e. every lexicalization set not matching the user criterion).
Alternatively, one could write just one SPARQL query and move the entire computation to the query engine, which would return only the relevant data. However, this approach is not compositional, and does not benefit from compile-time checks. Actually, if an information need is sufficiently recurring, it can be reasonable to promote the associated SPARQL query to a new operation in the API.
Nonetheless, in our API we reconcile compositionality and efficiency, by allowing the user to specify as Java code complex matching conditions that are then translated into a SPARQL query for efficient execution.
Our design was inspired by the library Hamcrest [
The fragment below shows how to retrieve lexicalization sets matching the aforementioned conditions on reference dataset and language: Collection<Resource> lexicalizationSets =
QueryResults.asList(conn.getLexicalizationSets( suchThat( language("en"), referenceDataset("http://example.org/referenceDataset1") )));
The API invocation above produces the following SPARQL query, which corresponds to the user’s expressed information need: SELECT ?v0 WHERE { ?v0 a lime:LexicalizationSet . ?v0 lime:language "en" . ?v0 lime:referenceDataset
<http://example.org/referenceDataset1> .
}
The method getLexicalizationSets expects a Matcher<? super
LexicalizationSet> producing the SPARQL fragment expressing the desired selection
criterion over lexicalization sets. Matcher is a generic interface, which can be
instantiated with a Java type representing the class of resources over which the criterion is
defined. The interface LexicalizationSet in the example is just one of the
interfaces we defined to represent the classes in the LIME vocabulary. Following the
example of the Guava library [
Our information need can be made even more complex, for example by requesting conceptualization sets with an average ambiguity less than 0.5 for an English lexicon the subject of which is agriculture, as for the example in Fig. 2
The fact that we push the comparison down into the SPARQL query, allows us to take advantage of the optimizations that some triple stores implement (e.g. GraphDB: http://graphdb.ontotext.com/documentation/free/storage.ht ml#literal-index). 3.3
The peak of the contribution of the LIME API is a profiler, which automates the computation of LIME metadata for different scenarios. As already said, the necessity of this component is determined by the need for a reference implementation of the metrics defined by the OntoLex specification.
Under the hood, the profiler executes some SPARQL queries on the provided dataset, recognizing the main types of dataset defined by LIME. Currently, the profiler is able to recognize lexicalizations of ontologies and thesauri expressed as RDFS and SKOS(-XL) labels, as well as using lemon lexical entries.
The behavior of the profiler can be controlled via configuration parameters, as well as an initial set of LIME metadata, e.g. telling the name and void:uriSpace of distributed reference datasets not contained in the profiled data. Work is underway to Collection<Resource> conceptualizationSets = QueryResults .asList(conn.getConceptualizationSets( suchThat( avgAmbiguity(lessThan(0.5)), lexiconDataset( suchThat(language("en"),hasProperty(DCTERMS.SUBJECT, vf.createIRI(
"http://dbpedia.org/resource/Agriculture") ) )); )
)) SELECT ?v0 { ?v0 rdf:type lime:ConceptualizationSet . ?v0 lime:avgAmbiguity ?v1 .
FILTER( ?v1 < "0.5"^^xsd:decimal) ?v0 lime:lexiconDataset ?v2 . ?v2 lime:language "en" .
?v2 dct:subject <http://dbpedia.org/resource/Agriculture> . complete the support for other dataset types defined in lemon, e.g. concept sets, conceptualization sets and lexical linksets.
Fig. 3 reports an excerpt of the metadata generated from a dump of the EuroVoc1 thesaurus. In this scenario, the main dataset coincides with the reference dataset, and a number of void:subsets correspond to lexicalizations in different natural languages: for conciseness, we only show the details of the Italian lexicalization set. Currently, we assume that void:entities in the reference dataset gives the number of potentially lexicalizable resources, and thus that it can be used to compute lime:percentage and lime:avgNumOfLexicalizations. In case of thesauri, we count as entities only concepts, collections and concept schemes. So the fact that the number of lexicalized references is higher than the number of concepts is explained by the labels attached to concept schemes. The current implementation of the profiler does not collapse country-specific variants, and counts lexical entries by canonical form (altough the specification in some cases seems to suggest to count the lexical entry resources).
The AGROVOC [
foaf:primaryTopic meta:EuroVoc . meta:EuroVoc a void:Dataset ; void:triples 2505003 ; dct:conformsTo <http://www.w3.org/2004/02/skos/core> ; void:classPartition [void:class skos:Concept ;
void:entities 7172 ], … ; void:entities 7302 ; void:subset meta:EuroVoc_mt_lexicalization_set, … . meta:EuroVoc_mt_lexicalization_set a lime:LexicalizationSet; dct:language <http://id.loc.gov/vocabulary/iso639-1/it> , <http://lexvo.org/id/iso639-3/ita> ; lime:avgNumOfLexicalizations 2.537 ; lime:language "it" ; lime:lexicalizationModel <http://www.w3.org/2008/05/skosxl> ; lime:lexicalizations 18521; lime:percentage 0.997 ; lime:referenceDataset meta:EuroVoc ; lime:references 7273 . 1 http://eurovoc.europa.eu/ 2 http://aims.fao.org/aos/agrovoc/void.ttl Our primary means for evaluating the LIME API was a set of unit tests accompanying its source code. Concerning the repository (connection) wrapper, the unit tests allowed us to spot a number of programming errors, which would have prevented some combination of conditions. The relevance of unit tests for the profiler is instead determined by their ability to function as an executable specification of what is the expected metadata for different dataset types. These tests verify that the profiler meets its specification, while their small size allows manual computation and verification of the statistics, so that we can ascertain the correctness of the specification, and ultimately validate our software. We hope that a few people knowledgeable about lemon will verify by hand these test cases, thus strengthening our confidence in the correctness of the profiles, especially when the profiler is applied to datasets sufficiently large that verification by hand is almost impossible. We believe that the efficiency gain of our approach to API composition has already been supported convincingly, while the scalability of the profiler required some empirical verification. To that end, we considered two very large thesauri encoded in SKOS: AGROVOC and EuroVoc. We performed the experiments on a Notebook equipped with an Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 24 GB of RAM DDR3 1600 MHz, Windows Home 10 64bit operating system and Oracle JDK 8 (build 1.8.0_121-b13). Table 1 reports the total required time, as well as its break out into time to load the data and time to produce the metadata. 5
Our LIME API is similar in purpose to existing APIs for lemon, such the one [
Both the M-ATOLL and the Monnet lemon API define an object-oriented model
corresponding to the (Monnet) lemon ontology. However, they differ in how they
implement that model. The M-ATOLL API uses the RDF middleware Apache Jena
[
The profiling module for the automatic generation of LIME metadata is related to
works on dataset analytics. With this regard, LODStats [
A related use case is the integration of the profiler into an RDF/ontology/thesaurus
editor as a means to better understand the dataset being edited from the perspective of
available lexical material. Current support for statistics inside editors is limited to
lower-level structural characteristics. TopBraid Composer [
The aforementioned LODStats and LOV already report languages used in a dataset. However, they do not fulfill the needs of the OntoLex community for a mechanism to discover related but independently published lexical material. In fact, LOV supports this interlinking at the level of vocabularies, by making explicit the relationships between vocabularies and their use in datasets. 6
As we envisaged [
Towards the realization of such a scenario, our work on LIME API intends to foster
the creation of LIME metadata describing lexical assets published on the Semantic
Web. In order to reach end-users, we also aim plan to seamlessly support the use of the
lemon vocabulary in the third version of our thesaurus/ontology editor VocBench [
Concerning the lower levels of the API for data manipulation, we will extend them with additional operations (in particular, write operations), borrowing and integrating ideas from previous lemon APIs. Depending on the feedback of the community, we will also consider to support other lemon modules (starting from the core). Similarly, we will investigate the usefulness of an extension of the LIME module to support other lemon modules in addition to the core one.
Acknowledgments. This work has been partially funded by the ISA2 Work Programme action for the realization of the VocBench 3 collaborative editing platform for ontologies and thesauri: https://ec.europa.eu/isa2/solutions/vocbench3
Monnet
Project.
Available