Warning:
This wiki has been archived and is now read-only.

Main Page

From W3PM
Jump to: navigation, search

Product Modelling XG (W3PM) Wiki

Initial content by the initial Chair, Michel Böhms (TNO). Heaviliy extended by David Leal for Quantities, Units & Scales. This public wiki can be seen by all and edited by all XG members.

Abbreviations

Optionally a context for the abbreviation is given in brackets.

  • BREP - Boundary REPresentation
  • CWA - Closed World Assumption
  • D - Dimensional (as in 3D)
  • DBO - Design, Build, Operate (typical global LC phases)
  • EU - European
  • FP - Framework Programme [EU]
  • ISO - International Organization for Standardization
  • LC - Life Cycle
  • OWA - Open World Assumption
  • OWL - Web Ontology Language [SW]
  • PM - Product Modelling
  • PMO - Product Modelling Ontology [SWOP]
  • SC - Supply Chain
  • SE - System Engineering
  • SW - Semantic Web (activity) [W3C]
  • SWOP - 'Semantic Web'-based Open engineering Platform [FP7]
  • STEP - STandard for the Exchange of Product model data [ISO]
  • W3C - World Wide Web Consortium
  • W3pm - WWW product modelling XG Group [W3C]
  • WWW - World Wide Web [W3C]
  • XG - Incubator Group [W3C]

Definitions

DEFINITION Product
A product can be a ‘one-of-a-kind’, such as (typically) a building, ship or process plant, or a mass produced item, such as a car, refrigerator, or notebook computer. A Product will in general involve one or more Life Cycle phases and one or more Supply Chain levels.
A Product will always refer to a particular individual physical product in reality. "Something you could point at".
DEFINITION Product Modelling
Product Modelling involves Product Ontologies (product models can be regarded as instantiations or sets of individuals according to these product ontologies).
DEFINITION Product Ontology
A Product Ontology defines all possible/impossible configurations (instances/values) for a given product by specifying its relevant classes, (datatype and object) properties (including min/max cardinalities and relevant underlying datatypes) covering one or more product LC phases:
  • Design
  • Built (realize, manufacture, construct, ...)
  • Operate (use/exploit, manage, maintain the product by the end-user)
