Posts Tagged ‘context dependency’

The Virtue of Naming concepts

July 16, 2009

Everybody knows the Pizza Ontology that has been used for ages now to demonstrate tools and methods in the Semantic Web community. Nowadays the Beer Ontology is gaining interest, and I wonder how many concept types the Belgian beer namespace will consist, as there is no clear enumeration of that :-) Anyway, when talking about pizza or even about Belgian beers, we are still playing around with small ontologies.

(Too long) names to decontextualise the proliferation of concept types

Seriously, an ontology should refer to context-independent and language-neutral concepts. However, natural language (vocabulary etc.) is still needed to represent these concepts. Wittgenstein once said:

“The limits of my language means the limits of my world. “

When building large conceptual frameworks of thousands of concept types, vocabulary is usually exhausted before finishing. BTW, is the job ever finished given the proliferation of concepts in communities? Anyway, (as in natural language) terms will have different meanings depending on the context. E.g., the term  java can refer to coffee, a country, or a programming language. In the latter case we can even doubt whether we are talking about java as a sub-type or an instance of the concept type programming language. Let’s not see how deep the philosophical rabbit hole goes here. IMHO, in a formal semantic system we could consider to introduce a fuzzy parameter that can switch between both perspectives.

Now, let’s get back to the ambiguity problem of vocabulary. Lacking better solutions, many of these large ontologies have chosen very long labels to refer their concepts in an unambiguous manner (as the title of this blog already suggests). Usually, these labels are concatenations of a number of parameters that determine the context of the label. Consider, for example, the IFRS Taxonomy 2009 which is a complete translation of International Financial Reporting Standards (IFRSs) as of 1 January 2009 into XBRL:Picture 1

The label for the illustrated concept reads (first take a deep breath):


And this is not a single occurance. The IFRS taxonomy counts hundreds of concept labels fo this size. See for yourself:

Picture 2

This may be ok for one single person who built the ontology, and actually chose the labels, but when sharing it is not understandable for machines, or even other user. This situation creates a vicious circle: long labels are difficult to navigate, hence users introduce new concept types as they cannot retrieve what they are looking for. When defining these new concept types, they have no choice than to invent new labels “with the wet index”, inexorably aggravating the situation.


The problem is also found when people tend to overcategorise. This is an excerpt of a product taxonomy from Kevin Jenkins during a discussion on SemWeb on this matter:

Product (Root Class)
--- software
------ desktop software
----------- desktop internet software
------------------- desktop internet access software (individual)
------------------- desktop internet browser software (individual)
------------------- desktop internet messaging software (individual)
------------ desktop multimedia software
------------------- desktop multimedia 3d software (individual)
------------------- desktop multimedia audio software (individual)
------------------- desktop multimedia video software (individual)
------ internet software
------------ internet saas software
------------------- internet saas collaboration software (individual)
------------------- internet saas videosharing software (individual)
------------ internet cloud software
------ enterprise software

In order to differentiate a subtype from its parent, a term is appended to the more general label. According to Azamat Abdoullaev long classification is done according the scheme “noun specifying another noun”, like below:

((subsubclass)(subclass(class)): audio multimedia desktop software.

He compares it withe problem of URI schemes or computer directory (folder, catalog) names, it will be written as a root hierarchy:


However, this is not how humans talk to each other. Humans tend to contextualise their concepts through sentences in which they qualify certain attributes. This is done in terms of facts. E.g, following example shows 4 facts for this Person.

Person drives Car with Brand “Minerva” and married to Woman with Name “Athena”.

The fact types used here are:

Person drives Car
Car with Brand
Person married to Woman
Woman with Name

Hence, using simple fact types we can describe very complex concept types without even using categorisation in many cases. The terms used to refer to the concept types of course need to be disambiguated. There is no deus ex machina here: context is a social construct as well that has to be included in the ontology.

Context as first-class citizen

Context is an inexorable construct when representing ontologies. As I already discussed in an earlier publication. Particularly when stakeholders in a community use a different vocabulary to refer to the common concept types.

In our approach we use a context identifier g to articulate a term t with a concept type identifier c with the following function.


Hence, c is a URI that refers to a language-neutral and context-independent concept type. This can be represented in the WordNet manner in terms of a gloss (=informal description) plus a synset (=set of synonymous terms). For one of the terms on the above fact types this would be (based on WordNet):

(drivingfordummies, person)->(gloss,synset)
gloss="a human being"

Assuming that this fact type was extracted from a book called Driving for Dummies. So by keeping track of the context of elicitation g of very fact type, we can disambiguate the involved terms properly without the need for very long labels.

Further Reading

In my PhD, I developed a methodology that enacts a community to collaboratively construct an ontology architecture consisting of several layers (upper common, lower common, stakeholder level).

  • The top layer refers to language-neutral and context-independent concepts that are already agreed and applied by the community.
  • The lowest stakeholder layer consists of “stakeholder perspectives” on these upper layers, specialising the upper layer with locally relevant concept types represented by local vocabularies.
  • Gradually these lower perspectives are reconciled in the lower common layer, and when a new version is produced parts are promoted the upper common layer.

Hence community does not only have to agree on the concept types (gloss) but also on the preferred terms (synset) to refer to these concept types.


Using Graph transformation for Collaborative Ontology Evolution

October 16, 2007

De Leenheer, P. and Mens, T. (2007) Using Graph transformation for Collaborative Ontology Evolution. Proc. of the Third International Symposium on Applications of Graph Transformation with Industrial Relevance (AGTIVE 2008) (Kassel, Germany), LNCS 5088, Springer.changedifftosibling

In collaborative ontology engineering, contexts are key to manage the complexity of different dependency types between ontological artefacts. Instead of being frustrated by out-of-control evolution processes, proper context dependency management will allow human experts to focus on the meaning interpretation and negotiation processes. This requires support for the detection and resolution of meaning ambiguities and conflicts. In this article, we explore to which extent the theory of graph transformation can be used to support this activity. More specifically, we propose the use of critical pair analysis as a formal means to analyse conflicts between ontologies that are evolving in parallel. We illustrate this with an example from a realistic case study.

Context Dependency Management in Ontology Engineering: a Formal Approach

June 12, 2007

jods_viii_deleenheer_fig1A viable ontology engineering methodology requires supporting domain experts in gradually building and managing increasingly complex versions of ontological elements and their converging and diverging interrelationships. Contexts are necessary to formalise and reason about such a dynamic wealth of knowledge. However, context dependencies introduce many complexities. In this article, we introduce a formal framework for supporting context dependency management processes, based on the DOGMA framework and methodology for scalable ontology engineering. Key notions are a set of context dependency operators, which can be combined to manage complex context dependencies like articulation, application, specialisation,
and revision dependencies. In turn, these dependencies can be used in context-driven ontology engineering processes tailored to the specific requirements of collaborative communities. This is illustrated by a real-world case of interorganisational competency ontology engineering.

De Leenheer, P., de Moor, A., and Meersman, R. (2007) Context Dependency Management in Ontology Engineering: a Formal Approach. Journal on Data Semantics VIII, LNCS 4380, Springer-Verlag, pp. 26-56.