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.
# 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).
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.
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 http://purl.org/pav/):
pav:authoredBy rdf:type owl:ObjectProperty ;
dcterms:creator rdfs:isDefinedBy <http://purl.org/dc/terms/> .
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:
<http://example.com/person1> 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:
And in schema.org using schema:worksFor from the person:
<http://example.com> a schema:Organization;
And so we can't use rdfs:isSubPropertyOf here to map ex:companyName to FOAF or schema.org, 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: <http://www.w3.org/2000/01/
ex:companyName a owl:DatatypeProperty ;
foaf:name rdfs:isDefinedBy <http://xmlns.com/foaf/0.1/> .
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).