Publish and link your vocabularies in LOV. Reuse Linked Open Vocabularies

The Linked Open Vocabularies (LOV) initiative started in 2011 as part of the DataLift research project and is hosted by the Open Knowledge Foundation. LOV promotes and facilitates the reuse of well documented vocabularies in the Linked Open Data (LOD) ecosystem. If you think your vocabulary can be reused by others, just make it visible in LOV…


Which vocabularies could be used to describe the semantics of data?

First of all, it's good to remember that best practices are always context dependent. Think, for instance, of the LOD cloud, which is the collection of  Linked Data (LD) - rather than isolated ‘semantic islands’ - on the Web.

   # How dataset publishers or other people that want a dataset to be added to the LOD cloud, describe datasets on

   # RDF allows Anyone to say Anything about Any related topic (Anywhere and at Any time)  = the AAA(AA) slogan.

Take a look at LOV : Linked Open Vocabularies, which is a high quality catalogue of reusable linked (thus context dependent) semantic vocabularies for the description of data on the Web.

All data/vocabularies/ontologies (or some samples of ontologies) listed in under LOV are linked to other vocabularies and are ‘open’ for legal reasons.

With LOV you can cut down your overhead for creating, documenting, hosting, and supporting terms that you need but may already exist and are in use.

In particular, the LOV initiative gathers and makes visible indicators that have not been previously harvested such as:

  • the interconnections (incoming and outgoing links) between vocabularies,
  • version history along with past and current referent (individual or organization).

In LOV you can search in VOCABS, TERMS, AGENTS, LOV SPARQL Endpoint  and  reuse retrieved data for your next Linked Data modeling project. LOV goes beyond existing Semantic Web vocabulary search engines and takes into consideration the value’s property type, matched with a query, to improve vocabulary terms scoring.

Having your vocabulary/ontology/data included in the LOV is a simple and very effective way of achieving that (see, e.g., AGROVOC Classification in LOV).

You can suggest a vocabulary, ontology, or anything else (published to a Web-accessible location) that leverages RDF Language sentences/statements and LD principles to be included in the LOV catalog.

Anyhow, you cannot simply submit your vocabulary or ontology to LOV and it will be listed there (there is also the notion of 'quality'...).

The LOV team will ask you to:

  • enrich your vocabulary/ontology with minimum metadata and labels;
  • align your vocabulary/ontology  to other ontologies (this is also part of the dissemination of SemWeb stack layer, at least the one related to ontologies).

   # Metadata Recommendations for Linked Open Data Vocabularies (in RDFS or OWL).

Whenever available each vocabulary in LOV includes references to the datasets using it, in particular those listed in CKAN (the world’s leading open-source data portal platform).

The descriptions use in particular the VOAF vocabulary to state different ways such vocabularies can rely on, extend, specify, annotate or otherwise link to each other, and reuse a lot of vocabularies it describes, such as Dublin Core, VoID Vocabulary, BIBO, and many more.

   # The RDFS Schema vocabulary (rdfs)

   # The OWL 2 Schema vocabulary (owl)

   # Ontology Design Pattern Participation (odpart)


Source: LOV: Linked Open Vocabularies

Related content: Linked Open Vocabularies (LOV): a gateway to reusable semantic vocabularies on the Web (article, IOS Press, 2014)


Two 'soft approaches' for reusing  semantic vocabularies/ontologies:

1 # Soft ontology reuse 

with extensions of existing ontologies through "citations"


Copy only the URI (and type), then (important!) cite back to the original ontology with rdfs:isDefinedBy

If that ontology does not already have an authorative rdfs:isDefinedBy or owl:versionIRI you can use, use a retrievable IRI to the ontology - which might differ from the namespace.

For instance (adapted from

        @prefix pav:  <> .
        @prefix rdfs:  <> .
        @prefix dcterms:  <> .

        pav:authoredBy  rdf:type    owl:ObjectProperty ;
          rdfs:subPropertyOf  dcterms:creator .

        dcterms:creator  rdfs:isDefinedBy  <> .

Here the namespace is already what is declared as rdfs:isDefinedBy upstream.

With soft ontology reuse, inferences like dcterms:creator being a subproperty of dcterms:contributor would not be visible unless you also loaded the full dcterms ontology - a kind of optional inference if you like.

2 # Soft ontology reuse 


In some cases the above can get fragile - e.g. the vocabulary you cite is not directly compatible ontology-wise (e.g. too strong rdfs:range). In that case you could still have a rdfs:seeAlso or SKOS mapping to existing ontologies where it seems obvious.

For example, let's say you have an ontology of workers at companies, but it is for whatever reason not directly compatible with the model of FOAF; let's say you have a simple property ex:companyName:

    <> ex:companyName "Example inc." .

In FOAF this would instead be modeled indirectly with a resource for the work place and an inverse link foaf:member to the person:

    <> a foaf:Organization ;
        foaf:name "Example inc." ;
        foaf:member <> .

And in using schema:worksFor from the person:

   <> schema:worksFor <> .

   <> a schema:Organization;
      schema:name "Example inc." .

And so we can't use rdfs:isSubPropertyOf here to map ex:companyName to FOAF or, as that would imply things like person1 being an organization and having the name "Example inc.".

But let's still keep some kind of link:

        @prefix rdfs:   <> .
        @prefix owl:    <>.
        @prefix foaf:   <>.
        @prefix skos:   <>.
        @prefix schema: <>.
        @prefix ex:     <>.

        ex:companyName a owl:DatatypeProperty ;
          rdfs:seeAlso foaf:name, foaf:member, schema:worksFor, schema:name ;
          skos:closeMatch schema:worksFor ;
          skos:relatedMatch foaf:name, foaf:member, schema:name .

        foaf:name rdfs:isDefinedBy <> .
        foaf:member rdfs:isDefinedBy <> .
        schema:name rdfs:isDefinedBy schema:name .
        schema:worksFor rdfs:isDefinedBy schema:worksFor .

The various SKOS mapping properties can be used when something is more specific or broader.

This would mean your ontology can be not just Open, but also Linked - and thus resources with statements using just your ontology could be seen as part of the LOD cloud rather than an isolated 'semantic island'.

Obviously in this second approach you can't do much reasoning and infer SKOS/FOAF statements, but at least you can follow the links rather than be an isolated ontology.

An isolated ontology/namespace with no links would in my view would just be slightly better than a arbitrary custom XML or JSON properties.  (Luckily using URIs still allows others to do such a mapping at a later point).