Linked Open Vocabularies (LOV): A gateway to reusable semantic vocabularies on the Web

Abstract

One of the major barriers to the deployment of Linked Data is the difficulty that data publishers have in determining which vocabularies to use to describe the semantics of data. This systematic report describes Linked Open Vocabularies (LOV), a high-quality catalogue of reusable vocabularies for the description of data on the Web. The LOV initiative gathers and makes visible indicators such as the interconnections between vocabularies and each vocabulary’s version history, along with past and current editor (individual or organization). The report details the various components of the system along with some innovations, such as the introduction of a property-level boost in the vocabulary search scoring that takes into account the property’s type (e.g., dc:comment) associated with a matching literal value. By providing an extensive range of data access methods (full-text search, SPARQL endpoint, API, data dump or UI), the project aims at facilitating the reuse of well-documented vocabularies in the Linked Data ecosystem. The adoption of LOV by many applications and methods shows the importance of such a set of vocabularies and related features for ontology design and the publication of data on the Web.

1. Introduction

The last two decades have seen the emergence of a “Semantic Web” enabling humans and computer systems to exchange data with unambiguous, shared meaning. This vision has been supported by World Wide Web Consortium (W3C) Recommendations such as the Resource Description Framework (RDF), RDF-Schema and the Web Ontology Language (OWL). Thanks to a major effort in publishing data following Semantic Web and Linked Data principles [6], there are now tens of billions of facts spanning hundreds of linked datasets on the Web covering a wide range of topics. Access to the data is facilitated by portals (such as Datahub1

¹

http://datahub.io/.

or UK Government Data2 ²

http://data.gov.uk/.

) or direct publication by organisations (e.g. New York Times3 ³

http://data.nytimes.com/.

).

Despite the enormous volume of data now available on the Web, the Linked Data community has relatively little interest in vocabulary4 ⁴

We use the terms “semantic vocabulary”, “vocabulary” and “ontology” interchangeably.

management, focusing rather on the data itself. A vocabulary consists of classes, properties and datatypes that define the meaning of data. RDF vocabularies are themselves expressed and published following the Linked Data principles; this gives humans and machines access to the definitions of the terms used to qualify the data. Unfortunately some vocabularies are not published or are no longer not available; this breaks the semantic interoperability of the data, one of the fundamental principles of the Semantic Web [16].

The Linked Open Vocabularies (LOV) initiative5 ⁵

http://lov.okfn.org/dataset/lov/.

is an innovative observatory of the semantic vocabularies ecosystem. Started in March 2011, as part of the DataLift research project [27] and hosted by the Open Knowledge Foundation, LOV gathers and makes visible indicators not previously harvested, such as the interconnections between vocabularies, the versioning history along with past and current editor (individual or organization). The number of vocabularies indexed by LOV is constantly growing (527 as of October 2015) thanks to a community effort. It is the only catalogue, to the best of our knowledge, that accepts all types of search criteria: metadata search, ontology search, APIs, a comprehensive dump file and SPARQL endpoint access.

The purpose of LOV is to promote and facilitate the reuse of well documented vocabularies in the Linked Data ecosystem. In D’Aquin and Noy [12]’s categorisation of ontology libraries, LOV falls into the categories “curated ontology directory” and “application platform”. Specifically, LOV supports the following main activities for the design of ontologies and the publication of data on the Web [19,20,30,32]:

Ontology Search.

LOV enables searching for vocabulary terms (class, property, datatype) based on domain: vocabularies (and therefore vocabulary terms) are categorised according to the domain they address.

Ontology Assessment.

LOV provides a ranking (cf. Section 3.3.1 for each term retrieved by a keyword search to assist in ontology assessment.

Ontology Mapping.

LOV categorizes seven different types of relationships between ontologies: metadata, import, specialization, generalization, extension and equivalence (cf. Section 3.1.1). These relationships can be useful for finding alignments between ontologies.

This report is structured as follows: in the next section, we provide statistics on the usage of LOV. In Section 3, we describe the components and features of the system. Thereafter, in Section 4, we provide an overview of some applications and research projects based on and motivated by the LOV system. In Section 5, we report on related work. The limitations and further development of LOV are discussed in Section 6. We conclude in Section 7.

2. LOV state

Fig. 1.

Evolution of the number of vocabularies in LOV from March 2011 to June 2015.

The LOV dataset consists of 527 vocabularies as of October 2015.6 ⁶

However, the figures and evaluation used in this report are based on LOV catalogue with 511 vocabularies as of June 2015.

Figure 1 shows the evolution of the number of vocabularies inserted in the LOV dataset since March 2011. The addition of new vocabularies to LOV has been fairly constant with two exceptions: 1) the deployment of LOV version 2 [early 2012] automated most of the vocabulary analyses, resulting in the increase number of vocabularies; and 2) the deployment of LOV version 3 [early 2015], resulting in a small decrease and plateau of the vocabularies. At that time we were considering removing offline vocabularies but finally decided to keep them with a special flag, making LOV the only source of continuity for datasets referencing unreachable vocabularies.

By observing the vocabularies contained in LOV as a whole, we can extract some information about Semantic Web adoption and dynamics. Figure 2 shows the distribution of LOV vocabularies by creation date. The distribution follows a bell curve with its peak in 2011. It is worth noting that a decrease in number of vocabulary creation does not necessarily mean a decrease in use of the technology but rather that the existing vocabularies now cover a large part of the semantic description needed. When looking at the last modified date of the same vocabularies (as illustrated in Fig. 3), we see that LOV vocabularies are part of a living ecosystem in constant evolution.

