Face-to-face 2008-10-24

1 Present

• Michel Böhms, TNO, NL (chair)
• David Leal, CAESAR Systems, UK (secretary)
• Lothar Klein, LKSoft, DE
• Henson Graves, Lockheed-Martin, USA
• Evan Wallace, NIST, USA (principally for quantities, units and scales)
• Bijan Parsia, Clark & Parsia, UK (principally for quantities, units and scales)

2 Agreements

2.1 What can be done

1. We develop stuff that is independent of engineering discipline, and that is "upper" such as product structure, or "ubiquitous" such as quantities, units and scales.

2. There are other W3C groups that are domain specific, such as life sciences and possibly a future one for oil and gas. The product modelling group will provide generic stuff which they can use.

3. W3C is a good place to work, because it does not have a legacy in this area which slows progress. Also its stuff is freely available on the Web.

2.2 Quantities,units and scales

1. A theory (possibly expressed as an OWL ontology or knowledge base) for quantities, units and scales is needed. This theory will have many uses. One may be to define datatypes for quantities in a future OWL extension, such as that proposed by Bijan (see http://clarkparsia.com/files/pdf/units-owled2008-eu.pdf).

2. A pilot will define the part of the theory for something simple like length, its units, and the scales derived from them. Bijan's OWL datatype proposal, and the direct use of the theory when expressed as an OWL ontology, will be demonstrated using this pilot.

3. The W3PM will perform the following stages before 2009-05-01:

   1. create and document the theory;
   2. document as an OWL ontology/knowledge base, with the information necessary to create datatypes;
   3. create instantiations as Bijan datatypes and as OWL objects (this validates items 1 and 2);
   4. create a set of test cases for the use of quantities, units and scales in engineering scenarios;
   5. define a project to create more comprehensive ontology/knowledge base for release as a standard;
   6. approach ISO TC12 for collaboration on this work.

   Stages 1 to 6 will be followed by a project to create a "standard". (The exact form of this "standard" is uncertain. It may be a W3C publication at some level. It may also involve standardisation activities, such as assigning URIs to quantities, units and scales, outside W3C.)

   The discussion about what happens when a URI that identifies a quantity, unit or scale is dereferenced is not within stages 1 to 6, but may be part of the subsequent project.

4. Some requirements for the theory are the need to state that:

   • velocity is length/time;
   • lengths can be added, multiplied by a real, etc.;
   • a scale is linear, logrithmic, isomorphic with respect to addition, etc.;
   • a scale is derived from a unit.

5. Initial work on the theory noted that:

   • The different "types of physical quantity" or "physical quantity spaces" are fundamental. They have to be separately defined and identified.
   • A statement that each quantity in a physical quantity space is obtained by arithmetic operations on quantities in other physical quantity spaces is useful, but does not define a physical quantity space.
   • Some physical quantity spaces are arbitrarily selected by BIPM as spaces for which an SI base unit is defined.
   • A dimensionality for a physical quantity space can be specified in terms the physical quantity spaces selected for the SI base units.
   • Many different physical quantity spaces have the same dimensionality. For example, an energy quantity can be expressed in terms of the unit Joule (J), which is the name for Newton×metre when used as a unit for energy. A torque can be expressed in Newton×metre, but the derived unit for torque is not called Joule.
   • Valid units for a physical quantity space can be derived from its dimensionality, but this is not sufficient. Uni-axial stress (change of length/length) is dimensionless, as is taper (change of width/length). Both uni-axial stress and taper can be expressed without reference to units, or as cm per mile. Neither can be expressed as grammes per ton, but mass concentration (also dimensionless) can.
   • Some combinations of other units have special names, e.g. litre, BTU.
   • There is a multitude of properties that are functions from a class of physical object to a physical quantity space. For example "maximum sump oil temperature" has "engine for a period of time" as its domain and temperature as its range. These properties are out of scope.

2.3 Product structure

1. Requirements and designs are classes. It is necessary to prove that a design meets (is a subclass of) the requirements. It is necessary to prove that an individual complies with (is a member of) a requirement or design.

   Requirements modelling may be a separate topic.

2. Henson's proposal, which leads to a graph of relationships between classes (requirements or designs) that has the same structure as the corresponding relationships between individuals, seem promising. Note the proposal is very similar (perhaps identical) to the use of class_of_relationship and relationship in ISO 15926-2.

3. The Product Modelling XG will produce test cases to validate Henson's approach.

   The instantiation may show differences between Henson's approach and the PMO approach.

4. Attempted representations of the test cases in OWL will determine whether or not extensions to the OWL language are required.

5. The Product Modelling XG will define different cases for "hasPart", distinguishing between its use in the definition of physical parts and in the definition of systems.

3 Miscellaneous points made

... and noted more or less at random by David.

3.1 Introductions

LK: STEP has achieved a lot. We need to move STEP into the new technology. "Semantic STEP" is a proposal, but there is only limited interest within ISO TC184/SC4.

HG: OWL as it stands is not quite sufficient for what we want, but it is pretty close. With some small extensions we can do product structure.

MB: The development of STEP within the architecture, engineering and construction (AEC) domain was too slow. In parallel, the IAI was set up to develop the AEC Industry Foundation Classes (IFC). There is a desire to add more semantics dynamically to the geometric representation in the IFCs. OWL is seen as a better way than ISO 12006-3 "Building construction — Organization of information about construction works — Part 3: Framework for object-oriented information" to do this.

Initial models that provide starting points include:

• MB: PMO model (SWOP project)
• LK: Semantic STEP model (S-TEN project)
• DL: ISO 15926 (-2 general, -3 topology and geometry)

3.2 What can be done?

HG: W3C may not be the right place in the long run, because product modelling is so open ended.

HG: We need good upper ontologies.

DL: We need simple "tools" at a high level, such as an approach to quantities and units and to product structure, which are so simple, obvious and authoritative that other people will pick them up and use them.

MB: Others define quantities, units and scales. We work on the usage of quantities, units and scales.

HG: How do we get the resources we need for defining things like units of measure? Industry consortiums are needed to join W3C and sponsor the work. Perhaps also NIST, NASA, ESA.

3.3 Quantities, units and scales

LK: We need a "has aspect" that specifies what properties something can have. We need for URNs for physical quantity spaces, units and scales.

BP: OWL has abstract domains and concrete domains. A datatype is a concrete domain which must have well defined axioms.

BP: A datatype with the lexical form that is the triple (physical quantity space id; unit or scale id, number as decimal) will probably be added to a future version of OWL. This will satisfy many simple engineering applications.

3.4 Product modelling

LK: "Semantic STEP" contains a meta-model in EXPRESS derived from OWL.

EW: The entity "product" in "Semantic STEP" is semantically vague.

LK: The concept of product in STEP has been deliberately designed to be semantically vague and is therefore ABSTRACT. Only the non-abstract subtypes provide the needed semantic clarity.

HG: A graph theory approach cam be used to comparing design and requirement definitions with instances. The relationships between classes have a similar structure to the relationships between individuals.

MB: Henson's decomposition apporach is similar to that of the PMO developed by the SWOP project.

DL: Henson's approach is the same as that of ISO 15926-2.

LK: The same can be achieved by the less formal models within STEP provided that specific code is written to process them.

DL: The STEP models will not be used to for product structure data on the web because they are too complicated.