IDIOM Architecture Specification

apprenticegunnerInternet and Web Development

Oct 22, 2013 (3 years and 11 months ago)

118 views


IDIOM Architecture
S
pecification


Future
SC 4
Architecture
PWI

Deliverable


David Price
,
David Leal
, Allison Barnard Feeney

-

Editor
s

Version 0.
2






AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



ii

Contents

0

Introduction

................................
................................
................................
...............................

v

0.1

Basis of the approach

................................
................................
................................
......................

v

0.2

Components of IDIOM

................................
................................
................................
.....................

v

0.3

The approach to change

................................
................................
................................
.................

vi

1

The IDIOM IT framework

................................
................................
................................
..........

1

1.1

Overview

................................
................................
................................
................................
..........

1

1.2

Relationship with other parts of IDIOM

................................
................................
..........................

3

1.3

Relationship with the OMG Model Driven Architectu
re®

................................
...............................

3

2

Natural language dictionaries

................................
................................
................................
...

4

2.1

The role of natural langu
age dictionaries

................................
................................
........................

4

2.2

Technologies for the representation of natural language dictionaries

................................
...........

4

2.3

Natural language dictionaries within IDIOM

................................
................................
...................

5

2.4

Natural language dictionaries for industrial and engineering domains

................................
..........

5

2.5

A catalogue of natu
ral language dictionaries

................................
................................
..................

5

2.6

Use cases for natural language dictionaries

................................
................................
....................

6

3

Ontologies

................................
................................
................................
................................
.

6

3.1

Use of ontologies in the IDIOM architecture

................................
................................
...................

6

3.2

Knowledge about an industrial domain

................................
................................
..........................

7

3.2.1

Language

................................
................................
................................
................................
...

7

3.2.2

Visual representation

................................
................................
................................
...............

9

3.2.3

Beyond OWL

................................
................................
................................
...........................

10

3.3

Management of knowledge about an industrial domain

................................
..............................

10

3.4

Implementation of an ontology

................................
................................
................................
.....

11

3.4.1

Implementation without using a data model

................................
................................
.........

11

3.4.2

Integration of generic and specific knowledge

................................
................................
......

12

3.5

Ontology and dictionary of definitions

................................
................................
..........................

14

4

Process models

................................
................................
................................
.......................

14

4.1

The role of process models

................................
................................
................................
............

14

4.2

UML process models

................................
................................
................................
.....................

15

4.3

BPMN process models

................................
................................
................................
...................

16

5

Data models

................................
................................
................................
............................

16

5.1

The role of data models

................................
................................
................................
.................

16

5.2

Relation

to the STEP data model architecture

................................
................................
..............

18

6

Service models

................................
................................
................................
........................

18

7

Mappings and traces

................................
................................
................................
...............

19

7.1

The role of mapping and traces

................................
................................
................................
.....

19

7.2

Trace

................................
................................
................................
................................
..............

20

7.2.1

Mechanisms

................................
................................
................................
............................

20

7.2.2

OWL mechanisms

................................
................................
................................
...................

20

7.2.3

UML mechanisms

................................
................................
................................
...................

21

7.2.4

EXPRESS mechanisms

................................
................................
................................
.............

21

7.2.5

XML mechanisms

................................
................................
................................
....................

21

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



iii

7.3

Mappings

................................
................................
................................
................................
.......

21

7.3.1

General

................................
................................
................................
................................
...

21

7.3.2

EXPRESS mappings

................................
................................
................................
..................

22

7.3.3

UML/MOF mappings

................................
................................
................................
..............

22

7.3.4

XML mappings

................................
................................
................................
........................

22

7.3.5

RDF/OWL mappings

................................
................................
................................
................

22

8

Migration paths

................................
................................
................................
.......................

22

8.1

ISO 10303 migration path

................................
................................
................................
..............

22

8.1.1

Migrating ISO 10303 schemas to new architecture

................................
...............................

22

8.1.2

Aligning an existing ISO 10303 standard with new SC 4 standards

................................
........

23

8.2

ISO 15926 migration p
ath

................................
................................
................................
..............

24

9

Integrating other standards

................................
................................
................................
....

25

10

Conclusion

................................
................................
................................
.............................

26

10.1

The nature of the IDIOM architecture

................................
................................
.........................

26

10.2

The next steps

................................
................................
................................
..............................

27

Annex A
-

Abbreviations

................................
................................
................................
...............

28

Bibliography

................................
................................
................................
................................
..

29


Figures

Figure 1
-

High level IT Framework

................................
................................
................................
..............

vi

Figure 2
-

IT framework
-

second level of detail

................................
................................
...........................

2

Figure 3
-

IT framework
-

detail for mapping and trace

................................
................................
................

2

Figure 4
-

Representing knowledge using EXPRESS

................................
................................
......................

8

Figure 5
-

Representing
required data using EXPRESS

................................
................................
..................

8

Figure 6
-

A simple approach to representing knowledge using OWL

................................
..........................

8

Figure 7
-

Simple OWL with a cardinality constraint

................................
................................
.....................

9

Figure 8
-

Simple UML representation of OWL

................................
................................
...........................

10

Figure 9
-

Simple instances of classes and properties in an ontology

................................
........................

11

Figure 10
-

EXPRESS model with
reference data

................................
................................
........................

13

Figure 11
-

OWL with reference data

................................
................................
................................
..........

13

Figure 12
-

E
xample process model

................................
................................
................................
............

15

Figure 13
-

Simple example UML data model

................................
................................
.............................

17

F
igure 14
-

Mapping and trace

................................
................................
................................
....................

20

Figure 15
-

Excerpt from QUDT ontology

................................
................................
................................
....

26

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



iv

Foreword

At its Parksville meeting in June 2009, ISO
TC 184/SC 4

passed the following resolution:

RESOLUTION 785 (Parksville, British Columbia, Canada
-

May 2009)

Creation o
f a PWI on “Future SC 4 Architecture”

SC 4 approves a PWI on “Future SC 4 Architecture” to:



Explore the range of options for exploiting new technologies to support
interoperability between
SC 4

standards, and the work of other committees,
operating across a range of platforms



Recommend an overall architecture for future use by SC 4 standards



Define migration paths for existing SC 4 capabilities



Identify specific licensing, commercial or other ad
ministrative barriers



Illustrate and validate any conclusions against a representative example.

SC 4 invites all of its member bodies and WGs to contribute to the work of the PWI.

SC 4 appoints David Leal and David Price as joint leaders for the PWI and in
vites them to
report back no later than the November 2009 meeting.

The work of the P
reliminary
W
ork
I
tem

(PWI)
team was conducted by means of telecon
ference
s,
an
SC 4

ShareP
oint workspace

[1]
, two face
-
to
-
face meetings, and a project wiki

[2].

The work of
the PWI team
was presented to ISO
TC 184/SC 4

at its meeting in Rotterdam in November 2009

[3]
.

This document is the report of the PWI. It has been derived from the technical content
developed

on
the project wiki, and from the comments made at the first r
eview in Rotterdam.

The name Industrial Data Integrated Ontologies and Models (IDIOM), was suggested by the

PWI team in
Rotterdam, and met with approval. It is used to refer to the proposed future SC

4 architecture within
this document.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



v

0

Introd
uction

0.1

Basis of the approach

Industrial Data Integrated Ontologies and Models (IDIOM) is
an

architecture for the representation and
exchange of industrial data using technologies, methodologies and approaches that are current industry
best practice. IDIOM

has been developed by experts from s
tandards
-
making bodies

but its use is not
restricted to standards.

Since 2004, the US National Institute of Standards and Technology (NIST) has hosted an Ontology
Summit as part of their general advocacy designed to bri
ng ontology science and engineering into the
mainstream. The 2009 the topic was Toward Ontology
-
Based Standards and the following quote from
the resulting summit provides important background to the effort.

Ontologies represent the best efforts of the tec
hnical community to unambiguously
capture the definitions and interrelationships of concepts in a variety of domains.
Standards
-

specifically information standards
-

are intended to provide unambiguous
specifications of information, for the purpose of err
or
-
free access and exchange. If the
standards community is indeed serious about specifying such information
unambiguously to the best of its ability, then the use of ontologies as the vehicle for
such specifications is the logical choice.

[4]

IDIOM has imp
lemented the recommendation of the Ontology Summit 2009 and has put ontologies
specified using logic
-
based languages at the centre of the approach.

The development of IDIOM has also recognised the breadth of data specifications that exist within ISO,
Objec
t Management Group (
OMG
)
,
Organization for the Advancement of Structured Information
Standards (
OASIS
)
, the World Wide Web Consortium (W3C)

and other standardization bodies. These
specifications include dictionaries and thesauri, process models, web servi
ces models, data models and
model mappings, views and transforms of various kinds. All these standardization deliverables have
their place within IDIOM.

