Vocabularies are more and more (re)-used in the Linked Data ecosystem. However, managing the pre xes associated to their Uniform Resource Identi ers (URIs) is still cumbersome and namespaces are sometimes referring to di erent pair <prefix, URI>. In this paper, we propose to align two well-known services with the aim of managing and harmonizing vocabularies' namespaces. We use pre x.cc that provides a look up service for namespaces in general and Linked Open Vocabularies (LOV) that extracts vocabularies metadata. Our method enables to identify three di erent scenarios: (i) con icts between pre x.cc and LOV; (ii) pre xes in LOV not present in pre x.cc and (iii) URIs in pre x.cc that are actually LOV-able vocabularies. We describe how we solve each of these issues, with actions ranging from updating the di erent services to contacting the editors of the vocabularies to x clashes among pre xes. Finally, we present the new LOV API that enables to check whether those namespaces in pre x.cc can actually be vocabularies to be inserted in the LOV ecosystem or not.
RDF vocabularies bring their meaning to linked data by de ning classes and properties, and their formal semantics. Relying on W3C standards RDFS or OWL, those vocabularies are a fundamental layer in the architecture of the Semantic Web. Without the explicit semantics declared in vocabularies, linked data, even using RDF, would be just linked pieces of information where links have no meaning. Interoperability between data and datasets rely heavily on shared vocabularies, but given the distributed nature of the Web, vocabularies are published by independent parties and there is no centralized coordination of this publication, nor should it be. Various independent services have been developed in order to discover vocabularies and provide information about them, and the community of data publishers and vocabulary managers have all interest in complementarity and coordination between such services. In this paper, we focus on a speci c aspect of vocabularies: their identi cation by namespaces and associated pre xes.
In the original XML syntax of RDF, pre xes are simply local shortcuts associated with XML namespaces using xmlns declarations. The usage of pre xes has been further extended to other syntaxes of RDF such as N3 and Turtle. Although a pre x to namespace association is syntactically limited to the local context of the le in which it is declared, common pre xes such as rdf:, rdfs:, owl:, skos:, foaf: and many more have become de facto standards. For example, RDFa has 1.1 has a default pro le made of 11 well-used vocabularies based on their general usage on the Semantic Web according to the crawl of Yahoo! and Sindice as of March 20131. Similarly, the YASGUI SPARQL editor has a list of built-in pre x-namespace associations to ease the construction of SPARQL queries. However, this list of \standard" pre xes is open-ended. Interfaces such as SPARQL endpoints (e.g. Virtuoso) use a list of built-in pre xes declaration for more and more namespaces but the choice of entries in this list is all but transparent. Hence, the reason of a given namespace being or not in this list could be interpreted in many ways, a potential source of technical and social con icts. Therefore, the notion has been slowly spreading, at least implicitly, that common pre xes could and indeed should have a global use, implying some kind of governance and good practices. More and more vocabularies explicitly recommend the pre x that should be used for their namespace, generally using a common if not written good practice to avoid frontal clashes by recommending a pre x not already used. But there is no global policy except implicit rules of fair use to avoid potential con icts resulting from polysemy (di erent namespaces using or recommending the same pre x) or synonymy (di erent pre xes used for the same namespace).
A vocabulary publisher needs to have access to some services capable of
monitoring the existing pre xes usage in order to stick to those rules. In this paper,
we focus on two services providing such information on pre xes usage namely
pre x.cc2 and LOV (Linked Open Vocabularies) [
2 Service: http://prefix.cc/; Code: https://github.com/cygri/prefix.cc
The initial motivation of the work presented in this paper was to provide some kind of harmonization between those two services, from simple obvious tasks such as checking that pre x.cc provides all pre xes present in LOV and add them as necessary, to more complex ones such as detection and possible resolution of con icts. We describe an approach for discovering new vocabularies in the wild by reconciling vocabularies in pre x.cc using SPARQL federated queries. This work was made semi-manually and involved collaboration between the two services managers to exchange data and take actions on each side. The remainder of this paper is structured as follows. In Section 2, we provide an overview of related work and services that support vocabulary management including the current approaches implemented by the LOV and pre x.cc services. In Section 3, we present how we have aligned those two services, detected conicts and resolved them. In Section 4, we describe a method enabling to nd new LOV-able vocabularies from the pre x.cc service. Finally, we discuss some lessons learned and outline future work in Section 5. 2
Many di erent type of repositories exist to support users and developers to nd controlled terms and entire vocabularies or ontologies on the web of data. We rst describe the LOV initiative (Section 2.1) and we propose then our own classi cation based on the content, the domain, the purpose and the way such catalogs are populated or index created (Section 2.2). 2.1
The Linked Open Vocabularies (LOV) initiative aims to bring more insights about published vocabularies in order to foster their reuse. Compared to other projects, LOV bene ts from a community: { to assess the quality (including documentation, metadata) and the reuse potential of a vocabulary before it is indexed. LOV contains currently 350+ reusable and well-documented vocabularies; { to augment vocabularies with explicit information not originally de ned in the RDF vocabulary. For example, only 55% of vocabularies have explicit metadata of at least one creator, contributor or editor. In LOV, we augmented this information leading to more than 85% of vocabularies with this information; { to automatically extract the implicit relations between vocabularies using the Vocabulary Of Friend3 (VOAF) ontology. These relations can be used as a new metric for ranking terms based on their popularity at the schema level; { to consider vocabulary semantic in the result ranking: a literal value matched for the rdfs:label property has a higher score than for the dcterms:comment property.
The way vocabularies are considered in LOV is similar to the way datasets
are considered in the LOD cloud [
The LOV-Bot is the tool that automatically keeps up-to-date the relationships and the metadata about the vocabularies indexed in LOV, using the following steps: { LOV-Bot daily checks for vocabularies update (any di erence in the vocabulary formal description fetched using content negotiation); { LOV-Bot uses SPARQL constructs to detect relationships and metadata and creates explicit metadata descriptions in the LOV dataset; { LOV-Bot annotations are then listed in a back-o ce administration dashboard in order to be reviewed. This manual part enables LOV curators to interact with vocabularies authors and the wider community to raise issues and make remarks or suggestions.
The LOV dataset is synchronized with the information presented in the web site. The latter allows a human user to browse LOV information. The Linked Open Vocabularies initiative does not only monitor the current state of the ecosystem. It also aims at storing and giving access to vocabularies history. To achieve this goal, the LOV database contains every di erent version of a vocabulary over the time since its rst issue. For each version, a user can access the le and a log of modi cations since the previous version. 2.2
While we refer the reader to [
Number of Search Feature vocabularies Catalog name vocab.org ontologi.es Joinup Semantic Assets Open Metadata Registry BioPortal SOCoP + OOR Marine Metadata Interoperability SWEEET 2.2 DAML ODPs vocab.derie.ie data.lirmm.fr ontologies TONES 9 http://daml.org/ontologies/ 10 http://neologism.deri.ie 11 http://watson.kmi.open.ac.uk/ 12 http://www.sindice.com 13 http://ws.nju.edu.cn/falcons/ 19
We observe that the existing catalogs of vocabularies in the literature have
some limitations compared with LOV. In terms of coverage, the number of
vocabularies indexed by LOV is constantly growing and it is the only catalog, to
the best of our knowledge, that provide all types of search criteria (metadata
search, within/across ontologies search), both an API and a SPARQL endpoint
access and that can be as well classi ed as an \Application platform" apart from
being at the same time an ontology directory and an ontology registry.
According to the categories of ontology libraries de ned in [
vocab.cc14 is a service which is similar to pre x.cc since it enables to look up and search for Linked Data vocabularies while providing more speci c information about the usage of a particular class or property in the Billion Triple Challenge Dataset (BTCD). It also provides the ranking of those properties or classes. The authors mentioned that \common pre xes are resolved with data from pre x.cc". Although they don't give further details, this service is somehow related to pre x.cc. Triple-Checker15 is a web service based on pre x.cc which aims at nding typos and common errors in RDF data. It parses a given URI/URL and the output is divided in two sections: the namespaces and the term section. The former matches against pre x.cc to determine whether they are \common pre xes" and the latter provides the term de nition. 3
In this section, we present how we perform the alignment between the two services LOV and pre x.cc. Figure 1 shows the evolution of the number of pre xes registered in these two services between April 2009 and July 2013. Our main goals are to align Qnames (pre x) to a unique URI in LOV and to make sure that all the vocabularies in LOV are actually inserted in pre x.cc.
We propose to perform SPARQL queries over all the les of pre x.cc at
http://prefix.cc/popular/all.file.vann in the FROM clause and compare
them to the content of the LOV SPARQL endpoint16 via a SERVICE17 call.
The SERVICE keyword de ned in the SPARQL 1.1 Query Language instructs
a federated query processor to invoke a portion of a SPARQL query against
a remote SPARQL endpoint [
First, we compute < LOV > IN T ERSECT S < P REF IX:CC > and < LOV > M IN U S f< LOV > IN T ERSECT S < P REF IX:CC >g. The following SPARQL query nds namespace URIs in LOV that do not exist in prex.cc along with their LOV pre x.
PREFIX vann: <http://purl.org/vocab/vann/> SELECT ?prefix ?lovURI FROM <http://prefix.cc/popular/all.file.vann> {
SERVICE <http://lov.okfn.org/endpoint/lov> {
SELECT ?prefix ?lovURI { } FILTER (NOT EXISTS { [] vann:preferredNamespaceUri ?lovURI }) OPTIONAL { [] vann:preferredNamespacePrefix ?prefix;
vann:preferredNamespaceUri ?pccURI; The rst results18 shown the following: card(LOV ) T card(P REF IX:cc) = 18819 and card(LOV ) card(P REF IX:cc) = 13320 pre xes in LOV not yet registered in pre x.cc. At this point, a rst batch of 80 pre xes/namespaces from LOV were safely imported in pre x.cc since there were no con icts. For the remaining conicting ones, they needed more in-depth analysis. 3.2
In the process of alignment, there were two types of con icts and we provide appropriate actions and/or solutions accordingly: { Clashes: cases where we have in both services the same pre x but di erent
URIs; { Disagreements on preferred namespace: cases where for the same URI, we found di erent pre xes.
Clashes. We performed a SPARQL query as above to identify clashes in vocabularies (30). In Table 2, we identify seven di erent types of issues to deal with, such as (i) real con icts, (ii) URIs are 404, (iii) URIs are obsolete versions and (iv) two URIs redirecting to the same resource.
Disagreements on namespace URIs. The general idea is that if vocabulary editors have not included explicitly a vann:preferredNamespacePrefix in their description, the curators of LOV are free to change it and put whatever seems appropriate. At the same time, in pre x.cc, having multiple pre xes for the same namespace IRI in not a problem. However, we computed those pre xes in LOV that have di erent pre xes in pre x.cc. The following query retrieves the URIs falling in those disagreements: 18 This query was performed in two weeks between March, 2nd and March, 20th 2013 and at this time, card(LOV) = 321 vocabularies while card(Pre x.cc) = 925 19 http://www.eurecom.fr/~atemezin/iswc2013/experiments/firstAlignments/
intersection-prefixLOV-02-03.csv 20 http://www.eurecom.fr/~atemezin/iswc2013/experiments/firstAlignments/
inLovNotINPrefixcc-02-03.csv Type of issue # Vocabularies Percentage From the results of this query (61 cases), we have three actions to perform: { add the lovPre x (pre x in LOV) in pre x.cc (e.g: adding geod:http://vocab.lenka.no/geo-deling#) to the existing ngeoi in pccPre x.) { add more alternative URIs to the existing pre x in pre x.cc (e.g: adding prov:http://purl.org/net/provenance/ns#) to the existing hartigprov, prv in pccPre x ) { change a pre x in LOV21 (e.g: lovPre x dc for http://purl.org/dc/terms not in the list fdcterm; dcq; dct; dctermsg has been replaced by dce in LOV). { No changes when the lovPre x is contained in the set of pre xes of pre x.cc.
Several vocabularies are maintained by a community of users. As part of the alignment process, we contacted the authors, creators or maintainers (if they 21 http://www.eurecom.fr/~atemezin/iswc2013/material/action-sameUriDifferentPrefixes.pdf exist) of vocabularies to involve them as well in the process of changing pre xes, and agree with them to x some issues regarding their vocabularies. From the homepages of the vocabulary authors and editors collected in LOV, we connect to their social platform accounts such as LinkedIn, Google+ or Twitter. Table 3 summarizes some cases of real con icts where the LOV curators have to nd and contact the editors of the vocabularies for negotiation. pre x lovURI Remark sp http://data.lirmm.fr/ontologies/sp# contact editor at LIRMM (sp ) osp) scot http://scot-project.net/scot/ns# contact editors at lovURI media http://purl.org/media# contact editors for negotiation pro http://purl.org/spar/pro/ contact editors for negotiation swp http://www.w3.org/2004/03/trix/swp-1/ contact editors, x on LOV side wo http://purl.org/ontology/wo/core# contact editors idemo http://rdf.insee.fr/def/demo# to resolve with INSEE Table 3. LOV and pre x.cc con icts resolution leading to contact vocabularies editors for negotiation. We provide the pre x, the URI in LOV and the action undertaken. 4
We want to nd out in pre x.cc, which of the couples (pre x, URI) could be potentially a vocabulary to be further assess to be included in the LOV catalog. To address this question, we rst compute all the di erences on pre x.cc NOT in LOV, i.e. P REF IX:CC MINUS (LOV < IN T ERSECT > P REF IX:CC), performing using a SPARQL query. This results in 742 URIs to be checked22. 4.1
We have implemented an API23 that allows a user to run the LOV-Bot over a distant vocabulary. It takes as parameter the vocabulary URI to process and the time out (integer) speci ed to stop the process. The result of this action is a set of 26 property-values from which we are interested in using only 8 of them, namely: { uri (string) { uri of the vocabulary. { namespace (string) { namespace of the vocabulary. { pre x (string) { pre x of the vocabulary { inLOV (boolean) { indicates if the vocabulary is already in the Linked Open
Vocabularies ecosystem. 22 http://www.eurecom.fr/~atemezin/iswc2013/experiments/input/notInLOV.json 23 http://lov.okfn.org/dataset/lov/apidoc/ { nbClasses (int) { Number of classes de ned in the vocabulary namespace. { nbProperties (int) { Number of properties de ned in the vocabulary namespace. { dateIssued (string) { Vocabulary date of issue. { title (Taxonomy) { List of titles with language information if available.
The code below gives the response of our algorithm for the vocabulary identi ed at http://ns.aksw.org/Evolution/. [caption={Sample output of a response of the Check API}] { "dateIssued": "None", "inLOV": false, "namespace": "http://www.agfa.com/w3c/2009/clinicalProcedure#", "nbClasses": 47, "nbProperties": 29, "pccURI": "http://www.agfa.com/w3c/2009/clinicalProcedure", "prefix": "clinproc", "title": [ { } "dataType": null, "language": "en", "value": "Clinical Procedure" ], "uri": "http://www.agfa.com/w3c/2009/clinicalProcedure" }, 4.2
We wrote a script calling the LOV Check API on the URIs in pre x.cc for determining the candidates vocabularies to be inserted in LOV using the algorithm in Listing 1. We ran four times the experiments (possibly due to some network instabilities) in order to determine from which results what should be assessed. Table 4 gives an overview of the number of URIs with respectively the attribute \inLOV=false"(TP), \inLOV=true"(FP) and the errors occurred (Null returned, http/proxy or time out reached by the API).
Regarding the experiments, Experiment4 gives stable results with less network errors. Therefore, we stick on this experiment to report our ndings and analysis. We found that 227 (43:48%) are vocabularies in the sense of LOV since they have at least one property or one class. 297 vocabularies (56:51%) might have some problems (or are even not vocabularies at all) as they have neither classes nor properties. Regarding the presence of pre xes, we found 140 (61:67%) of them. The 227 vocabularies could all be inserted in the LOV catalog since they ful ll the current requirements of what is a \ LOV-able vocabulary". In this list, we found vocabularies such as rdf, rdfs, owl that are used to build other vocabularies but are not yet integrated in the LOV catalog.
TP(inLOV=false) FP(inLOV=true) Errors Experiment1 Experiment2 Experiment3 Experiment4
From the list of URIs that were not LOV-able vocabularies, we wanted to do more analysis by checking the RDF les using the Triple-Checker tool. Our aim is to be sure if we did not leave out some candidate vocabularies or if there are other type of errors such as parsing errors. Table 5 provides results classi ed into 4 categories: { General errors such as loading les or proxy errors: 78.30% { Candidate LOV-able vocabularies: 12.20% { Clearly not vocabularies (nbClasses = nbProperties = 0), typically instances, datasets, html pages: 6.45% { Others (mainly parsing errors): 3.05% 5
In this paper, we have analyzed numerous vocabularies referenced in LOV and in pre x.cc and we have presented a way to manage the pre xes of those vocabularies. We have shown that in the process of mapping namespaces with pre xes, some con icts have to be resolved, often by contacting the editors themselves.
Total URIs One future work is to develop a new strategy for the LOV-Bot API to take into account vocabularies published in other formats such as n3 and turtle. This would require to rst test the validity of those formats and to adapt the way namespaces are obtained in order to not check only the presence of the vann:preferredNamespace property but to rely on similarity algorithm in order to guess the closest namespace given a URI vocabulary and some statistics of the number of classes and properties.
The work presented in this paper can be extended in several directions. Sticking to the two services we have studied and already contributed to harmonize, the possible next steps would be to automate as far as possible the tasks that have been made semi-automatically so far: i) developing a unique interface for submitting namespaces and pre xes to both services; ii) bridging the LOV backo ce and the pre x-cc database using both services API in order to publish a list of common recommended pre xes. The latter goes beyond the limited framework of the two original services since such a list could be consolidated and endorsed by the main actors in vocabulary publication and management, and recommended for use in linked data applications. This could be picked up by the upcoming W3C Vocabulary Management Working Group as part of the new Data Activity24.
This (apparently) simple issue of pre xes and namespaces is providing a good illustration of why some kind of governance is needed in the distributed ecosystem of vocabularies and linked data, pointing to both technical and social aspects, and proposing concrete examples of con ict resolution. There is no, and certainly there should never be any, central attribution authority for pre xes, and the needed regulation has to be made a posteriori, including good practices of cooperation and negotiation between vocabulary publishers. Development and harmonization of services such as LOV and pre x.cc is then to be considered as 24 http://www.w3.org/2013/05/odbp-charter.html part of the current and more general e ort already started by the DCMI25 and W3C26 for a sustainable governance of vocabularies.
This work is partially supported by the project Datalift funded by the French Research Agency (ANR) under grant number ANR-10-CORD-009. The Linked Open Vocabularies initiative is hosted by the Open Knowledge Foundation. The authors are very grateful for the support and help of Richard Cyganiak, author and maintainer of the pre x.cc service.