[wg11-owl] Re: Paper: Criticism of the STEP ApplicationModule approach

[David Price]

Hi David L,

I saw on a WG3/WG12 agenda that you will explain how OWL and 15926 can
address the issues raised in the paper.

I think the larger problem is really organizational or perhaps
architectural. For example, if you gave each separate AP/modules team 15926
as OWL and told them to go off and model you'd get completely different
results for the same scope. Who then would force them to harmonize across
multiple domains and who's going to fund them to do so? Harmonization costs
money and time both of which are ususally short in an AP project.

Do you have associated organizational or procedural changes in mind? Can
this really work in SC4 as it's constitued today? Could this be done better
outside SC4 (e.g. in OMG or OASIS)?

Just asking questions...

Cheers,
David P

-----Original Message-----
From: wg11-owl-bounces at steptools.com [mailto:wg11-owl-bounces at steptools.com]
On Behalf Of David Leal
Sent: 07 June 2005 16:39
To: wg11-owl at steptools.com; Tore.R.Christiansen at dnv.com;
matthew.west at shell.com
Subject: Re: [wg11-owl] Re: Paper: Criticism of the STEP ApplicationModule
approach


Dear Ed and other WG11ers,

The paper is attached.

You say:
>But as to the SC4 definitions, they are what they are, and the EXPRESS
models we have reflect the depth of our mutual understanding.  If we need to
discard most of the existing definitions in order to get the EXPRESS models
to make any sense, there isn't much value to the STEP models, and whether we
convert them to ontologies" is irrelevant to their uselessness.
>
>I don't believe that. My purpose is to get these models turned into
"ontologies" of the OWL kind, *so that* we can evaluate both the utility of
the EXPRESS models as an "engineering ontology" and the utility of DLs of
the OWL kind to engineering applications.

Unfortunately I do believe that - the negative assessment is true in many
cases. The STEP methodology can fix-up ill-defined concepts by specific
usages within an AP, but as soon as the concepts are converted into an
ontology, the failings are exposed and need to be fixed. The creation of an
'ontology' of ill-defined concepts is a complete waste of time.

Best regards,
David

At 10:39 07/06/2005 -0400, you wrote:
>David Leal wrote:
>
>> Lothar's paper is very welcome, however it is more than a 'criticism 
>> of the STEP application module approach'. Lothar's paper shows the 
>> problems that are caused by the vague definitions of the concepts at 
>> the heart of STEP - product, product category, 
>> product_definition_formation, and
product_definition.
>
>I do not know the paper to which David's email refers.
>Can someone point me to this paper?
>
>> If we are to do anything with OWL, then we need concepts with precise 
>> definitions. Lothar lists some concepts/terms that we should be able 
>> to define, and suggests subclass-superclass relationships between 
>> them. What about starting by defining these concepts, and creating a 
>> useful engineering ontology.
>
>I think the idea of creating an engineering ontology is an excellent
>academic research activity, and I might hope that one or two 
>universities are already engaged in it.
>
>But as to the SC4 definitions, they are what they are, and the EXPRESS
>models we have reflect the depth of our mutual understanding.  If we 
>need to discard most of the existing definitions in order to get the 
>EXPRESS models to make any sense, there isn't much value to the STEP 
>models, and whether we convert them to "ontologies" is irrelevant to 
>their uselessness.
>
>I don't believe that.  My purpose is to get these models turned into
>"ontologies" of the OWL kind, *so that* we can evaluate both the utility 
>of the EXPRESS models as an "engineering ontology" and the utility of 
>DLs of the OWL kind to engineering applications.
>
>-Ed
>
>P.S. High-level ontological classes, like Product, are deliberately
>large and have very few critical properties.  The question is whether 
>the EXPRESS models reflect the critical properties.  And I agree that in 
>some cases, they don't!  But the value to SC4 is to identify those 
>cases, not to start over.
>
>-- 
>Edward J. Barkmeyer                        Email: edbark at nist.gov
>National Institute of Standards & Technology
>Manufacturing Systems Integration Division
>100 Bureau Drive, Stop 8264                Tel: +1 301-975-3528
>Gaithersburg, MD 20899-8264                FAX: +1 301-975-4694
>
>"The opinions expressed above do not reflect consensus of NIST,
>  and have not been reviewed by any Government authority."
>
>