0.2

Components of IDIOM

IDIOM

consists of three parts
:

1.

information technology (IT)

f
ramework of software t
echnologies and tools;

2.

methodologies, policies and guidelines for the activities of people using the tools;

3.

framework of core concepts.

Although related, these parts can evolve independently.

The initial development work on IDIOM has concentrated on the
I
T f
ramework
, because the other two
parts rely upon it.

NOTE The IT
f
ramework and the methodologies, policies and guidelines can be regarded as the architecture within
which industrial data standards are developed, whereas the framework of core concepts is
standardized industrial
data. However the core concepts within ISO 10303
-
41
,

Fundamentals of product description and support

[5
]
,

and
ISO 15926
-
2
,

Data model

[6]
can equally be regarded as part of an architecture.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



vi

The IT
f
ramework specifies the set of technologies used to support the various components of the
approach. The framework is intended to be flexible and to be extended as new technologies become
available. A figure showing the various components of the architectu
re and examples of what might be
created and related is shown in
Figure
1
.


Figure
1

-

High level IT
F
ramework

As shown in th
e high level IT
f
ramework diagram, the ontologies are a core component upon which the
process models, data models and service models depend. The meaning of data within these models is
defined by reference to the ontologies. The ontologies identify and ma
ke precise statements about
things defined by natural language in dictionaries and thesauri, technical specifications and reference
manuals.

Each component of the IT
f
ramework includes models with different levels of abstraction. Within the
same component
, one technology may be used for abstract models, and another for models
that

are
directly implementable.

EXAMPLE Within the data modelling component, we may have abstract models defined using
the Unified
Modeling Language (
UML
) [7]

or EXPRESS
[8
]
and directly implementable models defined using
eXtensible Markup
Lanugage

(
XML
)

Schema

[9]
.

0.3

The approach to change

For each component of the
IT f
ramework
, an initial set of technologies is recommended. It is expected
that the recommended set will change
as new technologies mature, and old technologies fall out of use.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



vii

NOTE Although some of the IT
f
ramework components are called models
, they also include the various
implementation technologies or language bindings for each kind of model. In recommending
specific technologies
for the initial version of IDIOM, the following assertions provide a background to the recommendations.



When industry organizations and standards bodies develop ontologies, the language used more than any
other is
the Web Ontology Lan
guage (
OWL
) [10]
.



When industry organizations and standards bodies develop process models, the languages used more than
any other are UML and
the Business Process Modeling Notation (
BPMN
) [11]
.



When industry organizations and standards bodies develop service models, the languages used more than any
are UML, a profile of UML
corresponding to

the Web Service Definition Language (
WSDL
) [12]
, and WSDL.



When industry organizations and standards bodies

development data models, the languages used more than
any other are UML, EXPRESS and XML Schema.

The goal of IDIOM is to
document
industry best practices

for industrial data,

and at the same time to
attempt
to
put them on a firmer foundation.
K
ey
to

achieving this

goal is
the recognition that best
practices change. Therefore
this document
proposes

IDIOM in the beginning
, not as it will always be.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



1

1

The IDIOM IT
f
ramework

1.1

Overview

Components of the IT
f
ramework are
:



n
atural
l
anguage
d
ictiona
ries
;



o
ntologies
;



p
rocess
m
odels
;



d
ata
m
odels
;



s
ervice
m
odels
;




m
appings and
t
races.

These components are
described in detail
in
separate sections
.

NOTE
Although some of the IT f
ramework components
have the word model in their title, the components

also
include the various implementation technologies or language bindings for each kind of model.

Each component of the IT
f
ramework includes models
at different

levels of abstraction.

Some
technologies are used in the specification of more abstract mode
ls and some provide declarations of
elements that are directly implementable.


For each component a set of technologies
is

recommended,
with the full expectation that over time that set will be expanded as technologies mature and as users of
the architectu
re gain experience.

The following figures show some of the levels of abstraction and some
of the initial technology recommendations.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



2


Figure
2

-

IT
f
ramework
-

s
econd
l
evel
of d
etail


Figure
3

-

IT
f
rame
work

-

detail for
m
apping and
t
race

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



3

1.2

Relationship with other parts of IDIOM

The
m
ethodologies,
p
olicies and
g
uidelines
part of IDIOM
will
specif
y

how people define concepts within
the
IT f
ramework.

This part of IDIOM will include:



Methods for managing the standardization lifecycle when using a particular technology. This will
encompass
the appropriate level of granularity for maintenance and the way in which audit trail
and status data is recorded.

EXAMPLE 1 A managed item may be:



a single statement;



a single object with a set of statements about it;



a
n ontology

schema as a whole

consisting of many objects
.

EXAMPLE 2 A managed item may be reviewed and revised as part of the traditional ISO publication process for a
new edition of
a “paper” standard. A managed item may be reviewed and revised as part of

a standard published
as a data
base.



Guidelines for the naming of items in standards, whether classes or properties in an ontology, or
entities or attributes in a data model.

The
f
ra
mework of
core c
oncepts
part of IDIOM will be

created using
a

technology
specified by the

IT
f
ramework
by people f
ollowing the
m
ethodologies,
p
olicies and
g
uidelines.

The f
ramework of
core c
oncepts
will consist of small ontologies
that

can be used as needed

in
the
different standards

developed by ISO
TC 184/SC 4
.


Such

tested ontologies
will

be suitable for
use

in
knowledge engineering activities in industry and in standards
development
activities
by

other
organizations.

NOTE For those

with a backgro
und in ontology development, a framework of core concepts might sound like an
upper ontology, but this is not necessarily the intent. The framework may contain core concepts for asset
mana
gement, which could be seen as
an upper ontology
.

Th
e framework may also contain the ontology for
quantities and units of measure, which is currently bei
ng developed by the OASIS

Quantities and Units of Measure
Ontol
ogy Standard (QUOMOS) technical committee

[13
]
, which is not an upper ontology
.

The developm
ent of framework of core concepts will not determine the form of the IT framework and
methodologies, policies and guidelines parts of IDIOM.
Instead i
t is expected tha
t the content of the
framework of core concepts will emerge as standards based upon IDIO
M are developed
.

1.3

Relation
ship with

the OMG Model Driven Architecture
®

The OMG Model Driven Architecture
®

(MDA)

[14
]

is an approach aim
ed

at solving problems

similar to

those driving
the
development

of IDIOM
.

Many of the component models and mappings
within the
IDIOM
IT Framework

are equivalent to parts of the

OMG MDA
.

In many cases, the OMG MDA
technology is the initial choice for
the
IDIOM

IT f
ramework
.

However, the IDIOM approach
allows

more loosely
-
coupled information technologies
. IDIOM allows t
he
use of l
anguages for which there is no
Meta
-
Object Facility (MOF)

[15
]
.

A

second key distinction is that
IDIOM is an ontology
-
centric approach

that
puts

semantics at its core rather than mode
l
ling languages

and the MOF
.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



4

2

Natural
l
anguage
d
ictionaries

2.1

The role of
natural language dictionaries

The natural language dictionaries component of the
IT f
ramework

is about
information
that

is
represented using natural language, and

is

intended to be understood by people.

The vast majority of
things within an in
dustrial data ontology or model have a definition that relies entirely, or in part
, upon
natural language. V
ery few things are completely defined using a formal language.

NOTE 1 The term
natural language dictionaries

is used
with a
broad

meaning

and enco
mpasses bo
th terminologies
and thesauri
.

In the past, natural language text definitions for things in an ontology or schema have been provided by:



annotation inc
luded within a computer processa
ble representation of
the

ontology or schema,
which can be extr
acted and presented to people by a computer, but which cannot be understood
by a computer;



a separate document, intended to be read by people, which accompanies a computer processable
representation of
the

ontology or schema.

Many natural language text def
initions are published in sources
that

can be normatively referenced,
such as other standards and technical publications. IDIOM will provide computer navigable links from
things within ontologies and schemas to these original sources. This means that the
re will be no need to
extract natural language text from an original source, and to duplicate it as documentation of an
ontology or schema.

NOTE

2


This approach fits with devel
opment

of the ISO Concept Database [16
] that

is derived from the “Terms and
definitions” clauses of ISO standards. A thing within an ontology or schema can also be a concept in th
is data
base,
and can be d
efined by reference to the data
base.

There are very many natural language dictionaries,
most of

which are
developed

outside ISO TC

184/SC

4.

Hence t
his component of the
IT f
ramework

is

principally
realized
by a referencing mechanism.

2.2

Technolog
ies

for the representation of
natural language dictionaries

Most natural language dictionaries are developed outside ISO
TC 184/SC 4
. Therefore it is not
appropriate for IDIOM to specify technologies. The IDIOM
IT f
ramework