(including the relevant SC levels in all LC phases and/or disciplines (aestetics, function, form, material, cost, time, environmental issues etc.).

Scope

The scope of this XG is 'Product Modelling (PM)' with 'Semantic Web (SW)'-technologies. A product ontology can be defined from scratch in OWL but it is found that there are many generic features (though not part of current OWL-1.0 or future OWL-1.1/2.0 itself) that can be modelled by a reusable, generic ‘upper ontology for product modelling'.
The idea is that this W3pm XG will provide an OWL-based “language for” product ontology development. Graphically:

click to enlarge











The basic notion is that the (sub-)classes in an ontology contain ('virtual') individuals as members that directly correspond to physical individuals. These classes can be seen as corresponding to physical counterparts ('physical types') too. Graphically:

click to enlarge











The idea is to have a strongly modular approach for this XG. Small, focussed and clean Product modelling modules that can be flexibly mixed and matched to provide specific product modelling capabilities on top of plain OWL (OWL1.0 and/or OWL1.1/2.0).

The following modules are currently foreseen:

Short-term

  • Quantities, Units & Scales
    • Link with product-related classes and their datatype properties
    • prefixes ('multiples') like kilo
    • derived units like m/2
    • alternative units like miles
    • scalars versus higher-order tensors
    • need for n-ary relationships?
    • need for n-ary datatypes?
  • Product Decomposition
    • hasParts versus partOf versus both
    • Use of QCRs from OWL1.1/2.0?
    • direct via indirect parts (transitivity issue)
    • need for closures for 'atoms' in OWA
    • multiple decomposition
  • Topology
    • Need for 0D, 1 D, 2D, 3D, 4D objects/events?
    • Connection: Bound-by relationships (semantic counterpart of geometric evaluation)
    • Containment: Included-by relationships (idem.)

Long-term

  • Product-related Archetypes
    • Processes versus Products
    • Functions versus Spaces versus Physical Products
    • Interpretation/handling of “Features” compared to physical products
  • Explicit Shape Representation (geometry)
    • Compare IAI IFC/geometry part in case of construction sector
    • Compare ISO STEP Part42
  • Product Knowledge Rules (“Rules”)
    • Assertions versus derivations (both logical and calculations)
    • Link will RULE group (via Coordination/Ivan)
  • Specific Product Variants
    • Use of class variables (hasValue)

-Datatype property values -Object property values (“local occurrences/reuseable fixed BoM”)

  • Default values/individuals (“Defaults”)
  • As-Required/Allowed versus As-Designed/Proposed versus As-Built/Realized/Delivered/Constructed versus As-Operated
    • Interrelationships between Design & Built, Built & Operate, and Design & Operate
  • Change over Time
  • Product Versions
  • Alternative Ways/Solutions

Since we decided to first (short-term) address Quantities & Units, Product Decomposition and Topology some ideas/notions are detailed below at 'Design Principles' for these.

Use Cases & Requirements

We should clearly describe what our product ontologies/models are intended to support resulting in the right level of required expressivity in common PM modeling tasks.

So far we identified three primary product modelling needs that are to the point regarding what one wants to *do* in and the role of an ontology-based product modeling tools.

  1. The first need is to have consistent terminology with well-defined meaning that is stated independently of (the interpretation by) subject matter experts. Terminology with semantics is needed to facilitate and reuse information across specific applications within a broad community of interest. This is a primary use of OWL in life sciences etc.
  2. The second need is for consistency checking and verification tasks. Such tasks can be stated in terms of relationships between product modeling classes and properties of individuals in these classes. For example, one may want to check that a collection of requirements are consistent. This task can be expressed in terms of a class being consistent which means that it has models. This kind of reasoning can be performed in an appropriate framework. In my current job is concerned with, for example, verification that product versions that have been built according to a specific design also satisfy specific requirements such as weight restrictions. Reasoning is intrinsic to these kinds of tasks, as are observation and measurement. Current system engineering and product development language standards and the tools that operate on the KBs in the languages of standards do not address semantics and reasoning. The languages may be sufficiently expressive but there is no formal semantics. OWL 1.1 has been used to satisfy the first need for life sciences as it has such as semantics and so that is why it is a natural candidate for product modeling.
  3. Higher level software application functionalities on top of 1 and/or 2. Examples are SWOP's Product Configuration/Optimisation functionalities.

Ideas & Design Principles

General

Top-down versus Bottom-up ('use case requirements first' versus 'solutions first')

Looking at all things said sofar by e-mail I think we can safely conclude that the "truth is as usual in the middle". We will define our use cases and corresponding requirements and wishes as clear as possible. Next we will see how existing solutions (OWL-DL, OWL-Full) can or cannot satisfy these. It's clear that a solution beyond OWL-DL or even OWL-Full would for certain use cases/requirements not preferred (agreed product description language is one thing but reasoning capabilities in finite time is another...). To conclude: we will have to work both top-down and bottom-up (is this middle-out?) to get to the right compromise of reuse of resources already there and new capabilities to be developed.

Quantities & Units

Implicit versus Explicit

We should realize that quantities & units is a topic that is already thought about a lot for a long, long time. Some of the base standards here, ISO-1000 and ISO-31 do already quite a lot of specification. So how explicit should we be in our models? In the extreme can we just define a unit property or annotation property that has as underlying type an enumeration of all (or all typically relevant/used) names or symbols described in those existing ISO document. Counter-argument is that a bit more explicit specification would cover much more (potentially relevant) units. Example: m^2 is mentioned but m^6 is not. So, or we change our upper-ontology if we need m^6 or we can already dynamically define it when we use an exponential approach being able to specify already from the beginning all possible algebraic combinations of base units.

Class-level versus individual level

Often quantities and/or units are defined on class-level being relevant per definition for all members/individuals of that class. Some approaches however define quantiies or even units on member/individual level so that in the ontology we just have “height” defined that can be instantiated as “3.5 m” but also “418 km” or “16 mile” on individual level. It seems that it would be a good idea to have the most abstract info, the quantity info, at class level (i.e. as ontological information) where the actual unit used (incl. which alternative unit for such quantity including potential 'multiples') is modelled on instance/member/individual level. This seems a good approach balancing semantics and felxibility. We should think however about the need to already on class level constrain some quantity to some actual unit maybe even already having a fixed prefix.

Link with properties

Clearly the way we model units in the end will be influenced by the way we model specific properties of products since the value(s) of these properties are specified/measured according these units. In a pure/direct OWL way our product properties become instances of owl:DatatypeProperty like:

<owl:DatatypeProperty rdf:ID="doorColour"/>

Some approaches start to meta-model these product properties (for instance by subclassing owl:DatatypeProperty) as a new meta-class. Clearly in the one or the other way different approaches are possible or impossible to connect quantities/units to these product properties.

In the first case one could use an annotation property (like in SWOP/PMO), in the second case there is more flexibility (with penalties of course) to model a unit just as a property being connected in some way to the new meta-class say “ProductProperty”.

Quantities versus Units

Quantities and units are strongly connected; often even confused. Typically there are more units than quantities (see the length example above). That is why in general a quantity would feel a bit more abstracted and maybe easier related to the actual product property involved. On the other hand, when you agree to only agree ONE unit for a certain quantity, both concepts seem to unite (well at least have a one-2-one correspondence after all). Most systems use just units, some more complex/explicit systems use both.

Base quantities/units versus derived quantities/units

Base quantities (typically seven + maybe “currency” and “amount”) are easily agreed. The algebraic combinations are the harder part (EURO/m; farad^4). Typically the most relevant derived quantities/units have “own” names (like inductance in henry (H) for Wb/m^2). In more complex/flexible systems the derived ones are specified in terms of an exponent vector. If such vector is defined by [length, mass, time, etc.] the representation for velocity would be [1, 0, -1, 0, ...]. Clearly we define in such a way an infinite amount of (derived) units.

Multiples/Prefixes

A typical question would be if we have to specify (and thus agree) multiples of units say via prefixes like milli, kilo etc. To keep things simple one could also decide to leave them out since any user/software can do the transformation him/itself. At the same time avoiding quirks in the SI system like “kg”.

Higher order (than scalar) tensors (like units for matrices)

Typically we address simple scalar properties. In many technical contexts it might however be necessary to address higher level tensors like matrices. Such more composite properties could be associated to more complex/composite units too. Alternatively one can leave this extra complexity “at the property side” and just associate sets of simple units. Anyway, it’s worth a discussion.

Decomposition

Use of Qualified Cardinality Restrictions (QCR’s) as in OWL2.0

OWL2.0 (formerly OWL1.1; or whatever they will call it in the end) seems to provide a mechanism for a controlled/managed way of decomposition (where I mean controllable/manageable cardinalities involved). An example: a façade has exactly one door and at least two windows would be defined as: 

<owl:Class rdf:ID="Facade">
<rdfs:subClassOf>
 <owl:Restriction>
  <owl:onProperty rdf:resource="http://www.swop-project.eu/ontologies/pmo/product.owl#hasPart_directly"/>
  <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1</owl:minCardinality>
  <owl11:onClass rdf:resource="http://www.swop-project.eu/ontologies/d23/door.owl#Door"/>
 </owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
 <owl:Restriction>
  <owl:onProperty rdf:resource="http://www.swop-project.eu/ontologies/pmo/product.owl#hasPart_directly"/>
  <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1</owl:maxCardinality>
  <owl11:onClass rdf:resource="http://www.swop-project.eu/ontologies/d23/door.owl#Door"/>
 </owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
 <owl:Restriction>
  <owl:onProperty rdf:resource="http://www.swop-project.eu/ontologies/pmo/product.owl#hasPart_directly"/>
  <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">2</owl:minCardinality>
  <owl11:onClass rdf:resource="http://www.swop-project.eu/ontologies/d23/window.owl#Window"/>
 </owl:Restriction>
</rdfs:subClassOf>
</owl:Class>

See for more info also the well-known pizza example where a pizza decomposes in certain amounts of layers of a certain types. For those knowing the earlier proposals by Alain Rector in the best practices group it is clear that these QCR’s offer much more precision than just existential relationships.

Closures (for atoms and to constrain parts)

Because of the Open World Assumption (OWA) in OWL we have to explicitly model any restriction. If we want to decompose a facade only in doors and windows but not cows we have to model that by saying that A facade can only decompose in members of the union of doors and windows. For example: 

<rdfs:subClassOf>
 <owl:Restriction>
  <owl:onProperty rdf:resource="http://www.swop-project.eu/ontologies/pmo/product.owl#hasPart_directly"/>
  <owl:allValuesFrom>
   <owl:Class>
    <owl:unionOf rdf:parseType="Collection">
     <rdf:Description rdf:about="http://www.swop-project.eu/ontologies/d23/window.owl#Window"/>
     <rdf:Description rdf:about="http://www.swop-project.eu/ontologies/d23/door.owl#Door"/>
    </owl:unionOf>
   </owl:Class>
  </owl:allValuesFrom>
 </owl:Restriction>
</rdfs:subClassOf>

The alternative is to assume a closed world and not specify this but this is not a clean practice. Same is true for atomic products: you have to explicitly say such products have no parts. Example: 

<rdfs:subClassOf>
 <owl:Restriction>
  <owl:onProperty rdf:resource="http://www.swop-project.eu/ontologies/pmo/product.owl#hasPart_directly"/>
   <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">0</owl:maxCardinality>
 </owl:Restriction>
</rdfs:subClassOf>


partOf versus hasPart (or both/inverse)

One could choose to model one direction or both. In the case of both it is typically good to model also that these object properties are each others inverse relationship (to keep things consistent and automatic). In case of a choice one sees different camps: those that prefer hasPart and those that prefer partOf typically often depending on assumptions w.r.t. existence dependence.

direct versus indirect (transitivity)

Often a differentiation is made between direct and indirect parts. Often the direct version is applied to avoid “counting double or worse” in the actual functionalities making use of the data. Another reason is that the transitive version can easily be derived.

multiple decomposition

In a simple scenario one can decompose a product in a set of other products (of the same or different underlying type). In practice, people/applications have different views on the same product (like stakeholders, disciplines, in different LC phases etc.). In that case it is needed to specify multiple ways of decomposition. This might also be true in design stages where multiple solutions exist that associate to multiple/different decompositions. In that way we have non-disjunct parts and we might even have to introduce extra classes modelling such multiple decompositions. It is an important issue how complex we have to go here.

Topology

Need for 0D, 1D, 2D, 3D, 4D objects/events?

To do any precise/useful modelling of topological aspects for products it might be necessary to distinguish between object of different dimensionalities. Example: if we want to make use of the fact that a Room is next to another Room it might be essential to know that this Room is a 3D object and that its connection to another Room also being a 3D object is typically via a common 2D boundary, well etc.

boundBy / includeBy relationships

We need semantic counterparts of things we can now do as evaluations of explicit geometry models i.e. involving bounding boxes, BREPs, etc. Example: to model that a certain Component IS IN a certain Space (like stair in a room).

ISO 10303 (STEP) and ontologies

Introduction

The ISO 10303 (STEP) STEP family of standards are the result of a major product data modelling activity which began in 1984, and which is in use in major industry sectors. Therefore it is natural to seek to extract an ontology from this work.

Unfortunately the STEP data models are difficult to understand and have concepts which do not fit easily with other ontology work such as SUMO SUMO or DOLCE DOLCE.

The ISO 15936 (Life cycle data for process plant) ISO15926 data model has a scope which overlaps STEP and is also produced by ISO TC184/SC4. ISO 15926 has problems which are well explained by Barry Smith in "Against idiosyncrasy in ontology development" Smith 2006. Nonetheless, having overcome the "idiosyncrasy" it is possible to relate ISO 15926 to other work.

The challenge is STEP because:

  1. STEP has specific capabilities for the recording of product structure which are necessary for the work of the Product Modelling XG; and
  2. STEP is already widely use for product structure.

This section discusses how an ontology can be obtained from STEP, and why some of the entities in STEP do not fit easily into an ontology.

The semantics of the STEP product structure "backbone"

The backbone

The STEP product structure backbone contains of the entities shown in the following EXPRESS-G diagram.

Error creating thumbnail: Unable to save thumbnail to destination

This section discusses the semantics of these entities, and whether corresponding classes should be defined within a product modelling ontology.

Entities in the backbone

product

The definition of the entity product in ISO 10303-41 is:

A product represents a product or a type of product.

The term product is defined as:

thing or substance produced by a natural or artificial process

The entity product covers two quite different things. Two separate definitions can be given for the two cases as follows:

individual physical object
class of physical object that has versions defined by a producer

The additional clause "that has versions defined by a producer" is necessary to distinguish product from product_category.

product_category

The definition of the entity product_category in ISO 10303-41 is:

A product_category identifies a type of product.

This definition is almost identical to one of the possible definitions of product. A possible distinction between the two entities is that product_category is more generic and does not have versions defined by a producer. Hence a possible formal definition is:

class of product that does not have versions defined by a producer
product_definition_formation

The definition of the entity product_definition_formation in ISO 10303-41 is:

A product_definition_formation is a collector of definitions of a product.

It is far from clear what this means. The entity product_definition_formation is used in different ways within different ISO 10303 Application Protocols, so it is difficult to give it precise semantics. Two possiblities are:

  • a version of a product, where product is a class of physical object;
  • a temporal part of a product, where product is an individual physical object;

Formal statements of these two possibilities are:

version of a class of physical object
temporal part of an individual physical object
product_definition

The definition of the entity product_definition in ISO 10303-41 is:

The product_definition entity data type represents an aspect of a product, or of a class of products, for an identified life cycle stage. The life cycle stage for which a product_definition exists may be further characterized by discipline, by usage, or by both.

There on constraints upon how a product_definition is related to other things, as follows:

  • A product_definition is related to exactly one instance of property_definition_formation by the attribute formation. A product_definition_formation can be related to any number of instances of product_definition.
  • A property_definition is related to exactly one thing by the attribute definition. The thing can be a product_definition. A product_definition can be related to any number of instances of property_definition.

The definition in the standard is difficult to understand. A possible clearer definition is:

set of statements about a product_definition_formation which is relevant to a particular life cycle stage, discipline or usage

This is consistent with the ISO 10303-41 definition and with the constraints upon the relationships.

property_definition

The definition of the entity property_definition in ISO 10303-41 is:

A property_definition is a property that characterizes a single object."

This is difficult to understand also, but taking the same approach as for product_definition, we can propose a more formal version as:

statement about a physical property possessed by an object, or by all members of a class of object

NOTE A product_definition can be a statement about a physical property possessed by a product_definition_formation.

This is again consistent with the ISO 10303-41 definition. With this interpretation, the definition attribute of property_definition specifies that a property_definition statement is a member of a product_definition set of statements.

representation

A property_definition can be related to any number of instances of representation. A representation can be related to any number of instances of property_definition. The relationship is an instance of the entity product_definition_representation.

There is no proper definition of the entity representation in ISO 10303-43. The text is:

A representation is a collection of one or more representation_item instances that are related in a specified representation_context.

The could be useful if the entity representation_item were properly defined. Unfortuately, its definition is:

A representation_item is an element of representation. A representation_item participates in one or more instances of representation, or contributes to the definition of another representation_item.

Taking the approach used for product_definition and property_definition, a possible more formal definition of representation is:

statement about the physical quantity that is the value of a physical property possessed by an object, or by all members of a class of object

Classes of physical object

The entities product and product_definition_formation both have two quite different meanings. Consider their use meaning "class of physical object", and assign the names product-as_class and product_definition_formation-as_class to these meanings.

An instance of each of product_category, product-as_class and product_definition_formation-as_class is a class of physical object. Hence each of these is a subclass of class_of_physical_object, as shown in the following UML diagram.

Error creating thumbnail: Unable to save thumbnail to destination

The definitions of these subclasses given by ISO 10303-41 are weak. However precise definitions could be provided with respect to the types of activity within the engineering design process which create them.

Set of statements

The entities product_definition, property_definition and representation are unusual because they correspond to statements or sets of statements.

to be continued...

Proposals

Quantities, units and scales

An initial draft for this topic has been prepared by David Leal based on work within the S-TEN project, and funded by the S-TEN project.

Objective

Every new data modelling/ontology definition activity in science or engineering data feels the need to rework quantities, units and scales - we are no exception :). The problem is that the different approaches only have "authority" within the particular data models or ontologies. The organisations which have broad authority, such as:

