MUO&IPP

From Morfeo Wiki

Contents 1 Differences 2 Expressing measurements in the Semantic Web 2.1 Easy measurements, Interpretation Properties Pattern (IPP) 2.2 Advanced measurements, Mearument Units Ontology 2.3 Bridging both representation formats 2.4 The "Complete World" for measurements, MUO/IPP Framework 3 Exploitation of measurements in the Semantic Web 3.1 Automatic conversions for data integration 3.1.1 From MUO to IPP 3.1.2 From IPP to MUO 3.2 Reasoning Services 3.3 Queries

Differences

MUO and Interpretation Properties Pattern (IPP) are not easy to directly reconcile together. The main differences are the following:

• Treatment of Units of Measurement. In MUO, units are modeled as individuals. On the other hand, IPP pattern handles units as datatype properties.
• Treatment of Physical Quantities. Again, in MUO, quantities belong to the universe of discourse and are first order entities. However, IPP pattern models quantities as properties.
• What is measured. Both approaches propose patterns to represent measurements of objects' physical properties, managing same concepts: quantities and units of measurement. The divergence consists in the ontological aspect of the measurement. On the one hand, MUO does not consider the physical property of an object as itself (for instance, the individual that represents the weight of a device), but the measurement of the physical property (a.k.a, a quale). On the other hand, IPP introduces the physical property of the object as an individual of the discourse's domain. At this approach, the measurement is relation between object's actual physical quantity and its value. The measurement is represented using a specific unit of measurement.
• Level of expressivity. Everything that can say in IPP can be said in MUO. However, not everything that can be said in MUO can be said in IPP.

Expressing measurements in the Semantic Web

The value of a physical quantity Q is expressed as the product of a numerical value {Q} and a physical unit [Q]:

    Q = {Q} x [Q]. 

This physical quantity is inherent (or it is adscribed) to a particular individual or object of the physical world. In metrology, this indivudual does not appear in mathematical models, but it must be considered in domain modeling, as it is the subject of measurement. There are several RDF/OWL patterns that may be used to represent measurements. MUO allows two complementary and interchangeable formats to represent values of physical quantities.

Easy measurements, Interpretation Properties Pattern (IPP)

The first pattern considers abstract physical quantities for representing values of a physical quantity, closed to the principles of quantity calculus, a system of algebra in which symbols are used to represent physical quantities rather, than their measures, i.e. numerical values in certain units. The value of a physical quantity is always expressed as the following product:

   physical quantity = numerical value x unit

In the quantity calculus, units are related, therefore given that

   m = 1000 mm

where m stands for metre and mm for milimeters, we may write for the heigth of an object a:

   h(a) = 1820 mm = 1.82 m

NOTA: Existe un MUO Core que consiste las General Physical Quantities y las Units. Existen además dos patrones IPP y MP (Measurement Pattern). Existen dos tipos de reglas RIF:

1. Reglas de derivación: las que a partir de MUO Core generan las propiedades para expresar values of quantities, de acuerdo con los patrones MP y IPP. Estas reglas podrían ser reglas RIF.

1. Reglas de conformance: Dada una implementación de MUO, las reglas que validan que la base de conocimiento es correcta para utilizar alguno de los patrones.

producer and consumer IPP conformance definition

Advantages of IPP

• Simple for developers/producers
• Simple for consumers
• Simple for quantity calculus

Advanced measurements, Mearument Units Ontology

In MUO, the class muo:QuantityValue is used to represent the values of quantities, Q. Instances of this class are related with 1) exactly one unit, suitable for measure the physical quantity (meters for length, grams for weight, etc), by means of the property muo:measuredIn, [Q]; 2) a number, which express the relationship between the value and the unit by means of the rdf:value property, {Q}; 3) a time, which expresses the quantity value along the line of time. Quantity values can be temporalized, but this is not always necessary.

Bridging both representation formats

• Set of annotation properties
• How IPP can be derived from MUO
• Rules for derivation expressed in RIF PRD

This approach introduces new individuals and properties in order to have enough information to automatically transformate between both formats. We will introduce the following statements:

• For each MUO unit of measurement: "unit", a new datatype property is created: "in+Unit" (a.k.a, Interpretation Property). To synchronize both resources, an annotation property, "muo:propertyDerived" is used. Notice that the direction of the annotaction property is from "unit" to "in+Unit" property. The argument for this approach is to have normalized derived interpretation properties which a user can reach from unit definition. For instance, the description of meter will contain the following information:

:meter   rdf:type   :UnitOfMeasurement  ;
         :propertyDerivedf   :inMeters  .

:inMeters   rdf:type   owl:DatatypeProperty  .