will interface with any
dictionary whatever its form of representation.

NOTE 1 Natural la
nguage dictionaries created
within

ISO
TC 184/SC 4

already exist in many different formats,
including:



terms and definitions clauses of standards;



the
dict
ionary capability of ISO 13584
,

Parts library

[17
];



the
dict
ionary capability of ISO 22745
,

Open
technical dictionaries and t
heir application to master data
[18
];




the
spreadsheet

format defined
within

ISO 15826
-
6
,

Methodology for the development and validation of
reference data

[19
]
;



RDF

[20
]
,

with RDF and Dublin Core

[21
]

annotation.

NOTE 2
Simpl
e
Knowledge Organization System (SKOS)

[22
]
is a technology for representing a natural language
dictionary developed within W3C.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



5

2.3

N
atural language dictionaries

within IDIOM

A natural language dictionary may be created as part of
the
IDIOM
architecture
to contain concepts
that

are not specific to any particular industrial or engineering domain. Such a n
atural
l
anguage
d
ictionary
may contain

of definitions for

concepts related to the core areas of expertise

within ISO TC

184/SC

4,
such as:



product data c
onfiguration management
;



product structure
;



data quality
;



the maintenance of standard data items published as a data base.

An ISO TC

184/
SC

4 requirement for a concept does not mean that
ISO TC

184/
SC

4

should necessarily
standardize
the concept

itself.

I
t is an

underlying assumption of the
IDIOM
approach

that there is a

preference for
concepts
that

have been standardized outside
ISO TC

184/
SC

4

by domain experts
.

EXAMPLE

ISO 1087
,
Terminology work


Vocabulary

[
23
]
contains terms and definitions for terminology work.

ISO 9000
,
Quality management systems

[
24
]
contains terms and definitions for quality.

ISO/IEC 2382
,
Industrial
automation systems and integration


Open technical dictionaries and their application to
master data

[
25
]
contains terms and definitions for information technology
.

2.4

Natural language dictionaries for industrial and engineering domains

Most natural language dictionaries for industrial and engineering domains are developed outside ISO
TC
184/SC 4
.

EXAMPLE

1
The
International Electrotechnical Vocabulary (
IEV
)

[26
]
is an authoritative natural language dictionary
for electro
-
technology.

A few natural language dictionaries for industrial and engineering domains are developed within ISO
TC
184/SC 4
.

EXAMPLE

2 ISO 15926
-
4
,

I
nitial referen
ce data

[27
]
provides a dictionary for the process industry
.

A natural language dictionary for an industrial or engineering domain may be developed in accordance
with the IDIOM architecture, but is not usually part of

the IDIOM architecture.

A natural language dictionary
can

associate several different terms with the same concept, or several
different concepts with the same term. In either case
, the IDIOM reference mechanism associates a
thing in an ontology or model
with a concept defined in a natural language dictionary.

EXAMPLE


There are 21 entries for the term "signal" in the IEV.

2.5

A catalogue of natural language dictionaries

In order to provide a
two
-
way
referencing mechanism
between
natural language dictionaries

and the
ontologies and schemas
that

rely upon them
, IDIOM will contain
a catalogue of natural language
dictionaries.

For
each

natural language dictionary, the
catalogue
will

include the following information:



name

of the natural language dictionary
;

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



6



Uniform Resource Identifier (
URI
)

of

the natural language dictionary
;



bibliographic information about the

natural language dictionary
, where
the natural language
dictionary is a publication
;



ontologies and models that have been developed using IDIOM and th
at make reference to the
natural language dictionary.

The reference between a thing in an ontology or model and a concept defined within a na
tural language
dictionary is a trace
.
The way in which traces are represented and processed is discussed in
clause

7
.

2.6

Use cases

for

natural language dictionaries

U
se cases for the trace between a thing in an

ontology or model and a concept in a natural language
dictionary are as follows:

1.

A computer program processes instances of an e
ntity in a data model
, where the en
tity h
as a trace
to a concept in a natural language dictionary.

In the natural language dictionary, t
he concept is defined by text
that

can be presented to a person
by
the

computer program.

A
n expert in the industry or engineer
ing

domain can read
the definition
to understand the significance of the entity.

In the natural language dictionary, a

term is assigned to the concept
that

can be presented by a
computer program to refer to the entity.

Where the natural language dictionary is a multi
-
lingual
thesaurus, the computer program can
present definitions and terms in a chosen language.

2.

An engineer selects a concept using its term and definition from the natural language dictionaries in
the IDIOM catalogue
.


A computer program can
use
the traces
made f
rom ontologies and models to

the concept

to list the

relevant ontologies and models
.

3

Ontologies

3.1

Use of ontologies in the
IDIOM a
rchitecture

Within the IDIOM a
rchitecture:



an ontology provides the formal vocabulary used to make statements

about an industria
l domain. It can also contain statements about individuals

within the domain



a data model specifies
the

information
that
shall be recorded for a particular activity carried out
within an industrial domain.

NOTE
1

The term ontology

has many meanin
gs and us
es. Within the IDIOM a
r
chitecture the use of the term
ontology

means what i
n some discussions

is called a strong ontology [28
]
. A strong ontology is one that is
specified using logic
-
based languag
es. These are contrasted with weak ontologies

such as dat
a models.

The reco
mmended technologies for IDIOM o
ntologies are:



W3C OWL, including all species of OWL 1

[9
]

and OWL 2

[29
]
,

as

the primary recommendation; and

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



7



ISO/IEC 24707
,

Common Logic

[
30
]
,

as

a secondary recommendation.

NOTE
2


There

is nothing comparable to the o
ntology component of the IDIOM a
rchitectur
e within the current ISO
10303 a
rchitecture.

Both
the
application reference model (
ARM
)

and
the
application interpreted model (
AIM
)
are
data models.

Industrial data can be represente
d using either an ontology or a data model.

The differences between
these approaches are discussed
in
3.4
.

IDIOM ontologies are intended to be the
principal source of semantics for other models within the
architecture (e.g. data models). Hence wherever possible the semantics of an entity or attribute in a
data model is defined by a computer navigable reference to
an item

in an ontology.

NOTE 2 In the

current EXPRESS data models within ISO 10303, the semantics of entities and attributes
are

defined
by person readable text.

NOTE 3 There may be some parts of a data model
that are data structures
for which there is not a corresponding
thing in a formal mo
del. The nature of these data structures will be defined by person readable text within the
data model.

Because an ontology does not specify which information shall be recorded for a particular activity, it
can

be simpler than corresponding data model
s
.

3.2

Knowledge about an industrial domain

3.2.1

Language

OWL

is the recommended technology for the representation of
knowledge about an industrial domain.

This recommendation includes the use of all sub
-
languages and versions of OWL

[9, 29]
.

NOTE The task of repres
enting knowledge about an industrial domain using OWL is similar to the task of
representing knowledge about an industrial domain using EXPRESS, but there are significant differences.

Consider the following knowledge about
widgets
:



Each widget has exactly
one manufacturer.