stand aloof.

This separation between the modellers and ontology makers on the one hand and the owners of definitions of things (such as "length" and "metre") on the other has to be reduced, because on the Web the things are identified by URIs (ideally dereferencable URIs).

EXAMPLE If the metre is identified by an HTTP URI, then dereferencing can obtain the HTML web page provided by BIPM which defines the metre. Similarly dereferencing the URI for the inch could give an HTML web page which references "Federal Register, Vol. 24, No. 128, p. 5348, July 1, 1959" in which the international inch is defined. Content negotiation could also obtain an RDF formula which says that an international inch is 2.54 cm.

The authority for the definition of the URIs should be reflected in the namespace. Hence the URI for length or metre should be assigned by the organisation responsible for the definition.

Our objective should be to create an approach to the use of quantities, units and scales on the Web that is:

  1. simple, so that if things such as "length" and "metre" have URIs, then statements can be made about physical quantities;
  2. rigorous, so that the organisations with authority which define these things are happy to assign the URIs.

NOTE The need for both units and scales is not obvious and is discussed in Why units AND scales .

This note and the referenced section addresses the comment by Michel: "Your assumption here that we need 3 things and these things being quantities, units and scales is not (yet) 100% clear/sure for me. It's quite clear to me that we need at least two things say quantities and units but I am not fully convinced we need the difference between units and scales (not in this place where you state it but also not after reading your whole proposal). Some times the scale seems to be an alternative for unit, sometimes it seems (esp. in the examples) that we always need both the unit and the scale concept (well in the pedantic way, which is btw not necessarily a bad thing). I would see the need for units AND scales more easily if they were always relevant (i.e. in your examples: for BOTH metre and Celsius)."

Some starting points

A good starting point is "An Ontology for Engineering Mathematics" Gruber and Olsen 1994. This paper distinguishes between:

  • a unit, such as the metre, which is a length; and
  • a scale, such Celsius, which is a function from temperature to the reals.

The paper points out that for each unit, a corresponding scale can be defined by lambda calculus.

An second starting point is "An Ontology for Units of Measure" Berners-Lee 2007. This ontology consistenly regards a unit of measure as a scale, and hence an rdf:Property. The use of rdf:Property for a scale gives a concise RDF representation, such as: 

<Thing rdf:about="#MyShip">
 <waterlineLength>
  <Length><metre>12</metre></Length>
 </waterlineLength>
</Thing>

or in N3 as: 

:MyShip :waterlineLength [ a :Length ;
                           :metre 12 ] .

There is no need to specify that the anonymous node is a Length because that is the range of waterlineLength and the domain of metre. Hence, the N3 representation can be further reduced to: 

:MyShip :waterlineLength [ :metre 12 ] .

Tim Berners-Lee's ontology is incomplete because:

  • it does not recognise the existence of units as well as scales; and
  • it does not embrace the terminology used by ISO 31 and other standards (something which is essential in order to meet the Objective).

A third starting point is "International Vocabulary of Basic and General Terms in Metrology" (VIM) VIM 2004. This document defines some of the terms which it is necessary to place within an ontology.

Why units AND scales

What are units and scales

Unit and scale are different but related objects. For a length y, we can say: 

metre-scale(Length_y) = 12

or 

Length_y = Metre . 12

A fuller explanation follows.

A scale is an identification scheme, such that each quantity within a quantity space (set of "quantities of the same kind") is uniquely identified by a symbol.

Where the quantity space is assumed to be a manifold (i.e. to have a continuous variation), then it necessary to identify each quantity within the space by a real number. Hence in this case, the scale is a * function from the quantity space to the reals.

Metre-scale is a function from length to the reals. I can say that the metre-scale for the length y evaluates to give 12, i.e.:

  • in textural maths:
metre-scale(y) = 12
  • or in RDF/OWL:
<Length rdf:about="#y">
 <metre-scale>12</metre-scale>
</Length>
  • or in MathML:
<apply>
 <eq/>
 <apply>
  <csymbol definitionURL="#metre-scale"/>
  <ci definitionURL="#y"/>
 </apply>
 <cn>12</cn>
</apply>

A unit is a defined quantity within a quantity space.

If the quantity space has the right properties (not all do), then I can say that any other quantity within the quantity space is equal to the unit times a real. This is an indirect way of assigning a real number to each quantity within the quantity space.

The Metre is a unit within Length. I can say that the length y is equal to the Metre times 12, i.e.:

  • in textural maths:
y = Metre . 12
  • or in MathML:
<apply>
 <eq/>
 <ci definitionURL="#y"/>
 <apply>
  <times/>
  <ci definitionURL="#Metre"/>
  <cn>12</cn>
 </apply>
</apply>

NOTE 1 In the RDF/OWL world there is no widely accepted representation for this, but Bijan says he is working on one.

The derivation of a scale from a unit is trival. That this is expressed using lambda calculus seems like "using a "sledgehammer to crack a nut". Nonetheless, this is the computer interpretable form of derivation provided by MathML.