Fig. 2.

Distribution of LOV vocabularies by creation date. For indication, we use vertical red lines to mark the official release dates of the main Semantic Web languages (RDF, RDFS and OWL).

Fig. 3.

Distribution of LOV vocabularies by last modified date.

Overall, the LOV dataset contains 20,000 classes and almost 30,000 properties. The median is 9 classes and 17 properties per vocabulary. Table 1 presents a breakdown of LOV content by vocabulary element type. In this Table, the Classes type refers to any instance of rdfs:Class or owl:Class; the Properties type refers to any instance of rdf:Property or by inference, any instance of subclasses of rdf:Property defined in the OWL language; the Datatypes type refers to any instance of rdfs:Datatype; and finally, the members of a vocabulary class are known as instances of the class.

Table 1

LOV vocabulary element types statistics

Type	Count	Median per vocab
Properties	29,925	17
Classes	20,034	9
Instances	5,232	0
Datatypes	101	0

Table 2

Top five languages detected in the LOV catalogue, showing numbers and percentages of vocabularies using them. A vocabulary can make use of multiple languages

Language	# vocabs	% vocabs (out of 511)
English	338	66.14%
French	37	7.24%
Spanish	25	4.89%
German	19	3.72%
Italian	18	3.52%

Fig. 4.

Distribution of LOV vocabularies by number of languages explicitly mentioned using language tag. “Zero” means that there is no explicit language tag declared (i.e. no literal value of the vocabulary has a language tag).

Table 3

Type of elements searched from January to June 2015 by users in LOV for all searches and those with keyword

Element Type	# searches	% searches	# searches with keyword	% searches with keyword
Term	205,682	14.19%	80,728	92.84%
Vocabulary	178,837	12.34%	5,918	6.81%
Agent	1,064,597	73.47%	306	0.35%

Out of 511 vocabularies, 66.14% explicitly use the English language for labels/comments, i.e. containing @en tag. Table 2 presents the number and percentage of vocabularies using the top five languages detected in LOV. Figure 4 shows the distribution of vocabularies per number of languages explicitly used: 27.98% of the vocabularies still do not provide any language information, and only 14.68% of the vocabularies are multilingual. In total, 45 languages are used by vocabularies in LOV. We will discuss the importance of providing multilingual vocabularies in Section 7.

From January to June 2015, more than 1.4 million searches were conducted on LOV.7 ⁷

This figure includes searches from the API and UI as well as searches with and without keywords such as “all agents that participated in vocabulary design and publication in the geo-location domain”.

A breakdown of searches per element type is provided in Table 3. We can see that agent search (for person or organisation) is the most prevalent; this is a new feature in LOV version 3. This might be explained by the uniqueness (when compared to other ontology catalogues) and the recent development of this feature in LOV, which now allows a user to visualise who defined or published vocabularies. Searches that include keywords (and not only filters) are mainly seek vocabulary terms. Table 4 presents the top 10 searched terms between January and June 2015. Although most of the searches are performed through the user interface, an application ecosystem using LOV APIs has surfaced, as shown in Fig. 5.

Table 4

Top 10 terms searched from January to June 2015 by users in LOV

Vocabulary Term	# searches	% searches
set	7,092	8.79%
domain	2,518	3.12%
some	2,473	3.06%
status	1,486	1.84%
iso 639	1,389	1.72%
same	1,285	1.59%
state	1,235	1.53%
supports	1,145	1.42%
start	887	1.1%
space	864	1.07%

Fig. 5.

Evolution of the number of searches through UI and API methods from January to June 2015. Note that the y axis has a logarithmic scale.

Since 2011, the Linked Open Vocabularies initiative has gathered a community of about 480 people interested in various domains, including ontology engineering and data publication. The LOV Google+ community8 ⁸

https://plus.google.com/communities/108509791366293651606.

is now an important place to discuss, report and announce general facts related to vocabularies on the Web. The LOV dataset itself references 389 resources of type Person and 111 of type Organization participating in vocabulary design and/or publication.

3. System components and features

The LOV architecture is composed of four main components (cf. Fig. 6): 1) Tracking and Analysis. Checks for any vocabulary version update and analyses vocabularies’ specific features. 2) Curation. Ensures the high quality of the LOV dataset by enabling the community to suggest vocabularies or edit the catalogue. 3) Data Access. Provides access to the data through a large range of methods and protocols to facilitate the use of LOV dataset and 4) Data Storage. Offers a reliable and efficient method for storing and querying the data. Each component provides a set of features detailed in the following subsections.

Fig. 6.

Overview of the Linked Open Vocabularies Architecture.

3.1. Tracking and analysis

The Tracking and Analysis component dereferences9

⁹

A URI is looked up over HTTP to return content in a processable format such as XML/RDF, Notation 3 or Turtle.

LOV vocabularies, stores a version locally (in Notation 3 format) and extracts relevant metadata.

3.1.1. Vocabulary level analysis

At the vocabulary level, the system extracts three types of information for each vocabulary version (Fig. 7):

