Feedback on the W3C's proposal of the delivery context ontology
From Morfeo Wiki
Morfeo-MyMobileWeb comments on the Delivery Context Ontology
Authors:
Diego Berrueta y Luis Polo (Fundación CTIC)
Contributors:
Jose M. Cantera (Telefónica I+D) y Miguel Jiménez (FI-UPM)
Contents |
Introduction
This page includes comments about the current (at the time of writing this) Delivery Context Ontology proposal developed by the UWA and DDWG. The proposal is still a draft and has not been published yet.
These comments have been written by the participants of the WP3 of the MyMobileWeb CELTIC project.
Level of expressivity
We think the ontology should be in the OWL-DL variant of OWL. Reasons to this are that logical properties of the ontology can be exploited with DL reasoners, like Pellet or Fact: satisfability of the the concepts of the ontology, subsumptions, etc. By the way, we are not sure the level of expressivity of the current proposal. We have tried to check it with Pellet and we have obtained different results from the command line and calling Pellet from ontology editors like SWOOP or Protégé. Only the former states the ontology has DL level. We need deeper research to clarify this disagreement.
JMCF: This is done and reflected on the current version of the ontology http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-10-31/DCOntology.html
Disjointness Mechanism
We recommend to use the OWL constructor owl:disjointWith to assert disjoint concepts in the ontology. The current approach is very cumbersome and bizarre. Also the DIG protocol doesn't implement this operator (owl:hasValue) with datatype properties. Protege makes very easy to asser disjointeness between classes.
JMCF: Rhys suggested to maintain the current approach as it is described in the OWL Test Suite. A clarification has been made on the document to reflect why that bizarre disjoint mechanism has been used (to workaround a limitation of OWL).
Comments about the Alternate_names class
In the ontology, the Alternate_names class has as instances alternative names for resources of the domain modelled in the other branch of the ontology (DeliveryContext_Entity class and its subclasses). We consider it is not a good practice to model as instances the possible names a concept can be referred with. Moreover, in our opinion, names or labels shouldn't be part of the model of the domain and should be treated as annotation information. Following this pattern, we suggest to move these data from their current ontological status as instances to literals, and to use the property rdfs:label or a custom-made annotation property (for example, alternativeLabel) to relate the concepts to their different alternative names.
JMCF: An example provided to Rhys for his consideration
Comments about the Associated_UAProf_Entity Class
The ontology has a class, Associated_UAProf_Entity, that is used to reify the UAProf properties as instances of this ontology. These instances are then used as values of the annotation property rdfs:seeAlso. We think this is not necessary. It can be linked the object of the domain directly to the UAProf properties, obtaining the same results by letting elements of the UAProf specification being external resources of the ontology. This link can be done with rdfs:seeAlso or with a new custom-made annotation property (for instance, equivalentUAProfEntity).
JMCF: An example has been provided to Rhys for his consideration
Unit issues
Representation mechanisms
The problem of how to represent units systematically is an open issue in the ontology community. There are some factors like the granularity of the ontology or the modelled specific domain that affect the way in which unit should be treated. In the Delivery Context Ontology, units represent the kind of data used in the description of the device's properties, but modelling or defining them is out of scope.
We propose two different approaches that are still preliminary and need further research:
- To define a new datatype using XML Schema: for instance, meters could be a subtype of xsd:float. The advantage of this method is that is very simple and intuitive. Its main drawback is that the semantics of this approach is not well-understood yet. This approach requires a separate XML Schema to be used in conjunction with the ontology.
- To qualify the data using the same techniques as Dublin Core initiative ([1]). With this method, schemes where the semantics of the data is defined can be encoded directly in the ontology: a data-value of an attribute property will have specified the corresponding unit of measurement, as the following example shows. The main advantages are that it has a well-defined semantics using the current specification of RDF. On the other hand, the direct link between the object and its value is lost, since there is an intermediate blank_node. These structures shall be taken into account to perform queries.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns="http://example.org/">
<rdf:Description rdf:about="#me">
<height>
<rdf:Description rdf:value="1.77" rdfs:isDefinedBy="http://example.org/meters"/>
</height>
</rdf:Description>
</rdf:RDF>
- Regardless the alternatives above, we propose to avoid using different units encoding the device capacities information. Our suggestion is to set normative units for each measurable quality, based, for instance, on the International System of Units. For instance, for length, only meters should be used directly in the ontology. The unit should be specified in the rdfs:label of the property, or even better, using a new annotation property (measuredIn). Automatic conversion to other units can be done for different purposes.
Diego and Luis to make a proposal before next MyMobileWeb package 3 meeting (October 24th)
Unsatisfiable concepts
If Pellet is run from the command line it is reported that there are two concepts, MeterToMillimeter and MeterToCentimeter, that are unsatisfiable, i.e. they can not have instances because they are in conflict with some axioms of the ontology. In order to solve this issue either the conflict has to be removed or even better to remove these classes.
This presumably has been fixed in the current version
Measurable quantities
In the ontology there are some properties that can be measured with different units (for example, meters, centimeters, inches, etc.). The values of these properties are represented as different objects of the domain and not pure data (literal nodes in RDF representation). For instance, in the ontology there is the object oneCentimeter being an instance of the class Centimeters. The problem with the units will be solved elsewhere, and therefore there is no need of this kind of classes and instances.
We need to investigate further
Unit Conversion
An OWL ontology cannot reason with conversion factors. They can be represented but nothing more. Furthermore, they are out of scope of the Delivery Context Ontology. We kindly suggest to remove them from the ontology. The conversions can be executed by an external service (e.g. Google).
We need to investigate further
Terminal Device vs. Device Model
It is clear that there are some properties that apply to the model of the devices (e.g. NokiaN70) and some features specific of particular devices (e.g. My own device). In CC/PP vocabulary the former properties are treated as default characteristics and the user can overwrite these values. The approach followed by the Delivery Context Ontology is that, the class Device refers to the model of the Device. We suggest to rename this class as DeviceModel and add a new one TerminalDevice, otherwise it is very difficult to model contextual information such as the battery level, the signal power or ambient parameters: location, temperature, etc. The instances of DeviceModel and TerminalDevice can be linked using a property such as memberOf.
JMCF: According to Rhys the Device class can represent both the class of the device and an specific device