NOTE 2 In English we can say "there is a function metre-scale from Length to the Reals, such that for each length x, the function give the real r, where r = x/Metre ." To say this in a computer interpretable way, it is necessary to state that the length x is not a particular length but a variable within the domain of the function. Lambda calculus is merely a notation for making this statement, as follows:

  • in textual maths:
λ (x, (x / Metre)) = metre-scale
  • or in MathML:
<declare type="function">
 <ci definitionURL="&scale;metre"/>
 <lambda>
  <bvar>
   <ci>x</ci>
  </bvar>
  <apply>
   <divide/>
   <ci>x</ci>
   <ci definitionURL="&unit;Metre"/>
  </apply>
 </lambda>
</declare>
Why do we need both

Scales are essential for special cases, in which the identification schemes for quantity spaces are not simply derived from units.

EXAMPLES Decibel (for sound), Richter (for earthquakes), Moh (for hardness).

NOTE 1 With the understanding of temperature provided by thermodynamics, temperature is not a special case. However Celsius is a scale and not a unit. The unit is Kelvin.

The use of a scale does not make an assumption about the addition of quantities, but the use of a unit does. Hence we cannot pretend that there is a unit equivalent to a scale.

EXAMPLE Consider two sound sources A and B of equal intensity: 

decibel(A) = 88
decibel(B) = 88

Without explicit knowledge of the decibel scale, it is not possible to deduce a value for: 

decibel(A + B)

(It is about 91, because decibel is a logrithmic scale and not linear.)

If an ontology suggested that there was a decibel unit, then software would assume that: 

A = 88 . decibel
B = 88 . decibel

so that: 

A + B = 176.decibel

which is incorrect

In an ontology, subclasses of scale can be defined such as linear or logarithmic.

NOTE 2 All scales simply derived from units are linear.

Units are essential for derived quantity spaces defined by arithmetic operations. A unit for the derived quantity space can be obtained by arithmetic operations on the units for the base quantity spaces. Hence the unit for force is derived from the units for mass, length and time. These arithmetic operations are not defined for scales (which are functions not quantities).

What do we use and when
  • Always use scales for defining quantities because:
    • it is concise in RDF;
    • use of a scale is always valid.
  • In an ontology of scales, if a scale is derived from a unit, then record that this is so. The reference back to units is required because:
    • in many cases the fundamental definition (e.g. provided by the BIPM) is for a unit and not for a scale;
    • the definition of a derived unit (e.g. Newton) from base units by an expression, works only for units and not for scales.

Key objects

Key objects are as follows:

quantity 
property of a phenomenon, body, or substance, to which a magnitude can be assigned (definition taken from VIM 2004)

EXAMPLES The length that is 10 metres; the thermodynamic temperature that is 20 degrees Celsius.

NOTE 1 It is not entirely clear from the text of the VIM or of ISO 31 whether a particular length such as 10 metres, or length in general, is a quantity. The presence of the definition quantities of the same kind suggests that only a particular length is a quantity. Nonetheless, there are places in the text which suggest the opposite.

NOTE 2 The definition says "to which a magnitude can be assigned". Perhaps a better definition would be "that has a magnitude". There may be a unit or scale which allows a representation of a quantity, but it has a magnitude irrespective of its representation.

NOTE 3 Usually a quantity is referred to in terms of a representation with respect to a unit or scale. However in order to define a unit or scale, a quantity must be defined independently. Hence there are physical definitions of the metre, the kilogram, the second, etc.. The temperature scale ITS-90 relies on many defined temperature quantities, such as the triple point of argon. The ITS-90 scale assigns the representation 83.8058 degrees Kelvin to the triple point of argon.

NOTE 4 It is also possible that quantity is intended to be something like height, width, depth or waterline length. The simple example given in Some starting points, treats these as properties (functions) of physical objects which evaluate to give quantities. This seems to be a pragmatic approach because otherwise the relationship between height (say) and length is difficult to define.

  • Height is not a specialisation of length, because there is no subset of lengths which are heights.
  • Height can be regarded as a class of physical object, so that we can say "MyPhysicalObject is a thing_with_height_10m". Unfortunately, we now have to relate thing_with_height_10m to the length 10m, and this requires a new property (function) "length for height".

Mathematically, it seems best to start with a quantity space (or "quantities of the same kind") such as length. The operation add has closure for this space - i.e. adding two lengths gives another length. Height, width and depth are different. A height may equal a width plus a depth.

Notes 1-4 have been added to address:

  • CommentBYMichel: This definition looks more like the definition of a Property like height, width, depth, maxumumSpeed, strength, .... If this is true it would be more related to an OWL property but then specialised/interpreted to denote a specific product/body... characteristic.
  • CommentByMichel: Your example does suggest my interpretation is not OK. Since you don't give say height and width as example... Nevertheless, only with such examples I could really understand the concept of "quantities of the same kind" where Length is actually a container for height, width, depth.....but this way I would just call THIS concept "Quantity" (and the specific ones something like PropertyWithMagnitude if you see what I mean. This way all these properties of the same kind would actually reflect our general "quantity" understanding (base or derived quantities). Another comment is that I think the example does not comply with its definition: the definition says: "TO which a magnitude CAN be assigned" so the magnitude is something related to it; whereas the examples INCLUDE the magnitude"; maybe subtle but I guess crucial in our discussions.
quantities of the same kind 
quantities that can be placed in order of magnitude relative to one another (definition taken from VIM 2004)

EXAMPLES Length; Thermodynamic Temperature.

NOTE 1 Quantity space may be an alternative name for this object.

NOTE 2 Usually there is more to a set of quantities of the same kind than is specified by the VIM definition. Being ordered is a minimum requirement for a useful set of quantities of the same kind. However most useful sets of quantities have much more structure that that. It is possible to add to lengths and get another length. It is also possible to multiply a length by a real and get a length.

unit 
scalar quantity, defined and adopted by convention, with which other quantities of the same kind are compared in order to express their magnitudes (definition taken from VIM 2004)

EXAMPLE The Metre; the Kelvin, the Ampere.

NOTE The "International Temperature Scale of 1990" ITS-90 defines several thermodynamic temperature quantities. These are assigned real numbers within the T90 scale. None of these thermodynamic temperature quantities is assigned the real number 1.0.

scale 
monotonic increasing function from quantities of the same kind to a integer or real interval, such that the scale value of a quantity is used to identify it

EXAMPLES Metre (scale) from Length to the Reals; ITS-90 from Thermodynamic Temperature to the Reals.

NOTE There is usually much more to a scale than being monotonic and increasing. Usually it is also an isomorphism for valid arithmetic operators on the quantities of the same kind.

Key objects in RDF/OWL

If we are happy that a mathematical structure, such as manifold, metric space, vector space, etc., is an owl:Class (a big "if"), then we can say: 

<owl:Class rdf:about="#Quantity"/>

<owl:Class rdf:about="#Length">
 <rdf:type rdf:resource="#QuantitiesOfTheSameKind"/>
</owl:Class>
 
<owl:Class rdf:about="#ThermodynamicTemperature">
 <rdf:type rdf:resource="#QuantitiesOfTheSameKind"/>
</owl:Class>
  
<owl:Class rdf:about="#QuantitiesOfTheSameKind">
<rdfs:comment>QuantitiesOfTheSameKind is a subClass of the powerClass
of Quantity.</rdfs:comment> 
<rdfs:subClassOf>
  <owl:Restriction>
   <owl:onProperty rdf:resource="&owl;subClassOf"/>
   <owl:hasValue rdf:resource="#Quantity"/>
  </owl:Restriction>
 </rdfs:subClassOf>
</owl:Class>

<owl:Thing rdf:about="&unit;Metre">
 <rdf:type rdf:resouce="#Length"/>
 <rdf:type rdf:resouce="#Unit"/>
</owl:Thing> 

<owl:Thing rdf:about="&unit;Kelvin">
 <rdf:type rdf:resouce="#ThermodynamicTemperature"/>
 <rdf:type rdf:resouce="#Unit"/>
</owl:Thing>

<owl:Class rdf:about="'Unit">
 <rdfs:subClassOf rdf:resource="Quantity"/>
</owl:Class>