• The metadata associated to the vocabulary. This information is explicitly defined within the vocabulary to provide context and useful data about the vocabulary. Some high level vocabularies can be reused for that purpose, such as Dublin Core10

  ¹⁰

  http://purl.org/dc/terms/.

  to describe authors, contributors, publishers or Creative Commons11 ¹¹

  http://creativecommons.org/ns#.

  for the description of a license.

  Inlinks/incoming vocabularies, making explicit the links from another vocabulary based on the semantic relation of their terms.

  Outlinks/outgoing vocabularies, making explicit the links to another vocabulary based on the semantic relation of their terms.

  

  Fig. 7.

  Metadata type, vocabulary inlinks and outlinks of DCAT vocabulary.

  Two vocabularies can be interlinked in many different ways. Consider two vocabularies $\mathit{V}1$ and $\mathit{V}2$ such that $\mathit{V}1$ contains a class $\mathit{c}1$ and a property $\mathit{p}1$ and $\mathit{V}2$ contains a class $\mathit{c}2$ and a property $\mathit{p}2$ . Relationships between these two vocabularies can be of the following types (the lines and numbers in brackets correspond to real examples presented in Listing 1):

  Metadata.

  Some terms from $\mathit{V}2$ are reused to provide metadata about $\mathit{V}1$ , Listing 1 lines 1–2.

  Import.

  Some terms from $\mathit{V}2$ are reused with $\mathit{V}1$ to capture the semantic of the data (lines 3 to 4).

  Specialization.

  $\mathit{V}1$ defines some subclasses or subproperties (or local restrictions) of $\mathit{V}2$ , Listing 1 lines 5–8.

  Generalization.

  $\mathit{V}1$ defines some superclasses or superproperties of $\mathit{V}2$ , Listing 1 lines 9–11.

  Extension.

  $\mathit{V}1$ extends the expressivity of $\mathit{V}2$ , Listing 1 lines 12–15.

  Equivalence.

  $\mathit{V}1$ declares some equivalent classes or properties with $\mathit{V}2$ , Listing 1 lines 16–20.

  Disjunction.

  $\mathit{V}1$ declares some disjunct classes with $\mathit{V}2$ , Listing 1 lines 21–23.

  

  Listing 1.

  Examples of Inter-vocabulary relationships.

  These relationships, with the exception of Import which is represented by owl:imports, are captured by the Vocabulary of a Friend12 ¹²

  http://lov.okfn.org/vocommons/voaf/.

  (VOAF). Whenever a new vocabulary/vocabulary version is added to LOV, the system automatically detects and adds the inter-vocabulary relationships to the LOV catalogue using specific Construct SPARQL queries.13 ¹³

  The SPARQL Queries are described in the VOAF vocabulary.

  Table 5 presents a breakdown of the occurrences of each relation in LOV.

  Table 5

  Inter-vocabulary relationship types and their number of occurrences in LOV

  Inter-vocabulary relationship	# relations
  voaf:metadataVoc	2,637
  voaf:specializes	1,269
  voaf:extends	1,031
  owl:imports	373
  voaf:hasEquivalencesWith	201
  voaf:generalizes	57
  voaf:hasDisjunctionsWith	16

  3.1.2. Vocabulary term level analysis

  At the vocabulary term level, the system extracts two types of information:

3.3. Data access

The LOV system (code and data) is published under a Creative Commons 4.0 license17

¹⁷

https://creativecommons.org/licenses/by/4.0/.

(CC BY 4.0). Users and applications can access the LOV data in four ways:

1. Query the LOV search engine to find the most relevant vocabulary terms, vocabularies or agents matching keywords and/or filters;

2. Download data dumps of the LOV catalogue in RDF Notation 3 format or the LOV catalogue and the latest version of each vocabulary in RDF N-quads format;

3. Run SPARQL queries on the LOV SPARQL Endpoint; and

4. Use the LOV API which provides a full access to LOV data for software applications.

3.3.1. Search engine

In [9], Butt et al. compare eight different ranking methods grouped in two categories for querying vocabulary terms:

Content-based Ranking Models: tf-idf, BM25, Vector Space Model and Class Match Measure.

Graph-based Ranking Models: PageRank, Density Measure, Semantic Similarity Measure and Betweenness Measure.

Based on their findings, we defined a new ranking method adapting term frequency inverse document frequency (tf-idf) to the graph-structure of vocabularies. Compared to the other methods, tf-idf takes into account the relevance and importance of a resource to the query when assigning a weight to a particular vocabulary for a given query term. We reuse the augmented frequency variation of term frequency formula to prevent a bias towards longer vocabularies. Because of the inherent graph structure of vocabularies, tf-idf needs to be tailored so that the basic unit is not a word, but rather a vocabulary term t in a vocabulary V. Equation (1) presents the adaptation of tf-idf to vocabularies (a definition of the variables used in this paper’s equations is provided in Table 6).

$$\begin{array}{}\text{(1)}& \begin{array}{cc}\hfill \mathit{tf}\mathrm{(}\mathit{t}\mathrm{,}\mathit{V}\mathrm{)}& =0.5+{\displaystyle \frac{0.5\ast \mathit{f}\mathrm{(}\mathit{t}\mathrm{,}\mathit{V}\mathrm{)}}{max\{\mathit{f}\mathrm{(}{\mathit{t}}_{\mathit{i}}\mathrm{,}\mathit{V}\mathrm{)}:{\mathit{t}}_{\mathit{i}}\in \mathit{V}\}}}\hfill \\ \hfill \mathit{idf}\mathrm{(}\mathit{t}\mathrm{,}\mathcal{V}\mathrm{)}& =log{\displaystyle \frac{|\mathit{V}|}{|\{\mathit{V}\in \mathcal{V}:\mathit{t}\in \mathit{V}\}|}}\hfill \end{array}\end{array}$$

