Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This W3C Incubator Group (XG) seeks to enable the use of the (Semantic) Web for Product Modelling (PM): the definition, storage, exchange and sharing of product data. Product data is information about the structure and behaviour of things that are realized in industrial processes. So principally product data is about things that are manmade, but it can also be about things in the natural world that interact with those industrial processes and/or its resulting products. Typical products would include automobiles, airplanes, buildings, infrastructures, ships and other manmade complex products.
This report describes the role and scope of product data, and initial work in two technical areas:
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of Final Incubator Group Reports is available. See also the W3C technical reports index at http://www.w3.org/TR/.
This document was developed by the W3C Product Modelling Incubator Group (W3PM).
Publication of this document by W3C as part of the W3C Incubator Activity indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. Participation in Incubator Groups and publication of Incubator Group Reports at the W3C site are benefits of W3C Membership.
This XGR is prepared by the W3PM Incubator Group.
Publication of this document by W3C as part of the W3C Incubator Activity indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. Participation in Incubator Groups and publication of Incubator Group Reports at the W3C site are benefits of W3C Membership.
1.3 A future Product Modelling WG
2. Why is a new product modelling standard needed?
3. What would be the scope of the standard?
4. Why is W3C the right home for it?
5. What would be the relationship of a PM WG to the OWL WG and other W3C activities?
6. Who needs to be brought on board to get a W3C PM WG going?
A.6 A straw-man approach using RDF-OWL
B.2 Requirements and designs are classes
B.3 The vocabulary used to describe product structure is defined for individuals
B.4 Cardinalities in product structure can be specified using OWL 1.1/2.0
B.5 There is a difference between a "partition" and a set of hasPart statements
B.6 Role or "occurrence" classes are important
B.8 The graph of relationships between classes is useful
B.9 Inferencing on the RDF-OWL representation of a design or requirement is difficult
B.10 Sufficient conditions for a requirement or design are important
B.11 The edges in a graph of relationships between classes are functions
B.12 Role classes are important for functional design
B.13 Why the functional view is important
Optionally a context for the abbreviation is given in brackets.
The SWOP and S-TEN European projects, with the POSC Caesar Association, believed that it was possible to define a small core of basic OWL classes and properties constituting a generic, reusable ‘upper ontology’ for Product Modelling (PM). This "core" could be the basis of the ontologies defined by the two projects, and for many other application ontologies. This core could help the development of Web ontologies derived from existing international standards, such as BuildingSmart/IAI Industry Foundation Classes (IFC), ISO 10303 (STEP) and ISO 15926 (process plants). Therefore it was proposed to set up a W3C "Incubator Group (XG)" on "Product Modelling (PM)" referred to as W3PM or even the “PM XG” to investigate/develop this core.
The scope of this XGR is 'Product Modelling (PM)' with 'Semantic Web (SW)'-technologies; most notebly the Web Ontology Language (OWL) but also potentially specifications like SPARQL and RIF (or related specs like UML, ODL and SysML). 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. This upper ontology or “core” can be imported and specialised for any product ontology which on its term can be instantiated for specific product models associated to real-life (existing or planned) products. Said otherwise, the idea is that this PM XG will address an OWL-based 'language' for product ontology development as shown in Figure 1.
Figure 1: Role of a PM Upper Ontology
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, as shown in Figure 2.
Figure 2: Modelling principles
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 topics/modules listed below are currently foreseen. The underlined topics have been addressed in part by this XG.
Special topic of interest beside the modelling/definition of products is the graphical representation of product data / product structure. OMG’s Ontology Definition Metamodel (ODM) including a specific (RDF-OWL-based) UML Profile would be relevant here. One could also think of an Product Modelling specific representation method. The following short and long term topics have been identified by the XG:
Short-term topics:
Quantities, units & scales
Product structure
The details of the work carried out on these topics are contained in the two appendices to this document Quantities, Units & Scales, and Product Structure.
Long-term topics:
The XG began activities in two areas - "Quantities, units and scales" and "Core ontology for product structure". In the first area, is now being continued in a wider forum which also includes ISO, NIST and BIPM. The ultimate place of standardization has yet to be decided, but it will probably be ISO or BIPM, because these organization provide the authoritative metrology standards.
However in the second area, the "Core ontology for product structure", the XG has done key research and therefore a continuation of the work by a WG may be the best way to achieve a standard. Other organisations will have a major input, especially ISO TC184/SC4, OMG (Mantis),and SysML, but it is not clear that a core ontology published on the Web would be an appropriate deliverable for any of the other groups.
This is natural question, but it is not correctly posed. In the future there will probably not be a single product modelling standard, but a range of technologies which can be used to record information about products. One of the necessary technologies is a standard core ontology for product data. Other standards may specify how this is combined with domain specific reference data and particular implementation technologies, such as web services.
Most existing standards for product data, especially those created by ISO TC184/SC4, were developed before the Web. The original ISO TC184/SC4 architecture envisaged levels of compliance as follows:
1.File exchange: This is defined by a standard product data model and the implementations methods ISO 10303-21 and ISO 10303-28. Initially, in the mid-1980s, a magnetic tape in the post was regarded as a usual physical carrier for product data. Today it is assumed that files are sent as e-mail attachments, or managed by a PLM system and retrieved by Web Services.
2.API: An API derived from a standard product data model was intended to be a standard form of access to product data. An API is defined by ISO 10303-22, Standard Data Access Interface (SDAI). Different language bindings were standardised, but probably only the Java binding defined by ISO 10303-27 is in use. It was intended that CAx system vendors would provide SDAI access to their data bases, but few ever did. Instead the SDAI is principally used as a way of creating or accessing exchange files.
3.Shared data base: It was intended that a shared product data base based upon the standard product data models could be the basis for collaborative product development. This intention has been largely superceded by the development of PLM systems. Nonetheless part of the vision has been realised by PLM systems with a Web Services interface based upon the "Product structure kernal" defined within ISO 10303.
4.Knowledge base: The principal SC4 standard ISO 10303 "Product data representation and exchange", also known as "STEP" or "Standard for the Exchange of Product model data, has never got anywhere near this goal. There are two reasons:
ISO 15926 "Life cycle data for process plant" is a standard developed by ISO TC184/SC4 which can be regarded as an ontology. Some aspects of a knowledge base for a product could be created using this ontology.
The ICT environment has changed dramatically since the mid 1980s, as follows:
The business use of the Internet and the ubiquitous use of URIs means that it is no longer necessary to create a complete repository of product data - a package of product data as single exchange file or as a data base. When ISO 10303 was first designed, referencing between an object in one data repository and another was difficult, but now it is straightforward. This means that data can be distributed across the Internet, so that:
The need of software APIs has been reduced by two complementary technologies - Web Services (SOAP or REST based) and by the Semantic Web approach based solely upon dereferencing and content negotiation.
The development of RDF/RDFS/OWL with a widespread availability of tools has meant that there are some possible practical applications from the creation of a knowledge base.
RFID devices can be regarded a link between physical objects and the Web. At a minimum they can assign a URI to a physical object. They can also hold product data about that physical object as a repository which can be regarded as part of the Web. It is a part of the Web which can only accessed intermittently, but is reliably available just when needed.
Because existing product data standards were developed before Web technologies, opportunities are being missed. Consider a complicated assembly with systems, sub-systems, sub-sub-systems and so on. For this assembly there is a complicated supply chain. There are many questions which can only be answered by navigating back up the supply chain, such as:
What is the chemical composition of the final product? It is necessary to know this in order to comply with the EU's REACH directive.
What is the environmental impact of the production of the final product? How much CO2 is emitted?
Is it possible to increase production? To answer this question, it may be necessary to investigate the capacity of many different sub-contractors in the supply chain.
In all these cases, the questions could be answered by software which accesses product data published on the Web - but only if there is a standard for product data.
An additional problem with the ISO TC184/SC4 standards is their complexity. After 20 years of development the original architecture has become fuzzy as bug fixes, work-arounds, and "custom and practice" have accumulated.
In general one could say that the time is right for a modernization of existing methods and unification of currently distinct approaches (OWL, UML, SysML, …) w.r.t. the definition and representation (formal and informal) of product data.
Using the technology of the 1980s, a product data standard consisted of an integrated suite of schemas defined in accordance with a single architecture. Because data modelling technology was in its infancy, ISO TC183/SC4 created its own modelling language EXRPESS and required that all schemas be defined using it.
The possibilities for standardisation are now more open. Different vocabularies/ontologies expressed using RDF-OWL can be brought together from different sources. For example, there may be:
The Product Modelling XG has begun by looking at items 7 and 9. An implementable standard for a particular engineering application would:
Possibly, standards for particular engineering applications are within the scope of ISO, but the ISO standard may make normative reference to generic vocabularies for product data defined within W3C and elsewhere.
‘Processes’ (seen as a complementary meta-concept to ‘Products’) are not in scope of such WP WG.
The PM WG should not redo any existing work but select and refer to it where possible. Geometry is a typical example here.
NOTE There will be a proposal for a "New SC4 Architecture" at the Rotterdam meeting of ISO TC184/SC4 in November 2009. This proposal contains many of the ideas developed within this PM XG. Already the 2009 World Ontology Summit has accepted the crucial importance of an ontology for quantities, units & scales, and a team is being set up which will include representatives from BIPM, ISO, NIST, W3C and many different scientific and engineering data representation projects. A new era of standardisation is emerging, and it will become clear what is best standardised where.
W3C would be a good place (kind of ‘natural home’) for an upper ontology for Product Modelling since its fits so nicely with the ‘semantic web paradigm’ (the layered cake). It can also be seen as a perfect use case for/’on top of’ existing OWL technology.
The new standard will probably not completely supercede any standard. ISO 10303 is still being used alongside its predecessor IGES. However in the future, data management problems will not be solved by creating huge and complicated data models (valid against as complicated schemas). Instead a vocabulary to express the content will be assembled from different sources, and integrity constraints will be added.
Perhaps we have a key role in flagging up limitations in technologies such as OWL for product data. The graph based approach to product data may be an example of this. There is a need to take advantage of the topological similarity between the graph of classes defined by a requirement or design, and the graph of individuals that is the satisfaction of a requirement or an implementation of a design.
More positively formulated, the current OWL 1.1/2.0 specification fulfills the PM requirements already to a large extent so it seems logical to position it as a layer on top of it.
Standardization Institutes
ISO TC184/SC4 (“Industrial Automation”)
OMG Manufacturing Technology and Industrial Systems Domain Task Force
OASIS
Techical committees including Open Building Information Exchange (oBIX), Product Life Cycle Support (PLCS), and UnitsML.
NIST (US): Conrad Bock
Universities
Vorarlberg University of Applied Sciences (AUS): Bernd Wenzel
Companies
Caesar Systems (UK): David Leal
Clark & Parisa (US/UK): Kendall Clark
Eurostep (UK): David Price
Shell Global Solutions (UK/NL): Andries van Renssen
POSC-Caesar Association (NO): Magne Valen-Sendstad
R&D Institutes
TNO (NL): Michel Böhms
Initiatives/Projects
Individuals
Henson Graves (US)
Matthew West (UK)
An ontology is a conceptualization of a domain to enable knowledge sharing. Physical quantities and units have been proposed as a candidate topic for an ontology. The acceptance of a quantities and units ontology depend on the use of common agreed standards for physical properties of objects and their states. Even at the most basic level there does not appear to be consensus as to what quantities and units are and how they should be represented. For example, is a physical quantity such as length a thing which is measured, or is length the value of a measurement? Is metre a quantity? This document suggests some requirements and an approach to constructing a quantities and units ontology. The approach outlined here is in the spirit of Gruber and Olsen 1994 and makes free use of their work. However, some of the proposals as how to conceptualize the domain for mathematical modeling are not the same as Gruber and Olsen 1994.
Physical quantities are where mathematics is connected to the physical world. Physical quantities are concerned with the properties which we observe and measure or the properties which we derive from those we observe. This would suggest that to facilitate knowledge sharing by practicing engineers, analysts, and product designers a physical quantities and units ontology needs to interface with mathematical modeling of the physical world. Everyday mathematical modelling of physical world requires a very rich language. The language needed for mathematical modeling is much richer than is found in current DL based ontology languages. Quantities and units are most naturally expressed within a (data) type theory [Parsia and Smith 2008]. Type theory can be added to DL based ontology languages.
Every new data modelling/ontology definition activity in science or engineering data feels the need to rework quantities, units & 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 (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 & scales on the Web that is:
NOTE The need for both units & scales is not obvious and is discussed in Why units AND scales.
Some starting points include:
An Ontology for Engineering Mathematics
A good starting point is "An Ontology for Engineering Mathematics" Gruber and Olsen 1994. This paper distinguishes between:
Tim Berners-Lee's approach to units of measure
"An Ontology for Units of Measure" Berners-Lee 2007 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 Objectives).
International Vocabulary of Basic and General Terms in Metrology (VIM)
"International Vocabulary of Basic and General Terms in Metrology" (VIM) VIM 2004 is an authoritative document that defines some of the terms which it is necessary to place within an ontology.
NASA SWEET
"Semantic Web for Earth and Environmental Terminology" (SWEET) NASA-SWEET is a useful practical ontology but it does not seek to address the fundamental issues about the nature of quantities units & scales.
UnitsML
"Units Markup Language" (UnitsML) UnitsML is a project underway at the National Institute of Standards and Technology (NIST) to develop a schema for encoding scientific units of measure in XML.
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 scale is an identification scheme, such that each quantity value within a quantity space 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 value 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. Hence the length y is defined by the statement that the evaluation of metre-scale for y gives 12, i.e.:
in textural maths:
metre-scale(y) = 12
in RDF-OWL:
<Length rdf:about="#y">
<metre-scale>12</metre-scale>
</Length>
in MathML:
<apply>
<eq/>
<apply>
<csymbol definitionURL="#metre-scale"/>
<ci definitionURL="#y"/>
</apply>
<cn>12</cn>
</apply>
A unit is a defined quantity value within a quantity space.
If the quantity space has the right properties (not all do), then I can say that any other quantity value 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
in MathML:
<apply>
<eq/>
<ci definitionURL="#y"/>
<apply>
<times/>
<ci definitionURL="#Metre"/>
<cn>12</cn>
</apply>
</apply>
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 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
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 1 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
EXAMPLE 2 The "International Temperature Scale of 1990" ITS-90 defines several thermodynamic temperature magnitudess. These are assigned real numbers within the T90 scale. The scale is chosen to be close to the scale derived from the unit Kelvin..
In an ontology, subclasses of scale can be defined such as linear or logarithmic.
NOTE 2 All scales that are 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
A practical approach is:
Always use scales for defining quantities because:
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:
Key objects which need to be in an ontology are as follows:
quantity
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
kind of quantity
aspect common to mutually comparable quantities
measurement unit
real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the two quantities as a number
quantity value
number and reference together expressing magnitude of a quantity
quantity equation
mathematical relation between quantities in a given system of quantities, independent of measurement units
All the definitions in the preceding list above are taken from VIM 2008.
NOTE From the point of view of an ontology, there are issues with these definitions, which need to be worked out with the metrology experts. These include:
Does the term quantity apply to "length" or to a particular length such as "10 metres"? The VIM document is unclear. The examples given suggest that it applies to "length", but the definition of measurement unit is "real scalar quantity, ..." which suggests it applies to "10 metres".
The definition of quantity equation does not help, because the definition can be understood with either meaning of quantity. If "length" is a Quantity, then a quantity equation is a formula into which particular quantity values can be inserted. If "10 metres" is a quantity, then a quantity equation is a relationship between particular quantity values.
The English definition of quantity value is unclear. The French definition "ensemble d'un nombre et d'une référence constituant l'expression quantitative d'une grandeur" is better. An English translation could be "a number and a reference taken together which is the quantitative expression of a quantity". With this understanding, quantity is a term that applies to "10 metres", where the pair (10,metre) is the quantity value.
This interpretation causes another problem. The term quantity value is now applied to a mere data structure, for which the term "quantity representation" would be better. We need to have distinctly different terms for:
A possible choice of terms is "quantity space" and "quantity value", but this is perhaps not the meaning of "quantity value" defined in VIM 2008.
Consider example in Some starting points that involve the water line length of a ship. What is the concept waterline length. Some considerations are as follows:
Waterline length is not a specialisation of length, because there is no useful subset of lengths which are waterline lengths.
"Waterline length of 10 metres" could be regarded as a class of ship. Hence we could say:
MyShip is a "waterline length of 10 metres".
This works, but creates two problems:
A pragmatic alternative is to regard waterline length as an rdf:Property with domain Ship and range Length. Further it is assumed that Length is an owl:Class and that "10 metres" is a member of it. There is a choice of representations for the length "10 metres", as follows:
1. 10 metres is an object of type length, and the number 10 is an object of type Real, so that:
2. 10 metres is an object of type length, and the number 10 is a real datatype, so that:
3. 10 metres is a length datatype, so that:
At present, option (3) is not available in OWL, but an OWL extension has been proposed by Parsia and Smith 2008.
The use of option (1) is shown in Figure 3.
Figure 3: Graphical representation of the strawman approach to quantities
The objects within Figure 3 are divided into subject areas as follows:
This upper ontology needs to be based upon authoritative sources such as VIM 2008. In this strawman, the object QuantitySpace is a subclass of the powerclass of Quantity.
There is already good initial material for this area within NASA-SWEET and UnitsML.
This is where the bulk of the work lies, but it is out of scope.
A pedantic approach is shown here, which can be simplified as required.
NOTE 1 The strawman approach uses scales, but the scales are derived from units. The work of Tim Berners-Lee Berners-Lee 2007 and Dan Connolly Connolly-Blog 2007 is incorrect in its use of property chaining and the inverse properties to define scales for derived quantities. The only mathematically rigorous way of defining scales for derived quantities is via units. Units can be multiplied and divided as required. Once a unit for a derived quantity has been defined, a scale can be derived by lambda calculus.
Hence the "quantity and scale" (green) area is much more complicated than shown in Figure 3. The definition of derived quantities and their units is within the scope of MathML, so there is no need to invent anything new.
NOTE 2 There may be further subclasses of QuantitySpace, such as quantity spaces which are manifold and quantity spaces for which we can carry out arithmetic operations in the usual way. Such quantity spaces are probably one dimensional vector spaces, for which a unit can be chosen as the basis.
The area "ship" (yellow) in Figure 3 contains the phyisical property "waterline length". There are similar physical properties, and their definitions are rarely simple. In this case, is the waterline length:
The distinction between nominal physical properties specified for a design, which may have tolerances, and actual physical properties of individual which always vary with time is within the scope of product modelling but not within the scope of the quantities, units and scales discussion.
The problems occur even with a property as simple as mass. Theoretically a mass may be simply a class of a quantity of matter based upon its gravitational attraction or inertia. In practice, a quantity of matter has a usually has a complicated relationship with mass. For a tank, the nature of the relationship with mass needs to specify:
Complicated relationships with mass can probably be reduced to "hasMass" by modelling the tank as an assembly of things which changes with time. The approach to be taken is a choice.
The work of the Product Modelling XG has contributed to the raising of the issue of quantities, units & scales on the Web as a major problem which needs to be addressed within ISO, and W3C.
The theme of the 2009 World Ontology Summit [WOS 2009] was "Towards ontology based standards". An ontology for quantities, units and scales was identified as crucial and is the focus of a team created as a result of the summit.
The Industrial Data on the Web group within ISO TC184 has raised the issue within ISO. This group has agreed a position paper URIs for quantities, units & scales written by the W3C Product Modelling XG which explains the importance of the issue to ISO.
The work on quantities, units & scales now involves a much broader scope than product modelling, which is the focus of the Product Modelling XG. Hence it is now necessary to review the work from the point of view of product modelling rather than to initiate the work.
Work on information models for product structure goes back at least to the initial development of STEP (ISO 10303) in the mid-1980s. STEP's initial focus was on mechanical piece parts, and since then there have been many different parallel activities for different product types, such as power systems, building and construction, and process plant.
This work has created a morass of different terminologies and approaches, very few of which have a formal basis. The W3PM XG has started to create a formal basis for product structure by proposing a sequence of propositions, which are set out in this annex. At present, the propositions are of mixed type - some fundamental about an ontology for product structure, and some practical concerning the use of OWL for the representation of product structure.
As the work advances, it will be necessary to separate the ontological statements from the practical ones. The initial work seems to suggest that OWL 1.1/2.0 is capable of making most of the necessary statements. However, there are difficulties as follows:
The work on product structure may lead to new methods of product data representation, and new approaches for validating:
Some propositions about product structure are as follows:
requirement:
The statement "R is a requirement of X" can be interpreted to mean
"X wants a member of R". With this interpretation, the requirement R
is a class.
A requirement can be a class of activity.
EXAMPLE 1 "Deliver one widget of type PQR to address A on 2009-06-17" is a class of activity. This class can be a requirement.
A requirement can be a class of manufactured object.
EXAMPLE 2 "Aeroplane that can carry at least 300 passengers at least 4000 km" is a class of manufactured object. This class can be a requirement.
design:
X creates a design D for what may come to pass or may be created. The design D
can be more or less precise. If X is happy with outcome q, then "q
complies with design D". Therefore design D can be regarded as a the class
of all compliant outcomes.
A design can be a class of activity.
EXAMPLE 3 "Collect one widget of type PQR from depot D between 08:00 and 08:15 on 2009-06-17; unload at address A between 11:30 and 12:00; and return to base before 17:00" is a class of activity. This class can be a design. Designs for activities are often called "plans".
A design can be a class of manufactured object.
EXAMPLE 4 "Object with shape S machined from a billet with material specification M" is a class of manufactured object. This class can be a design.
The initial scope of the W3PM XG is limited to requirements and designs for manufactured objects.
NOTE 1 Design D satisfies requirement R means D is a subclass of R.
NOTE 2 A design activity often creates a sequence of designs D1 ... Dn of increasing precision. The design activity stops when Dn is precise enough to specify a manufacturing activity.
Statements can be made about individual manufactured object x, y and z, such as:
It is natural to use the same vocabulary to make statements about the designs of, or requirements for, manufactured objects X, Y and Z, such as:
However, because the vocabulary is defined for individuals, the statements about designs or requirements should be expressed as follows:
A correct use of the product structure vocabulary for individual and designs or requirements is shown in Fiqure 4 and Fiqure 5.
Figure 4: RDF-OWL representation of statements about individual manufactured objects
Figure 5: RDF-OWL representation of statements about designs of, or requirements for, manufactured objects
Using OWL 1.1/2.0, it is possible to state that "each member of X has exactly 2 members of Y as a part". This is shown in Fiqure 6.
Figure 6: RDF-OWL representation of cardinality in product structure
NOTE Although the scope of this document is not restricted to RDF-OWL, the ability to represent product structure using RDF and OWL 1.1/2.0 is particularly useful.
A partition consists of two propositions as follows:
NOTE It is necessary to have a partition of object x in order to calculate the mass of object x from the masses of its parts.
The first proposition of the partition can be represented using RDF-OWL as a set of n hasPart statements, provided that there is a closed world assumption (in case of an open world assumption one has to specify exlicitly that there are no other things part of the whole ). The second proposition can be reresented using RDF-OWL by n(n-1) "disjoint" statements. Alternatively, to represent a partition without a closed world assumption one could have "partition" as part of the product structure vocabulary, as shown in Fiqure 7.
Figure 7: RDF-OWL representation of an individual partition
To make an equivalent statement about a design or requirement is much more difficult, and requires a Cartesian product of classes. Currently this is way outside the scope of OWL. If it were added, the representation would be as shown in Fiqure 8.
Figure 8: RDF-OWL representation of a design or requirement partition
The statement "each member of X has exactly one member of Y as a part", implies that there is a subclass of Y that consists of each member of Y that is a part of X. The class "YinX" is important because information may need to be recorded about it. For example a maintenance activity may need to be carried out for each YinX every 10000 hours.
The statement "each member of X has exactly two members of Y as parts - one on the right and one on the left", implies that there are two subclasses of Y - "YinX-left" and "YinX-right". These classes are important. A structural analysis may show that the stresses in YinX-left are different to those in YinX-right. As a result, a different maintenance regime is specified for each.
There is a one-to-one relationship between occurence classes. Hence:
The one to one relationship can be represented in RDF-OWL, as shown in Fiqure 9.
Figure 9: RDF-OWL representation of a role class
NOTE 1 The class YinX is shown as a subclass of the intersection of Y, and the restriction "part of exactly 1 X", because the example does not assert that there are no other requirements for being a YinX.
In the example shown in Figures 12a to 12d, it is asserted that all the requirements are specified, so that the role class is defined by their intersection. The difference between "necessary" and "sufficent" conditions for membership of a class is discusses in section Sufficient conditions for a requirement or design are important..
NOTE 2 In Fiqure 9 there is no need to define the anonymous class that is the intersection of Y and "part of exactly 1 X". Instead the class YinX could have two subClassOf relationships - one with Y and the other with "part of exactly 1 X".
Consider a Widget, which is defined as follows:
A Widget is shown in Fiqure 10.
Figure 10: A Widget
There are two role classes WidgetLeftBracket and WidgetRightBracket.
The individual assembly WA-1234 is as follows:
The statements about WA-1234 can be represented in RDF-OWL, as shown in Fiqure 11.
Figure 11: RDF-OWL representation of an individual widget
NOTE 1 Fiqure 11 shows the statements that can be directly observed. WB-4567 is not shown as being of type WidgetLeftBracket because this is true only if many criteria are met. One of these criteria is that it is part of a Widget. It is not yet known whether or not WA-1234 is of type Widget.
To determine whether WA-1234 is of type Widget and WB-4567 is of type WidgetLeftBracket requires checking Fiqure 11 against the constraints shown in Figures 12a to 12d or against the equivalent shorthand shown in Figure 13.
If the definition of a Widget given in English at the beginning of this section were expessed formally, it should be possible to deduce from statements about WA-1234 that:
Hence the task is to express the definition of a Widget formally. It is difficult to fit the complete definition into one figure, so it is split into Figures 12a, 12b, 12c and 12d.
Figure 12a: RDF-OWL representation of the definition of Widget
Figure 12b: RDF-OWL representation of the definition of WidgetLeftBracket
Figure 12c: RDF-OWL representation of the definition of WidgetBasePlate
Figure 12d: RDF-OWL representation of the definition of WidgetRightBracket
The Figures 12a to 12d contain reciprocal constraints, each with cardinality 1, between the key objects - Widget, WidgetBasePlate, WidgetLeftBracket and WidgetRightBracket. A notation can be postulated for these constraints as shown in Figure 13.
Figure 13: A representation of the class Widget
The topology of Figure 13 is equivalent to that of Fiqure 11 - this is why it is significant. The labels on the thick arrows correspond to the names of the properties shown in Fiqure 11. The topological equivalence is important because it justifies the use of the vocabulary defined for individuals when refering to classes, as discussed in section The vocabulary used to describe product structure is defined for individuals.
Figure 13 is NOT an RDF-OWL diagram. Each thick arrow corresponds to RDF-OWL in Figures 12a to 12d. The relationship between classes WidgetLeftBracket and WidgetBracket is not type, but subClassOf. The thick arrow in Figure 13 is labeled "type" because an individual that is a WidgetLeftBracket has a type relationship with WidgetBracket.
NOTE 2 Figure 13 can be represented in RDF using the properties class-hasPart, class-connectedTo and class-hasPosition. However, there is no capability currently within OWL to relate these class level properties to the corresponding individual properties hasPart,connectedTo and hasPosition.
The class level property class-type is the same as subClassOf.
The graph of relationships between classes is the way in which people think about requirements and designs.
The analogy is with a drawing - which can be a drawing of an individual manufactured object, or of a requirement or design. The drawing would look the same in either case. The difference is that:
The similarity between the graph involving parts of an individual manufactured object and the graph involving role classes is a justification for ISO 10303 (STEP) using the same data structures for individual manufactured objects and for requirements and designs. Another example fin the area of ‘building and construction’ is the use of (strongly related) entities in the IFC schema in a dual way of X and Xtype (like IfcBeam and IfcBeamType).
In section There is an equivalence between the graph of relationships between classes in a design product structure and individuals in an individual product structure, a formal representation of a requirement or design is stated to be necessary so that is is possible to deduce whether or not an individual manufacture object meets a requirement or complies with a design.
Unfortunately inferencing on the RDF-OWL in Figures 12a to 12d is not possible using an engine such as Pellet. This is because there are reciprocal constraints, such as:
WA-1234 has WBP-4321 as a part. If it were known that WA-1234 is a Widget, then it could be infered that WBP-4321 is a WidgetBasePlate. If it were known that WBP-4321 is a WidgetBasePlate, then it could be infered that WA-1234 is a Widget. Unfortunately, neither is known a priori, and so nothing can be infered.
There are different approaches to solving this problem. One promising approach is to procedure heuristically and attempt to match graph topology. If the class graph matches the individual graph, then each individual is a member of the corresponding vertex in the class graph.
Figures 12a to 12d very nearly define sufficient conditions for being a member of the class Widget. Hence if an assembly is observed to consist of a WidgetLeftBracket, a WidgetBasePlate and a WidgetRightBracket, then it IS a Widget. There is no need to observe anything else in order to determine whether or not an assembly is a Widget.
NOTE The reason for the caveat "very nearly" is explained in Why the functional view is important.
The statements in Figure 12a can be reduced to being merely a set of necessary conditions, as shown in Figure 14.
Figure 14: Necessary conditions for being a member of the class Widget
This is much less helpful. Even if an individual manufactured object is observed to comply with all these conditions, it is still not known whether it is actually a widget. In this case, the observations merely do not exclude the possibility that it might be a widget.
The distinction between necessary and sufficient conditions is not an "open world - closed world" issue. Figure 12a represents sufficient conditions with either an open world or a closed world assumption. Figure 14 represents necessary conditions with either an open world or a closed world assumption.
The shorthand notation shown in Figure 13 is a closed world shorthand. For each vertex in the graph, only the connecting edges that are actually recorded are assumed to define classes which are used within the intersection that defines the sufficient conditions.
The edges in the class graph shown in Figure 13, can be given names as shown in Figure 15.
Figure 15: A class graph with named edges
The edge widgetHasLeftBracket is a one-to-one subPropertyOf hasPart. This can be recorded using RDF-OWL as shown in Figure 16.
Figure 16: A subproperty of hasPart
Unfortunately, Figure 16 does not define widgetHasLeftBracket because it does not specify the basis upon which the graph (where "graph" is used to mean the set of domain value - range value pairs) of widgetHasLeftBracket is selected from the graph of hasPart. Therefore Figure 16 does not provide an alternative to the Restriction classes in Figures 12a to 12d.
NOTE ISO 15926-2 can make the statements equivalent to the individual graph shown in Fiqure 11 and to the class-function graph shown in Figure 15. ISO 15926-2 cannot define Restriction classes, and therefore cannot provide the precision shown in Figures 12a to 12d. However ISO 15926-2 does provide an alternative notation for Fiqure 11 and Figure 15, as shown in Figure 17 and Figure 18.
Figure 17: ISO 15926 representation of an individual widget
Figure 18: ISO 15926 representation of a Widget
The links between Figure 17 and Figure 18 are represented in ISO 15925 as shown in Figure 19.
Figure 19: ISO 15926 link between individual graph and class graph
Figure 19 is useful because it is intuitive. However ISO 15926 assumes that hasPart is a set of pairs, so that widgetHasLeftBracket is a subset, and the relationship between WA-1234 and WB-4567 is a member.
In the "Widget" example described in section There is an equivalence between the graph of relationships between classes in a design product structure and individuals in an individual product structure, the roles are part occurences in a mechanical assembly. Each part occurence has a function, but the function is not stated explicitly.
In a functional design, the functions of the different components are stated explicitly. This approach is common in the process industry, and is illustrated by considering a "boiler feed water pump" and a "boiler feed water line".
boiler feed water pump
An object is not necessarily manufactured specifically to be a boiler feed water pump. Any reliable pump which can pump water, can have a low suction pressure, and can have a high discharge pressure, can be a boiler feed water pump. Such a pump could also be installed as a fire water pump.
A boiler feed water pump can be defined to be a pump that is also part of a boiler feed water line
boiler feed water line
A boiler feed water line can be defined to be a pipeline that is connected to a water tank at one end, to a boiler at the other, and that contains a boiler feed water pump.
A formal representation of the definition of these role classes in RDF-OWL is shown in Figure 20.
Figure 20: RDF-OWL representation of the definition of a boiler feed water line
The equivalent class graph is shown in Figure 21
Figure 21: Boiler feed water line class graph
Figure 21 is useful, and it provides a intuition about what role classes are - they are vertices in a class graph.
NOTE The leaf "vertex" water tank is itself a role class. This role class is defined by a different class graph.
Individual pump P-101 is part of pipeline L_101, which connects water tank T_101 to boiler B_101. This is stated formally in Figure 22.
Figure 22: Boiler feed water line indivdiual graph
NOTE It seams reasonable that a heuristic algorithm could deduced that L_101 is a boiler feed water line and that P_101 is a boiler feed water pump, but matching graph topology.
Figures 12a to 12d do not define sufficient conditions for being a member of the class Widget because of the case shown in Figure 23.
Figure 23: Not two widgets
Figure 23 shows two assemblies, each of which is similar to that shown in Fiqure 11. Both assemblies comply with the constraints shown in Figures 12a to 12d, yet neither is a widget. This is because although each WidgetLeftBracket is connected to a WidgetBasePlate, the WidgetLeftBracket and the WidgetBasePlate are not part of the same assembly.
The requirement that they shall be part of the same assembly is not stated in the OWL, can probably it cannot be stated using the available versions of OWL. Using the functional representation of a widget, shown in Figure 15, the constraint can be stated as follows:
leftBracketConnectedToBasePlate ⊗ widgetHasLeftBracket = widgetHasBasePlate
where ⊗ indicates composition of function, such that:
