The current OWL speci cation does not include a syntax for specifying calculated values for data type properties. Their introduction, although acknowledged among the desiderata, seems yet unlikely to appear in the forthcoming OWL 2.0. This paper shows one way of working around this absence using annotations. The aim here is not to suggest a standard but, rather, to individuate the potential issues that a full edged standard solution will have to tackle.
Our framework o ers the possibility to attach one or more alternative formulas1 to a data property so that, after a preprocessing phase, each individual admitting such properties in an OWL ontology, could have a ller computed using the appropriate formula. Our initial assumption is that formulas ought to be attached to properties. The most direct way to do that is by means of annotations on the 1 Please notice that the words formula, calculations, and their plurals are used henceforth interchangeably as synonyms for the same concept data property themselves. This has the direct consequence that, in the frequent case in which di erent classes of individuals require di erent formulas for computing the value for the same data property, such property will present as many annotations as there are alternatives. Moreover, this requires a mechanism for deciding which one should be applied. A more object-oriented approach would have, on the contrary, suggested to attach formulas to classes. However, we decided against the latter because it would have been convenient only for formulas that applied to named classes2, as there is no way in OWL to annotate a non primitive class. The only workaround would be to de ne such complex classes by asserting their equivalence with a named one, and then annotate the latter with the formula. However, this would not scale and would introduce new class names whose relevance in terms of domain model is at least dubious. Furthermore, OWL is axiom, rather than, object-oriented and this makes the annotation of properties more natural than the annotation of classes with formulas.
In Fig. 1 we summarise graphically the components of a formula in our framework: A formula can be decomposed into the following blocks: { Conflict Strategy: Indicates the strategy to adopt when a value is calculated for a functional property that already has got a ller for for the individual under consideration. The possible strategies are:
OVERRIDING - The engine will replace the existing value with the newly computed one.
OVERRIDDEN - The engine will discard the computed value preserving the existing one.
EXCEPTION - The engine will raise a speci c exception relinquishing control to an external application or to the user. { Applies to: Class expression that restricts the application scope of the formula to the instances of such description (Optional, if omitted the property domain will be the scope). In case more than one formula is applicable to an individual (i.e.: the individual is in more than one Applies to restriction for the same property, and such scopes are incomparable w.r.t. subsumption) an exception is raised and no value is computed. 2 Named class here is used to denote either de ned classes or primitive ones, as opposed to unnamed, anonymous, complex class { Bindings: A binding is an assignment of a formula variable. Each binding is a property chain that yields to a value (or a set of values) to be assigned to the corresponding variable in the formula. { Storage: Like bindings, storage paths are property chains that determine where to store the computed value(s). They are made of object properties only and the nal data property is omitted as it is the data property annotated by the formula itself. If omitted, for each computed value, a ller for the annotated data property will be attached directly to the each individual in the formula application scope. { Formula Body: The formula itself. It can be a simple formula or an aggregate. In case of multiple bindings for a variable, the former will output multiple results, the latter ones will out put the corresponding aggregate value.
We developed a syntax for encoding all the above inside OWL annotations
attached to data properties. The complete grammar can be found at
http://www.cs.man.ac.uk/~iannonel/owlcalculations/syntax.html. Besides
dealing with cases of di erent formulas for the same data property inherited by
an individual on account of multiple inheritance, our framework does not solve
any of the theoretical problems referenced above (see [
To the best of our knowledge, there is not, at the state of the art, a standard
way to express, in OWL, that the llers of a data property can (or should) be
derived from others by means of a formula. The immediate plans for OWL 2.0
speci cations drafted so far [
We presented a framework that enables the attachment of formulas to a data property in OWL and the computation of its values. This has been done in view of a more thorough standard speci cation covering this functionality for OWL and represents a temporizing solution. We also developed an API and a plug-in for Prootege 4 ontology editor that can be found along with essential documentation at http://www.cs.man.ac.uk/~iannonel/owlcalculations/. Future work in this direction will focus on layering formulas on top of each other, augmenting the set of arithmetic operators available, devising extension for custom strategies for con icts between computed values and pre-existing ones, and heuristics to detect dangerous (potentially undecidable) interactions with the reasoners.