Punning

From OWL
Revision as of 01:24, 10 July 2008 by AlanRuttenberg (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page covers Punning in general, and is used as somewhere to start collecting issues around punning.

On tracker

Possibly Related

Use cases

Web service modelling (Class ↔ Individual)

People often want to use a class to specify the value of some property. An example originating at the University of Karlsruhe[1] is in service modeling. Services are modeled as instances of the a:Service class. For each concrete service (i.e., for each instance of a:Service), the users wanted to state what the input to the service is. Here is an example of a service description:

(1) a:Service rdf:type owl:Class
(2) a:Person rdf:type owl:Class
(3) s1 rdf:type a:Service
(4) s1 a:input a:Person

Note that s1 is an individual due to (1), and that a:Person is a class due to (2); hence, in (4) we have a relationship between an individual and a class. Hence, you need some kind of metamodeling to solve this problem.

Treating classes as instances of metaclasses (Class ↔ Individual)

People sometimes want to have metaclasses. Here is an example from [2]. Imagine you want to model information about the animal kingdom. Hence, you introduce a class a:Eagle, and then you introduce instances of a:Eagle such as a:Harry.

(5) a:Eagle rdf:type owl:Class
(6) a:Harry rdf:type a:Eagle

Assume now that you want to say that "eagles are an endangered species". You could do this by treating a:Eagle as an instance of a metaconcept a:Species, and then stating additionally that a:Eagle is an instance of a:EndangeredSpecies. Hence, you would like to say this:

(7) a:Eagle rdf:type a:Species
(8) a:Eagle rdf:type a:EndangeredSpecies

Clearly, you need some kind of metamodeling to solve this problem.

Managing vocabulary in collaborative environments (Class/Property ↔ Individual)

It can be useful to relate schema elements (classes/properties) with each other in order to capture pragmatic relationships between them. An example observed in applications of Semantic MediaWiki (a simple but widely used OWL-based semantic content management system with light-weight expressiveness) [3] is that users wish to relate schema elements to indicate domain-specific relationships, and generally to organise ontological vocabulary. Examples are statements such as:

  • "The property is_located_in is in the class Deprecated_Properties and was replaced by property has_location."
  • "Objects of the class City should have a value for the property population." (expressed by relating class and property)

These are merely pragmatic descriptions, and no logical relationship on schema-level is intended. However, in collaborative vocabulary creation, it is relevant that users can express such intended relationships. An important aspect of Semantic MediaWiki is that users can also query for semantic information, and this is currently realised as intended by punning. Semantic MediaWiki has already been extended by using off-the-shelf OWL reasoners [4], and it would be desirable if such systems would also be able to deal with the use of punning in such simple cases.

Lists (ObjectProperty ↔ DatatypeProperty)

Data/Object property punning could enable the reuse of RDF vocabulary for representing lists by means of containers or collections (linked lists).

«Representing arbitrary lists in the instance data. The most straight-forward way to represent a list would be to use the rdf:List vocabulary where rdf:first can be used both for object and literal values. OWL-DL disallows the use of rdf:List vocabulary (outside built-in class constructors) and does not have punning so the common approach is to recreate the same terms under a different namespace and restrict the lists to lists of objects. OWL-S shadow list vocabulary this is one example and there are other proposals for lists with more semantics. Ability to pun object and data properties would generalize this approach to lists of literals. In addition, if punning built-in vocabulary (or at least rdf:List vocabuary) is allowed it would not be necessary to reinvent a new namespace.»

A similar use case arises in Semantic MediaWiki [3]. This system supports n-ary values for properties, and these values get encoded in a container-like fashion using ad hoc custom OWL vocablary. An example use case from the Halo project was to state the aggregate state of a certain chemical compound at a certain temperature and pressure (this associates a tuple of three values with the URI representing the compound). Expressing this with ad hoc OWL vocabulary impairs interoperability with RDF tools, which are e.g. useful for light-weight ontology browsing (an application in which the direct display of added auxilliary individuals confuses users).


Annotations (ObjectProperty ↔ DatatypeProperty)

Annotations in OWL can have both an individual and a data value. Hence, you can have an ontology O with this contents:

(9) a:myannprop rdf:type owl:AnnotationProperty
(10) a:myinstance a:myannprop a:other
(11) a:myinstance a:myannprop "string value"

I remember Ivan saying at the telecon that Dublin Core people often do this.

In OWL 1.1 (DL), annotations are ignored semantically. There are proposals to give semantics to annotations by translating the ontology into another ontology where annotation properties become data and/or object properties. Hence, to be able to give semantics to (10) and (11), you would translate O into an ontology O' with the following contents:

(12) a:myannprop rdf:type owl:DatatypeProperty
(13) a:myannprop rdf:type owl:ObjectProperty
(14) a:myinstance a:myannprop a:other
(15) a:myinstance a:myannprop "string value"

Since a:myannprop was used in O in annotations with both data and object values, you get into a situation that, in O', a:myannprop should be interpreted as both a data and as an object property.

Note that, in order to give some meaningful semantics to OWL 1.1 DL, you need a strict separation between the object and the data domain (otherwise the logic becomes really horrible). Punning between data and object properties is an easy solution to this problem.

UML Association Class (Class ↔ ObjectProperty)

The Unified Modeling Language (UML) includes a modeling element known as an Association Class which combines the features of a UML Class and a UML Association (UML's construct for defining class to class relationships). The Association Class allows a modeler to define a relation as an association and reify it simultaneously. This is convenient when one wants to model attributes of relations themselves. Class and Object Property punning may support the same modeling need for OWL 1.1.

example

Why Punning (i.e., What Kinds of Logical Consequences do we Want?)

In my experience, people usually do not expect any logical consequences from punning. Use cases of type 1 (classes as values) are typically fully metalogical: the main problem is to stick the desired information into an ontology; the applications then use this information in some programmatic way. Use cases of type 2 (classes as instances) might expect logical consequences; however, the precise interaction is usually axiomatized using rules. Use cases of type 3 (annotations/data/object properties) might require some logical consequences.

Punning is a simple way to provide for metamodeling that (a) does not require a major change to OWL 1.1 (DL) reasoners and (b) usually seems to satisfy the semantic requirements.

References

  1. Steffen Lamparter, Anupriya Ankolekar, Stephan Grimm, Rudi Studer: Preference-based Selection of Highly Configurable Web Services, WWW-07, Banff, Canada, May 2007. PDF
  2. B. Motik: On the Properties of Metamodeling in OWL, ISWC 2005, Galway, Ireland, 2005. PDF
  3. 3.0 3.1 Markus Krötzsch, Denny Vrandecic, Max Völkel, Heiko Haller, Rudi Studer: Semantic Wikipedia, Journal of Web Semantics 5: 251–261. September 2007. PDF
  4. Denny Vrandecic, Markus Krötzsch: Reusing Ontological Background Knowledge in Semantic Wikis, Proceedings 1st Workshop on Semantic Wikis. Budva, Montenegro, June 2006. PDF