Table 6

Definition of the variables used in the equations

Variable	Description
$\mathcal{V}$	Set of Vocabularies
V	A vocabulary: $\mathit{V}\in \mathcal{V}$
$|\mathit{V}|$	Number of vocabularies in $\mathcal{V}$
t	A vocabulary term URI (class, property, instance or datatype): $\mathit{t}\in \mathit{V}$ , $\mathit{t}\in \mathit{URI}$
Q	Query string
${\mathit{q}}_{\mathit{i}}$	Query term i of Q
${\mathit{\sigma }}_{\mathit{V}}$	Set of matched URIs for Q in V
${\mathit{\sigma }}_{\mathit{V}}\mathrm{(}{\mathit{q}}_{\mathit{i}}\mathrm{)}$	Set of matched URIs for ${\mathit{q}}_{\mathit{i}}$ in $\mathit{V}:\forall {\mathit{t}}_{\mathit{i}}\in {\mathit{\sigma }}_{\mathit{V}}$ , ${\mathit{t}}_{\mathit{i}}\in \mathit{V}$ , ${\mathit{t}}_{\mathit{i}}$ matches ${\mathit{q}}_{\mathit{i}}$
p	A term predicate: $\mathit{p}\in \mathit{URI}$
$\mathcal{D}$	Set of Datasets
D	A Dataset: $\mathit{D}\in \mathcal{D}$
$\mathit{M}\mathrm{(}{\mathit{t}}_{\mathit{i}}\mathrm{)}$	Number of Datasets: D in $\mathcal{D}$ , ${\mathit{t}}_{\mathit{i}}\in \mathit{D}$

As highlighted in [9] and [26], the notion of the vocabulary term’s popularity across the LOD datasets set $\mathcal{D}$ is quite important. In Eq. (2) we introduce a new popularity measure, which is a function of the normalisation of the frequency $\mathit{f}\mathrm{(}\mathit{t}\mathrm{,}\mathcal{D}\mathrm{)}$ of a term URI t in the set of datasets $\mathcal{D}$ and the normalisation of the number of datasets in which a term URI appears $\mathit{M}\mathrm{(}\mathit{t}\mathrm{)}:\mathit{t}\in \mathcal{D}$ . By using the maximum in this normalisation we emphasise the most used terms, result of a consensus within the community. This measure will give a higher score to terms that are often used in datasets and across a large number of datasets. $$\begin{array}{ll}\hfill \mathit{pop}\mathrm{(}\mathit{t}\mathrm{,}\mathcal{D}\mathrm{)}& ={\displaystyle \frac{\mathit{f}\mathrm{(}\mathit{t}\mathrm{,}\mathcal{D}\mathrm{)}}{max\{\mathit{f}\mathrm{(}{\mathit{t}}_{\mathit{i}}\mathrm{,}\mathcal{D}\mathrm{)}:{\mathit{t}}_{\mathit{i}}\in \mathcal{D}\}}}\\ \text{(2)}& \hfill & \ast {\displaystyle \frac{\mathit{M}\mathrm{(}\mathit{t}\mathrm{)}}{max\{\mathit{M}\mathrm{(}{\mathit{t}}_{\mathit{i}}\mathrm{)}:{\mathit{t}}_{\mathit{i}}\in \mathcal{D}\}}}\end{array}$$

RDF datasets have a consensual and stable structure, which arises from the best practices of vocabulary publication. It then becomes intuitive to assign more importance to a vocabulary term matching a query on the value of the property rdfs:label than dcterms:comment. Equation (3) extends the inner field-length norm $\mathit{lengthNorm}\mathrm{(}\mathit{field}\mathrm{)}$ from the Lucene-based search engine Elasticsearch, which attaches a higher weight to shorter fields, by combining it with a property-level boost $\mathit{boost}\mathrm{(}\mathit{p}\mathrm{(}\mathit{t}\mathrm{)}\mathrm{)}$ . Using this property-level boost we can assign a different score depending on which label property a query term matches. We distinguish four categories of matches:

Local name (URI without the namespace). While a URI is not supposed to carry any meaning, it is a convention to use a compressed form of a term label to construct the local name. The local name therefore becomes an important artifact for term matching for which the highest score will be assigned. An example of local name matching the term “person” is http://schema.org/Person.

Primary labels. The highest score will also be assigned for matches on the rdfs:label, dce:title, dcterms:title, skos:prefLabel properties. An example of primary label matching the term “person” is rdfs:label "Person"@en.

Secondary labels. We define as secondary label the following properties: rdfs:comment, dce:description, dcterms:description, skos:altLabel. A medium score is assigned for matches on these properties. An example of secondary label matching the term “person” is dcterms:description"Examples of a Creator include a person, an organization, or a service."@en.

Tertiary labels. Finally all properties not falling in the previous categories are considered as tertiary labels for which a low score is assigned. An example of tertiary label matching the term “person” is rdarel2:name "Person"@en.

$$\begin{array}{ll}\hfill \mathit{norm}\mathrm{(}\mathit{t}\mathrm{,}\mathit{V}\mathrm{)}& =\mathit{lengthNorm}\mathrm{(}\mathit{field}\mathrm{)}\\ \text{(3)}& \hfill & \ast {\displaystyle \prod }_{\mathit{p}\in \mathit{V}}\mathit{boost}\mathrm{(}\mathit{p}\mathrm{(}\mathit{t}\mathrm{)}\mathrm{)}\end{array}$$