Each widget has zero or one data of last services (it will be one if it has had at least one service and
zero if it has not yet had a service.

It is natural to represent this knowledge about widgets using
an
EXPRESS
schema, which is prese
nted
using EXPRESS
-
G
in
Figure
4
.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



8


Figure
4

-

Representing knowledge using EXPRESS

However EXPRESS is designed to specify the data that shal
l be recorded, rather than knowledge about the real
world. If
an application required data about the manufacturer of a widget only in certain circumstances, then the
EXPRESS model becomes as shown in
Figure
5
.


Figure
5

-

Representing
required data

using EXPRESS

The rule capability of EXPRESS can enforce the recording of the manufacture
r

when this is required. The
EXPRES
S model in
Figure
5

does not say that some widgets do not have a manufacturer.

The knowledge that
every Widget has exactly one manufacturer

can be repr
esented in OWL

and

presented as
in the

RDF diagram in

Figure
6
.


Figure
6

-

A simple approach to representing knowledge using OWL

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



9

Unfortunately this is not sufficient to completely

represent the knowledge about W
idget, because the
cardinality of an OWL
FunctionalProperty

is 0 or 1. An additional restriction
is required to state

that
each W
idget has exactly one manufacturer, as shown in
Figure
7
.


Figure
7

-

Simple

OWL with a cardinality constraint

Figure
7

records the knowledge that a widget has exactly on
e

manufacturer, but is complicated and not
as intuitive
as
Figure
6
.

3.2.2

Visual representation

A visual representation can communicate OWL ontologies across a wider community including
traditional STEP developers and users, and can fill the role of EXPRESS
-
G.


In

order to provide a visual
representation of OWL,
the recommended technologies are
:



representation as a Resource Description Framework (
RDF
) [20]

diagram
;

or



representation as UML using the UML Profile for
OWL defined within the OMG Ontology Definition
Met
amodel (ODM)

specification

[31]
.

NOTE An RDF diagram is defined in clause 3.1 of Resource Description Framework (RDF): Concepts and abstract
syntax (
http://www.w3.org/TR/rdf
-
concep
ts/#section
-
data
-
model
). There is no more to the definition of an RDF
diagram than
a collection of triples (subject, predicate, object) where each triple is represented as a node
-
arc
-
node
link
.

EXAMPLE 1
A v
isual

representation

of OWL as RDF is

shown as
Figure
6

and
Figure
7
.

EXAMPLE 2 A visual representation

of OWL as UML is shown

as

Figure
8
.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



10



Figure
8

-

Simple UML representation of OWL

It is not clear from the OMG ODM specification what cardinality to specify for the
manufacturer

relationship. UML allows a cardinality of 1 to any. However OWL only supports cardinality of [0, 1] to
any. This is
why the superclass thing with

exactly one manufacturer

needs to be defined in OWL.

The ambiguity about whether a data model represents knowledge about the real world or a statement
about the data that shall be recorded exists for UML as for EXPRESS.

3.2.3

Beyond

OWL

The capabilities of OWL are
a proper subset of those of
Common Logic

(CL
). In the initial set of
technology recommendations for IDIOM, OWL is the primary recommendation of this report because:



OWL
has better software support than

CL;



more ontologies a
re being developed in OWL than CL;



no important requirements have yet been identified
that

are outside the capabilities of OWL but
supported by CL.

There is some knowledge about an industrial domain
that

is most easily expressed as rules.


A rule
language such as
Semantic Web Rule Language

(SWRL
)
[32
]
can be used in conjunction with OWL.

SWRL
is not yet a W3C Recommendation, but the W3C Rule Interchange Format (RIF)

[33
]

upon which
it
is
likely to be based is nearing Recommendation.

Addit
ionally, many data validation constraints

can be
implemented against OWL
ontologies using the W3C
SPARQL Protocol and RDF Query Language
(
SPARQL
)

[34
]

language, which is a full W3C Recommendation.

SPARQL is analogous to SQL for
rel
ational databases. Many
EXPRESS

rules are simply queries against the data population so it may be
that SPARQL covers most of the
SC 4

requirements for EXPRESS constraint checking.

EXAMPLE It may be known that for thing X, the value of property “a” is 1.5 times the value of prope
rty “b”. This is
difficult to state using OWL, but easy to state using a rule.

3.3

Management of knowledge about an industrial domain

It is recommended that knowledge about an industrial domain be held
as

small independent modules

resulting in a suite of modu
lar ontologies. The
lessons learned from the
ISO 10303 STEP modular
a
rchitecture
will

provide guidance in this development.

EXAMPLE

1

If domain A can be divided into sub
-
domains A1 and A2, then:



knowledge

about A1 is (contained in) ontology O1 and knowledge about A2 is (contained in) ontology O2;



knowledge about A is (contained in) ontology O that consists only of the imported ontologies O1 and O2.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



1
1

Using OWL it is not possible to import part of an ontology
.

This is one motivation for keeping ontologies
relatively small.

OWL does, however, provide good capability with respect to extending and integrating
modular ontologies.

EXAMPLE
In the EXPRESS language it is not possible for:



a schema to add a su
percla
ss to an entity defined

elsewhere;



a schema to add an attribute to an entity define
d

elsewhere.

To get around this difficulty, subtypes are often created in EXPRESS. However, in OWL these restrictions do not
exist. The Open World Assumption upon which OW
L is based means it is expected that other ontologies will add
to existing things in the current ontology.

NOTE

A thin
g

defined in one ontology may have statements made about it in other ontologies.

It is possible that:



the team that defined the thing be
lieves that a statement made in another ontology is untrue;



different ontologies make conflicting statements about the thing.

This is not a difficulty.

A team developing an ontolo
gy need only import an ontology

if it believes that all the
statements made
within it are true.

There are alternative approaches in some areas of ontology development
that

may be equally valid.

EXAMPLE 3 There are alternative 3D and 4D approaches to the representation of change with time.

In order to make the definitions of thin
gs as widely usable as possible, it may be best to include
definitions within ontologies
that

are as agnostic as possible about philosophical issues.

The ontology
that contains the definition can then be used alongside another ontology that contains the p
hilosophy.

This approach is called a “lattice of theories”

[35
].

3.4

Implementation of an ontology

3.4.1

Implementation without using a data model

Statements about individuals can be made
using

an ontology
directly
without the use of a schema
.

EXAMPLE

Using

the ontology shown in
Figure
6

it is possible to state that:



Widget serial number 98
-
1234 was manu
factured by Fred Bloggs and Co.

This statement

is represented using the ontology
shown in the RDF diagram
in
Figure
9
.



Figure
9

-

Simple

i
nstances

of classes and properties in an ontology

The use of an ontology without a formal schema is appropriate in a data war
ehouse application
,

which is
intended to support a wide range of different industrial activities.

A data warehouse does not have
constraints upon the data that shall be recorded
,

because different industrial activities will have
AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



12

different constraints on t
he data that shall be recorded.

A data warehouse

is also intended to store
work
-
in
-
progress
,

which may violate constraints.

An ontology on its own is not sufficient to define data flows between activities, whether by file exchange
or web services.

Within

the IDIOM a
rchitecture data models are recommended for this purpose.

In the future, technologies
that apply integrity constraints

to information recorded in OWL may be an
alternative to data models.

NOTE 1 This is an active area of research. An important

paper
is “
Opening, closing worlds
-

on integrity contraints

is Evren Siri
n, Michael Smith, Evan Wallace

[36
].


NOTE 2 Integrity contraints are applied
to the ISO 15926 data model by templates
, as defined within ISO 15926
-
7
,
Base templates

[37
]
.

3.4.2

Integrat
ion

of generic and specific knowledge

Where an ontology is represented using OWL, the language does not enforce a separation between
:



generic knowledge about an industrial domain defined within the standard; and



specific knowledge about an industrial domai
n provided by a user of the standard.

A traditional data model imposes a separation

because
:



generic knowledge is recorded by entities within the data model;



specific knowledge is recorded by instances of entities within the data model.

EXAMPLE The generic

knowledge provided by a standard might be:



some widgets are marine widgets;



there are different types of marine widget.

The specific knowledge provided by a user of the standard might be:



offshore widget is a type of marine widget;



widget
serial number
98
-
1234

is an offshore widget.

A data model in EXPRESS
that

records the generic knowledge and which allows the specific knowledge
to be recorded is shown
in
Figure
1
0
.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



13



Figure
1
0

-

EXPRESS model with reference data

In
Figure
1
0

the yellow bo
xes at the top are entities in the data model, and the pink boxes at the bottom
are instances of the entities. The entity Marine widget type has the instance Offshore widget. Th
is
instance can be regarded as
re
ference data

defined by the user of the stan
dard.

The OWL representation of the same information is shown
in

Figure
11
.



Figure
11

-

OWL with reference data

In
Figure
11

the yellow ovals are th
ings defined within the standard and the pink ovals at the bottom are things
defined by the user of the standard.

All these things are represented using the same syntax and could be held
within the same
set of
RDF
statements
.


In practice the statements m
ade within the standard will
usually
be held in
one
set
and the statements made by the user will
usually
be held in another.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



14

3.5

Ontology and dictionary of definitions

Many of the things defined within an ontology developed using IDIOM will be already defined
by natural
language text within a dictionary.

The preference of IDIOM is to normatively reference the

dictionary
,
where possible
. If
a natural language text definition is
standardized

within
SC 4
,
then
it is recommended
that the definition be included within a dictionary of
SC 4

terminology.

EXAMPLE

An
ontology develope
d by
SC 4

may include the class product
. This class may have the natural language
text definition "thing or substance produced by a nat
ural or artificial process". An ontology may contain the
statements
:



product corresponds
to product

as d
efined within

dictionary X

(this is annotation);



product is a class (this is a statement that can be processed by a logic engine).

In this case, X woul
d be a dictionary of terms defined within
SC 4
.

NOTE A dictionary term may have more than one ontological interpretation. In the example above, the statement
"product is a class" is added by the ontology to the dictionary definition. This statement is p
robably not
controversial, but in other cases there may be different views. By separating the dictionary definition from the
ontology, different ontological interpretations for the same natural language definition are possible.

4

Process
m
odels

4.1

The r
ole of
process model
s

A process model is the specification of the types of processes or activities
that

are carried out within an
engineering domain.
A process model

has two roles

within IDIOM
:



the data required by the processes define the scope for the

ontologies and data models;



the actions on the data required by the processes define the scope for the service models.

An example process model is shown
in
Figure
12
.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



15


Figure
12

-

Example p
rocess

m
odel

NOTE
An application activity model (AAM) within an ISO 10303 application p
rotocol

(AP)

is a p
rocess model
.
This
model is used to
explain the scope of an application p
rotocol to a reader.
I
ntegration Definition for Function
Modeling
(
IDEF0
)

[38]
is effective
for

this purpose, and the AAM can be the most easily u
nderstood pa
rt of an ISO
10303 AP
.

Two problems wit
h an ISO 10303
AAM

are:



it is only informative;



type of
activit
y

and information flow cannot be referenced from a data model.

There are cases in which a reference to a type of activity or information flow is required.
In particular it
may be useful to mak
e a reference when recording the provenance of information.

T
he recommended technologies for specifying
process or activity models include
:



p
lain
UML for the specification of processes at an abstract level
;



BPMN

[11
]
for
the
specification

of processes at a more detailed level;



a
ny of the industry accepted technologies for
specifying the execution or simulation of processes

including:
Business Process Execution Language (
BPEL
)

[40
]

and

Process Specification Language
(
PSL
)

[41
]
.

More inform
ation about UML and BPMN process models is given in the following sections.

4.2

UML process m
odels

UML has support for process m
odels through the use of the following diagrams:



a
ctivity diagram



s
tate machine diagram



s
equence diagram

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



16



u
se case diagram



c
lass diag
ram

UML

[7
]

is standardized

in the OMG.

Additionally, work has been ongoing to provide a logic
-
based
underpinning for a subset of UML that is executable. This activity is known as Semantics of a
Foundational Subset for Executable UML Models (FUML)
[42
]
.

4.3

BPMN process m
odels

BPMN is a process
-
oriented mode
l
ling language
. In BPMN a p
rocess is “
any activity performed within a
company or organization

[
...
]
depicted as a network of Flow Objects, which are a set of other activities
and
the
controls that sequence

them” [10
]
.

BPMN is standardized in conjunction with the OMG
.
Version 1.2 is complete and Version
2.0 is at Beta 1
release status.

BPMN is used to model

processes that act on the world (e.g. create or consume data. These have two
main purposes:



scoping

and providing context for data
-
related standards;



standardizing processes, or adding detail to standard processes from other organizations. These
may be directly executable via bindings to execution engines (e.g. BPMN → BPEL).

5

Data m
odels

5.1

The role of data

models

The role of the data m
odels component of the
IT f
ramework

is to support processes such as interchange,
integration, archiving and preservation, service content specification and database structure
specification.

When related to o
ntologies to speci
fy the semantics of the concepts that are mode
l
led in
a data model, the data model can provide additional c
onstraints not possible in the o
ntology as the data
model is scoped for use in a particular process
-

which is often used base the basis for the scop
e of the
data model during its development.


Data models related to o
ntologies a
re also capable of providing a
closed world view of the knowledge in the open world ontology

for some purpose.

The data m
odels component includes implementation technology
-
inde
pendent or abstract data
mode
l
ling languages such as UML and EXPRESS.


It also includes abstract data models that are then tied
to one or more implementation language or binding such as XML Schema

[12
]
.


An example of a simple
UML data model diagram is sho
wn in
Figure
13
.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



17


Figure
13

-

Simple example UML data m
odel

Bindings are typically mappings to various file formats, such as text and XML files and including mode
l
-
driven approaches

such as
ISO 10303
-
28
,

XML representations of EXPRESS schemas and data, using XML
schemas
[43
]
.


However, a model
-
driven approach to bindin
gs is not a requirement on all data m
odels.


For example, UML class diagram(s) with definitional

text that help descr
ibe a hand
crafted XML Schema
is also a possible approach to standardizing a data model for data exchange.

In the IDIOM a
rchitecture the recommend
ed technologies for specifying data m
odels are:



UML Static Class Diagrams, both as normative specifications and

as informative specifications used
to document XML
-
related schema language forms. In OMG

Model Driven Architecture

terms, use
UML for the Platform Independent Models
;



EXPRESS and EXPRESS
-
G

(but

largely as part of the migration strategy for brin
g
ing existing EXPRESS
models into the new architecture,
and possibly
not
for use in the long term);



XML
-
related schema languages (e.g
.

XML Schema, Schematron

[44]
, Relax NG

[45]
)
.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



18

A secondary recommendation is that a UML Profile for EXPRESS be utilized.

A
draft UML Profile for
EXPRESS is in

development through the NIST Engineering Enterprise Integration project.

NOTE
1

For EXPRESS schemas, all the 10303
-
20s series parts are applicable.

NOTE
2

EXPRESS
is particularly effective in applications for which the
re are complicated data structures, especially
geometry, and for which there are complicated instant
i
ation constraints
.

For these applications EXPRESS may
continue to be used alongside UML for many years.

5.2

Relation

to the STEP data m
o
del a
rchitecture

There

are several possible relati
onships between the variety of data models possible in the IT framework
and the STEP ARM, mapping
specification
, AIM, integrated r
esources, ISO 10303
-
20s series architecture.


Some possible
relationships are described here just
to
illustrate what is possible;

they are
not
intended
as a recommendation.

One view is that a data m
odel for exchange purposes can play the role of AIM in the architecture while
the r
ole of the ARM is played by an o
ntology.

Another view is that an XML Sche
ma for exchange purposes can play the combined role of AIM and 20s
series part while the role of the ARM is played by a UML data model linked to a UML service model that
also uses the XML Schema as the basis for its service content.

Given the generic natur
e of the technical content of the current suite of STEP module ARMs, another
view is that a set of modules
plays the role of modular ARM, m
apping

specification
, AIM, etc. and the
modular ARM EXP
RESS concepts are traced to an o
ntology that specifies their industry semantics.

The
o
ntology in this case plays the role of an ARM in the pre
-
modular STEP architecture.

6

Service m
odels

The role of the service m
odels component is to be the standard specifications of software services ma
d
e
available by an application or server.

These often support a process model and have a
n ontology

or data
model defining their content.


Models of services and their relationships such as choreography or
orchestration are also considered aspects of this c
omponent of the architecture.

A service model is defined as follows:

a model of the mechanisms that enable access to one or more capabilities, where the
access is provided using a prescribed interface and is exercised consistent with
constraints and polici
es as specified by the service description. A service is provided by
an entity


the service provider


for use by others, but the eventual consumers of the
service may not be known to the service provider and may demonstrate uses of the
service beyond the

scope originally conceived by the provider

[
46
]
.

NOTE The IDIOM a
rchitecture is not limited to SOA
-
style services even though that definition appears here
-

the
definition is general enough to cover other approaches.

In t
he IDIOM a
rchitecture the
recommended technologies for specifying services are:



OMG UML for the specification of software services at an abstract level;



OMG Service
-
Oriented Architecture Modeling Language (S
oaML
)

[
47
]
for the specification of
software services at an abstract level;

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



19



a
ny of the industry accepted technologies for detailed service implementation including WSDL,
SOAP

[48]

and

Representational State Transfer (REST)

[49
]
services.

The following are the elements of an IDIOM services standard:



abstract specification of the s
ervice (required);



abstract specification of data that is input to or output to service calls (required);



specified bindings (required);



rules for generating bindings (optional).

The abstract service specification shall include a graphical presentation in
UML and a human
-
readable
textual description.

7

Mappings and traces

7.1

The role of mapping and traces

The role of the mappings and t
races component is to be the mechanism by which m
odels, including
references to natural language d
ictionaries, and model elements

in the various components of the
framework are related.

The distinction between a mapping and a trace is as follows:

mapping
:

This is a specification of the relationship between two formats for the representation of data,
that enables the transformation
of data from one format to the other.

trace
: This is a statement about the relationship between the semantics of
terms

within different
models. A t
race
can be a
weaker form of relation
and can require human interpretation. However it
is a requirement t
hat traces be
computer
-
navigable.

EXAMPLE 1 Languages suppo
rting m
appings include the OMG Query/View/Transform
(QVT)
language

[50
]
, ISO
EXPRESS
-
X
[51
]
and W3C
eXtensible Stylesheet Language Transformations (
XSLT
) [52
]
.

EXAMPLE 2 Examples of t
races include

the W3C OWL/RDFS
seeAlso

annotation property, the Dublin Core
isReferencedBy

term, and the
Semantic Annotations for Web Service Definition Language

(
SAWSDL
) [53]

modelReference

XML attribute
.

T
he initial recommendations for mapping and t
race are shown in
Figure
14
.


AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



20


Figure
14

-

Mapping and t
race

7.2

Trace

7.2.1

Mechanisms

A trace within a model adds value to that model by providing either a computer
processable definition
of a term in the model or a computer navigable link to human interpretable information about a term in
the model.
In order to allow
the best possible use of traces, it is intend to specify them where possible
using the native techno
logy
for each type of

model.

So, for example for o
ntologies written using the
W3C OWL language an approach native to the OWL language and its related tools is prefe
r
r
ed
.

7.2.2

OWL mechanisms

The link from an ontology element to a model element or term in a natural language dictionary
can be

specified as OWL annotation using the following annotation properties
:



The Dublin Core
source

property
can

be used to trace to “
A related resource from whi
ch the
described resource is derived
.”

The URI for this annotation property is
http://purl.org/dc/terms/source



The RDF
seeAlso

property shall be used to trace a more generic relationship with no additional
meaning.

There are two approaches to t
he link fro
m a data model element to
an

ontology:



a simple markup embedded in an annotation of the data model element that points to the
ontology element on which the data element is based.


This is embedded using the mechanisms
specified elsewhere in this section, a
ccording to the syntax of the data model language.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



21



a forma
l semantic mapping

between the ontology and the data schema expressed in a formal
language, and suitable for use by mediation tooling or test
i
ng tooling or other tooling. This is in a
separate file,

which is
not referenced directly in data element annotations.

7.2.3

UML mechanisms

The UML trace capability can be used for traces between elements in UML and UML Profiles. These,
however, are part of the model not annotations of the model elements.

For traces from UML elements
to elements or terms not in a UML model, a comment representing the Dublin Core
source

property
can
be used to represent the trace. The comment
is

of the form:

dcterms:source <value>

where

dcterms:source = whitepace + 'dcterms:
source' + whitespace

<value> = trace link + whitespace

and
is contained within the model element
.

Any processing of the comment will treat <value> as the
trace link value removing any leading and trailing whitespace.

7.2.4

EXPRESS

mechanisms

For traces from EXP
RESS elements to anything else, an EXPRESS remark tag representing the Dublin Core
source

property
can

be used to represent the trace.


The remark tag
is

of the form:

(*"Schema.Entity(.Attribute) dcterms:source <value> *)

where

dcterms:source = whitepace +

'dcterms:source' + whitespace

(*"Schema.Entity(.Attribute)

= start of the remark tag

<value> = trace link + whitespace

*)

= end of the remark tag.

and
is part of

the EXPRESS model element.

Any processing of the comment will treat <value> as the
trace lin
k value removing any leading and trailing whitespace.

7.2.5

XML mechanisms

For traces in general XML documents,
SAWSDL

modelReference

and the XML
attribute

can be used
.

7.3

Mappings


7.3.1

General

The subject of mappings is compl
icated
,

and mappings are often difficult to standardize.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



22

7.3.2

EXPRESS

mappings

When two EXPRESS schemas are involved
,

the EXPRESS
-
X language can be
used
.

W
ith the
standardization of the m
etamodel of EXPRESS in the OMG

[54]
, the

OMG Query/View/Transform
language
can

also be
used
.

7.3.3

UML/MOF
mappings

When two UML/MOF
-
based models are involved, the OMG Query/View/Transform language can be
used
.

QVT is a very generic mapping language.

7.3.4

XML mappings

XSLT is the XML
-
based transformation language.

Under the
IDIOM
architecture,
standards can make use
of XSLT for mapping between two XML documents.

7.3.5

RDF/OWL mappings

The SPARQL query language includes a
CONSTRUCT

capability that allows the creation of data based on
existing data.

This approach can be used to specify m
appings between anything represented as RDF.

The flexibility of the OWL language to import ontologies and relate them using
subClassOf
,
sameAs
,
equivalentClass

and other capabilities actually make OWL itself a mapping language suitable for some
use cases.

NOTE The mapping, integration or alignment of ontologies is a major research area, and software tools for this
have been developed.
These tools can be used to define the relationship between different ontologies, and
therefore also between different dat
a models which are linked to different ontologies.

8

Migration p
aths

8.1

ISO 10303

migration p
ath

If as par
t of a project using the IDIOM a
rchitecture, the ISO 10303 series of standards contains reusable
technical content, the project may determine the best appr
oach is to migrate that technical content to
fit better under the new architecture. Several approaches can be useful, depending on the kind of
project underway. Some of the possible scenarios are outlined here:



migrating

elements of one or more ISO 10303 standards to form the core ontology for a set of
related standards, and



alignment of an existing ISO 10303 standard with new standards developed under the new
architecture.

8.1.1

Migrating ISO 10303 schemas to new architecture

It is not expected that an existing AP AIM, implemented ARM or conformance class schema can be
automatically converted into an ontology using a structural mapping tool. However, as an initial step in
the process it may be useful to convert the EXPRESS to O
WL, or perhaps to UML where the UML Profile
for OWL can be applied. The NIST Engineering Enterprise Integration project has made a set of tools
available for that purpose. Of course, it's also possible to
handcraft

OWL while using the ISO 10303
Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



23

standard(s)

as a source of information requirements, rather than by converting EXPRESS to OWL
automatically.

Note that if significant portions of the 10303 data models are migrated to the new architecture, many of
the problems in the existing 10303 data models can be

addressed. The best of the IR, AIM,
application
interpreted construct (
AIC
)

and ARM schemas can be migrated and the ISO 10303 strict upward
compatibility requirement does not apply. Restructuring the data models is possible even if it's decided
to maintai
n the results of the migration as EXPRESS schemas so that EXPRESS
-
X can be used to specify
an interoperability mapping. Equivalent UML and EXPRESS data models could be made available to
support both suites of
modelling

tools depending on project requiremen
ts. For example, relating UML
classes to UML service specifications in one tool is simpler than relating elements of a UML service
model and an EXPRESS data model.

The following steps are representative of the kinds of things this an ISO 10303 migration sh
ould
consider:

1.

select the EXPRESS schema(s) and/or subset of EXPRESS schema(s) to be migrated
;

2.

make any necessary or desired improvements in the EXPRESS schemas
;

3.

specify an EXPRESS
-
X mapping from the new to the legacy schemas
;

4.

convert

the improved EXPRESS schema(s) to UML for the purpose of supporting UML
-
driven data
exchange and/or the definition of related UML process models or UML service models
;

5.

convert the improved EXPRESS schema(s) to OWL as the first step in restructuring them a
s
ontologies that fit into the new architecture core ontology approach
;

6.

develo
p, align and document the core o
ntology concepts starting from the EXPRESS to OWL starter
set of concepts
;

7.

if the AP

is one for which libraries of reference d
ata exi
sting, consid
er including that reference d
ata,
perhaps directly as
may be possible for OASIS Prod
uct Life Cycle Support (
PLCS
) [55] reference data
as OWL

as part of the o
ntology concepts of interest
;

8.

develop any necessary natural language t
erm definitions for the
SC 4

natural language d
ictionary
;

9.

develop related UML service models, as required,
with reference to the migrated o
ntology concepts
as their semantics
;

10.

develop related UML process models, as required,
with reference to the migrated o
ntology concepts
as their se
mantics
;

11.

document and standardize the necessary artefacts from the previous steps
.

Under this kind of scenario, it is up to
SC 4

and its members to decide whether/when to continue to
confirm or to retire the existing ISO 10303 standard(s). For example,
SC
4

might retire a standard and
state that the new standards supersede then
-

perhaps while also stating that the EXPRESS
-
X mapping
provides interoperability for existing implementations of the retired standard with the new one, if
industry requires it.
SC 4

might also simply make recommendations that new implementations be based
on the new standard or might simply say nothing and continue to confirm both the legacy and new
standards as they might be aimed at different communities of interest.

8.1.2

Aligning an exi
sting ISO 10303 standard with new
SC 4

standards

It is assumed there will be cases where existing ISO 10303 standards are in place, with good industry
acceptance, and a project is put in place to use

the IDIOM a
rchitecture to add inter
-
related standards.
F
or example, to add Service Models based on the ISO 10303 AP as was done with ISO 10303
-
214
,
Automotive design

[
56
]
and the OMG
Product Lifecycle Management (
PLM
)

Services standard

[57]
.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



24

While

it might not be required of a
ll projects that use the IDIOM a
rch
itecture, the best practices
approach is to at least create a simple set of Ontology concepts based on the existing ISO 10303 AP that
can be referen
ced for semantics from the new service m
odels. This allows additional sta
ndards coming
later, a related p
roc
ess

m
odel for example, to be better aligned with the existin
g ISO 10303 AP and the
related service m
odels. Depending on the d
iscipline and whether existing natural language d
ictionaries
exist, it might also be useful for the project to create content in th
e I
DIOM architecture natural language
d
iction
ary supporting traces from the o
nto
logy and other models to those natural language t
erms. This
also provides a better basis for future work in related standards inside and outside
SC 4
.

The following steps are r
epresentative of the kinds of things this an ISO 10303 alignment should
consider:

1.

clearly identify select the EXPRESS schema(s) and/or subset of EXPRESS schema(s) that
are part of the alignment scope
;

2.

depending on the choice of technology for the content o
f th
e s
ervices being standards,
make any necessary or desired impr
ovements in the EXPRESS schemas;

3.

depending on the choice of tec
hnology for the content of the s
ervices being standards,
generate equivalent UML models from the relevant EXPRESS and make any
necessary or
desired improvements
;

4.

depending on the choice of tec
hnology for the content of the s
ervices being standards,
generate or hand craft XML Schemas based on the UML or EXPRESS and make any
necessary or desired improvements
;

5.

depending on the choice

of tec
hnology for the content of the s
ervices being standard,
convert the improved EXPRESS schema(s) to UML for the purpose of supporting the
definition of related UML process models or UML service models
;

6.

convert the improved EXPRESS schema(s) to OWL as
the first step in restructuring them as
ontologies that fit into the new architecture core ontology approach
;

7.

develo
p, align and document the core o
ntology concepts starting from the EXPRESS to
OWL starter set of concepts
;

8.

develop any necessary natural l
an
guag
e term definitions for the
SC 4 natural l
anguage
di
ctionary
;

9.

develop related UML service models or process models, as required,
with reference to the
migrated o
ntology concepts as their semantics
;

10.

document an
d standardize the necessary arte
facts from t
he previous steps
.


Under this kind of scenario,
SC 4

continues to confirm the existing ISO 10303 standards as valid so
existing implementations can continue to be ISO
-
conforming tools. In fact, the
new standard likely
contains a normative r
eference to the

existing standard.

8.2

ISO 15
926 migration p
ath

The approach to relating ISO 15926 and sta
ndards created using the IDIOM a
rchitecture must handle a
very different set of scenarios from that described for ISO 10303
.
The term m
igration

is used loosely
here; do
not read too much into the use of that word
.

ISO 15926 is intended to be a target for data aggregation, rather than a source of data. As such, part of
the approach that goes without being explicitly stated is that the current Extract/Transform/Load (ETL)
a
pproaches in use for ISO 15926 data warehouse applications should be applicable in scenarios where
users want to load data based in a standard using the new architecture in
to their warehouses. The
IDIOM a
rchitecture technologies are widespread, so in fact
the ETL processes may be simpler than those
necessary for data based on an ISO 10303 AP.

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



25

There are two obvious areas where
the relationship between IDIOM a
rchitecture standards and ISO
15926 needs to be analyzed in some detail, those are:



whether ISO 15926

core model concepts as OWL or Common Logic

can be made part of the IDIOM
architecture o
ntology core, and;



regardless of the answer to the

first question, how the IDIOM architecture o
ntology core can

reuse
or adapt existing 15926 reference d
ata, hopefully
available as OWL.

The first question ab
ove is related to the issue of upper ontologies
. There are several

open questions
related to the o
ntology component of the architectur
e and upper ontologies:



will or should it contain an
upper ontology;



might it be
ap
propriate that more than one
upper ontology be included
;



will or should the o
ntologies being developed be allowed or required

to relate to upper ontologies

from outside
SC 4

(e.g. Dolce
[58]
or Cyc
[59]
which are two of nine upper ontologies listed in
Wiki
pedia)
;



whether all projects will be required to use an upper ontology, assu
ming one or more exist, during
o
ntology development
;



whether projects should be left to grow their ontolog
ies

with abstractions being added as
discovered so that an upper ontology
emerges over time
;



whether should
SC 4

focus
o
n a library of reusable o
ntology patterns, rather than one or more
upper ontologies being the focus or requirement
.

It is clear that whether the ISO 15926 upper ontology i
s actually used as part of the o
ntology

component, the analysis approach that results from using ISO 15926 is a useful a
pproach as part of the
overall o
ntology development methodology.

9

Integrating
o
ther
s
tandards

Models developed outside
SC 4

can be use
d in the new architecture too (e
.g. the
Quantities and Units of
Measure ontology work initiated in OASIS). This activity is entirely based in the BIPM VIM standard

[60
]

and should address issues and be an improvement to
the value_with_
units capabilities migrated from
the ISO 10303 models. An ex
c
erpt of the
Quantities, Units Dimensions, Types (
QUDT
)

ontology
[61]
is
shown in
Figure
15
.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



26


Figure
15

-

Excerpt from QUDT ontology

It may a
lso be the case that an existing standard covers many of the requirements for an industrial data
need, but that it needs extension. With the IDIOM approach, extending existing standards is possible.
For example, the OMG standardized a Product Lifecycle Man
agement (PLM) set of Web services. For use
in Engineering Analysis Management (EAM), a project might specify the use of the PLM core services
a
nd then standardize additional s
ervices specific to EAM.

10

Conclusion

10.1

The

nature of the IDIOM architecture

The
development of the
IDIOM a
rchitecture and
its
IT f
ramework development
has two principal
motivations:

1.

In order to get more widespread use of its standards,
SC 4

needs to move towards more widespread
and modern modelling and implementation technologies and
methodologies.

2.

In order
provide a better product
for

its

customers
,
SC 4

needs to p
roduc
e

suites of inter
-
related standards
which are
based on
common definitions contained within a core set of
modular
ontolog
ies
.

It
i
s also recognized that the IT landscape changes constantly and so an approach that is flexible and
extensible
i
s a strong requirement.

No si
ngle component of the IDIOM IT f
ramework is
new in itself
.

The
value added by
IDIOM
is the use of
the components to
gether, and in the important role within the overall architecture of the natural
language dictionaries and the core set of modular ontologies
.

All the components of the

IDIOM
architecture are already supported by
industry
-
proven
software tools
.


IDIOM is
also intended to evolve
as new technologies are adopted within industry.

IDIOM is not intended to be the only architecture used within
SC 4
. The existing ISO 10303 architecture
will continue to exist for many years. However IDIOM provides:

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



27



an alternative

to, or an extension of, the ISO 10303 architecture that enables the introduction of
new components and modelling tools;



a way in which the ISO 15926 core ontology and reference data can be used within other parts of
ISO
TC 184/SC 4
;



a clearer
relationshi
p between the dictionary capabilities contained within ISO 13584 and ISO 22745
and the standard ontologies and data models developed by other parts of
SC 4

10.2

The next steps

There is still work to be done before the initial report of the

Future
SC 4

Architect
ure
PWI

can become a
document that governs the development of standards within ISO
TC 184/SC 4
. This work includes the
following:



A specification of how IDIOM components are included within the existing ISO 10303 module
document structure
.

NOTE
1

An

early use of IDIOM could be the reference to ontologies and natural language dictionaries from the
ARM of an ISO 10303 module.



Procedures for standardising natural language dictionaries and small ontologies derived from
existing ISO
TC 184/SC 4

standards.



Some initial content for the natural language dictionaries and small ontologies derived from
existing ISO
TC 184/SC 4

standards.

NOTE
2

This will set the style, validate the procedures, and be the basis for further extensions.



Definition of the

precise

s
emantics of a trace relationship from a schema to an ontology

and on to a
natural language dictionary.

NOTE
3

This is important because the new architecture envisages that the natural language text which is currently
associated with
an
entit
y

or

attribute

as documentation
of a schema is replaced by a trace to an item in an
ontology. The natural language text is then held as annotation of the item in the
ontolog
y

or in a

natural language
dictionar
y that

is referenced from the ontology
.

Hence an informal li
nk from an entity or attribute to its documentation is replaced by a formal and computer
navigable link to an item in an ontology

or to a natural language dictionary
.

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



28

Annex A
-

Abbreviations


AAM

Application Activity Model

AIC

Applicatio
n Interpreted Construct

AIM

Application Interpreted Model

AP

Application Protocol

ARM

Application Reference Model

BIPM

Bureau International des Poids et Mesures

BPEL

Business Process Execution Language


BPMN

Business Process Modeling Notation

CL

Common
Logic

EAM

Engineering Analysis Management

ETL

Extract/Transform/Load

FUML

Semantics of a Foundational Subset for Executable UML Models

IDEF0

I
ntegration Definition for Function Modeling

IDIOM

Industrial Data Integrated Ontologies and Models

IEC

Internatio
nal Electrotechnical Commission

IEV

International Electrotechnical Vocabulary

ISO

International Organization for Standardization

IT

Information Technology


MDA

Model Driven Architecture


MOF

Meta Object Facility

OASIS

Organization for the Advancement of St
ructured Information Standards

OMG

Object Management Group

OWL

Web Ontology Language

PLCS

Product Life Cycle Support

PLM

Product Lifecycle Management



PSL

Process Specification Language

PWI

Preliminary Work Item


QUDT

Quanitity Unit

QUOMOS

Quantities and
Units of Measure Ontology Standard

RDF

Resource Description Framework

REST


Representational State Transfer

RIF

Rule Interchange Format

SAWSDL

Semantic Annotations for Web Service Definition Language

SKOS

Simpl
e Knowledge Organization System

SOA

Service
-
Oritented Architecture

SoaML

Service
-
Oriented Architecture Modeling Language

SOAP

formerly stood for Simple Object Access Protocol, now just SOAP

SPARQL

SPARQL Protocol and RDF Query Language

SWRL

Semantic Web Rule Language

UML

Unified Modeling Language

UR
I

Uniform Resource Identifier

VIM

International Vocabulary of Metrology

WSDL

Web Service Definition Language

W3C

World Wide Web Consortium

XML

eXtensible Markup Language


Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



29

XSLT

eXtensible Stylesheet Language Transformations



AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



30

Bibliography


[1]

Future
SC 4

A
rchitecture

project website
.
http://sp.tc184
sc4.org/SC4Projects/
-
FutureSC4Arch/default.aspx

[2]

Future
SC 4

Architecture wiki.
http://futurearch.wikispaces.org

[3]

slides from Rotterdam

[4]

Ontology Summit 2009
Communiqué: Toward Ontology
-
based Standards,
v
ersion 1.1.1,

http://ontolog.cim3.net/cgi
-
bin/wiki.pl?OntologySummit2009_Communique#nid1WLI
,
2009.05.15

[5]

IS
O 10303
-
41,
Industrial automation systems and integration


Product data representation and
exchange
-


Part 41: Integrated generic resource: Fundamentals of product description and
support

[6]

I
SO 15926
-
2
, Industrial automation systems and integration


Integration of life
-
cycle data for
process plants including oil and ga
s production facilities


Part 2
:.
Data model


[7]

Unified Modeling Language™ (UML®). Available at
http://www.omg.org/spec/UML/

Unified
Modeling Language (UML), Version 2.2, Needham, Massachusetts : Object Management
Group, 2009
-
02
-
02 [cited 2009
-
08
-
31]. Available from World Wide Web:
<http://www.omg.org/technology/documents/formal/uml.htm/>.

[8]

I
SO 10303
-
11,
Industrial automation system
s and integration


Product data representation and
exchange


Part 11: Description methods: The EXPRESS language reference manual.

[9]

OWL Web Ontology Language Reference, W3C Recommendation, World Wide Web Consortium,
2004
-
02
-
10 [cited 2009
-
08
-
31].
Available from World Wide Web: <http://www.w3.org/TR/owl
-
ref/>.

[10]
Business Process Model and Notation (BPMN). Available at
http://www.omg.org/spec/BPMN/

[11]
Web Services Description Language (WSDL) 1.1, W3C

Note 15 March 2001. Available at
http://www.w3.org/TR/wsdl

[12]
XML Schema Part 1: Structures Second Edition, W3C Recommendation 28 October 2004. Available
at ttp://www.w3.org/TR/xmlschema
-
1/

[12a]
XML Schema Part

2: Datatypes Second Edition, W3C Recommendation 28 October 2004. Available
at
http://www.w3.org/TR/xmlschema
-
2/

[13] QUOMOS

[14]
OMG MDA Guide V1.0.1. Available at
http://www.omg.org/cgi
-
bin/doc?omg/03
-
06
-
01

[15]
OMG Meta Object Facility (MOF™) Core. Available at
http://www.omg.org/spec/MOF/

[16]
ISO Concept Database.
http://cdb.iso.org/

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



31

[17
]
ISO 13584 (all parts),
Industrial automation systems and integration
-



Parts library

[18
]
ISO 22745 (all parts), Industrial automation systems and integration


Open technical dictionaries
and their application to master data.

[19
] 15826
-
6 Methodology for the development and validation of reference data

[20]

RDF

Resource Description Framework (RDF): Concepts and abstract syntax
http://www.w3.org/TR/rdf
-
co
ncepts/#section
-
data
-
model
.


RDF/XML Syntax Specification (Revised), W3C Recommendation 10 February 2004. Available at
http://www.w3.org/TR/rdf
-
syntax
-
grammar/

[21
]
Dublin Core Metadata Element Set, Version 1.1. Available at
http://dublincore.org/documents/dces/

[22
] Simple Knowledge Organization System SKOS

[23
]
ISO 1087 (all parts), Terminology work


Vocabulary.

[24
]
ISO 9000, Quality management systems


Fundamentals and vocabulary.

[25
]
ISO/IEC 2382

(all parts), Information technology


Vocabulary.

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

[26
]

IEV, Electropedia

(also known as the "IEV Online"),
http://www.electropedia.org
.

[27
]
ISO 15926
-
4, Industrial automation systems and integration


Integration of life
-
cycle data for
process plants including oil and gas production

facilities


Part 4: Initial reference data.

[28
]

The Ontology Spectrum & Semantic Models, Dr. Leo Orbst
, MITRE

[29
]
OWL 2 Web Ontology Language, Structural Specification and Functional
-
Style Syntax, W3C
Recommendation 27 October 2009. Available at http:/
/www.w3.org/TR/owl2
-
syntax/

[30
]
ISO/IEC 24707
, Information technology

Common Logic (CL): a framework for a family of logic
-
based languages,
http://standards.iso.org/ittf/Pu
bliclyAvailableStandards/index.html

[31
]
ODM

[32]
S
WRL

[33
]
RIF Core Dialect

http://www.w3.org/TR/2009/CR
-
rif
-
core
-
20091001/

W3C Candidate
Recommendation


[34
]
SPARQL Query Language for RDF, W3C Recommendation 15 January 2008. Available at
http://www.w3.org/TR/rdf
-
sparql
-
query/

[35
]
SOWA, John
.

A Dynamic Theory of Ontology, Proceeding of the 2006

conference o
n Formal
Ontology in Information Systems
.

http://www.jfsowa.com/pubs/dynonto.htm
.

[36
]

Evren
SIRIN
, Michael
SMITH
, Evan
WALLACE
.

Opening, closing worlds
-

on integrity contraints
http://www.webont.org/owled/2008/papers/
-
owled2008eu_submission_30.pdf

AAMReport of the
Future ISO
TC 184/SC 4 Architecture

PWI



32

[37
]
Industrial automation systems and integration


Integration of life
-
cycle data for process plants including oil
and gas production facilities


Part 7: Implementation methods for the integration of distributed system
-


Template methodology

[38]
I
EEE Std 1320.1, Standard for Functional Modeling Languag
e


Syntax and Semantics for IDEF0, 1998.

[39] unused

[40
]
BPEL

[41
]

ISO 18629 (all parts),
Industrial automation systems and integration


Process specification
language
--

Part 1: Overview and basic principles

[42
]
FUML

[43
]
ISO 10303
-
28,
Industrial auto
mation systems and integration


Product data representation and
exchange


Part 28: Implementation methods: XML representations of EXPRESS schemas and data,
using XML schemas

[44] Schematron

[45] Relax NG

[46]

OASIS Reference Model for Service Oriented Architectures


[47] SoaML

[48] SOAP

[49] REST

[50] Meta
-
Object Facility
2.0 Query/View/Transformation (QVT). Available at
http://www.omg.org/spec/QVT/

[51]
ISO 10303
-
4
1, I
ndustrial automation systems and integration


Product data representation and
exchange


Part 14: Description methods: The EXPRESS
-
X language reference manual

[52] XSLT

[53]
Semantic Annotations for WSDL and XML Schema, W3C Recommendation 28 August 20
07.
Available at ttp://www.w3.org/TR/sawsdl/

[54] EXPRESS MM

[55]
ISO 10303
-
239,
Industrial automation systems and integration


Product data representation and
exchange


Part 239: Application protocol: Product life cycle support

[56]
Industrial automatio
n systems and integration


Product data representation and exchange


Part
214: Application protocol: Core data for automotive mechanical design processes

[57] OMG PLM Services

[58] Dolce

Report of the
Future ISO
TC 184/SC 4 Architecture

PWI



33

[59] Cyc

[60] BIPM VIM

[61] QUDT


BUTEK, Russell, "Which style of W
SDL should I use?",
http://www.ibm.com/developerworks/webservices/library/ws
-
whichwsdl/
.


KIM, Kyoung
-
Yun, CHIN, Seongah, KWON, Ohbyung, and ELLIS, R Darin, "Ontology
-
based

modeling
and integration of morphological characteristics of assembly joints for network
-
based collaborative
assembly design", Artificial Intelligence for Engineering Design, Analysis and Manufacturing (2009),
23, 71

88