HCLSIG/OWL1.1

From W3C Wiki
Jump to: navigation, search

HCLSIG Use-Cases for Utilizing OWL1.1 Features

This is to help the HCLS community better understand the features OWL 1.1 and their applications in the Life Science and Healthcare context. For more overview information, see http://www.w3.org/Submission/owl11-overview/

Examples

Below is an open list of the OWL 1.1 features as related to some basic HCLS examples (please add any relevant examples):

Qualified Cardinality Restrictions (QCRs)

These allow one to classify based on there being a certain number of instances of a specific class as a property.

  1. The classic example is that you can now say that a hand has_part 5 digits, has_part 4 fingers, has_part 1 thumb. Before QCRs you could only say hand has_part 5 things.
  2. Can also be used to implement the ACPP counted inclusion and exclusion criteria rules.

Datatypes Restriction

Datatypes allow the specification of classes that restrict, e.g. a number to a certain range.

  1. One can define "Adult" as someone whos age is greater than 18 years.
  2. Useful in the clinical context, e.g., for classification based on diagnostic results.

Role Inclusions

Role inclusions allow for propagation of values across more than one property. A useful example would be when using reified properties.

  1. This is useful in, e.g. Biopax, where it will allow you to much more cleanly connect pathways to participants in the pathways. That's because you can express the fact that if a complex is a participant, and the complex has components, then the components are also participants.

component of participant < participant.

  1. Another example is that of traversal using the part_of hierarchy. For e.g., if the ventricle is a part of the heart and the heart is a part of the body, then the ventricle is part of the body.
   PART_OF o PART_OF < PART_OF (n.b. this is equivalent to transitivity of a property, already part of OWL DL)

Punning

Punning gets rid of a big reason for using annotation properties, when you otherwise would want to use a datatype or object property with a class or property as subject. Punning lets you do that, with the caveat that, e.g, properties of classes don't have any effects on their instances. It implements this by allowing a given URI to be a name for an instance, a class, and a property all at the same time and using the usage context to decide which of the three is meant.

Example: It happens all the time that you want to, say, restrict some property (say curator) to one of several values. Since curator makes sense for both classes and instances, previously you couldn't say this because being a property of a class meant the property had to be an annotation, and therefore have no axioms. Now it no longer does. Suppose you say :aninstance rdf:type :myclass. :myclass :curator :alan. In the first triple, :myclass is in a position where a class must be, so we are referring to the class :myclass. In the second triple :myclass is in a position where an instance must be, so we are referring to the instance :myclass.

Disagreement and Counterargument: (Vipul Kashyap) I have reservations on the use of punning, because it can be the cause of potentially dangerous errors while designing an ontology.

Disagreement and Counterargument: (Vipul Kashyap) properties like curator belong to the OWL meta-model layer, where: classes, properties, axioms, constraints and instances are all treated as data. I think there is a need for separation of concerns here, though I need to do some more thinking around this to be sure. I would propose that it makes for good practice to define these two notions as different properties, because the notion of curator probably has different set of semantics when applied to class as opposed to when applied to instances.