For every vocabulary in LOV, terms (classes, properties, datatypes, instances) are indexed and a full text search feature is offered.18 ¹⁸

http://lov.okfn.org/dataset/lov/terms.

Human users or agents can further narrow a search by filtering on term type (class, property, datatype, instance), language, vocabulary domain and vocabulary.

Fig. 8.

The LOV catalogue RDF schema model, in a UML class diagram representation.

The final score of t for a query Q (Eq. (4)) is a combination of the tf-idf, the importance of label properties of t on which query terms matched, and the popularity of that term in the LOD dataset. While the factorisation of the tf-idf and field normalisation factor is common for search engine ranking,19 ¹⁹

See elasticsearch documentation: http://bit.ly/1e37sFL.

we add a fourth parameter – the popularity – as it is fundamental in the Semantic Web. Indeed, the intention of LOV is to foster the reuse of consensual vocabularies that become de facto standards. The popularity metric provides an indication on how widely a term is already used (in frequency and in the number of datasets using it). We therefore add this new factor specific to the Semantic Web to the scoring equation: $$\begin{array}{ll}\hfill \mathit{score}\mathrm{(}\mathit{t}\mathrm{,}\mathit{Q}\mathrm{)}& =\mathit{tf}\mathrm{(}\mathit{t}\mathrm{,}\mathit{V}\mathrm{)}\ast \mathit{idf}\mathrm{(}\mathit{t}\mathrm{,}\mathcal{V}\mathrm{)}\\ \hfill & \ast \mathit{norm}\mathrm{(}\mathit{t}\mathrm{,}\mathit{V}\mathrm{)}\ast \mathit{pop}\mathrm{(}\mathit{t}\mathrm{,}\mathcal{D}\mathrm{)}\\ \text{(4)}& \hfill & :\forall \mathit{t}\{\exists {\mathit{q}}_{\mathit{i}}\in \mathit{Q}:\mathit{t}\in {\mathit{\sigma }}_{\mathit{V}}\mathrm{(}{\mathit{q}}_{\mathit{i}}\mathrm{)}\}\end{array}$$

3.3.2. Data dumps

The system provides two data dumps, one containing the LOV vocabulary catalogue only in RDF Notation 3 format20

²⁰

http://lov.okfn.org/lov.n3.gz.

and another containing the LOV catalogue along with the latest version of each vocabulary and the statistics of use in LOD in RDF N-quads format21 ²¹

http://lov.okfn.org/lov.nq.gz.

(keeping each vocabulary in a separate named graph). As illustrated in Fig. 8, the RDF model mainly reuses the Data CATalogue Vocabulary (DCAT) which allows the representation of the LOV catalogue as a dcat:Catalog composed of vocabulary entries (dcat:CatalogRecord) capturing information like the insertion date in LOV. Each entry point to the vocabulary itself is represented by a sub class of dcat:Dataset defined in the Vocabulary Of A Friend (VOAF). This artifact contains metadata extracted by the LOV application such as creators, first issued date, number of occurrences of the vocabulary in Linked Open Data. Each vocabulary is then linked to its various published versions represented by the dcat:Distribution entity on which information such as inter-vocabulary relations or languages can be found.

3.3.3. SPARQL endpoint

The LOV SPARQL endpoint22

²²

http://lov.okfn.org/dataset/lov/sparql.

offers a complementary data access method and allows clients to pose complex queries to the server and retrieve direct answers computed over the LOV dataset [8]. We use the Jena Fuseki triple store to store the N-quads file containing the LOV catalogue and the latest version of each vocabulary. We believe that this is the first service that allows users to query multiple vocabularies at the same time and to detect inter-vocabulary dependencies.

Fig. 9.

List of APIs to access LOV data.

3.3.4. LOV application program interfaces and user interfaces

LOV APIs give a remote access to the many functions of LOV through a set of RESTful services.23

²³

http://lov.okfn.org/dataset/lov/apidoc/.

The basic design requirements for these APIs is that they should allow applications to get access to the very same information humans do via the User Interfaces. More precisely the APIs give access, through three different services (cf. Fig. 9), to functions related to:

• Vocabulary terms (classes, properties, datatypes and instances). With these functions, a software application can query the LOV search engine, ask for auto-completion or a suggestion for misspelled terms.

• Vocabularies. A client can get access to the current list of vocabularies contained in the LOV catalogue; search for vocabularies, get auto-completion or obtain all details about a vocabulary.

• Agents. This provides a software agent with a list of all agent references in the LOV catalogue, a means to search for an agent, get auto-completion and details about an agent.

LOV APIs are a convenient means to access the full functionality and data of LOV. It is particularly appropriate for dynamic Web applications using scripting languages such as JavaScript. The APIs described above have been developed for, and follow the requirements of, Ontology Design and Data Publication tools.

The LOV Website offers intuitive navigation within the vocabularies catalogue. It allows users to explore vocabularies, vocabulary terms, agents and languages, and to see the connections between these entities. For instance, a user can use the agent search to look for experts in geography and geometry domains.24 ²⁴

http://lov.okfn.org/dataset/lov/agents?&tag=Geography,Geometry.

We use the d325 ²⁵

http://d3js.org/.

JavaScript library [7] to display charts and make the navigation more interactive; for example, we use the star graph representation to display incoming and outgoing links between vocabularies (cf. Fig. 10).