<owl:ObjectProperty rdf:about="&scale;metre">
 <rdf:type rdf:resouce="#Scale"/>
 <rdfs:domain rdf:resource="#Length"/>
 <rdfs:range rdf:resource="#Reals"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:about="&scale;kelvin">
 <rdf:type rdf:resouce="#Scale"/>
 <rdfs:domain rdf:resource="#ThermodynamicTemperature"/>
 <rdfs:range rdf:resource="#Reals"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:about="&scale;celsius">
 <rdf:type rdf:resource="#Scale"/>
 <rdfs:domain rdf:resource="#ThermodynamicTemperature"/>
 <rdfs:range rdf:resource="#Reals"/>
</owl:ObjectProperty>

<owl:Class rdf:about="#Scale">
 <rdfs:subClassOf rdf:resource="&owl;ObjectProperty"/>
<owl:Class>

or alternatively in N3: 

:Quantity   a owl:Class .

:Length     a :QuantitiesOfTheSameKind .

:ThermodynamicTemperature a QuantitiesOfTheSameKind .

:QuantitiesOfTheSameKind
  rdfs:comment "QuantitiesOfTheSameKind is a subClass of the powerClass
  of Quantity." .
            rdfs:subClassOf [ owl:onProperty owl:subClassOf ;
                              owl:hasValue   :Quantity ] .

unit:Metre  a :Length ;
            a :Unit . 

unit:Kelvin a :ThermodynamicTemperature ;
            a :Unit .

:Unit       rdfs:subClassOf :Quantity .

scale:metre a :Scale ;
            rdfs:domain :Length ;
            rdfs:range  :Reals .

scale:Kelvin a :Scale ;
             rdfs:domain :ThermodynamicTemperature ;
             rdfs:range  :Reals" .

scale:Celsius a Scale ;
              rdfs:domain :ThermodynamicTemperature ;
              rdfs:range  :Reals .

:Scale        rdfs:subClassOf owl:ObjectProperty .

NOTE 1 In this OWL, a scale is an ObjectProperty with the domain Reals. In the example in Some starting points a scale is a Datatype property. Probably both approaches are required.

Having the Reals as an object, is consistent with MathML. In order to represent a real it is necessary to have a Datatype property decimal as follows: 

<owl:DatatypeProperty rdf:about="#decimal">
 <rdfs:domain rdf:resource="#Reals"/>
</owl:DatatypeProperty>

NOTE 2 The simple ship waterline length example in Some starting points, can be expressed with Reals as an object as: 

<Ship rdf:about="#MyShip">
 <waterlineLength>
  <Length>
   <scale:metre><decimal>12</decimal></scale:metre>
  </Length>
 </waterlineLength>
</Ship>

or in N3 syntax: 

:MyShip :waterlineLength [ scale:metre [ :decimal 12 ] ] .

NOTE 3 The OWL shown in this section does not record the relationship between unit:Metre and scale:metre. Gruber and Olsen point out that they can be related by lambda calculus. This is discussed in detail in section Maths and scales .

The following statements relate units and scales: 

<Quantity rdf:about="&unit;Metre">
 <scale:metre><decimal>1.0</decimal></scale:metre>
</Quantity>

<Quantity rdf:about="&unit;Kelvin">
 <scale:kelvin><decimal>1.0</decimal></scale:kelvin>
</Quantity>

or in N3: 

unit:Metre  scale:metre  [ :decimal 1.0 ] .

unit:Kelvin scale:kelvin [ :decimal 1.0 ] .

If a scale is classified as linear (and most are), then these statements are sufficient to define the scale.

NOTE 4 A Graphical representation of the approach outlined in this section is shown below.

Error creating thumbnail: Unable to save thumbnail to destination
.

This figure regards a Real as an object. A simpler, but less formal, approach would regard a Real as a datatype, and hence regard a scale as a DatatypeProperty. This approach is shown in the figure below.

Error creating thumbnail: Unable to save thumbnail to destination
.

NOTE 5 This approach implies that derived scales such as kilometre and metre_per_second have to be explicitly assigned URIs and included in an ontology. The cannot be defined "on the fly" as they are used. This may be a strength or a weakness of this approach.

Note 5 responds to the comments by Michel:

  • guess we still have to explicitly use "kilometre" in this approach further defined by math? Or can we ad some prefix datatype property somewhere?
  • idem.: can we have a non-rigorous math approach to m/s etc. on this level?

A previous graphical representation created by Michel is shown in Media:quantitiesbydavid.pdf. It is still mostly valid.

NOTE 6 The class QuantitiesOfTheSameKind or QuantitySpace is difficult, and does not fit with OWL-DL.

The class PowersetOfQuantity can be defined that contains all sets of quantities. QuantitySpace can be defined as a subclass of all this, such that a member contains ALL quantities of a kind, such as all lengths and all masses.

There may be further subclasses of QuantitySpace, such as a quantity spaces which is manifold, or a quantity space for which addition of quantities is defined.

For most day to day use of quantities, the nature of the quantity space is not important, and this part of the ontology can be ignored.

NOTE 6 addresses the comment by Michel "Oef, subclass of a powerclass....do we really need such a construct?"

Maths and scales

Why MathML

Many relationships of interest are expresses as mathematics, such as:

  • the relationship between length, time duration and speed;
  • the relationship between metre (unit) and metre (scale);
  • the relationship between metre, second and metre.sec-1;
  • the relationship between metre and millimetre.

We already have a language for expressing these relationships - MathML MathML. Hence the following approach is proposed:

  1. express the relationships as MathML embedded within the OWL;
  2. define an equivalent OWL representation if this seems useful.

NOTE 1 Tim Berners-Lee's Berners-Lee 2007 work relies upon chaining which is defined in Connolly 2007. Chaining is identical to the operator composition within MathML.

NOTE 2 MathML is based upon applying operators to operands. Hence the statement: 

z = x + y

is expressed in MathML as: 

<apply>
 <eq/>
 <ci>z</ci>
 <apply>
  <plus/>
  <ci>x</ci>
  <ci>y</ci>
 </apply>
</apply>

If x, y and z have URIs, then this can be written as: 

<apply>
 <eq/>
 <ci definitionURI="&somewhere;z"/>
 <apply>
  <plus/>
  <ci definitionURI="&somewhere;x"/>
  <ci definitionURI="&somewhere;y"/>
 </apply>
</apply>

We could express exactly the same thing in RDF as follows: 

<rdf:List>
 <rdf:first rdf:resource="&somewhere;x"/>
 <rdf:rest rdf:parseType="Resource">
  <rdf:first rdf:resource="&somewhere;y"/>
  <rdf:rest
   rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
 </rdf:rest>
 <MathML:plus rdf:resource="&somewhere;z"/>
</rdf:List>

In this example the list (x, y) is the subject, "plus" is the predicate and z is the object. Many people may find MathML a more intuitive approach to mathematics - that is what it is for.

Unit and Scale

The Metre is a Length. A Length can be multiplied by a Real to give another Length. Hence we have the equation: 

LengthOf12Metres = 12 . Metre

NOTE 1 Here "." is the multiplication operator between a Real and a Length. Since its properties are very like any other multiplication operator, it is usually not explicitly classified as such.

MathML could be embedded in RDF to give a definition of LengthOf12Metres as follows: 

<Length rdf:about="#LengthOf12Metres">
 <rdfs:isDefinedBy  rdf:parseType="Literal"
                    xmlns="http://www.w3.org/1998/Math/MathML">
   <apply>
   <times/>
   <cn>12</cn>
   <ci definitionURL="&unit;Metre"/>
  </apply>
 </rdfs:isDefinedBy>
</Length>

NOTE 2 Usually a length would be anonymous. Hence the waterline length 
example would be:

<Ship rdf:about="#MyShip">
 <waterlineLength>
  <Length>
   <rdfs:isDefinedBy  rdf:parseType="Literal"
                      xmlns="http://www.w3.org/1998/Math/MathML">
    <apply>
     <times/>
     <cn>12</cn>
     <ci definitionURL="&unit;Metre"/>
    </apply>
   </rdfs:isDefinedBy>
  </Length>
 </waterlineLength>
</Ship>

I can't say that I like it, but it is precise definition of LengthOf12Metres with respect to the unit Metre. The example in Some starting points shows that a far more elegant approach is to define the metre scale, which is a function from Length to the Reals.

The BIPM does not define the metre scale. Instead it defines the unit Metre. Hence our challenge is to derive the metre scale from the unit Metre. Gruber and Olsen 1994 show that this can be done using lambda calculus as follows: 

λ (l, (l / unit:metre)) = scale:metre

where "/" is the inverse of the "⋅" operator defined above.

MathML has a notation for this, as follows: 