• For each MUO physical quantity: "Quality", at least a new objet property is created: "quality" (for IPP representation). This property is functional and its range represents a concrete individual quality of a physical object. For instance, the weight of a device. Notice that we are not talking about any measurement of this physical magnitude, but about the individual weight itself. In summary, that a device has one and only one weight quality. However, it is not really clear how many properties must be created, because this new property can not be used in MUO as it is assumed that the property is functional and that its range is not a measurement (a quale, in MUO's terminology). This is the reason to propose two possible alternatives which consider the creation of another property for MUO pattern:
  1. At least, two new properties are derived from the physical quantity in a hierarchy relationship. From a physical quantity, "Quality", 1) "quality" is derived, to use in MUO; 2) "qualityFunctional" is derived, to use in IPP. The property "quality" subsumes "qualityFunctional" and both are related with the entity "Quality" by the annotation property "muo:qualityDerived" (similar to the previous one for units)
  2. At least, two new properties are derived from the pysical quantity. Firstly, the one used for MUO pattern, being a subproperty of "muo:qualityValue". Secondly, the one used for IPP pattern (being a subproperty of "muo:hasQuality", TO BE DISCUSSED).

First option,

:Weight    rdf:type   :PhysicalQuality  ;
           :qualityDerived    :weight ;
           :qualityDerived    :weightFunctional  .

:weightFunctional   rdfs:subPropertyOf   weight  . 

Second option,

:Weight    rdf:type   :PhysicalQuality  ;
           :qualityDerived    :weight ;
           :qualityDerived    :weightFunctional  .

:weight             rdfs:subPropertyOf   :qualityValue  .
:weightFunctional   rdfs:subPropertyOf   :hasQuality  . 

• Advantages:
  1. MUO and IPP are loosely coupled.
  2. Combinations of MUO and IPP in the same knowledge base are still DL-safe.
  3. Automatic conversions between both representation formats

The "Complete World" for measurements, MUO/IPP Framework

Full integration for MUO and IPP. Both approaches can be derived from MUO/IPP Framework

Distinction between

• simple qualities (in IPP, as intances of Quality)
• physical quantities (in MUO, as instances of Quality)
• physical qualities (in MUO/IPP as properties). They are derived from physical quantities. A physical quantity can produce several qualities, such as length and height.

Exploitation of measurements in the Semantic Web

Automatic conversions for data integration

From MUO to IPP

MUO measurements can be converted to IPP measurements applying a transformation based on the "bridge" defined above. Consider, for instance, the following RDF graph:

<http://muo-example.org/graph1> 

:stick  :lengthValue [ rdf:type  muo:QualityValue
                       muo:numericalValue "1.35"^^xsd:double ;
                       muo:measuredIn muo:meter ] .

muo:meter   muo:qualityMeasures   muo:length .

In this example, :lengthValue is derived from the physical quantity muo:length applying condition [FIXME] of MUO:

:lengthValue  rdfs:subPropertyOf   muo:qualityValue ;
              muo:qualityFrom      muo:length  . 

Moreover, the application of MUO conditions [FIXME] derives the following:

:hasLength   rdfs:subPropertyOf   muo:hasQuality ;
             muo:qualityFrom      muo:length  .

The same conditions [FIXME] applies to muo:meter as a unit of measurement:

:inMeters    rdfs:subPropertyOf   muo:inUnit ;
             muo:unitFrom         muo:meter  .      

The following RIF-PRD rule defines the conversion from a MUO measurement to an IPP measurement:

Import(<http://purl.oclc.org/NET/muo/muo#> <http://www.w3.org/2007/rif-import-profile#Simple>)

(* :rule_muo2ipp *)

Forall ?object ?measurement ?unit ?hasquality ?inUnit ?qualityValue ?quantity such that 
         And  ( ?object [?qualityValue -> ?measurement]
                ?measurement # muo:QualityValue
                ?measurement [measuredIn -> ?unit]
                ?qualityValue [rdfs:subPropertyOf -> muo:qualityValue
                               muo:qualityFrom -> ?quantity])
If       Exists ?hasquality ?inUnit
         And   ( ?hasquality [muo:qualityFrom -> ?quantity 
                              rdfs:subPropertyOf -> muo:hasQuality]
                 ?inUnit [muo:unitFrom -> ?unit 
                          rdfs:subPropertyOf -> muo:inUnit])

Then Do( (?value ?measurement [muo:numericalValue -> ?value]) (?quality New ()) 
     Assert(?object  [?hasquality -> ?quality])
     Assert(?quality [?inUnit -> ?value]) )

If we apply this rule to the previous RDF graph,

Import(<http://muo-example.org/graph1>  <http://www.w3.org/2007/rif-import-profile#Simple>)
Import(<http://purl.oclc.org/NET/muo/muo#> <http://www.w3.org/2007/rif-import-profile#Simple>)

(* :rule_muo2ipp *)

the execution of the rule gives as a conclusion the following statements (the result is expressed in RDF. It is supposed that results are translated from RIF to RDF):

:stick :hasLength  [ :inMeters "1.35"^^xsd:double ] .

Notice that MUO ontology is imported using RDF Simple profile. At this moment, the combination of RIF-PRD with RDF/OWL is only defined for simple entailment regime, inheriting from RIF-Core dialect. This implies that an OWL ontology will be interpreted just as a simple RDF graph.

Also notice that there might be a loss of information in the transformation process. As IPP is not as expressive as MUO, when you convert measurements with data about timestamp, margin of error, authorship of the measurement, etc., this information can not be preserved in the target format (i.e., IPP). This is not a problem itself, it is just a natural limitation that arises from the downgrading process.

There is an open question here about definition of units and qualities, whether they are in the MUO specification, or in another separated file, or even they are inferred applying previous defined conditions. This rule assumes that corresponding properties have been derived for a particular physical quantity applying MUO entailment regime defined in above conditions [FIXME]. Moreover, this rule also assumes that a specific property is used to expressed the quality value, and not the generic one: muo:qualityValue. Therefore, two cases must be considered in the future [FIXME].

From IPP to MUO

IPP measurements can be converted to MUO measurements applying a transformation based on the "bridge" defined above. Consider now the following RDF graph:

<http://muo-example.org/graph2> 

:stick  :hasLength [:inMeters "1.35"^^xsd:double ] .

Consider also previous definitions of both properties derived from the application of MUO conditions (i.e., MUO entailment regime, FIXME).

The following RIF-PRD rule defines the conversion from an IPP measurement to a MUO measurement:

Import(<http://purl.oclc.org/NET/muo/muo#> <http://www.w3.org/2007/rif-import-profile#Simple>

(* :rule_ipp2muo *)

Forall ?object ?hasQuality ?inUnit ?quantity ?quality ?unit ?value such that 
         And  ( ?hasQuality  [rdfs:subPropertyOf  -> muo:hasQuality
                              muo:qualityFrom  -> ?quantity ]
                ?inUnit  [rdfs:subPropertyOf  -> muo:inUnit 
                           muo:unitFrom  -> ?unit ]
                ?object  [?hasQuality  -> ?quality ]
                ?quality [?inUnit  -> ?value ] )

If       Exists ?qualityValue 
         And   (?qualityValue [muo:qualityFrom -> ?quantity 
                                rdfs:subProperty -> muo:qualityValue ])
 
Then Do( (?measurement New())
     Assert(?object [?qualityValue -> ?measurement])
     Assert(?measurement [muo:measuredIn -> ?unit]) 
     Assert(?measurement [muo:numericalValue -> ?value]) )

If we apply this rule to the above RDF graph,

Import(<http://muo-example.org/graph2>  <http://www.w3.org/2007/rif-import-profile#Simple>)
Import(<http://purl.oclc.org/NET/muo/muo#> <http://www.w3.org/2007/rif-import-profile#Simple>)

(* :rule_ipp2muo *)

we obtain the following dataset (after applying conversion between RIF and RDF):

:stick :lengthValue  [ muo:measuredIn -> muo:meter  ;
                       muo:numericalValue -> "1.35"^^xsd:double ] .

Reasoning Services

MUO reasoner New extensions should be considered

Queries

MUO and IPP patterns can live together in the same RDF graph, in particular when we are talking about Linked Data universe. As we have said previously, MUO is a superset of IPP, thus we expect measurements can be uniformly accessed without much consideration about which of both formats is used to express measurements. Nevertheless, things are not as easy as we imagine. SPARQL is a query language for RDF datasets but SPARQL is not aware about MUO and IPP compatibility (i.e., about the shared semantics of both representation patterns).

Our approach is to provide users with an invisible mechanism to be able to query in a particular format and retrieve answers from data in both formats. For instance, to formulate a MUO query and obtain results coming from MUO and IPP datasets. The idea is to have:

1. a SPARQL query for MUO patterns: Q1(MUO), and transform it to an equivalent IPP SPARQL query: Q2(IPP);
2. a SPARQL query for IPP patterns: Q1(IPP), and transform it to an equivalent MUO SPARQL query: Q2(MUO).

These transformations can be done dynamically applying some methods to the Abstract Syntac Tree of the query.

• PropertyListNotEmpty > Verb (...) > IRIRef: qualityValue property.
  • Checking conditions: qualityValue property must be subproperty of muo:qualityValue and it must be derived from a particular quantity.
  • Operation: get the hasQuality property derived from quantity. Substitute qualityValue property with hasQuality property.

• PropertyListNotEmpty > Verb (...) > IRIRef: muo:measuredIn && PropertyListNotEmpty > Verb (...) > IRIRef: unit.
  • Checking conditions: unit is an instance of muo:UnitOfMeasurement
  • Operation: get the inUnit property derived from unit. (TO BE CONTINUED)