Fig. 10.

A graphical representation of the incoming and outgoing links for the Schema.org vocabulary as displayed in the UI.

3.4. Data storage

To support the features presented above, we make use of specific storage technologies. The LOV catalogue is stored in MongoDB^®, a document-based schema-less data store that scales and allows for dynamic changes in the data schema.26

²⁶

https://www.mongodb.org/.

We use Jena Fuseki27 ²⁷

https://jena.apache.org/documentation/serving_data/.

to serve the data exported in RDF through the SPARQL protocol. The search feature is supported by Elasticsearch^®, a full text index based on Lucene technology.28 ²⁸

https://lucene.apache.org/.

This storage solution is particularly well adapted to our User Interface technology (Node.js) as it offers RESTful APIs with output in JSON format. Finally we store each vocabulary version file and RDF dumps of LOV catalogue in the environment file system.

4. LOV adoption

LOV, with its various data access methods, supports the emergence of a rich application ecosystem. Below we list some tools using our system as part of their service and project.

4.1. Derived tools and applications

In [18], Maguire et al. use the LOV search API to implement OntoMaton,29

²⁹

https://github.com/ISA-tools/OntoMaton.

a widget for using ontology lookup and tagging within the Google spreadsheets collaborative environment.

YASGUI (Yet Another SPARQL Query GUI)30 ³⁰

http://legacy.yasgui.org/.

is a client-side JavaScript SPARQL query editor that uses the LOV API for property and class auto-completion together with prefix.cc31 ³¹

http://prefix.cc.

for namespace prefix auto-completion [25]. YASGUI is itself reused by LOV for its SPARQL Endpoint User Interface.

Data2Ontology maps data objects and properties to ontology classes and predicates available in the LOV catalogue. Data2Ontology is part of the Datalift32 ³²

http://datalift.org/.

platform [27], a framework for “lifting” raw data into RDF. The Data2Ontology module takes as input “raw RDF”, straightforward conversion of legacy format to RDF, with the goal of helping data publishers in selecting vocabulary terms that could be used to better represent their data.

OntoWiki33 ³³

http://ontowiki.net/.

facilitates the visual presentation of a knowledge base as an information map, with different views on instance data [4]. It enables intuitive authoring of semantic content, with an inline editing mode for editing RDF content, similar to WYSIWIG for text documents. OntoWiki offers a vocabulary selection feature based on LOV.

Furthermore, we can mention the ProtégéLOV,34 ³⁴

http://labs.mondeca.com/protolov/.

a plug-in for the Protégé editor tool [14] that aims at improving the development of lightweight ontologies by reusing existing vocabularies at a low fine grained level. The tool searches for a term in LOV via APIs and provides three actions if the term exists: 1) to replace the selected term in the current ontology, 2) to add the rdfs:subClassOf axiom and 3) to add the owl:equivalentClass.

4.2. Using LOV as a research platform

LOV has served as the object of studies in [21] where Poveda-Villalón et al. analysed trends in ontology reuse methods. In addition, the LOV dataset has been used to analyse the occurrence of good and bad practices in vocabularies [22].

Prefixes in the LOV dataset are regularly mapped with namespaces in the prefix.cc service. In [2], the authors perform alignments of Qnames of vocabularies in both services and provide different solutions to handle clashes and disagreements between preferred namespaces. Both LOV and prefix.cc provide associations between prefixes and namespaces but follow a different logic. The prefix.cc service supports polysemy and synonymy, and has a very loose control on its crowd-sourced information. In contrast, LOV has a much more strict policy forbidding polysemy and synonymy ensuring that each vocabulary in the LOV database is uniquely identified by a unique prefix identification allowing the usage of prefixes in various LOV publication URIs.

The LOV query log covering the period between 2012-01-06 and 2014-04-16 has been used in [9] to build a benchmark suite for ontology search and ranking. The CBRBench35

³⁵

https://zenodo.org/record/11121.

benchmark uses eight ranking models of resources in ontologies and compares the results with ontology engineers’ results. Our vocabulary term ranking method relies on and extends the outcome of this work.

In [16], the authors provide a 5 star rating for RDF vocabulary publication to boost interoperability, query federation and better interpretation of data on the Web similar to the 5 stars rating for Linked Open Data. Based on LOV’s best practices criteria, all vocabularies must be 5 stars using this ranking and must provide further quality attributes imposed by LOV to facilitate vocabulary reuse.

RDFUnit36 ³⁶

https://github.com/AKSW/RDFUnit.

is a test-driven data debugging framework for the Web of Data. In [17], the authors provide an automatic test case for all available schema registered with LOV. Vocabularies are used to encode semantics to domain specific knowledge to check the quality of data.

Finally, Governatori et al. [15] analyse the current use of licenses in vocabularies on the Web based on the LOV catalogue in order to propose a framework to detect incompatibilities between datasets and vocabularies.

Table 7

Comparison of LOV with respect to Swoogle, Watson, Falcons and Vocab.cc; adapted from the framework presented by d’Aquin and Noy [12]. SWD stands for Semantic Web Document