<declare type="function">
 <ci definitionURL="&scale;metre"/>
 <lambda>
  <bvar>
   <ci>l</ci>
  </bvar>
  <apply>
   <divide/>
   <ci>l</ci>
   <ci definitionURL="&unit;metre"/>
  </apply>
 </lambda>
</declare>

This definition can be embedded in the RDF/OWL definition of scale:metre, as follows: 

<owl:ObjectProperty rdf:about="&scale;metre">
 <rdfs:domain rdf:resource="#Length"/>
 <rdfs:range rdf:resource="#Reals"/>
 <rdfs:isDefinedBy  rdf:parseType="Literal"
                      xmlns="http://www.w3.org/1998/Math/MathML"> 
  <lambda>
   <bvar>
    <ci>l</ci>
   </bvar>
   <apply>
    <divide/>
    <ci>l</ci>
    <ci definitionURL="&unit;metre"/>
   </apply>
  </lambda>
 </rdfs:isDefinedBy>
</owl:ObjectProperty>

This is a bit long winded, and requires an ability to parse both RDF/OWL and MathML. However, it says exactly what we want, and is a specification of what we may want to say in RDF/OWL alone.

Unit prefixes

A prefix can define a derived unit in terms of a base unit.

EXAMPLE The unit Millimetre is defined from the unit Metre by the expression: 

Millimetre = 0.001 . Metre

This can easily be expressed in MathML as: 

<apply>
 <eq/>
 <ci definitionURL="&unit;MilliMetre"/>
 <apply>
  <times/>
  <cn>0.001</cn>
  <ci definitionURL="&unit;Metre"/>
 </apply>
 </apply>

We can state that the number 0.001 has the name "Milli", as follows: 

<apply>
 <eq/>
 <cn>0.001</cn>
 <ci definitionURL="&prefix;Milli"/>
</apply>

Hence the definition of Millimetre becomes: 

<apply>
 <eq/>
 <ci definitionURL="&unit;Millimetre"/>
 <apply>
  <times/>
  <ci definitionURL="&prefix;Milli"/>
  <ci definitionURL="&unit;Metre"/>
 </apply>
</apply>

The MathML definition can be embedded in RDF/OWL as follows: 

<Length rdf:about="&unit:Millimetre">
 <rdfs:isDefinedBy  rdf:parseType="Literal"
                    xmlns="http://www.w3.org/1998/Math/MathML">
  <apply>
   <times/>
   <ci definitionURL="&prefix;Milli"/>
   <ci definitionURL="&unit;Metre"/>
  </apply>
 </rdfs:isDefinedBy>
</Length>

It is possible to go through the same procedure as before, to derive the scale millimetre from the unit Millimetre. However, it may be more convenient to derive the scale millimetre from the scale metre directly. The definition can be expressed using lambda calculus as: 

λ (l, scale:metre(l) / 0.001) = scale:millimetre

The MathML representation for this is: 

<declare type="function">
 <ci definitionURL="&scale;millimetre"/>
 <lambda>
  <bvar>
   <ci>l</ci>
  </bvar>
  <apply>
   <divide/>
   <apply>
    <csymbol definitionURL="&scale;metre"/>
    <ci>l</ci>
   </apply>
   <ci definitionURL="&prefix;Milli"/>
  </apply>
 </lambda>
</declare>

As before the MathML can be embedded in an RDF/OWL definition to give: 

<owl:ObjectProperty rdf:about="&scale;millimetre">
 <rdfs:domain rdf:resource="#Length"/>
 <rdfs:range rdf:resource="#Reals"/>
 <rdfs:isDefinedBy rdf:parseType="Literal"
                   xmlns="http://www.w3.org/1998/Math/MathML"> 
  <lambda>
   <bvar>
    <ci>l</ci>
   </bvar>
   <apply>
    <divide/>
    <apply>
     <csymbol definitionURL="&scale;metre"/>
     <ci>l</ci>
    </apply>
    <ci definitionURL="&prefix;Milli"/>
   </apply>
  </lambda>
 </rdfs:isDefinedBy>
</owl:ObjectProperty>

This is a bit long winded, and requires an ability to parse both RDF/OWL and MathML. However, it says exactly what we want, and is a specification of what we may want to say in RDF/OWL alone.

An approach to the algebraic combinations of quantities

Quantities can be given by an algebraic expression involving other quantities. However, the algebraic expression does not define the quantity that results.

An example of the same algebraic expression giving different quantities, is as follows:

  • Force multiplied by length gives energy, provided that the force is applied to a moving body, and the length is the distance if moves.
  • Force multiplied by length gives moment, provided that the force is applied to a point in a rigid body, and the length is the perpendicular distance between the line of action of the force and the point about which the moment acts.

In these examples, the semantics comes from the relationships between the quantities and the physical objects, rather than from the quantities themselves. This is shown in the figues below.

Error creating thumbnail: Unable to save thumbnail to destination
Error creating thumbnail: Unable to save thumbnail to destination

In some cases, the result of an algebraic expression involving quantities is just a number. One number is much like another - the semantics of the number is its relationship with the physical object. This is illustrated for Reynold's number in the figure below.

Error creating thumbnail: Unable to save thumbnail to destination

The conclusions are as follows:

  1. An expresions involving quantities which gives another quantity does not, on its own, define the resulting quantity. This is because the expression is a representation of a physical law, which has semantics defined outside the expression.
  2. Is it useful to know an expression which gives a quantity, because this indicates the units (if any) with respect to which it can be represented.
Units for algebraic combinations of quantities

Consider the quantity speed which is given by the expression: 

speed = length / time duration

NOTE 1 This expression does not define speed. The rate of change of average height of citizens of the EU is given by the same expression, but in this case, nothing is moving.

We know that metre is a unit for length and second is a unit for time duration. Hence speed can be expressed as: 

speed = a . Metre / (b . Second)

where a and b are Reals. The expression can be reorganised as: 

speed = a/b . Metre/Second

Hence a unit for speed is derived from units for length and time duration.


NOTE 2 Apologies for the pedantry.

A derived unit can easily be represented in MathML as follows: 

<apply>
 <eq/>
 <ci definitionURL="&unit;MetrePerSecond"/>
 <apply> 
  <divide/>
  <ci definitionURL="&unit;Metre"/>
  <ci definitionURL="&unit;Second"/>
 </apply>
</apply>

This can be embedded within an RDF/XML definition as follows: 

<Quantity rdf:about="&unit;MetresPerSecond">
 <rdf:type rdf:resource="#Unit"/>
 <rdfs:isDefinedBy  rdf:parseType="Literal"
                    xmlns="http://www.w3.org/1998/Math/MathML">
  <apply> 
   <divide/>
   <ci definitionURL="&unit;Metre"/>
   <ci definitionURL="&unit;Second"/>
  </apply>
 </rdfs:isDefinedBy>
</Quantity>

Unfortunately, this does not yet tell you that MetresPerSecond is a unit appropriate to Speed. In order to say that Speed is Length divided by Time, we need to say that:

  1. there is a function length / time; and
  2. the codomain of this function is speed.

In MathML, this is represented as follows: 

<apply>
 <eq/>
 <apply>
  <codomain/>
  <lambda>
   <bvar>l</bvar>
   <bvar>t</bvar>
   <condition>
    <apply>
     <in/>
     <ci>l</ci>
     <ci definitionURL="#Length"/>
    </apply>
   </condition>
   <condition>
    <apply>
     <in/>
     <ci>t</ci>
     <ci definitionURL="#TimeDuration"/>
    </apply>
   </condition>
   <apply>
    <divide/>
    <ci>l</ci>
    <ci>t</ci>
   </apply>
  </lambda> 
 </apply>
 <ci definitionURL="#Speed"/>
</apply>

NOTE 3 This seems very messy, and assistance from a MathML expert is required.

This can be embedded in RDF/XML to give (something like) : 

<owl:Class rdf:about="#Speed">
 <rdf:type rdf:resource="#QuantitiesOfTheSameKind"/>
 <dc:description>
  <apply>
   <codomain/>
   <lambda>
    <bvar>l</bvar>
    <bvar>t</bvar>
    <condition>
     <apply>
      <in/>
      <ci>l</ci>
      <ci definitionURL="#Length"/>
     </apply>
    </condition>
    <condition>
     <apply>
      <in/>
      <ci>t</ci>
      <ci definitionURL="#TimeDuration"/>
     </apply>
    </condition>
    <apply>
     <divide/>
     <ci>l</ci>
     <ci>t</ci>
    </apply>
   </lambda> 
  </apply>
 </dc:description>
</owl:Class>

This is a bit long winded, may be flawed in many ways, and requires an ability to parse both RDF/OWL and MathML. However, it is an initial attempt at what we may want to say in RDF/OWL alone.