Feature	Swoogle	Watson	Falcons	Vocab.cc	LOV
Listing ontologies	Yes	Yes	Yes	Yes	Yes
Ontology discovery method	Automatic	Automatic	Automatic	Automatic	Automatic/Manual
Scope	SWDs	SWDs	Concepts	vocab terms	Vocabularies
Ranking	LOD metric	LOD metric	LOD metric	BTC corpus + label’s property type	LOD/LOV metric
Domain filtering	No	No	No	No	Yes
Comments and review	No	Yes	No	No	Curators
Web service access	Yes	Yes	Yes	Yes	Yes
SPARQL endpoint	No	No	No	No	Yes
Read/Write	Read	Read/Write	Read	Read	Read
Ontology directory	No	No	No	Yes	Yes
Application platform	No	No	No	N/A	Yes
Storage	Cache	N/A	N/A	API	Dump/endpoint
Interaction with contributors	No	N/A	No	No	Yes
Version tracking	No	No	No	No	Yes
Inter-vocab. relationship visualization	No	No	No	No	Yes

5. Related work

Reusing vocabularies requires searching for terms in existing specialised vocabulary catalogues or search engines on the Web. While we refer the reader to [12] for a systematic survey of ontology repositories, below we list some existing catalogues relevant for finding vocabularies:

• Catalogues of generic vocabularies/schemas similar to LOV catalogue. Example of catalogues falling in this category are vocab.org,37

  ³⁷

  http://vocab.org/.

  ontologi.es,38 ³⁸

  http://ontologi.es/.

  JoinUp Semantic Assets or the Open Metadata Registry. Most of those repositories are not regularly updated and are created/owned by the institutions using the service.

  Catalogues of ontologies for a specific domain such as biomedicine with the BioPortal [33], geospatial ontologies with SOCoP+OOR,39 ³⁹

  https://ontohub.org/socop.

  Marine Metadata Interoperability and the SWEET [24] ontologies.40 ⁴⁰

  http://sweet.jpl.nasa.gov//.

  The SWEET ontologies include several thousand terms, spanning a broad extent of Earth system science and related concepts (such as data characteristics), with the search tool to aid finding science data resources.

  Catalogues of ontology Design Patterns (ODP) focus on reusable patterns in ontology engineering [23]. The submitted patterns are small pieces of vocabularies that can further be integrated or linked with other vocabularies. ODP does not provide a search function for specific terms as is the case with some of these other catalogues.

  Search Engines of ontology terms. Among ontology search engines, we can cite: Swoogle [13], Watson [11], FalconS [10] and Vocab.cc [29]. These search engines crawl for data schema from RDF documents on the Web. They offer filtering based on ontology type (Class, Property) and a ranking based on the popularity. They don’t look for ontology relations nor do they check if the definition of the ontology is available (usually known as dereferenciation). While in Swoogle the ranking score is displayed, Watson shows the language of the resource and the size. However, none of these services provide any relationship between the related ontologies, or any domain classification of the vocabularies. Table 7 presents a summary of key features of LOV with respect to Swoogle, Watson, Falcons and Vocab.cc.

  Datasets and Vocabularies statistics. In this category we can mention LODStats [3] and the vocabularies derived from the LOD Cloud. LODStats makes a bridge between datasets and vocabularies gathering up to 32 different statistical criteria based on a statement-stream-based approach for RDF datasets in Datahub.41 ⁴¹

  http://datahub.io/.

  LODStats maintains a comprehensive statistics on vocabularies terms (i.e. classes, properties) defined and used in a dataset. Schmachtenberg et al. [28] present a survey based on a large-scale Linked Data crawl from March 2014 to analyse the differences in best practices adoption across different application domains. Their results concerning the most used vocabularies (e.g., foaf, dcterms, skos, etc.) and the adoption of well-known vocabularies are inline with the findings of this paper.

  While most of the related work focuses on automatic techniques to gather as many ontologies as possible, LOV focuses on maintaining a high quality collection of vocabularies that data publishers can reuse to describe their own data. To ensure the high quality of LOV data, we set up some stringent requirements for vocabularies to be inserted (cf. Section 3.2.1) such as the fact that a vocabulary URI must be dereferenceable. These kinds of requirements are not always taken into account in the aforementioned work: for instance, the authors in [28] define the notion of partly dereferenceable for vocabularies. As a consequence, anyone using a vocabulary referenced in LOV is ensured to get access to the vocabulary metadata but most importantly to its formal definition and preservation by accessing to various versions.

  As part of our system evaluation we have compared the list of vocabularies in LOV with the ones in external services (LODStats and the empirical survey of Schmachtenberg et al. [28]) so as to understand the discrepancy.

  LODStats contains 2,940 vocabularies extracted from datasets listed in Datahub.io. This list contains in fact a large number (2,596) of invalid vocabulary URIs and resource URIs that do not refer to a vocabulary (e.g. http://data.kingcounty.gov/resource/d665-vvmd/ or http://lod2.eu/view). The domain “http://dati.opendataground.it” contains 962 Resource URIs which are instances and not vocabularies. As a result, only 344 candidate URIs in LODStats are comparable with LOV vocabularies. Out of those 344 URIs, 73 (21.22%) are covered by LOV. We randomly chose 20 vocabularies not already present in LOV for assessment. None of the randomly chosen vocabularies met LOV requirements and 8 different categories of errors were detected: 1) Failed to determine the triples content type, 2) Not found exception, 3) 403 forbidden, 4) Unknown host exception, 5) Peer not authenticated, 6) 504 gateway, 7) Bad URI and 8) Unqualified typed nodes are not allowed.

  Recently, an updated comprehensive empirical survey of Linked Data conformance has been presented by Schmachtenberg et al. [28]. Their survey is based on a large-scale Linked Data crawl from March 2014 to analyse the differences of best practices adoption in different domains. Their results concerning the most used accessible vocabularies and the adoption of well-known vocabularies are inline with the findings of this paper. However, comparing the vocabularies in the LOD cloud with the LOV catalogue needs some alignments. From the 638 mentioned by Schmachtenberg et al., we removed invalid URIs such as domain names such as “umbel.org”. Additionally we removed misspelled URIs and incomplete URIs. As a result, 270 candidate URIs (42.31%) can be compared with LOV vocabularies. Based on this analysis, we found that 102 vocabularies in the LOD cloud are already in the LOV catalogue, representing 38% of the 270 candidates. The general difference of our work with the one presented by Schmachtenberg et al. is that our approach applies strict criteria to include a vocabulary while their approach is dataset driven.

  6. Discussion

  Whilst providing access to high quality vocabularies, LOV system presents several limitations. As described in the last section, LOV system could benefit from an automatic discovery process to suggest vocabulary candidates. We could for instance extract vocabularies from the latest version of the Billion Triple Challenge or the Web Data Commons42

  ⁴²

  http://webdatacommons.org/.

  dataset. Manual curation is a critical activity to ensure the high quality of the LOV catalogue but also represents a limitation. At the moment we have been able to recruit new curators as the catalogue is growing. The version 3 of LOV system automates most of the processes and analyses but there are still some assessment and support activities that only a human can perform.

  Currently, LOV’s scope focuses on vocabularies for the description of RDF data and does not include any Value Vocabularies such as SKOS thesauri. By making the code of LOV system open source, we encourage anyone to set up an instance of the system to target such artifacts.

  LOV relies on external projects such as LODStats to get the valuable information of vocabulary usage in published datasets. At the moment, the popularity information coming from LODStats does not take into account the most recent interest in publishing RDF data using markup language (e.g. schema.org). As a consequence, the popularity measure is incomplete and does not represent all possible use of a vocabulary. In future work we intend to extract those information from the latest datasets versions of the Billion Triple Challenge and the Web Data Commons.

  From the study of LOV as a dynamic ecosystem we can draw two main lessons learned: the need for more multilingual vocabularies on the Web and the importance of long term preservation of vocabularies.

  Labels are the main entry point to a vocabulary and their associated language is the key. Only 15% of LOV vocabularies make use of more than one language. Multilingualism is important at least for two reasons: 1) the most obvious one is allowing users to search, query and navigate vocabularies in their native language; and 2) translation is a process through which the quality of a vocabulary can only improve. Looking at a vocabulary through the eyes of other languages and identifying the difficulties of translation helps to better outline the initial concepts and if necessary refine or revise them. Hence multilingualism and translation should be native, built-in features of any vocabulary construction, not a marginal task.

  Currently there is no solution for long-term vocabulary preservation on the Web [5]. This is a particularly important problem in a distributed and uncontrolled environment where any individual can create and publish a vocabulary. Third parties can reuse such vocabularies and therefore create a dependency on the original vocabulary availability as it retains the semantics of the data. This issue weakens the Semantic Web foundations.

  7. Conclusions and future work

  In this system report we presented an overview of the Linked Open Vocabularies initiative, a high quality catalogue of reusable vocabularies for the description of data on the Web. The importance of this work is motivated by the difficulty that data publishers have in determining which vocabularies to use to describe their data. The key innovations described in this article include: 1) the availability of a high quality dataset of vocabularies available through multiple access methods 2) the curation by experts, making explicit for the first time the relationships between vocabularies and their version history; and 3) the consideration of property semantics in term search relevance scoring.

  In the future, the LOV initiative could evolve in several ways. First, an area that is still largely unexplored is multi-term vocabulary search. During the ontology design process, it is common to have more than 20 concepts represented using existing vocabularies or a new one in case there is no corresponding artifact. While we are able to search for relevant terms in LOV it is still the responsibility of the ontology designer to understand the complex relationships between all these terms and come up with a coherent ontology. We could use the network of vocabularies defined in LOV to suggest not only a list of terms but graphs to represent several concepts together.

  Second, we would like to provide more vocabulary based services such as vocabulary matching to help authors add more relationships to other vocabularies. Vocabulary checking is another service the community is asking for. We could integrate useful applications directly into LOV, such as Vapour,43 ⁴³

  https://bitbucket.org/fundacionctic/vapour/wiki/Home.

  RDF Triple-Checker44 ⁴⁴

  http://graphite.ecs.soton.ac.uk/checker/.

  and OOPS!.45 ⁴⁵

  http://oops.linkeddata.es/.

  Another research direction is SPARQL query extension and rewriting based on Linked Vocabularies. Using the inter-vocabulary relationships we could transform a query to use the same semantics (same vocabulary terms) as the data source(s) being queried.

  Finally, we plan to provide a user study and publish the results on the different usage of LOV by end users. In addition, we plan to include the vocabularies from LODStats and LOD Cloud that are suitable for inclusion in the LOV catalogue.

  The adoption and integration of the LOV catalogue in applications for vocabulary engineering, reuse and data quality are significant. LOV has a central role in vocabulary life-cycle on the Web of data as highlighted by the W3C:46 ⁴⁶

  http://www.w3.org/2013/data/.

  “The success of LOV as a central information point about vocabularies is symptomatic of a need, for an authoritative reference point to aid the encoding and publication of data”.