NOTE 4 It really is a bit tacky. I am not happy about the MathML or the embedding. The MathML is not a definition, but some useful information, which is why I have used dc:description. - David Leal

Scales for an algebraic combinations of quantities

Because it is straightforward to create algebraic combinations of units, the best route to a scale for an algebraic combination of quantities may be:

  1. create the unit for the algebraic combination of quantities;
  2. derive the scale by lambda calculus.

This is probably the only valid route, and attempts to combine scales for different quantities seem flawed. Berners-Lee 2007 contains the following attempt to derived metresPerSecond (mps) by chaining (or "composing") the scales metre (m) and hertz (hz): 

<rdf:Description>
 <rdf:first rdf:resource="http://www.w3.org/2007/ont/unit#m"/>
 <rdf:rest rdf:parseType="Resource">
  <rdf:first rdf:resource="http://www.w3.org/2007/ont/unit#hz"/>
  <rdf:rest
    rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
 </rdf:rest>
 <o2:chain rdf:resource="http://www.w3.org/2007/ont/unit#mps"/>
</rdf:Description>

This is certainly incorrect because the range of the Property hertz is not within the domain of the property metre.

Some Cases

Considering cases

This section has been included, because it is necessary to check that a general scheme actually works in specific cases.

Amount of substance and Mole

Definitions from the BIPM (http://www.bipm.org/en/si/si_brochure/chapter2/2-1/mole.html) are:

amount of substance 
Amount of substance is defined to be proportional to the number of specified elementary entities in a sample, the proportionality constant being a universal constant which is the same for all samples.
mole 
The mole is the amount of substance of a system which contains as many elementary entities as there are atoms in 0.012 kilogram of carbon 12; its symbol is "mol".

The BIPM also states:

 
When the mole is used, the elementary entities must be specified and may be atoms, molecules, ions, electrons, other particles, or specified groups of such particles.

EXAMPLE The amount of MyBatchOfSubstance is 5.43 mol. This can be recorded as follows: 

<owl:Thing rdf:about="#MyBatchOfSubstance">
 <rdf:type>
  <quantity:AmountOfSubstance>
   <scale:mole>
    <maths:Real>
     <maths:decimal>5.43</maths:decimal>
    </maths:Real>
   </scale:mole>
  </quantity:AmountOfSubstance>
 </rdf:type>
</owl:Thing>

There are two issues with this example:

  • What is the relationship between MyBatchOfSubstance and the quantity that is 5.43 mol? The example assumes that the quantity is a class which has MyBatchOfSubstance as a member. Hence it is rdf:type.
  • How is the BIPM injuction that "the elementary entities must be specified" to be implemented? As is common practice, the example ignores this, because usually the sensible choice of elementary entity can be deduced from the nature of MyBatchOfSubstance. In a formal representation, it is necessary to be specific. One approach is to specify this as a property of the AmountOfSubstance, as follows:
<owl:Thing rdf:about="#MyBatchOfSubstance">
 <rdf:type>
  <quantity:AmountOfSubstance>
   <quantity:elementaryEntityType rdf:resource="&physics;atom"/>
   <scale:mole>
    <maths:Real>
     <maths:decimal>5.43</maths:decimal>
    </maths:Real> 
   </scale:mole>
  </quantity:AmountOfSubstance>
 </rdf:type>
</owl:Thing>

and this requires somebody to assign a URI to the class atom. :)

The mass of MyBatchOfSubstance can be recorded similarly, as follows: 

<owl:Thing rdf:about="#MyBatchOfSubstance">
 <rdf:type>
  <quantity:Mass>
   <scale:kilogram>
    <maths:Real>
     <maths:decimal>0.0754</maths:decimal>
    </maths:Real>
   </scale:kilogram>
  </quantity:Mass>
 </rdf:type>
</owl:Thing>

Difficulties and alternative approaches

Representation

The formal approach defined in the previous sections requires that:

  1. the definition of a physical quantity relies upon a scale which is defined elsewhere;
  2. a scale is assigned a URI.

This is shown in the figure below.

Error creating thumbnail: Unable to save thumbnail to destination

NOTE 1 In this figure, the symbols in the green shaded area are not proper RDF but an informal shorthand to show what operations are needed to define the scale.

The definition of the scale is recorded once within an ontology. The scale is referred to by URI in order to define an item of engineering data.

An alternative which combines the definition of the scale and the item of engineering data as a "representation" is as follows:

Error creating thumbnail: Unable to save thumbnail to destination

NOTE 2 In this figure, the attributes of the representation are not proper RDF but an informal shorthand to show that the definition of the scale can be encoded as attributes.

NOTE 3 Possibly, the encoding of the definition of the scale as attributes may be more concise that a formal definition using MathML, or an RDF equivalent to MathML, in some circumstances. However, for a fully generic capability the difference will not be great. The only thing which can be omitted in a less formal approach, is the final step of defining a scale from a unit by lambda calculus.

Many items of engineering data have the same scale. Perhaps there may be 100000 values each expressed as N.mm-2/mol. Hence for conciseness, part of the representation can be separated as a reusable "representation context" as follows:

Error creating thumbnail: Unable to save thumbnail to destination

This is similar to the approach used in ISO 10303-41. In some cases the representation approach may be more concise than a more formal approach, but it has disadvantages as follows:

  1. The exact semantics of a "representation" is difficult. It can probably be regarded as an RDF formula, so that the relationship between MySpeed and the anonymous representation is rdfs:isDefinedBy.
  2. The exact semantics of an attribute of the representation is also difficult. It probably specifies the value of a parameter within a parameterised formula.
  3. The semantics of "representation context" is even worse. Presumably it is a class of formula.

The representation approach uses data structures as an alternative to explicit semantics. This can be more concise, but it is less easy to process with generic software.

Management of URIs

The assignment of a URI to a derived scale, e.g. N.mm-2/mol, or to a reusable representation context, leads to a process issue: a) is the URI assigned locally without considering whether or not the same scale (or representation context) has already been assigned a URI elsewhere; or b) is a data base of scales (or representation contexts) queried first to see if a URI has already been assigned?

NOTE This problem does not occur within current implementation of ISO 10303-41, because each "representation context" has a # number which is local to the exchange file/data store. It is not easy for one exchange file/data store to reference a representation context defined in another. But for a Web implementation of ISO 10303-42, in which a representation context had a URI, the problem would occur.

Probably standards bodies and trade associations will define useful derived scales for particular industries and assign URIs to them. Companies within the industries will then reference these URIs as far as possible.

Unfortunately, this may cover only a fraction of all scales - perhaps 90%. The other 10% may be defined again and again by different projects, and assigned a new URI each time. This is untidy, but perhaps something that we have to live with.

Conclusions

This section contains tentative conclusions about quantities units and scales, initially drafted by David Leal.

  • The scale approach, in which the metre (as a scale) is regarded as an rdf:Property, gives a convenient and concise representation. This approach was developed by the S-TEN project S-TEN, which converted the approach to scales in ISO 15926-2 directly into RDF/OWL. This approach was developed independently by Tim Berners-Lee Berners-Lee 2007 and Dan Connolly Connolly-Blog 2007.
  • The relationship between the scale approach an units was not addressed by ISO 15926-2, S-TEN, or Tim Berners-Lee and Dan Connolly. It was addressed using lambda calculus by Gruber and Olsen Gruber and Olsen 1994, and has been included here.
  • The scale approach in ISO 15926-2 and in the work of Tim Berners-Lee and Dan Connolly did not use the terminology of ISO 31 and the International Vocabulary of Basic and General Terms in Metrology (VIM) VIM 2004. This was partially remedied in S-TEN and more completely remedied here.
  • The work of Tim Berners-Lee and Dan Connolly is incorrect in its use of chaining and the inverse in order to create scales for derived quantities. The only mathematically rigorous way of creating scales for derived quantities is via units. Units can be multiplied and divided as required. Once a unit for a derived quantity has been obtained, a scale can be derived by lambda calculus. This approach is explained here.
  • The scale approach does not require additional work on datatypes. Datatypes do not seem to be the right place to start for the following reasons:
    • Length, the metre and 12 metres are three things (a class an two members of it) about which information can be recorded. It seems appropriate that they should be treated is a similar way as elephant, Babar and Nellie.
    • Much of the work on datatypes assumes that only numbers are subject to arithmetic operations. This is completely wrong - scientific and engineering expressions involve quantities. The preferred use of quantity expressions is stated in the NIST "Guide for the Use of the International System of Units" NIST SI Guide section 7.11. The guide contains the text "It is the strong recommendation of this Guide that because of their universality, quantity equations should be used in preference to numerical-value equations.". The same recommendation is in the ISO/IEC "Rules for the structure and drafting of International Standards" ISO/IEC Directives Part 3 clause 6.6.9.1.

Ranges

Use of ranges

Ranges are important in engineering, because of tolerances. A statement about a design is not:

  • each item of type Model_XYZ has a mass of 10 kg exactly;

but:

  • each item of type Model_XYZ has a mass of 10 kg, plus or minus 0.1 kg;

or equivalently:

  • each item of type Model_XYZ has a mass in the range 9.9 kg to 10.1 kg.

The statement can be made using a Restriction class as follows: 

<owl:Class rdf:about="#Model_XYZ">
 <rdfs:subClassOf>
  <owl:Restriction>
   <owl:onProperty rdf:resource="&design;hasMass"/>
   <owl:allValuesFrom rdf:resource="#Mass_range_9.9_to_10.1kg"/>
  </ow:Restriction>
 </rdfs:subClassOf>
</owl:Class>

The difficult part is defining the object Mass_range_9.9_to_10.1kg.

Mathematical basis

For most quantities, a range is a part of a one dimensional manifold. To treat this formally, the following taxonomy of objects is required:

  • Manifold1d: a Manifold that is topologically the same as an open real interval
  • ManifoldEdge: a Manifold1D that has two boundaries (i.e. ends)
  • OrderedSet: set of things with an order
  • DirectedManifoldEdge: a ManifoldEdge and an OrderedSet

NOTE 1 It is reasonable assume that TopologicalSpace (and Manifold, etc.) is a subclass of owl:Class. This is because a TopologicalSpace has members. Unfortunately this takes us into the issue of metasubclassing raised by Conrad.

NOTE 2 Although a TopologicalSpace can be regarded as an owl:Class, it is not a set. It is a set plus other things, which give the set a structure.

The class DirectedManifoldEdge has many uses. Some examples are:

  1. Range of a quantity (e.g. Mass)
    • Mass is a Manifold1D and an OrderedSet
    • Mass_range_9.9_to_10.1kg is a DirectedManifoldEdge, with masses 9.9 kg and 10.1 kg at the ends
  2. Range of real numbers
    • Reals is a Manifold1D and an OrderedSet
    • Real_interval_9.9_to_10.1 is a DirectedManifoldEdge, with real numbers 9.9 and 10.1 at the ends
  3. Interval of Time
    • Time (as defined by [TAI]) is a Manifold1D and an OrderedSet
    • Time_from_2008-07-010T10:30_to_2008-07-010T11:15 is a DirectedManifoldEdge with times 2008-07-010T10:30 and 2008-07-010T11:15 at the ends
  4. Segment of a directed line in space
    • Points_in_the_path_of_MyShip is a Manifold1D and an OrderedSet
    • Path_of_MyShip_on_2008-07-12 is a DirectedManifoldEdge with points at latitude-longitude (83.10, 51.23) and (85.32, 53,67) at the ends

The properties end1 and end2 can be defined for a DirectedManifoldEdge, as follows: 

end1: DirectedManifoldEdge -> Thing
end2: DirectedManifoldEdge -> Thing

Putting the parts together

This approach allows Mass_range_9.9_to_10.1kg to be defined as follows: 

<topology:DirectedManifoldEdge rdf:about="#Mass_range_9.9_to_10.1kg"/>
 <topology:end1>
  <quantity:Mass>
   <scale:kilogram>
    <maths:Reals>
     <maths:decimal>9.9</maths:decimal>
    </maths:Reals>
   </scale:kilogram>
  </quantity:Mass>
 </topology:end1>
 <topology:end2>
  <quantity:Mass>
   <scale:kilogram>
    <maths:Reals>
     <maths:decimal>10.1</maths:decimal>
    </maths:Reals>
   </scale:kilogram>
  </quantity:Mass>
 </topology:end2>
</topology:DirectedManifoldEdge>

In N3 (without bothering to type the objects), this becomes: 

:Mass_range_9.9_to_10.1kg
  topology:end1 [ scale:kilogram [ maths:decimal 9.9 ] ] ;
  topology:end2 [ scale:kilogram [ maths:decimal 10.1 ] ] .

Background Information

References

  • [Gruber and Olsen 1994] "An Ontology for Engineering Mathematics", Thomas R. Gruber and Gregory R. Olsen, 1994, [1]
  • [Berners-Lee 2007] "An Ontology for Units of Measure", Tim Berners-Lee 2007, [2]
  • [VIM 2004] "International Vocabulary of Basic and General Terms in Metrology (VIM)", ISO 2004, [3]
  • [ITS-90] "International Temperature Scale of 1990", BIPM 1990, [4]
  • [MathML] "Mathematical Markup Language (MathML) Version 2.0 (Second Edition)", W3C 2003, [5]
  • [Connolly 2007] "An extension vocabulary for chain relations in ontologies", Dan Connolly 2007, [6]
  • [Connolly-Blog 2007] "Units of measure and property chaining", Dan Connolly 2007, [7]
  • [NIST SI Guide] "Guide for the Use of the International System of Units (SI)", NIST 2008, [8]
  • [ISO/IEC Directives Part 3] "Rules for the structure and drafting of International Standards", ISO/IEC Directives Part 3, 1997, [9]
  • [SWOP 2008] SWOP website
  • [S-TEN] S-TEN website
  • [W3pm 2008] W3pm website
  • [STEP] ISO 10303, Product Data Representation and Exchange, [10] (select ‘SC4 Legacy Products’ on menu)
  • [SUMO] Suggested Upper Merged Ontology [11]
  • [DOLCE] Descriptive Ontology for Linguistic and Cognitive Engineering [12]
  • [ISO15926] ISO 15926, Integration of life-cycle data for oil and gas production facilities, [13] (select ‘SC4 Legacy Products’ on menu)
  • [Smith 2006] "Against Idiosyncrasy in Ontology Development", Barry Smith, 2006, [14]

Issues & Actions

Issues

  • Involvement of owning initiatives (ISO etc.)

Actions


Meetings

  • First Product Modelling XG (W3PM) 'Face2Face'-Meeting
    • Friday 24th October 2008, 8:30-18:00 hour
    • During TPAC-2008
    • Room: 2 (not member confidential/observers allowed)
    • Initial Chair: Michel Böhms - TNO (NL)
    • Initial Secretary: David Leal - Caesar Systems Limited (UK)
    • Proposed Agenda:
      • 08:30 Welcome by (initial) Chair
      • 08:40 Determine Final Agenda (incl. flight check)
      • 08:50 Short Introductions by Participants
      • 09:15 Admin. Stuff (final chair/secretary, public/members, way of working, telcons, wiki etc.)
      • 10:00 Discussion on Context & Scope of our XG
      • 10:30 Refreshment Break - Lobby, Agora
      • 11:00 Quantities, Units & Scales
        • Where are we now?
        • General issues
        • - language versus ontology approach (owl-extension approach C&P/NIST)
It seems that there are distinctively different requirements
a) If there is an explicit numeric representation for each quantity, and the quantity types and units/scales are within a predefined set, then the quantity-as-datatype approach is simple and powerful. It permits inferencing.
b) If some quantities are identified parameters, are non-scalar with properties (e.g. tensors), are of user defined types, or are described by user defined units/scales, then the quantity-as-object approach is necessary.
        • - units in computational systems (Microsoft refs)
        • - authoritative URLs
      • 12:00 Lunch (Restaurant le Féréol) {could be one hour shifted)
      • 13:00 Detailed discussions on Quantities, Units & Scales
      • 15:00 Refreshment Break - Lobby, Agora
      • 15:30 Cont. detailed discussions, incl. beyond Quantities, units and scales
      • 17:00 Wrap Up & Actions (esp. on Quantities, Units & Scales)
      • 18:00 Finish (or earlier depending on flights)
    • Minutes of the meeting (taken by David Leal)

Relevant External Contacts

At W3C


At ISO


At OASIS

Current wiki editors (subset of XG members/participants)

  • Michel Böhms - TNO (NL), Chair
  • Evan Wallace - NIST (US)
  • Kendall Clark - Clark & Parsia LCC (US)
  • David Leal - CAESAR Systems (UK), Co-convenor ISO TC184/SC4 "Industrial Data on the Web"
Retrieved from "https://www.w3.org/2005/Incubator/w3pm/wiki/index.php?title=Main_Page&oldid=566"