From david.price at eurostep.com  Tue Sep  7 08:04:02 2004
From: david.price at eurostep.com (David Price)
Date: Tue Sep  7 07:16:53 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
Message-ID: <001a01c494d2$c4010260$2101a8c0@esukpc20>

All,

 

I have a general question for you folks. As you know, I've been playing with
UML/XMI for a long time and trying to relate it to EXPRESS. All the work
I've done with EXPRESS is based on the XML representation of EXPRESS used by
STEPMod, not the Part 28 Edition 1 XML DTD. This has happened because the
Part 28 DTD required every expression to be broken into bits which seemed
pointless to most people - and also meant reconstructing EXPRESS from the
XML using XSLT would be very difficult.

 

So, my question is . Are people generally comfortable with using the STEPMod
XML representation of EXPRESS as the de facto standard for open-source STEP
work?  

 

I'm asking because I've been thinking that we could steal some of the ideas
from UML/XMI and apply them to EXPRESS/STEP by extending the STEPMod DTD for
EXPRESS. A simple example is that we could implement the UML tagged value or
stereotype concepts as a way of marking up EXPRESS in a way that's similar
to what the OMG Model Driven Architecture people are trying to do as part of
their model-to-model mappings (e.g. to control the mapping from EXPRESS into
SQL DDL). Perhaps we could even agree between ourselves on some of the
specific stereotypes/tagged values for interoperability between the various
open-source efforts.

 

Cheers,

David

 

Phone +44 207 704 0499

Mobile +44 7788 561308

8 Highbury Place, Flat 5

London, UK

N5 1QZ

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://step.nasa.gov/pipermail/step-os/attachments/20040907/ae41f776/attachment.html
From lubell at nist.gov  Tue Sep  7 10:54:26 2004
From: lubell at nist.gov (Joshua Lubell)
Date: Tue Sep  7 10:07:12 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <001a01c494d2$c4010260$2101a8c0@esukpc20>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>
Message-ID: <413DCBA2.8000806@nist.gov>

I think using the stepmod DTD as a de facto standard is a great idea. I 
also think a specification document to accompany the DTD would be useful 
to would-be software developers. I would be willing to help write such a 
specification document.

Josh

David Price wrote:

> All,
>
> I have a general question for you folks. As you know, I?ve been 
> playing with UML/XMI for a long time and trying to relate it to 
> EXPRESS. All the work I?ve done with EXPRESS is based on the XML 
> representation of EXPRESS used by STEPMod, not the Part 28 Edition 1 
> XML DTD. This has happened because the Part 28 DTD required every 
> expression to be broken into bits which seemed pointless to most 
> people - and also meant reconstructing EXPRESS from the XML using XSLT 
> would be very difficult.
>
> So, my question is ? Are people generally comfortable with using the 
> STEPMod XML representation of EXPRESS as the de facto standard for 
> open-source STEP work?
>
> I?m asking because I?ve been thinking that we could steal some of the 
> ideas from UML/XMI and apply them to EXPRESS/STEP by extending the 
> STEPMod DTD for EXPRESS. A simple example is that we could implement 
> the UML tagged value or stereotype concepts as a way of marking up 
> EXPRESS in a way that?s similar to what the OMG Model Driven 
> Architecture people are trying to do as part of their model-to-model 
> mappings (e.g. to control the mapping from EXPRESS into SQL DDL). 
> Perhaps we could even agree between ourselves on some of the specific 
> stereotypes/tagged values for interoperability between the various 
> open-source efforts.
>
> Cheers,
>
> David
>
> Phone +44 207 704 0499
>
> Mobile +44 7788 561308
>
> 8 Highbury Place, Flat 5
>
> London, UK
>
> N5 1QZ
>
>------------------------------------------------------------------------
>
>_______________________________________________
>step-os mailing list
>step-os@step.nasa.gov
>http://step.nasa.gov/mailman/listinfo/step-os
>  
>

-- 
Josh Lubell
National Institute of Standards and Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263
Gaithersburg MD 20899-8263, USA
Phone: 1-301-975-3563, Email: lubell@nist.gov

From david.price at eurostep.com  Tue Sep  7 11:04:18 2004
From: david.price at eurostep.com (David Price)
Date: Tue Sep  7 10:17:02 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413DCBA2.8000806@nist.gov>
Message-ID: <001201c494eb$f2f9f770$2101a8c0@esukpc20>

Josh,

If you're willing to write such a document, I'll put it and the DTD on the
www.exff.org site and keep it synched with STEPMod ... and I'm sure others
would put it on their Web sites as well. If you want to publish the document
at NIST instead of exff, that's fine as long as it's got a URL.

I'm going to set up a server so the exff code can be executed over the Web.
As part of that, we'll provide access to the eep parser which can read
EXPRESS and generate the STEPMod-based XML. So, your documentation of the
DTD fits perfectly. 

I offer my help and be a reviewer of your documentation.

Thanks!
David

> -----Original Message-----
> From: step-os-bounces@ned.gsfc.nasa.gov [mailto:step-os-
> bounces@ned.gsfc.nasa.gov] On Behalf Of Joshua Lubell
> Sent: 07 September 2004 15:54
> To: STEP Open-Source
> Subject: Re: [step-os] Using STEPMod XML Representation of EXPRESS
> 
> I think using the stepmod DTD as a de facto standard is a great idea. I
> also think a specification document to accompany the DTD would be useful
> to would-be software developers. I would be willing to help write such a
> specification document.
> 
> Josh
> 
> David Price wrote:
> 
> > All,
> >
> > I have a general question for you folks. As you know, I've been
> > playing with UML/XMI for a long time and trying to relate it to
> > EXPRESS. All the work I've done with EXPRESS is based on the XML
> > representation of EXPRESS used by STEPMod, not the Part 28 Edition 1
> > XML DTD. This has happened because the Part 28 DTD required every
> > expression to be broken into bits which seemed pointless to most
> > people - and also meant reconstructing EXPRESS from the XML using XSLT
> > would be very difficult.
> >
> > So, my question is . Are people generally comfortable with using the
> > STEPMod XML representation of EXPRESS as the de facto standard for
> > open-source STEP work?
> >
> > I'm asking because I've been thinking that we could steal some of the
> > ideas from UML/XMI and apply them to EXPRESS/STEP by extending the
> > STEPMod DTD for EXPRESS. A simple example is that we could implement
> > the UML tagged value or stereotype concepts as a way of marking up
> > EXPRESS in a way that's similar to what the OMG Model Driven
> > Architecture people are trying to do as part of their model-to-model
> > mappings (e.g. to control the mapping from EXPRESS into SQL DDL).
> > Perhaps we could even agree between ourselves on some of the specific
> > stereotypes/tagged values for interoperability between the various
> > open-source efforts.
> >
> > Cheers,
> >
> > David
> >
> > Phone +44 207 704 0499
> >
> > Mobile +44 7788 561308
> >
> > 8 Highbury Place, Flat 5
> >
> > London, UK
> >
> > N5 1QZ
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >step-os mailing list
> >step-os@step.nasa.gov
> >http://step.nasa.gov/mailman/listinfo/step-os
> >
> >
> 
> 
> --
> Josh Lubell
> National Institute of Standards and Technology
> Manufacturing Systems Integration Division
> 100 Bureau Drive, Stop 8263
> Gaithersburg MD 20899-8263, USA
> Phone: 1-301-975-3563, Email: lubell@nist.gov
> 
> _______________________________________________
> step-os mailing list
> step-os@step.nasa.gov
> http://step.nasa.gov/mailman/listinfo/step-os

From edbark at nist.gov  Tue Sep  7 12:51:29 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Tue Sep  7 12:04:11 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413DCBA2.8000806@nist.gov>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>
	<413DCBA2.8000806@nist.gov>
Message-ID: <413DE711.5070307@nist.gov>

All,

The attached two emails represent a proposal for resolving a Part 28 
issue.

There was a ballot comment from Japan requesting Part 28 to provide a 
means for including "an XML representation of the EXPRESS schema" in 
addition to the "text" version currently supported.  At the Part 28 
Editing meeting we guessed that the request was for the feature that was 
in Part 28 v1.  Apparently that was wrong!  This email would have been a 
more useful ballot comment, but neither of these contributors thought to 
provide it in July, nor did either think to provide this recommendation 
to the editing meeting.  Now we are approaching DIS ballot, but there is 
still time for them to make up for their poor timing.

If Japan concurs, David and Josh, will you please write the text to use 
the STEPmod DTD, suitably rendered into XML Schema, to provide the 
resolution for ballot comment JP-5.  It goes in Clause 5.4 of Part 28. 
You can markup N229 or Heidi's latest draft.

Then you can actually make (a part of) an ISO standard that is "de 
facto", instead of a competitor.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."

--

Joshua Lubell wrote:

> I think using the stepmod DTD as a de facto standard is a great idea. I 
> also think a specification document to accompany the DTD would be useful 
> to would-be software developers. I would be willing to help write such a 
> specification document.
> 
> Josh
> 
> David Price wrote:
> 
>> All,
>>
>> I have a general question for you folks. As you know, I?ve been 
>> playing with UML/XMI for a long time and trying to relate it to 
>> EXPRESS. All the work I?ve done with EXPRESS is based on the XML 
>> representation of EXPRESS used by STEPMod, not the Part 28 Edition 1 
>> XML DTD. This has happened because the Part 28 DTD required every 
>> expression to be broken into bits which seemed pointless to most 
>> people - and also meant reconstructing EXPRESS from the XML using XSLT 
>> would be very difficult.
>>
>> So, my question is ? Are people generally comfortable with using the 
>> STEPMod XML representation of EXPRESS as the de facto standard for 
>> open-source STEP work?
>>
>> ...
>>
>> Cheers,
>>
>> David
>> _______________________________________________
>> step-os mailing list
>> step-os@step.nasa.gov
>> http://step.nasa.gov/mailman/listinfo/step-os

From lubell at nist.gov  Tue Sep  7 13:13:54 2004
From: lubell at nist.gov (Joshua Lubell)
Date: Tue Sep  7 12:26:37 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413DE711.5070307@nist.gov>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>	<413DCBA2.8000806@nist.gov>
	<413DE711.5070307@nist.gov>
Message-ID: <413DEC52.7070309@nist.gov>

But Ed, if the STEPmod spec were to be included in Part 28, then it 
would become the property of ISO. People would have to buy Part 28 from 
ISO in order to read the STEPmod spec. I would much rather see the 
STEPmod spec published independent of ISO so that it can be freely 
distrubuted. Otherwise, we're not likely to see much STEPmod-based 
implementation outside of those already active in SC4.

I think the way to go is to first publish the spec as a freely available 
technical report. It can then be adapted for Part 28 if SC4 so wishes. 
But ISO should not be the first venue in which it is published.

Josh

Ed Barkmeyer wrote:

> All,
>
> The attached two emails represent a proposal for resolving a Part 28 
> issue.
>
> There was a ballot comment from Japan requesting Part 28 to provide a 
> means for including "an XML representation of the EXPRESS schema" in 
> addition to the "text" version currently supported.  At the Part 28 
> Editing meeting we guessed that the request was for the feature that 
> was in Part 28 v1.  Apparently that was wrong!  This email would have 
> been a more useful ballot comment, but neither of these contributors 
> thought to provide it in July, nor did either think to provide this 
> recommendation to the editing meeting.  Now we are approaching DIS 
> ballot, but there is still time for them to make up for their poor 
> timing.
>
> If Japan concurs, David and Josh, will you please write the text to 
> use the STEPmod DTD, suitably rendered into XML Schema, to provide the 
> resolution for ballot comment JP-5.  It goes in Clause 5.4 of Part 28. 
> You can markup N229 or Heidi's latest draft.
>
> Then you can actually make (a part of) an ISO standard that is "de 
> facto", instead of a competitor.
>
> -Ed
>

-- 
Josh Lubell
National Institute of Standards and Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263
Gaithersburg MD 20899-8263, USA
Phone: 1-301-975-3563, Email: lubell@nist.gov

From edbark at nist.gov  Tue Sep  7 14:21:49 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Tue Sep  7 13:34:32 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <001a01c494d2$c4010260$2101a8c0@esukpc20>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>
Message-ID: <413DFC3D.9080309@nist.gov>

David Price wrote:

> [snip]
> So, my question is ? Are people generally comfortable with using the 
> STEPMod XML representation of EXPRESS as the de facto standard for 
> open-source STEP work? 

Couldn't care less, subject of a previous email.

> I?m asking because I?ve been thinking that we could steal some of the 
> ideas from UML/XMI and apply them to EXPRESS/STEP by extending the 
> STEPMod DTD for EXPRESS. A simple example is that we could implement the 
> UML tagged value or stereotype concepts as a way of marking up EXPRESS 
> in a way that?s similar to what the OMG Model Driven Architecture people 
> are trying to do as part of their model-to-model mappings (e.g. to 
> control the mapping from EXPRESS into SQL DDL). 

Or to XML schema, or to Java, to choose examples for which we already 
have SC4 standards.  Or to WSDL, or (to please JTC1/SC34) to RELAX NG, 
or to Schematron or to CAMS or to the XML modeling technology of the week.

> Perhaps we could even 
> agree between ourselves on some of the specific stereotypes/tagged 
> values for interoperability between the various open-source efforts.

Well...

First, stereotypes and tagged values are a feature of the UML language 
that is described in the language standard.  There are no corresponding 
features in EXPRESS.  I would think the logical choice would be to add 
those features as markups to the EXPRESS or EXPRESS-G languaages.

So what is David proposing here?  From an EXPRESS schema, you convert to 
a UML v2 meta-model representation using Part 25.  And then what?  Since 
you have a meta-model representation of the EXPRESS model, the OMG MDA 
idea is that you make a formal mapping to a representation using some 
other meta-model, presumably the meta-model for SQL or XML schema or 
Java or whatever.  That is pretty much what the 20-series standards do. 
  Of course, they don't do it using MOF meta-model formalisms, but that 
doesn't seem to be what David is proposing, either.

Of course, you can take the UMLv2 metamodel representation of a given 
EXPRESS schema, convert it to a UML static structure diagram, and mark 
up that diagram with the "refinement" stereotypes for the implementation 
language, thereby specifying the mapping using current UML technology.
Is that what David intends?  Then, when we talk about agreement on the 
"implementation" stereotypes, we are in fact talking about agreement on 
a weak metamodel for (the interesting elements of) the implementation 
language.  (The meta-model implied by the implementation stereotypes is 
"weak", because it contains the terms from the implementation language, 
but not their relationships or constraints.)

But I don't understand what the XML version of the EXPRESS schema would 
have to do with that.  Are we talking about devising a kind of 
stereotype feature for EXPRESS that tools will implement by modifying 
the XML representation of the EXPRESS schema?  Why not markup the 
EXPRESS language text, or the EXPRESS-G diagram?  In those cases, at 
least, the stereotyping will be easier to read and comprehend.  Or do we 
envisage a browser app that presents the EXPRESS model in yet another 
form (not EXPRESS text, not EXPRESS-G, not UML static structure), 
accepts the markups and creates the marked up XML?

I don't think the "implementation markup" idea is a bad one; I just 
don't understand it in this context.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From edbark at nist.gov  Tue Sep  7 16:06:22 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Tue Sep  7 15:19:08 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413DEC52.7070309@nist.gov>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>	<413DCBA2.8000806@nist.gov>
	<413DE711.5070307@nist.gov> <413DEC52.7070309@nist.gov>
Message-ID: <413E14BE.1090204@nist.gov>

Joshua Lubell wrote:

> But Ed, if the STEPmod spec were to be included in Part 28, then it 
> would become the property of ISO. People would have to buy Part 28 from 
> ISO in order to read the STEPmod spec. 

How many people in the world should ever have to read the STEPmod spec 
for XML rendition of an EXPRESS schema?  About 7, I would guess, all of 
whom are no doubt NB experts participating in SC4.  (And they can get 
SC4 documents free from ISO.)

> I would much rather see the 
> STEPmod spec published independent of ISO so that it can be freely 
> distrubuted. Otherwise, we're not likely to see much STEPmod-based 
> implementation outside of those already active in SC4.

I'm not sure what this means, but I would hope that exchanging ISO 
copyrighted EXPRESS schemas in any form is a rare occurrence in STEP 
implementation.

> I think the way to go is to first publish the spec as a freely available 
> technical report. It can then be adapted for Part 28 if SC4 so wishes. 
> But ISO should not be the first venue in which it is published.

By this logic, we should certainly stop making standards in WG11, 
because people would have to buy them from ISO, instead of inventing 
their own and publishing technical reports online.  That certainly 
applies to Part 14, 25, and 27, which didn't need to be ISO standards, 
and to Part 28, on which there has never been consensus.  And this logic 
should apply to Part 25v2 and binary exchange of STEP data.  Indeed, any 
future 20-series spec should be a technical report in the open software 
community and not an ISO standard, so as to maximize its accessibility. 
  Right?

That the ISO publication control process interferes with adoption of ISO 
standards has been an issue in several ISO communities in the recent 
past.  But we can't solve that problem -- it is out of our scope.  Our 
scope is to support the SC4 standards community as constituted, warts 
and all.

My concern is that Part 28, an ISO project SC4 intended to serve this 
same community, is required to specify a mechanism for representing 
EXPRESS schemas in XML.  If David and Josh think the most useful 
representation is the STEPmod representation and others agree, then 
surely that should be the proposed standard.  In any case, STEPmod 
should not refuse to allow its representation to be the Standard 
representation and simultaneously suggest that it be the "de facto 
standard" in the STEP community, IN LIEU OF the ISO standard 
representation.  What does Josh suggest Part 28 should standardize? 
(It's a little late to vote No on the NWI.)

-Ed

P.S.  The NIST goal in this whole effort was to get SC4 to agree to 
*common* XML representations.  Et tu, Brute?

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From golux at comcast.net  Tue Sep  7 18:41:45 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Tue Sep  7 17:59:38 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413E14BE.1090204@nist.gov>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>	<413DCBA2.8000806@nist.gov>	<413DE711.5070307@nist.gov>
	<413DEC52.7070309@nist.gov> <413E14BE.1090204@nist.gov>
Message-ID: <413E3929.4070401@comcast.net>

Ed Barkmeyer wrote:

> I'm not sure what this means, but I would hope that exchanging ISO 
> copyrighted EXPRESS schemas in any form is a rare occurrence in STEP 
> implementation.

I thought the documents were copyrighted, not the schemas.
Is it not okay to freely distribute STEP schemas?

Steve
From golux at comcast.net  Tue Sep  7 18:43:33 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Tue Sep  7 18:01:24 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413E14BE.1090204@nist.gov>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>	<413DCBA2.8000806@nist.gov>	<413DE711.5070307@nist.gov>
	<413DEC52.7070309@nist.gov> <413E14BE.1090204@nist.gov>
Message-ID: <413E3995.8080902@comcast.net>

Ed Barkmeyer wrote:

> By this logic, we should certainly stop making standards in WG11, 
> because people would have to buy them from ISO, instead of inventing 
> their own and publishing technical reports online.

What, like the OMG does?  ;)
From david.price at eurostep.com  Tue Sep  7 19:07:35 2004
From: david.price at eurostep.com (David Price)
Date: Tue Sep  7 18:20:17 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413E3929.4070401@comcast.net>
Message-ID: <000001c4952f$76ad58d0$2101a8c0@esukpc20>

STEP EXPRESS schemas are freely available. It's the text explaining them
that's copyrighted.

DP

> -----Original Message-----
> From: step-os-bounces@ned.gsfc.nasa.gov [mailto:step-os-
> bounces@ned.gsfc.nasa.gov] On Behalf Of Stephen Waterbury
> Sent: 07 September 2004 23:42
> To: edbark@nist.gov; STEP Open-Source
> Subject: Re: [step-os] Using STEPMod XML Representation of EXPRESS
> 
> Ed Barkmeyer wrote:
> 
> > I'm not sure what this means, but I would hope that exchanging ISO
> > copyrighted EXPRESS schemas in any form is a rare occurrence in STEP
> > implementation.
> 
> I thought the documents were copyrighted, not the schemas.
> Is it not okay to freely distribute STEP schemas?
> 
> Steve
> _______________________________________________
> step-os mailing list
> step-os@step.nasa.gov
> http://step.nasa.gov/mailman/listinfo/step-os

From golux at comcast.net  Tue Sep  7 19:30:13 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Tue Sep  7 18:48:05 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <000001c4952f$76ad58d0$2101a8c0@esukpc20>
References: <000001c4952f$76ad58d0$2101a8c0@esukpc20>
Message-ID: <413E4485.5020603@comcast.net>

David Price wrote:
> STEP EXPRESS schemas are freely available. It's the text explaining them
> that's copyrighted.

Exactly what I thought.
From david.price at eurostep.com  Tue Sep  7 20:34:15 2004
From: david.price at eurostep.com (David Price)
Date: Tue Sep  7 19:46:56 2004
Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413E14BE.1090204@nist.gov>
Message-ID: <000001c4953b$91b60210$2101a8c0@esukpc20>

Ed and company,

To clarify, STEPMod is the modules publication infrastructure. As such, the
STEPMod DTD was based only on requirements for producing a documented schema
using XSLT. Requirements for any other use of EXPRESS (e.g. validating data
against EXPRESS rules or mapping to MathML) were not considered. I was
unaware of the Japanese ballot comment on Part 28 E2 and so can't comment on
their requirements. Adapting Part 28 E1 may be exactly what they want, or
they may need something else entirely.

The STEPMod DTD was not put through the ISO process because of the overhead
and delay involved and because it wasn't intended for use in Industrial Data
application scenarios - it just had to work for STEPMod, not be perfect. It
also seemed unnecessary to use ISO ballots to deal with the modules
publication infrastructure as any delay could mean a delay in getting an
AP/module approved. Personally, I doubt if the STEPMod developers are
convinced any benefits outweigh that risk, even today. One very practical
point is that I imagine putting the DTD through an SC4 ballot would result
in people wanting to "fix" bits they don't like and I am sure nobody who
funded STEPMod wants to fund changes to it based on the whims of a ballot
resolution workshop.

For the purpose of my particular open-source project, I've found the STEPMod
DTD sufficient. I was asking if others have had a similar experience. My use
of the term "de facto standard" seems to have raised concerns. Perhaps
"open-source implementers agreement" would have been more appropriate as I
intended on experimenting with adapting some UML concepts to EXPRESS and
sharing the code. 

Regardless of anything else that might happen, I think Josh volunteering to
work on a user guide to be made freely available on the Web is great.

Cheers,
David

> -----Original Message-----
> From: wg11-bounces@steptools.com [mailto:wg11-bounces@steptools.com] On
> Behalf Of Ed Barkmeyer
> Sent: 07 September 2004 21:06
> To: Joshua Lubell
> Cc: SC4 WG11; STEP Open-Source
> Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
> 
> Joshua Lubell wrote:
> 
> > But Ed, if the STEPmod spec were to be included in Part 28, then it
> > would become the property of ISO. People would have to buy Part 28 from
> > ISO in order to read the STEPmod spec.
> 
> How many people in the world should ever have to read the STEPmod spec
> for XML rendition of an EXPRESS schema?  About 7, I would guess, all of
> whom are no doubt NB experts participating in SC4.  (And they can get
> SC4 documents free from ISO.)
> 
> > I would much rather see the
> > STEPmod spec published independent of ISO so that it can be freely
> > distrubuted. Otherwise, we're not likely to see much STEPmod-based
> > implementation outside of those already active in SC4.
> 
> I'm not sure what this means, but I would hope that exchanging ISO
> copyrighted EXPRESS schemas in any form is a rare occurrence in STEP
> implementation.
> 
> > I think the way to go is to first publish the spec as a freely available
> > technical report. It can then be adapted for Part 28 if SC4 so wishes.
> > But ISO should not be the first venue in which it is published.
> 
> By this logic, we should certainly stop making standards in WG11,
> because people would have to buy them from ISO, instead of inventing
> their own and publishing technical reports online.  That certainly
> applies to Part 14, 25, and 27, which didn't need to be ISO standards,
> and to Part 28, on which there has never been consensus.  And this logic
> should apply to Part 25v2 and binary exchange of STEP data.  Indeed, any
> future 20-series spec should be a technical report in the open software
> community and not an ISO standard, so as to maximize its accessibility.
>   Right?
> 
> That the ISO publication control process interferes with adoption of ISO
> standards has been an issue in several ISO communities in the recent
> past.  But we can't solve that problem -- it is out of our scope.  Our
> scope is to support the SC4 standards community as constituted, warts
> and all.
> 
> My concern is that Part 28, an ISO project SC4 intended to serve this
> same community, is required to specify a mechanism for representing
> EXPRESS schemas in XML.  If David and Josh think the most useful
> representation is the STEPmod representation and others agree, then
> surely that should be the proposed standard.  In any case, STEPmod
> should not refuse to allow its representation to be the Standard
> representation and simultaneously suggest that it be the "de facto
> standard" in the STEP community, IN LIEU OF the ISO standard
> representation.  What does Josh suggest Part 28 should standardize?
> (It's a little late to vote No on the NWI.)
> 
> -Ed
> 
> P.S.  The NIST goal in this whole effort was to get SC4 to agree to
> *common* XML representations.  Et tu, Brute?
> 
> --
> Edward J. Barkmeyer                        Email: edbark@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."
> _______________________________________________
> wg11 mailing list
> wg11@steptools.com
> http://lists.steptools.com/mailman/listinfo/wg11

From david.price at eurostep.com  Tue Sep  7 21:06:48 2004
From: david.price at eurostep.com (David Price)
Date: Tue Sep  7 20:19:31 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413DE711.5070307@nist.gov>
Message-ID: <000001c49540$1e34f850$2101a8c0@esukpc20>

All,

I forgot to respond to Ed's request:

> 
> If Japan concurs, David and Josh, will you please write the text to use
> the STEPmod DTD, suitably rendered into XML Schema, to provide the
> resolution for ballot comment JP-5.  It goes in Clause 5.4 of Part 28.
> You can markup N229 or Heidi's latest draft.
> 

As you may have gathered from my other email, I'm not yet convinced this is
a good idea so cannot agree to do this. Even if I was convinced, I just
don't have time to write text for Part 28 E2 to cover all this in the given
timeframe. 

I'm not sure what makes sense given the timeframe and that we haven't had
any discussion on this with the STEPMod developers. Adding the STEPMod DTD
as-is as an informative annex or referencing it from an informative
annex/note and making it available on SC4 Online with an SC4 N number might
be sufficient. As I said, I don't know what the requirements really are.

Cheers,
David

From michael.loeffler at gm.com  Wed Sep  8 01:02:47 2004
From: michael.loeffler at gm.com (michael.loeffler@gm.com)
Date: Wed Sep  8 00:41:40 2004
Subject: [step-os] Michael T Loeffler/US/GM/GMC is out of the office.
Message-ID: <OFA8509986.6D33FD3B-ON85256F09.001BB8D0-85256F09.001BB8D0@mail.gm.com>

I will be out of the office starting  09/03/2004 and will not return until
09/14/2004.

I will respond to your message when I return.

From golux at comcast.net  Wed Sep  8 03:25:22 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Wed Sep  8 02:43:12 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <001a01c494d2$c4010260$2101a8c0@esukpc20>
References: <001a01c494d2$c4010260$2101a8c0@esukpc20>
Message-ID: <413EB3E2.3050403@comcast.net>

David Price wrote:

> I have a general question for you folks. As you know, I?ve been playing 
> with UML/XMI for a long time and trying to relate it to EXPRESS.

Allow me to inject a little devil's advocacy:  I've always been
somewhat uncomfortable about mappings between EXPRESS and UML
that map EXPRESS entities directly to UML classes (for example),
since UML was originally designed for the purpose of modeling
executable software, and EXPRESS was designed to model sets of
information to be exchanged in files or stored in databases.
There is going to be *some* correlation, but I've always felt that
in general it's not a simple entity <-> class mapping (although
it *can* be in some special cases -- usually at ARM level) --
in general, it will be a more complex (AIM-to-ARM-like) mapping.

The designers of EXPRESS bent over backward to make life
easy for (non-programming) information modelers (not for
programmers), which is part of the source of the mismatch here.
STEP information modelers describe the data that is needed to
describe the contents of their domains, but they give
absolutely no thought (nor should they) to database design nor
to the design of any kind of executable code, so there's not
necessarily a high correlation between the structure of STEP AP
AIMs (and even ARMs in some cases) and how a database or
application code that stores and/or uses that data is best
structured.

EXPRESS and OWL are a much closer semantic match, although
it's pretty difficult to think of any STEP AP's AIM as an ontology
that anyone but a STEP expert would ever understand.  OTOH, in the
STEP world, the idea of exchanging ARM data is considered a heresy.
(Of course, heresies can sometimes be useful.  ;)

> All the 
> work I?ve done with EXPRESS is based on the XML representation of 
> EXPRESS used by STEPMod, not the Part 28 Edition 1 XML DTD. This has 
> happened because the Part 28 DTD required every expression to be broken 
> into bits which seemed pointless to most people - and also meant 
> reconstructing EXPRESS from the XML using XSLT would be very difficult.
> 
> So, my question is ? Are people generally comfortable with using the 
> STEPMod XML representation of EXPRESS as the de facto standard for 
> open-source STEP work? 

Sounds fine to me.  Perhaps you could send us a link to the
STEPMod EXPRESS DTD ...?

> I?m asking because I?ve been thinking that we could steal some of the 
> ideas from UML/XMI and apply them to EXPRESS/STEP by extending the 
> STEPMod DTD for EXPRESS. A simple example is that we could implement the 
> UML tagged value or stereotype concepts as a way of marking up EXPRESS 
> in a way that?s similar to what the OMG Model Driven Architecture people 
> are trying to do as part of their model-to-model mappings (e.g. to 
> control the mapping from EXPRESS into SQL DDL).

For model-to-model mapping, I'd like to use a more robust solution.
My current preference is EXPRESS-X (of which Express Engine, aka
Expresso, provides an open source implementation).  I believe that in
general, it's better to have an explicit, separable, managed mapping
than one that's embedded in mark-up of the models that are being mapped.

I find it hard to imagine a robust equivalent to EXPRESS-X being
implemented using UML tagged values and stereotypes.
Call me unimaginative.  :)

Steve
From david.price at eurostep.com  Wed Sep  8 06:15:33 2004
From: david.price at eurostep.com (David Price)
Date: Wed Sep  8 05:28:13 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413EB3E2.3050403@comcast.net>
Message-ID: <000001c4958c$c70489e0$2101a8c0@esukpc20>

Hi Steve,

On EXPRESS/UML, I disagree the are different - mainly because UML isn't what
it used to be, and that's a good thing. With MDA, UML Static Class diagrams
are equivalent to EXPRESS-G diagrams, just with slightly different
capabilities. That's how they're being used today in OMG - not only to model
software systems, but to define a data exchange capability.

On EXPRESS/OWL, I disagree the are more similar. I think UML Static Class
diagrams and EXPRESS are quite similar as they define a structure for data
exchange. However, I think an ontology is an entirely different beast. It's
very important to map things into OWL as they are in the real world in order
for the reasoners to work properly. For example, some UML Objects and
EXPRESS entity instances should map to classes in OWL (e.g. Product_category
instances should be subclasses of the Product Class). OWL properties being
first class concepts is also completely different from EXPRESS/UML.

On mappings, EXPRESS-X is fine, except that EXPRESS has to be both target
and source. It's useless for EXPRESS->SQL DDL or EXPRESS->OWL. That's why I
propose experimenting with stereotypes and tagged values. To be fair, the
stuff I'm doing is not probably less "mapping" and more "configuration".

Using the Product/Product_category example, if I stereotyped
Product_category "CLASS_OF_CLASS" then I would know its entity instances
should map to OWL Classes rather than OWL Individuals. If I added a tagged
value to Product_category saying "Superclass:Product" then I know where to
attached the OWL Classes in the hierarchy. I'd also need something to handle
the Product_category hierarchy, but hopefully you get the idea.

This isn't just an abstract discussion, I'm working on two mappings of
EXPRESS to OWL, one structural and one semantic. The semantic one requires
human intervention and stereotypes/tagged values applied to EXPRESS might
enable that intervention. If there were a more robust solution, I'd happily
adopt it.

On your preference for a mapping to be separate from the schemas, that's all
just presentation to me.

I'll put the STEPMod DTD on the exff Web site, it's not easy to find on
SourceForge. Here's the SourceForge link for now:

http://cvs.sourceforge.net/viewcvs.py/stepmod/stepmod/dtd/express_model.dtd?
rev=1.14&view=markup

Sorry for being so "disagreeable":-)
David

> -----Original Message-----
> From: step-os-bounces@ned.gsfc.nasa.gov [mailto:step-os-
> bounces@ned.gsfc.nasa.gov] On Behalf Of Stephen Waterbury
> Sent: 08 September 2004 08:25
> To: STEP Open-Source
> Subject: Re: [step-os] Using STEPMod XML Representation of EXPRESS
> 
> David Price wrote:
> 
> > I have a general question for you folks. As you know, I've been playing
> > with UML/XMI for a long time and trying to relate it to EXPRESS.
> 
> Allow me to inject a little devil's advocacy:  I've always been
> somewhat uncomfortable about mappings between EXPRESS and UML
> that map EXPRESS entities directly to UML classes (for example),
> since UML was originally designed for the purpose of modeling
> executable software, and EXPRESS was designed to model sets of
> information to be exchanged in files or stored in databases.
> There is going to be *some* correlation, but I've always felt that
> in general it's not a simple entity <-> class mapping (although
> it *can* be in some special cases -- usually at ARM level) --
> in general, it will be a more complex (AIM-to-ARM-like) mapping.
> 
> The designers of EXPRESS bent over backward to make life
> easy for (non-programming) information modelers (not for
> programmers), which is part of the source of the mismatch here.
> STEP information modelers describe the data that is needed to
> describe the contents of their domains, but they give
> absolutely no thought (nor should they) to database design nor
> to the design of any kind of executable code, so there's not
> necessarily a high correlation between the structure of STEP AP
> AIMs (and even ARMs in some cases) and how a database or
> application code that stores and/or uses that data is best
> structured.
> 
> EXPRESS and OWL are a much closer semantic match, although
> it's pretty difficult to think of any STEP AP's AIM as an ontology
> that anyone but a STEP expert would ever understand.  OTOH, in the
> STEP world, the idea of exchanging ARM data is considered a heresy.
> (Of course, heresies can sometimes be useful.  ;)
> 
> > All the
> > work I've done with EXPRESS is based on the XML representation of
> > EXPRESS used by STEPMod, not the Part 28 Edition 1 XML DTD. This has
> > happened because the Part 28 DTD required every expression to be broken
> > into bits which seemed pointless to most people - and also meant
> > reconstructing EXPRESS from the XML using XSLT would be very difficult.
> >
> > So, my question is . Are people generally comfortable with using the
> > STEPMod XML representation of EXPRESS as the de facto standard for
> > open-source STEP work?
> 
> Sounds fine to me.  Perhaps you could send us a link to the
> STEPMod EXPRESS DTD ...?
> 
> > I'm asking because I've been thinking that we could steal some of the
> > ideas from UML/XMI and apply them to EXPRESS/STEP by extending the
> > STEPMod DTD for EXPRESS. A simple example is that we could implement the
> > UML tagged value or stereotype concepts as a way of marking up EXPRESS
> > in a way that's similar to what the OMG Model Driven Architecture people
> > are trying to do as part of their model-to-model mappings (e.g. to
> > control the mapping from EXPRESS into SQL DDL).
> 
> For model-to-model mapping, I'd like to use a more robust solution.
> My current preference is EXPRESS-X (of which Express Engine, aka
> Expresso, provides an open source implementation).  I believe that in
> general, it's better to have an explicit, separable, managed mapping
> than one that's embedded in mark-up of the models that are being mapped.
> 
> I find it hard to imagine a robust equivalent to EXPRESS-X being
> implemented using UML tagged values and stereotypes.
> Call me unimaginative.  :)
> 
> Steve
> _______________________________________________
> step-os mailing list
> step-os@step.nasa.gov
> http://step.nasa.gov/mailman/listinfo/step-os

From edbark at nist.gov  Wed Sep  8 10:59:43 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Wed Sep  8 10:12:19 2004
Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <000001c4953b$91b60210$2101a8c0@esukpc20>
References: <000001c4953b$91b60210$2101a8c0@esukpc20>
Message-ID: <413F1E5F.2050403@nist.gov>

David Price wrote:

> To clarify, STEPMod is the modules publication infrastructure. As such, the
> STEPMod DTD was based only on requirements for producing a documented schema
> using XSLT. Requirements for any other use of EXPRESS (e.g. validating data
> against EXPRESS rules or mapping to MathML) were not considered. I was
> unaware of the Japanese ballot comment on Part 28 E2 and so can't comment on
> their requirements. Adapting Part 28 E1 may be exactly what they want, or
> they may need something else entirely.
> 
> The STEPMod DTD was not put through the ISO process because of the overhead
> and delay involved ...
> 
> For the purpose of my particular open-source project, I've found the STEPMod
> DTD sufficient. I was asking if others have had a similar experience. My use
> of the term "de facto standard" seems to have raised concerns. ...

Let me make my position clear.  Per JP-5, Part 28 should provide a means 
of exchanging EXPRESS schemas in some XML "parsed" form.  I am hoping 
that Japan will clarify that request.  The question is whether what 
Japan wants is the Part 28v1 "fully parsed" form, or something more like 
the STEPmod form.  If the latter, then Part 28 should probably just use 
the STEPmod form.

Both David and Josh think the STEPmod form matches toolsmith needs 
better than the Part 28 v1 form, and I personally can conceive of no 
other needs for the exchange of EXPRESS schemas in parsed form.  But I 
have heard that there are implementations of the Part 28 v1 form, and 
those implementors might be in a position to answer David's original 
question differently.

Clearly there was no need to standardize the STEPmod form heretofore, 
but now there may well be value in doing so.  And since Josh volunteered 
to write it up, we could kill two birds with one stone.

My second email can be summarized as:  Josh's argument for 
'availability' is totally irrelevant.  We have a requirement to make an 
ISO standard form for the exchange of XML-parsed EXPRESS schemas.  The 
question is only whether the ISO standard form should be the STEPmod form.

I don't care what the answer to that question is, but if the answer is 
that there should be two 'standards', then there is NO consensus and 
there should be NO ISO Standard.

The larger question is whether on any aspect of XML representation all 
of you toolsmiths will ever compromise on a single standard, or 
consensus on XML will remain just as much a joke in SC4 as it is in the 
rest of the IT toolsmith community!  When we have no consensus, we 
should have the honesty to stop progressing a wastepaper 'standard'. 
And if that is what Josh really meant, then NIST does have a common 
position.

-Ed

"You have sat here too long for any good you may have been doing!"
   -- Oliver Cromwell, in dissolving the "Rump Parliament"

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From david.price at eurostep.com  Wed Sep  8 11:47:03 2004
From: david.price at eurostep.com (David Price)
Date: Wed Sep  8 10:59:45 2004
Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F1E5F.2050403@nist.gov>
Message-ID: <001201c495bb$166642c0$2101a8c0@esukpc20>

All,

I checked the Part 28 E1 express DTD annex and there's no text at all. The
reader must look at Part 11 to figure out what each element means. Could
Part 28 E2 continue with that approach? If not, why not?

Also, I have to disagree with Ed about the free availability of
specifications being "totally irrelevant". I expect that means we are
talking about different things. I agree Josh's point is irrelevant with
respect to Part 28 Edition 2 and JP-5.

I think Josh's point is very important with respect to the open-source
projects and making EXPRESS/STEP more widely known. This discussion started
on the open-source exploder, not the WG11 exploder, and in that community
what Josh offered to do is very valuable.

I do not believe the text for the Part 28 E2 standard, if it is needed, is a
suitable replacement for the DTD user guide Josh proposed. I expect the user
guide would more closely resemble the text in Part 11 than anything Part 28
needs.

Cheers,
David

> -----Original Message-----
> From: step-os-bounces@ned.gsfc.nasa.gov [mailto:step-os-
> bounces@ned.gsfc.nasa.gov] On Behalf Of Ed Barkmeyer
> Sent: 08 September 2004 16:00
> To: STEP Open-Source
> Cc: 'SC4 WG11'
> Subject: Re: [wg11] Re: [step-os] Using STEPMod XML Representation of
> EXPRESS
> 
> David Price wrote:
> 
> > To clarify, STEPMod is the modules publication infrastructure. As such,
> the
> > STEPMod DTD was based only on requirements for producing a documented
> schema
> > using XSLT. Requirements for any other use of EXPRESS (e.g. validating
> data
> > against EXPRESS rules or mapping to MathML) were not considered. I was
> > unaware of the Japanese ballot comment on Part 28 E2 and so can't
> comment on
> > their requirements. Adapting Part 28 E1 may be exactly what they want,
> or
> > they may need something else entirely.
> >
> > The STEPMod DTD was not put through the ISO process because of the
> overhead
> > and delay involved ...
> >
> > For the purpose of my particular open-source project, I've found the
> STEPMod
> > DTD sufficient. I was asking if others have had a similar experience. My
> use
> > of the term "de facto standard" seems to have raised concerns. ...
> 
> Let me make my position clear.  Per JP-5, Part 28 should provide a means
> of exchanging EXPRESS schemas in some XML "parsed" form.  I am hoping
> that Japan will clarify that request.  The question is whether what
> Japan wants is the Part 28v1 "fully parsed" form, or something more like
> the STEPmod form.  If the latter, then Part 28 should probably just use
> the STEPmod form.
> 
> Both David and Josh think the STEPmod form matches toolsmith needs
> better than the Part 28 v1 form, and I personally can conceive of no
> other needs for the exchange of EXPRESS schemas in parsed form.  But I
> have heard that there are implementations of the Part 28 v1 form, and
> those implementors might be in a position to answer David's original
> question differently.
> 
> Clearly there was no need to standardize the STEPmod form heretofore,
> but now there may well be value in doing so.  And since Josh volunteered
> to write it up, we could kill two birds with one stone.
> 
> My second email can be summarized as:  Josh's argument for
> 'availability' is totally irrelevant.  We have a requirement to make an
> ISO standard form for the exchange of XML-parsed EXPRESS schemas.  The
> question is only whether the ISO standard form should be the STEPmod form.
> 
> I don't care what the answer to that question is, but if the answer is
> that there should be two 'standards', then there is NO consensus and
> there should be NO ISO Standard.
> 
> The larger question is whether on any aspect of XML representation all
> of you toolsmiths will ever compromise on a single standard, or
> consensus on XML will remain just as much a joke in SC4 as it is in the
> rest of the IT toolsmith community!  When we have no consensus, we
> should have the honesty to stop progressing a wastepaper 'standard'.
> And if that is what Josh really meant, then NIST does have a common
> position.
> 
> -Ed
> 
> "You have sat here too long for any good you may have been doing!"
>    -- Oliver Cromwell, in dissolving the "Rump Parliament"
> 
> --
> Edward J. Barkmeyer                        Email: edbark@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."
> _______________________________________________
> step-os mailing list
> step-os@step.nasa.gov
> http://step.nasa.gov/mailman/listinfo/step-os

From golux at comcast.net  Wed Sep  8 13:09:34 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Wed Sep  8 12:27:23 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <000001c4958c$c70489e0$2101a8c0@esukpc20>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>
Message-ID: <413F3CCE.40505@comcast.net>

David Price wrote:
> Hi Steve,
> 
> On EXPRESS/UML, I disagree the are different - mainly because UML isn't what
> it used to be, and that's a good thing. With MDA, UML Static Class diagrams
> are equivalent to EXPRESS-G diagrams, just with slightly different
> capabilities. That's how they're being used today in OMG - not only to model
> software systems, but to define a data exchange capability.

I have never heard of UML used that way in practice.  Are there any
real-world examples of programmers using it that way, or are the OMG
the only ones using it that way?  What data is being exchanged using
models developed that way?  (I mean real data, in production. ;)

> On EXPRESS/OWL, I disagree the are more similar. I think UML Static Class
> diagrams and EXPRESS are quite similar as they define a structure for data
> exchange.

As I say, I've never heard of UML class diagrams being used to define
data exchange structures, unless you mean data exchange between UML
tools.  (But that's just saying that UML has an exchange format, XMI.)
In practice, I've never seen UML used for anything other than software
modeling.  SysML will, of course, be another matter, but we're not
talking about that here.  ;)

> However, I think an ontology is an entirely different beast. It's
> very important to map things into OWL as they are in the real world ...

Which is *exactly* what ARM models do -- they describe the domain
in the domain expert's real-world terms.

> ... in order
> for the reasoners to work properly. For example, some UML Objects and
> EXPRESS entity instances should map to classes in OWL (e.g. Product_category
> instances should be subclasses of the Product Class).

No, Product_category instances are classes themselves --
it doesn't make sense for them to subclass the Product class,
whose instances are Products.  (Unless it's for an enterprise
whose product is taxonomies.  You don't see too many such
enterprises.  ;)

> OWL properties being
> first class concepts is also completely different from EXPRESS/UML.

That is only a structural difference.  I would argue that OWL
properties are semantically equivalent to EXPRESS attributes.
In EXPRESS, a property is simply defined as part of its domain class's
declaration; in OWL, a property is defined in a separate declaration
that includes an "owl:domain" statement that specifies its domain class.
The information is the same, it's just presented differently.

(BTW, I've always felt that EXPRESS should regard properties as first
class -- as they are in the IEC 61360 dictionary, for example, and
in PLIB, which uses the same dictionary standard.) 

> On mappings, EXPRESS-X is fine, except that EXPRESS has to be both target
> and source. It's useless for EXPRESS->SQL DDL or EXPRESS->OWL. 

I disagree.  EXPRESS-X is what would enable mapping EXPRESS
models to SQL, UML, or OWL:

EXPRESS-model  -[EXPRESS-X map 1]->  DDL-like-EXPRESS-model  -[direct]->  SQL
EXPRESS-model  -[EXPRESS-X map 2]->  UML-like-EXPRESS-model  -[direct]->  UML
EXPRESS-model  -[EXPRESS-X map 3]->  OWL-like-EXPRESS-model  -[direct]->  OWL

... where the "-[direct]->" mapping means:
entity -> table for SQL,
entity -> class for UML or OWL.

How sophisticated the EXPRESS-X has to be depends on the context of
the EXPRESS model.  If it's a STEP AIM model, the EXPRESS-X needed to
derive DDL-like, UML-like, or OWL-like models from it may have to
be fairly elaborate.

> This isn't just an abstract discussion ...

One of the few things you've said that I agree with.  :)

> ... I'm working on two mappings of
> EXPRESS to OWL, one structural and one semantic. The semantic one requires
> human intervention and stereotypes/tagged values applied to EXPRESS might
> enable that intervention. If there were a more robust solution, I'd happily
> adopt it.
> 
> On your preference for a mapping to be separate from the schemas, that's all
> just presentation to me.

On the contrary, since I see a need for many mappings, I see it as a code
management issue.

> I'll put the STEPMod DTD on the exff Web site, it's not easy to find on
> SourceForge. Here's the SourceForge link for now:
> 
> http://cvs.sourceforge.net/viewcvs.py/stepmod/stepmod/dtd/express_model.dtd?
> rev=1.14&view=markup

Thanks!

> Sorry for being so "disagreeable":-)

No problem -- I started it!  ;)

Cheers,
Steve
From hardwick at steptools.com  Wed Sep  8 09:49:19 2004
From: hardwick at steptools.com (Martin Hardwick)
Date: Wed Sep  8 12:47:45 2004
Subject: [step-os] Role of data exchange
In-Reply-To: <000001c4953b$91b60210$2101a8c0@esukpc20>
References: <413E14BE.1090204@nist.gov>
Message-ID: <5.1.0.14.2.20040908091246.02ba4fd8@localhost>

All,

1. Data exchange is about exchanging data. 
2. To exchange data you must have a conformant translator.
3. To obtain a conformant translator you must invest.
4. To invest you must have confidence that your investment
   will be protected.

The whole SC4/ISO infrastructure exists to protect the investment
necessary to build a conformant data exchange translator.

Ed is right many of the SC4 standards are unnecessary because they
do not protect the investment of a data exchange user instead they
define infrastructure that is used by the rest of SC4.

If STEPmod is building a system then there is no reason to tie the
internal formats of that system to a standard because to do so will
make the time necessary to implement enhancements unacceptable and
it will introduce features into the data that are unwanted by the
customers (even if they are wanted by other data exchange users).

If STEPmod intends to market its system using the argument that our
system is better because we are standards developers then life
is going to get interesting.

Martin

At 01:34 AM 9/8/2004 +0100, David Price wrote:
>Ed and company,
>
>To clarify, STEPMod is the modules publication infrastructure. As such, the
>STEPMod DTD was based only on requirements for producing a documented schema
>using XSLT. Requirements for any other use of EXPRESS (e.g. validating data
>against EXPRESS rules or mapping to MathML) were not considered. I was
>unaware of the Japanese ballot comment on Part 28 E2 and so can't comment on
>their requirements. Adapting Part 28 E1 may be exactly what they want, or
>they may need something else entirely.
>
>The STEPMod DTD was not put through the ISO process because of the overhead
>and delay involved and because it wasn't intended for use in Industrial Data
>application scenarios - it just had to work for STEPMod, not be perfect. It
>also seemed unnecessary to use ISO ballots to deal with the modules
>publication infrastructure as any delay could mean a delay in getting an
>AP/module approved. Personally, I doubt if the STEPMod developers are
>convinced any benefits outweigh that risk, even today. One very practical
>point is that I imagine putting the DTD through an SC4 ballot would result
>in people wanting to "fix" bits they don't like and I am sure nobody who
>funded STEPMod wants to fund changes to it based on the whims of a ballot
>resolution workshop.
>
>For the purpose of my particular open-source project, I've found the STEPMod
>DTD sufficient. I was asking if others have had a similar experience. My use
>of the term "de facto standard" seems to have raised concerns. Perhaps
>"open-source implementers agreement" would have been more appropriate as I
>intended on experimenting with adapting some UML concepts to EXPRESS and
>sharing the code. 
>
>Regardless of anything else that might happen, I think Josh volunteering to
>work on a user guide to be made freely available on the Web is great.
>
>Cheers,
>David
>
>> -----Original Message-----
>> From: wg11-bounces@steptools.com [mailto:wg11-bounces@steptools.com] On
>> Behalf Of Ed Barkmeyer
>> Sent: 07 September 2004 21:06
>> To: Joshua Lubell
>> Cc: SC4 WG11; STEP Open-Source
>> Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
>> 
>> Joshua Lubell wrote:
>> 
>> > But Ed, if the STEPmod spec were to be included in Part 28, then it
>> > would become the property of ISO. People would have to buy Part 28 from
>> > ISO in order to read the STEPmod spec.
>> 
>> How many people in the world should ever have to read the STEPmod spec
>> for XML rendition of an EXPRESS schema?  About 7, I would guess, all of
>> whom are no doubt NB experts participating in SC4.  (And they can get
>> SC4 documents free from ISO.)
>> 
>> > I would much rather see the
>> > STEPmod spec published independent of ISO so that it can be freely
>> > distrubuted. Otherwise, we're not likely to see much STEPmod-based
>> > implementation outside of those already active in SC4.
>> 
>> I'm not sure what this means, but I would hope that exchanging ISO
>> copyrighted EXPRESS schemas in any form is a rare occurrence in STEP
>> implementation.
>> 
>> > I think the way to go is to first publish the spec as a freely available
>> > technical report. It can then be adapted for Part 28 if SC4 so wishes.
>> > But ISO should not be the first venue in which it is published.
>> 
>> By this logic, we should certainly stop making standards in WG11,
>> because people would have to buy them from ISO, instead of inventing
>> their own and publishing technical reports online.  That certainly
>> applies to Part 14, 25, and 27, which didn't need to be ISO standards,
>> and to Part 28, on which there has never been consensus.  And this logic
>> should apply to Part 25v2 and binary exchange of STEP data.  Indeed, any
>> future 20-series spec should be a technical report in the open software
>> community and not an ISO standard, so as to maximize its accessibility.
>>   Right?
>> 
>> That the ISO publication control process interferes with adoption of ISO
>> standards has been an issue in several ISO communities in the recent
>> past.  But we can't solve that problem -- it is out of our scope.  Our
>> scope is to support the SC4 standards community as constituted, warts
>> and all.
>> 
>> My concern is that Part 28, an ISO project SC4 intended to serve this
>> same community, is required to specify a mechanism for representing
>> EXPRESS schemas in XML.  If David and Josh think the most useful
>> representation is the STEPmod representation and others agree, then
>> surely that should be the proposed standard.  In any case, STEPmod
>> should not refuse to allow its representation to be the Standard
>> representation and simultaneously suggest that it be the "de facto
>> standard" in the STEP community, IN LIEU OF the ISO standard
>> representation.  What does Josh suggest Part 28 should standardize?
>> (It's a little late to vote No on the NWI.)
>> 
>> -Ed
>> 
>> P.S.  The NIST goal in this whole effort was to get SC4 to agree to
>> *common* XML representations.  Et tu, Brute?
>> 
>> --
>> Edward J. Barkmeyer                        Email: edbark@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."
>> _______________________________________________
>> wg11 mailing list
>> wg11@steptools.com
>> http://lists.steptools.com/mailman/listinfo/wg11
>
>
>_______________________________________________
>wg11 mailing list
>wg11@steptools.com
>http://lists.steptools.com/mailman/listinfo/wg11
>
>
>!DSPAM:413e53a1103991659011899!

From edbark at nist.gov  Wed Sep  8 14:39:46 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Wed Sep  8 13:52:22 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <000001c4958c$c70489e0$2101a8c0@esukpc20>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>
Message-ID: <413F51F2.2000002@nist.gov>

David Price wrote:

> On EXPRESS/UML, I disagree they are different - mainly because UML isn't what
> it used to be, and that's a good thing. With MDA, UML Static Class diagrams
> are equivalent to EXPRESS-G diagrams, just with slightly different
> capabilities. That's how they're being used today in OMG - not only to model
> software systems, but to define a data exchange capability.

Well.  Actually, the use of UML to define "data exchange" capabilities 
really requires one to add stereotypes to the UML model.  The fact that 
OMG "information models" don't routinely do that is semantically 
difficult to reconcile with the UML standard.

In general, I agree with David.  EXPRESS has Entities, attributes, data 
types, and rules.  UML "static structure" has Classes, attributes, 
associations, 'data types', and OCL rules.  The main distinction is that 
UML, by distinguishing 'associations' from 'attributes' and 'structures' 
from 'objects', is semantically richer than EXPRESS, while EXPRESS has a 
more uniform 'data type' system and a more useful SELECT model.  Both 
founder in their models of 'aggregations'.  The upshot, as Steve says 
and Part 25 shows, is that there is not a 1-to-1 mapping of concepts, 
and you have to use some 'heuristics' on an EXPRESS model to get a good 
UML approximation, and you have to use some knowledge not captured in 
the EXPRESS to get a correct UML model.

Steve says:
>The designers of EXPRESS bent over backward to make life
>easy for (non-programming) information modelers (not for
>programmers), which is part of the source of the mismatch here.
>STEP information modelers describe the data that is needed to
>describe the contents of their domains, but they give
>absolutely no thought (nor should they) to database design nor
>to the design of any kind of executable code, so there's not
>necessarily a high correlation between the structure of STEP AP
>AIMs (and even ARMs in some cases) and how a database or
>application code that stores and/or uses that data is best
>structured.

Well, the EXPRESS language designers gave no thought to the semantic 
concepts that need to be separated in order to enable mappings to 
several different implementation platforms.  If they had, they would 
have separated entity (compare by id) from record/structure (compare by 
value) from relationship, and attribute (owned) from association 
(joint), and distinguished the syntax for multi-valued relationships 
from the syntax for "aggregations", particularly LIST and ARRAY.  UML 
designers, over time, did actually do most of these.  The error in the 
STEP approach is that, in order to enable multiple 20-series mappings, I 
have to have *more* semantic richness in EXPRESS, not less.  We could 
easily do many-to-1 EXPRESS-to-xyz mappings, but it is very difficult to 
do 1-to-many.

I disagree that "STEP information modelers ... give absolutely no 
thought ... to database design".  ALL of the IRMs are essentially 
relational models, in which ENTITY is a synonym for Table.  And if ANDOR 
and multiple inheritance weren't easy to do in SQL, they wouldn't be 
permitted in STEP models.  And there are database biases in EXPRESS 
itself.  Requiring named SELECT types isn't a semantic notion; it is a 
requirement for database implementations (but only some OOPL 'union's). 
  The domain modelers may not be conscious of this bias, but they have 
been forced into it.

Conversely, the UML bias is toward OOPL implementation, and UML modelers 
are, perhaps unconsciously, forced into OO-biased models much of the time.

For market reasons, the UML vendors have made an effort to reach out to 
the database community, and to accommodate features of their languages: 
EXPRESS, ORM, SQL, OQL, etc.  And the OCL2 constraint language is 
approximately equal to the EXPRESS rules syntax.  That is why it is 
possible in 2004 to say that UML is closer to EXPRESS.

It is the (belated) recognition of this situation that has motivated OMG 
to re-define "Platform-Independent Model" to "specific to a class of 
platform but not to a member of the class".  So a "PIM" can be 
OOPL-specific, but not specific to Java or C# or C++.

> On EXPRESS/OWL, I disagree they are more similar. I think UML Static Class
> diagrams and EXPRESS are quite similar as they define a structure for data
> exchange. However, I think an ontology is an entirely different beast. It's
> very important to map things into OWL as they are in the real world in order
> for the reasoners to work properly. For example, some UML Objects and
> EXPRESS entity instances should map to classes in OWL (e.g. Product_category
> instances should be subclasses of the Product Class). OWL properties being
> first class concepts is also completely different from EXPRESS/UML.

UML Static structure diagrams don't define a structure for data 
exchange.  They define object classes, attributes, and relationships 
among classes.  They specify whether the attribute and relationship 
accessors are exposed or private (elements of state).  Those that define 
only exposed elements of state are 'equivalent' to EXPRESS models.  The 
relationship between exposed elements of state and the structure for 
information exchange is something else again, which is why SC4 has 
20-series standards.

OWL models define classes and properties (both 1st class, as David says) 
and state relationships between classes and properties.  While it is 
tempting to say that ontologies are "models of the real world", it is 
not significantly more true of OWL than of UML or EXPRESS.  In 1985 we 
told ourselves that EXPRESS-like "information models" were "models of 
the real world", and in 1990, we were told the same of "object models" 
(whilst discounting "information models" as "database models").  The 
problem is that OWL models are also "information technology models". 
They only represent the 'truth' to the extent that the language can 
express it and it is useful to the intended applications.  In this case, 
the intended applications are DL-engines supporting search engines, 
instead of OOPL compilers or DBMS.

So in OWL I model a "property" by giving it a name I expect to be 
meaningful to searches in my semantic domain, and I attach it to classes 
named for concepts in my domain, so that it can be distinguished from a 
property with the same name in a different domain.  That attachment can 
be necessary, sufficient or neither, and it can be seen as 
characterizing the class, the property, or both.

We don't tend to think of things this way in EXPRESS or UML, but
- declaring an ENTITY is naming a 'primitive' class
- declaring an attribute is naming a 'property' and attaching it to the 
ENTITY/class as 'domain' and to its data type 'class' as 'range'. 
Unless the attribute is SET [0:something] or OPTIONAL, it also declares 
the property 'necessary' to the domain class -- every instance of the 
entity data type (class) must have a value for this attribute.
- it is possible using EXPRESS Rules to state that a property is 
'sufficient', e.g. every instance of some supertype that has a given 
value for this attribute is an instance of this subtype.
- it is possible to express most of the capabilities of the OWL language 
using EXPRESS Rule constructs.

The problem is that EXPRESS concepts have a different 'flavor', as 
described in Part 11, and it takes a change of mindset to see them as 
expressing the OWL concepts.  Further, the EXPRESS Rule syntax is much 
more general (and clumsy), making it necessary to *comprehend* the 
intent/effect of a rule in order to determine its equivalence to an OWL 
constraint.  OWL uses set operations to express constraints among 
classes and properties and property domains and so on, while EXPRESS has 
different syntax for each of those, some of which can be mixed with 
others.

So Steve is right in one way: there is a large overlap in what you can 
*declare* in EXPRESS and OWL.

But the main difference, which David hinted at in saying properties are 
1st class, is that OWL allows you to identify the same concept as having 
different names in different namespaces.  In EXPRESS, this can be 
simulated in some cases, but there is no real EXPRESS equivalent.  In 
EXPRESS an entity declaration creates a new "scope"="namespace".  The 
attribute names belong to that scope/namespace and there is no way to 
say that the 'id' and 'description' attributes of a 'product' and the 
'id' and 'description' attributes of an 'action' have the same semantic 
relationships to those otherwise unrelated classes.  In OWL this is the 
default interpretation, and you have to name 'id' 'product.id' if its 
semantics are different.  But you can also state that two 'terms' with 
entirely different spellings have the same meaning.  This is not usually 
important for data exchange, because the 'meaning' is built into the 
sending and receiving systems.  But it is very important in Web-search. 
  For example, in searching for 'services', you can use the information 
from publications that describe them as a subtype of 'product' and also 
the information from publications that describe them as a subtype of 
'action', and know what information should be the same.

> Using the Product/Product_category example, if I stereotyped
> Product_category "CLASS_OF_CLASS" then I would know its entity instances
> should map to OWL Classes rather than OWL Individuals. 

Well, that is a design choice.  It has nothing to do with the real 
world.  In the real world, there is no dichotomy between Class and 
Individual.  In mathematics, and in OWL, there is.  This is one of those 
special expressiveness things that OWL has and EXPRESS doesn't.  Yes, it 
is useful to be able to express this distinction, for the purpose of 
useful reasoning, but it also creates side effects that may prevent 
other 'truths' from being expressed in OWL.

Conversely, it is easy in EXPRESS to write a rule that says of two 
OPTIONAL attributes that for any given entity instance exactly one of 
them is present
  wr1: EXISTS(a) XOR EXISTS(b);
In OWL, you have to invent two subtypes, because DL-engines can't reason 
with ORs and XORs in the consequent.

> ...
> This isn't just an abstract discussion, I'm working on two mappings of
> EXPRESS to OWL, one structural and one semantic. The semantic one requires
> human intervention and stereotypes/tagged values applied to EXPRESS might
> enable that intervention. 

This is what I'm having trouble with.  Human intervention is enabled by 
presenting the human with elements of an EXPRESS model and allowing the 
human to provide "annotations" to those elements, presumably using some 
formal language and means of expression afforded him by the tool.  That 
is largely an HCI issue.  The related problem is the form in which the 
tool will archive or exchange the annotated EXPRESS model, which is 
"quite another thing entirely".

It appears that David's approach is:
- define an XML form for the annotated EXPRESS, and capture the EXPRESS 
in that XML form
- capture the annotations and add them to that XML form
- convert the XML form of the EXPRESS model to the UMLv2 MOF model, 
using Part 25 and additional special code for the annotations
- exchange actual annotated model instances using XMI and UML meta-model

It is certainly true that you could do this by:
- make a MOF model of EXPRESS, and capture the EXPRESS model in that 
"MOF database"
- extend that MOF model to add the annotation features, and capture the 
annotations in the extended MOF database
- (optionally) exchange actual (possibly annotated) EXPRESS model 
instances using MOF/XMI
- convert the annotated EXPRESS model instances (from the MOF database 
or XMI input) to the UMLv2 MOF model, using Part 25 and additional 
special code for the annotations
- exchange actual annotated model instances using XMI and UML meta-model

> If there were a more robust solution, I'd happily adopt it.

With my OMG hat on, I would describe the latter as the more robust 
solution.  But I see that as making "model management" the dominant 
concern, rather than "XML-based exchange".  If you have a bunch of 
separate programs and programmers that have to process the pieces, 
XML-based exchange becomes dominant, either because they are in various 
parts of the globe, or because you don't trust more than one or two of 
them to use a MOF database without corrupting it.  The definition of 
"robust" depends on many practical considerations. ;-)

-Ed

P.S. My current project is looking at fundamental semantics and what 
models actually capture.

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From edbark at nist.gov  Wed Sep  8 14:52:20 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Wed Sep  8 14:04:53 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F3CCE.40505@comcast.net>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>
	<413F3CCE.40505@comcast.net>
Message-ID: <413F54E4.7030309@nist.gov>

A quick note.

Stephen Waterbury wrote:

> As I say, I've never heard of UML class diagrams being used to define
> data exchange structures, unless you mean data exchange between UML
> tools.  (But that's just saying that UML has an exchange format, XMI.)
> In practice, I've never seen UML used for anything other than software
> modeling.  SysML will, of course, be another matter, but we're not
> talking about that here.  ;)

There are UML class diagrams in the TC211 (Geospatial data) standards, 
whose purpose is to model data exchanges that use XML.  There are UML 
class diagrams in ISO 11179 (Metadata registries), whose purpose is to 
define the conceptual schema for registry databases and their contents. 
   UML class diagrams were used by the AIAG Inventory Visibility and 
Interoperability project to describe the required information entities 
and data elements, and then to map them to OAGIS XML elements.  And the 
OMG PLM standard (from PDTnet) has two sections -- one using UML to 
specify the (STEP) PDM Schema elements for exchange via XML and the 
other using UML to specify PDM Enablers-like service interfaces.

Shall I go on?

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From david.price at eurostep.com  Wed Sep  8 14:53:41 2004
From: david.price at eurostep.com (David Price)
Date: Wed Sep  8 14:06:23 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F3CCE.40505@comcast.net>
Message-ID: <004a01c495d5$287fbfd0$2101a8c0@esukpc20>

Hi Steve,

We seem to have very different views of these three languages:-)

> David Price wrote:
> > Hi Steve,
> >
> > On EXPRESS/UML, I disagree the are different - mainly because UML isn't
> what
> > it used to be, and that's a good thing. With MDA, UML Static Class
> diagrams
> > are equivalent to EXPRESS-G diagrams, just with slightly different
> > capabilities. That's how they're being used today in OMG - not only to
> model
> > software systems, but to define a data exchange capability.
> 
> I have never heard of UML used that way in practice.  Are there any
> real-world examples of programmers using it that way, or are the OMG
> the only ones using it that way?  What data is being exchanged using
> models developed that way?  (I mean real data, in production. ;)

A UML Class diagram and an XML encoding for exchange are how many, many data
exchange applications work today. That's how ebXML is defined in OASIS too.
I'm not talking about XMI at all. You need to get out more:-) The first OMG
MDA standard was life sciences XML data exchange and the UML to XML binding
was s Java program. Check out the eclipse EMF project too. You model in UML
or Java and it creates the other, along with a read/write API and little
editor... all automatically from one source.

> 
> > On EXPRESS/OWL, I disagree the are more similar. I think UML Static
> Class
> > diagrams and EXPRESS are quite similar as they define a structure for
> data
> > exchange.
> 
> As I say, I've never heard of UML class diagrams being used to define
> data exchange structures, unless you mean data exchange between UML
> tools.  (But that's just saying that UML has an exchange format, XMI.)
> In practice, I've never seen UML used for anything other than software
> modeling.  SysML will, of course, be another matter, but we're not
> talking about that here.  ;)
> 
> > However, I think an ontology is an entirely different beast. It's
> > very important to map things into OWL as they are in the real world ...
> 
> Which is *exactly* what ARM models do -- they describe the domain
> in the domain expert's real-world terms.

An ARM defines information requirements for a domain - which is important
but far from describing the whole domain. Look at some of the frameworks
like RM-ODP or Zachman to see all the other bits that are required. And it's
just not true that ARM models result in the proper distinction between
classes and individuals in the real-world (see discussion below).

> 
> > ... in order
> > for the reasoners to work properly. For example, some UML Objects and
> > EXPRESS entity instances should map to classes in OWL (e.g.
> Product_category
> > instances should be subclasses of the Product Class).
> 
> No, Product_category instances are classes themselves --
> it doesn't make sense for them to subclass the Product class,
> whose instances are Products.  (Unless it's for an enterprise
> whose product is taxonomies.  You don't see too many such
> enterprises.  ;)

That's exactly what I said, subclasses ARE classes. In more detail:

ENTITY Product; ENTITY Product_category; ENTITY Product_category_assignment;

#1=PRODUCT('A');
#2=PRODUCT_CATEGORY('Pump');
#3=PRODUCT_CATEGORY_ASSIGNMENT(#1,#2);

ends up as

OWL CLASS Product
OWL CLASS Pump subClassOf Product
OWL Individual A

This is needed otherwise reasoners won't work because they don't understand
Product_category_assignment.

> 
> > OWL properties being
> > first class concepts is also completely different from EXPRESS/UML.
> 
> That is only a structural difference.  I would argue that OWL
> properties are semantically equivalent to EXPRESS attributes.
> In EXPRESS, a property is simply defined as part of its domain class's
> declaration; in OWL, a property is defined in a separate declaration
> that includes an "owl:domain" statement that specifies its domain class.
> The information is the same, it's just presented differently.

It's not only a structural difference. It allows unnamed classes to be
defined as restrictions on the properties and then used by set theory
operations like intersection to create other classes. Classes don't have to
be pre-defined, they can be inferred.

> 
> I disagree.  EXPRESS-X is what would enable mapping EXPRESS
> models to SQL, UML, or OWL:
> 
> EXPRESS-model  -[EXPRESS-X map 3]->  OWL-like-EXPRESS-model  -[direct]->
> OWL
> 
> ... where the "-[direct]->" mapping means:
> entity -> table for SQL,
> entity -> class for UML or OWL.
> 
> How sophisticated the EXPRESS-X has to be depends on the context of
> the EXPRESS model.  If it's a STEP AIM model, the EXPRESS-X needed to
> derive DDL-like, UML-like, or OWL-like models from it may have to
> be fairly elaborate.

Not really. You cannot have an OWL-like-EXPRESS-model because OWL is so
different from EXPRESS (see above). Trying to do this with EXPRESS-X is
really stretching its usefulness. We'll see though, the OMG Ontology work
and the OMG QVT work aren't ready yet. They may not really do the job
either.

Interesting chat....
DP

From edbark at nist.gov  Wed Sep  8 15:19:48 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Wed Sep  8 14:32:25 2004
Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <001201c495bb$166642c0$2101a8c0@esukpc20>
References: <001201c495bb$166642c0$2101a8c0@esukpc20>
Message-ID: <413F5B54.1000304@nist.gov>

David Price wrote:

> I checked the Part 28 E1 express DTD annex and there's no text at all. The
> reader must look at Part 11 to figure out what each element means. Could
> Part 28 E2 continue with that approach? If not, why not?

David Price wrote (on 7 September):

> All the work I?ve done with EXPRESS is based on the XML representation of   > EXPRESS used by STEPMod, not the Part 28 Edition 1 XML DTD. This has
> happened because the Part 28 DTD required every expression to be broken 
> into bits which seemed pointless to most people - and also meant 
> reconstructing EXPRESS from the XML using XSLT would be very difficult.

Ipse dixit.  This might be exactly why not.

> So, my question is ? Are people generally comfortable with using the 
> STEPMod XML representation of EXPRESS as the de facto standard for 
> open-source STEP work? 

Note how this conveniently views "open-source STEP work" as a different 
category of effort, requiring different standards, from "in-house STEP 
work" or "proprietary product STEP work".  What is sauce for the goose 
is evidently unsuitable for the gander in the UK.  (But then British 
cooking has never been highly regarded. ;-)

> Also, I have to disagree with Ed about the free availability of
> specifications being "totally irrelevant". I expect that means we are
> talking about different things. I agree Josh's point is irrelevant with
> respect to Part 28 Edition 2 and JP-5.

My only point.

> I think Josh's point is very important with respect to the open-source
> projects and making EXPRESS/STEP more widely known. 

Absolutely.  All the competitor standards to SC4 work will appear on the 
Web, some password-protected, some free of charge.  The difference is 
that all the competitor standards will appear in their full text, with 
explanations and formal requirements.  All the "open-source projects" 
can hope to publish is the bare schemas and home-grown 'user guides' and 
'tutorials'.  OTOH, SC4 has required the useful standards to be 
unreadable compendia of overstructured stuff, and the user guides and 
tutorials are vastly more useful.

> This discussion started
> on the open-source exploder, not the WG11 exploder, and in that community
> what Josh offered to do is very valuable.

Incredible as it may seem, I thought that what Josh offered to do might 
actually be of use to an SC4 Standard *as well*.

> I do not believe the text for the Part 28 E2 standard, if it is needed, is a
> suitable replacement for the DTD user guide Josh proposed. I expect the user
> guide would more closely resemble the text in Part 11 than anything Part 28
> needs.

An interesting view:  The text that explains how to use this set of XML 
objects to convey an EXPRESS schema will be markedly different if it is 
in a technical report for the 'open-source STEP developer' community 
from what it would be in a Standard for the (unwashed?) STEP developer 
community.

Only in SC4 could such a mindset be possible:  Our standards are 
unintelligible, whereas our technical reports are lucid.  The problem, 
of course, is that this is largely valid!  ;-)  Josh's text would be a 
welcome departure.  But then David seems to think Part 11 is 
intelligible, and Martin insists that Part 21 is clear and lucid; so 
such a departure would not be so atypical for WG11.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From golux at comcast.net  Wed Sep  8 15:55:19 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Wed Sep  8 15:13:07 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F51F2.2000002@nist.gov>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>
	<413F51F2.2000002@nist.gov>
Message-ID: <413F63A7.8000405@comcast.net>

Ed Barkmeyer wrote:

> Steve says:
> 
>> The designers of EXPRESS bent over backward to make life
>> easy for (non-programming) information modelers (not for
>> programmers), which is part of the source of the mismatch here.
>> STEP information modelers describe the data that is needed to
>> describe the contents of their domains, but they give
>> absolutely no thought (nor should they) to database design nor
>> to the design of any kind of executable code, so there's not
>> necessarily a high correlation between the structure of STEP AP
>> AIMs (and even ARMs in some cases) and how a database or
>> application code that stores and/or uses that data is best
>> structured.
> 
> Well, the EXPRESS language designers gave no thought to the semantic 
> concepts that need to be separated in order to enable mappings to 
> several different implementation platforms.  If they had, they would 
> have [done various things differently] ...

I agree with this part.

> I disagree that "STEP information modelers ... give absolutely no 
> thought ... to database design".

Okay, "absolutely no thought" was too strong.  I should have said
"lip service".  ;)

> ALL of the IRMs are essentially 
> relational models, in which ENTITY is a synonym for Table.

True, but they are part of the infinite class of relational
models that would be totally impractical to use directly as
physical relational database designs.  I'm aware that some
experiments were done early on with using AIM-level models as
relational database schemas, but I don't know of any that are
used in practice, do you?

> And if ANDOR 
> and multiple inheritance weren't easy to do in SQL, they wouldn't be 
> permitted in STEP models.

So you're saying that's a *requirement* that was observed in
designing EXPRESS?  That's interesting, but still doesn't convince
me that the early STEP architects really thought the issues through.

> And there are database biases in EXPRESS 
> itself.  Requiring named SELECT types isn't a semantic notion; it is a 
> requirement for database implementations (but only some OOPL 'union's). 
>  The domain modelers may not be conscious of this bias, but they have 
> been forced into it.

Are you kidding?  Domain modelers *love* named SELECT types!
I disagree that it is not a semantic notion -- I think anything
that is reified (such as a SELECT list) is nameable, even if
it is not typically named outside of software.  If you're saying
there's nothing in the "interpretation" that the name maps to,
I'll agree only partially, because in some cases SELECT types are
given names even in human discourse.

> Conversely, the UML bias is toward OOPL implementation, and UML modelers 
> are, perhaps unconsciously, forced into OO-biased models much of the time.

Agreed.

> For market reasons, the UML vendors have made an effort to reach out to 
> the database community, and to accommodate features of their languages: 
> EXPRESS, ORM, SQL, OQL, etc.  And the OCL2 constraint language is 
> approximately equal to the EXPRESS rules syntax.  That is why it is 
> possible in 2004 to say that UML is closer to EXPRESS.

In theory perhaps;  I would say not in practice/application.

> It is the (belated) recognition of this situation that has motivated OMG 
> to re-define "Platform-Independent Model" to "specific to a class of 
> platform but not to a member of the class".  So a "PIM" can be 
> OOPL-specific, but not specific to Java or C# or C++.
> 
>> On EXPRESS/OWL, I disagree they are more similar. I think UML Static 
>> Class
>> diagrams and EXPRESS are quite similar as they define a structure for 
>> data
>> exchange. However, I think an ontology is an entirely different beast. 
>> It's
>> very important to map things into OWL as they are in the real world in 
>> order
>> for the reasoners to work properly. For example, some UML Objects and
>> EXPRESS entity instances should map to classes in OWL (e.g. 
>> Product_category
>> instances should be subclasses of the Product Class). OWL properties 
>> being
>> first class concepts is also completely different from EXPRESS/UML.
> 
> UML Static structure diagrams don't define a structure for data 
> exchange.  They define object classes, attributes, and relationships 
> among classes.  They specify whether the attribute and relationship 
> accessors are exposed or private (elements of state).  Those that define 
> only exposed elements of state are 'equivalent' to EXPRESS models.  The 
> relationship between exposed elements of state and the structure for 
> information exchange is something else again, which is why SC4 has 
> 20-series standards.

This is basically my position as well.  The differences between
the PDM Schema and the PDM Enablers are a good illustration of this
contrast.

> OWL models define classes and properties (both 1st class, as David says) 
> and state relationships between classes and properties.  While it is 
> tempting to say that ontologies are "models of the real world", it is 
> not significantly more true of OWL than of UML or EXPRESS.  In 1985 we 
> told ourselves that EXPRESS-like "information models" were "models of 
> the real world", and in 1990, we were told the same of "object models" 
> (whilst discounting "information models" as "database models").  The 
> problem is that OWL models are also "information technology models". 
> They only represent the 'truth' to the extent that the language can 
> express it and it is useful to the intended applications.  In this case, 
> the intended applications are DL-engines supporting search engines, 
> instead of OOPL compilers or DBMS.

Agree ... also, the "real world" includes software, thereby
blurring the distinction still more.  ;)

> So in OWL I model a "property" by giving it a name I expect to be 
> meaningful to searches in my semantic domain, and I attach it to classes 
> named for concepts in my domain, so that it can be distinguished from a 
> property with the same name in a different domain.  That attachment can 
> be necessary, sufficient or neither, and it can be seen as 
> characterizing the class, the property, or both.

Agreed.

> We don't tend to think of things this way in EXPRESS or UML, but
> - declaring an ENTITY is naming a 'primitive' class
> - declaring an attribute is naming a 'property' and attaching it to the 
> ENTITY/class as 'domain' and to its data type 'class' as 'range'. Unless 
> the attribute is SET [0:something] or OPTIONAL, it also declares the 
> property 'necessary' to the domain class -- every instance of the entity 
> data type (class) must have a value for this attribute.

Similar to OWL's cardinality, minCardinality, and maxCardinality.
OWL can even use InverseFunctionalProperty to define primary keys,
speaking of database-friendly!

> - it is possible using EXPRESS Rules to state that a property is 
> 'sufficient', e.g. every instance of some supertype that has a given 
> value for this attribute is an instance of this subtype.
> - it is possible to express most of the capabilities of the OWL language 
> using EXPRESS Rule constructs.

Sounds ugly, though.  ;)

> The problem is that EXPRESS concepts have a different 'flavor', as 
> described in Part 11, and it takes a change of mindset to see them as 
> expressing the OWL concepts.

That seems a subjective judgment -- it didn't require a change
of mindset for me.  I expect that to see EXPRESS concepts as
expressing OWL concepts would seem obvious to someone who comes 
to EXPRESS from the Semantic Web world, as well.  :)

> Further, the EXPRESS Rule syntax is much 
> more general (and clumsy), making it necessary to *comprehend* the 
> intent/effect of a rule in order to determine its equivalence to an OWL 
> constraint.  OWL uses set operations to express constraints among 
> classes and properties and property domains and so on, while EXPRESS has 
> different syntax for each of those, some of which can be mixed with others.
> 
> So Steve is right in one way: there is a large overlap in what you can 
> *declare* in EXPRESS and OWL.

In my view, there is also a huge semantic overlap.

> But the main difference, which David hinted at in saying properties are 
> 1st class, is that OWL allows you to identify the same concept as having 
> different names in different namespaces.  In EXPRESS, this can be 
> simulated in some cases, but there is no real EXPRESS equivalent.

That's a good point; EXPRESS is not designed to deal gracefully
with multiple namespaces, in general, whereas it is a fundamental
requirement for OWL, which will be operating in a sea of
homonyms!  (STEP also does, but doesn't usually acknowledge it.)

> In 
> EXPRESS an entity declaration creates a new "scope"="namespace".  The 
> attribute names belong to that scope/namespace and there is no way to 
> say that the 'id' and 'description' attributes of a 'product' and the 
> 'id' and 'description' attributes of an 'action' have the same semantic 
> relationships to those otherwise unrelated classes.  In OWL this is the 
> default interpretation, and you have to name 'id' 'product.id' if its 
> semantics are different.  But you can also state that two 'terms' with 
> entirely different spellings have the same meaning.  This is not usually 
> important for data exchange, because the 'meaning' is built into the 
> sending and receiving systems.  But it is very important in Web-search. 

That's a good point.  For my application, Web-search is a relatively
lower-priority source of requirements.  However, the namespace-aware
nature of RDF/RDFS/OWL is very useful when dealing with many standards
and many ontologies which have to be integrated and/or reasoned over,
which is one of the central problems facing Systems Engineering, and
is therefore a current challenge in the STEP world, both in AP233 and
in modularization in general.

>  For example, in searching for 'services', you can use the information 
> from publications that describe them as a subtype of 'product' and also 
> the information from publications that describe them as a subtype of 
> 'action', and know what information should be the same.
> 
>> Using the Product/Product_category example, if I stereotyped
>> Product_category "CLASS_OF_CLASS" then I would know its entity instances
>> should map to OWL Classes rather than OWL Individuals. 
> 
> 
> Well, that is a design choice.  It has nothing to do with the real 
> world.

Yep.

Good discussion, David and Ed!  Lots of food for thought.  :)

Steve
From golux at comcast.net  Wed Sep  8 16:10:27 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Wed Sep  8 15:28:17 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F54E4.7030309@nist.gov>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>	<413F3CCE.40505@comcast.net>
	<413F54E4.7030309@nist.gov>
Message-ID: <413F6733.40307@comcast.net>

Ed Barkmeyer wrote:
> A quick note.
> 
> Stephen Waterbury wrote:
> 
>> As I say, I've never heard of UML class diagrams being used to define
>> data exchange structures, unless you mean data exchange between UML
>> tools.  (But that's just saying that UML has an exchange format, XMI.)
>> In practice, I've never seen UML used for anything other than software
>> modeling.  SysML will, of course, be another matter, but we're not
>> talking about that here.  ;)
> 
> There are UML class diagrams in the TC211 (Geospatial data) standards, 
> whose purpose is to model data exchanges that use XML.

Do the class diagrams model the data to be exchanged or
the exchange process?  How are they mapped to the XML data?
I don't know of any standard mapping other than XMI -- are they
using XMI, or some non-standard mapping?

> There are UML 
> class diagrams in ISO 11179 (Metadata registries), whose purpose is to 
> define the conceptual schema for registry databases and their contents. 

I assume that these are an after-thought.  Are they normative?

>   UML class diagrams were used by the AIAG Inventory Visibility and 
> Interoperability project to describe the required information entities 
> and data elements, and then to map them to OAGIS XML elements.

Sounds similar to a PDES, Inc. pilot ... did real software and
production exchanges come out of this?

> And the 
> OMG PLM standard (from PDTnet) has two sections -- one using UML to 
> specify the (STEP) PDM Schema elements for exchange via XML and the 
> other using UML to specify PDM Enablers-like service interfaces.

Again, this sounds more like "cosmetics", or was there some direct
UML-to-XML implementation mapping?

> Shall I go on?

Sure, if you have some real ones.  ;)

Sorry about the skepticism, but these all sound like applications of UML
to provide visual presentation of models that were developed by other
means, rather than as an actual aid to the definition of exchange structures
or software.

Steve
From edbark at nist.gov  Wed Sep  8 16:43:25 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Wed Sep  8 15:55:59 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F3CCE.40505@comcast.net>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>
	<413F3CCE.40505@comcast.net>
Message-ID: <413F6EED.8050602@nist.gov>

A second short note.

Stephen Waterbury wrote:

> David Price wrote:
>> ...
>> OWL properties being
>> first class concepts is also completely different from EXPRESS/UML.
> 
> That is only a structural difference.  I would argue that OWL
> properties are semantically equivalent to EXPRESS attributes.
> In EXPRESS, a property is simply defined as part of its domain class's
> declaration; in OWL, a property is defined in a separate declaration
> that includes an "owl:domain" statement that specifies its domain class.
> The information is the same, it's just presented differently.

I agree with Steve this time.  The syntactic characteristics are not 
important.  But as I said before, the important feature of OWL is that I 
can say that two properties with entirely different domains are 
semantically equivalent.  That the OWL property declaration syntax 
facilitates this within a namespace is nice, but it is imperative that 
one be able to state the equivalence across namespaces (by qualifying 
the property names).  That is the critical OWL idea.  I can qualify 
property names in EXPRESS; but I have no way to state the semantic 
equivalence.

> (BTW, I've always felt that EXPRESS should regard properties as first
> class -- as they are in the IEC 61360 dictionary, for example, and
> in PLIB, which uses the same dictionary standard.)

Dictionaries traditionally regard all concepts as first-class, and then 
provide several distinct domain-specific definitions for many 
"properties".  Ideally, you want the ability to make them either local 
or global, like ASN.1 and XML Schema.  Then you can say what you mean.

But a lot of "global properties" produce subtle semantic confusion.  The 
problem is in agreeing on the exact characteristics of the common 
property.  Using the common STEP 'id' attribute as an example, almost 
all uses of 'id' have range 'identifier'.  But there is no expectation 
that there is any syntactic commonality in the 'identifier' values.  So 
while there may be value in modeling 'id' as a global property, there 
may be more value in modeling 'product.id' as a local property that 
embodies rules for product identification. The problem arises when I 
intend the latter "extended" property and use the global term.  If I do 
this twice and later discover instances with dual inheritance:
  (a) when the property is single-valued, the two values may not be the 
same (!), even though they are both stated to be THE value of the same 
global property, because the interpretation included the context of use.
  (b) when the property is multi-valued, the local implications of the 
values inherited from one ancestor may not be the same as the local 
implications of the values inherited from the other, because each 
ancestor embodies a different local semantic extension.

So when you use "global properties", you have to be very careful about 
the common interpretation.

One thing that I would like to do in OWL and can't is to "refine" a 
"property".  E.g., captain_of(Person, Ship) is a special case of (or 
"implies") crew_member(Person, Ship).  I can do this in ORM and UML, and 
in EXPRESS I can do it with a RULE, but in OWL I have to reify the 
property relationship into a class/entity and subtype the reified 
relationship.  (And then I have to create pseudo-"properties" for 
'relating_item' and 'related_item', etc.)

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From golux at comcast.net  Wed Sep  8 17:46:30 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Wed Sep  8 17:04:18 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <004a01c495d5$287fbfd0$2101a8c0@esukpc20>
References: <004a01c495d5$287fbfd0$2101a8c0@esukpc20>
Message-ID: <413F7DB6.2040408@comcast.net>

> Hi Steve,

Hi David!

> We seem to have very different views of these three languages:-)

Yes, we do.  :)

>>I have never heard of UML used that way in practice.  Are there any
>>real-world examples of programmers using it that way, or are the OMG
>>the only ones using it that way?  What data is being exchanged using
>>models developed that way?  (I mean real data, in production. ;)
> 
> A UML Class diagram and an XML encoding for exchange are how many, many data
> exchange applications work today. That's how ebXML is defined in OASIS too.
> I'm not talking about XMI at all. You need to get out more:-)

Too true.  :)

> The first OMG
> MDA standard was life sciences XML data exchange and the UML to XML binding
> was a Java program.

So I guess they're not using IDL any more!  Defining
the UML to XML binding directly as a Java program ...!  ;)

> Check out the eclipse EMF project too. You model in UML
> or Java and it creates the other, along with a read/write API and little
> editor... all automatically from one source.

I do know that one, but I wouldn't characterize that kind
of UML modeling as modeling of data exchange -- it's modeling of
application objects, which can (incidentally) be serialized into
XML.  Not a big deal -- I do can do that in Python, too.  :)

>>>However, I think an ontology is an entirely different beast. It's
>>>very important to map things into OWL as they are in the real world ...
>>
>>Which is *exactly* what ARM models do -- they describe the domain
>>in the domain expert's real-world terms.
> 
> An ARM defines information requirements for a domain - which is important
> but far from describing the whole domain.

Whoa, whoa, whoa!  I never claimed that an ARM describes "the
whole domain"!!

The philosophy behind ontology development it that an ontology
describes some part of a domain /from someone's (or some
application's) point of view/, not from all possible views!
This is explicitly stated in the OWL literature.

The information requirements (ARM model) *are* the content of an
ontology:  the domain from the ARM developer's point of view.

Therefore, an ontology is *not* an entirely different beast from
an EXPRESS model.  QED!  (I would say they are not the same, but
they have a *large* semantic overlap.)

> Look at some of the frameworks
> like RM-ODP or Zachman to see all the other bits that are required.

"Required" by whom?  Not by the end-user!  Those bits are required
for implementation, and possibly for users with other points of view.

Remember:  I was answering your statement that "an ontology is an
entirely different beast [from an EXPRESS model]" -- my point is that
an ARM *is* an ontology, from the ARM developer's point of view.

> And it's
> just not true that ARM models result in the proper distinction between
> classes and individuals in the real-world (see discussion below).

I never claimed that they do ... but that also depends on what you
mean by "real-world".

>>>... in order
>>>for the reasoners to work properly. For example, some UML Objects and
>>>EXPRESS entity instances should map to classes in OWL (e.g.
>>
>>Product_category
>>
>>>instances should be subclasses of the Product Class).
>>
>>No, Product_category instances are classes themselves --
>>it doesn't make sense for them to subclass the Product class,
>>whose instances are Products.  (Unless it's for an enterprise
>>whose product is taxonomies.  You don't see too many such
>>enterprises.  ;)
> 
> That's exactly what I said, subclasses ARE classes. In more detail:
> 
> ENTITY Product; ENTITY Product_category; ENTITY Product_category_assignment;
> 
> #1=PRODUCT('A');
> #2=PRODUCT_CATEGORY('Pump');
> #3=PRODUCT_CATEGORY_ASSIGNMENT(#1,#2);
> 
> ends up as
> 
> OWL CLASS Product
> OWL CLASS Pump subClassOf Product
> OWL Individual A

Except that that OWL stuff is *not* mapped from that EXPRESS stuff,
because the EXPRESS stuff does not contain a declaration of the
PRODUCT entity -- it only contains an instance of it (the OWL
Individual A).

> This is needed otherwise reasoners won't work because they don't understand
> Product_category_assignment.

I agree, but that simply reinforces my point that EXPRESS and OWL
are similar:  it is quite easy to exchange OWL data structures that
contain both ontologies and instance data.  OWL Full also allows
you to treat classes (such as PRODUCT_CATEGORY) as individuals.
Some reasoners might insist on OWL-DL, for "decidability", but in
the opinion of some, that's a bit of a fetish (and I agree :).

Combination of early and late-bound data in EXPRESS files is no
more idiomatic than the same thing in OWL files.  I don't think
it's a big issue.  In EXPRESS applications, it's much rarer for
both ends not to agree on the ontology before instance
data is exchanged than it will be in Semantic Web applications.

Besides, in a data exchange application, it's easy to separate
metadata exchanges and data exchanges.  Even in Semantic Web apps,
I don't think this will be a big issue for most inferencing
apps.  I suspect the most commonly used ontologies will be
well-known, and even the more obscure ones can be grabbed in advance
of any reasoning process -- hey, they're just web resources!  ;)

>>>OWL properties being
>>>first class concepts is also completely different from EXPRESS/UML.
>>
>>That is only a structural difference.  I would argue that OWL
>>properties are semantically equivalent to EXPRESS attributes.
>>In EXPRESS, a property is simply defined as part of its domain class's
>>declaration; in OWL, a property is defined in a separate declaration
>>that includes an "owl:domain" statement that specifies its domain class.
>>The information is the same, it's just presented differently.
> 
> It's not only a structural difference. It allows unnamed classes to be
> defined as restrictions on the properties and then used by set theory
> operations like intersection to create other classes. Classes don't have to
> be pre-defined, they can be inferred.

That has nothing to do with the fact that properties are first-class
in OWL and not first-class in EXPRESS.  But it does require EXPRESS-X, in
which you could use a mapping to do the same thing with the "extent" of an
ENTITY.  Okay, so OWL <-> (EXPRESS + EXPRESS-X).  ;)

Interesting.  Conceptually:  owl:Class <-> [exp:entity + expx:extent]

>>I disagree.  EXPRESS-X is what would enable mapping EXPRESS
>>models to SQL, UML, or OWL:
>>
>>EXPRESS-model  -[EXPRESS-X map 3]->  OWL-like-EXPRESS-model  -[direct]->
>>OWL
>>
>>... where the "-[direct]->" mapping means:
>>entity -> table for SQL,
>>entity -> class for UML or OWL.
>>
>>How sophisticated the EXPRESS-X has to be depends on the context of
>>the EXPRESS model.  If it's a STEP AIM model, the EXPRESS-X needed to
>>derive DDL-like, UML-like, or OWL-like models from it may have to
>>be fairly elaborate.
> 
> Not really. You cannot have an OWL-like-EXPRESS-model because OWL is so
> different from EXPRESS (see above).

Hmmm ... I think my diagram perhaps didn't convey my intended meaning.  ;)
It should have said "data conforming to XXX-model" instead of "XXX-model":

data-conforming-to-EXPRESS-AIM-model  -[EXPRESS-X map 3]->
    data-conforming-to-OWL-like-EXPRESS-schema  -["direct"]->
    OWL-instance-data-set-conforming-to-OWL-"equivalent"-of-EXPRESS-schema

... the last bit being, of course, an RDF/XML data set.

I think you would have to agree that it's easy to create an EXPRESS schema
that can be converted directly (naively :) into OWL Classes and Properties --
i.e., an ontology.  You've done that!  :)

> Trying to do this with EXPRESS-X is
> really stretching its usefulness.

Again, total disagreement -- this is right in EXPRESS-X's sweet spot!

Mind you, I don't necessarily think EXPRESS-X in its current form is
the be-all and end-all of mapping languages, but it's a good start.

Also, IMO, mapping languages are *way* more important than modeling
languages -- precisely because there are so darn *many* of the latter,
and now so many XML Schema standards, etc., etc.!  ;)

> Interesting chat....

Indeed!

Cheers,
Steve
From edbark at nist.gov  Wed Sep  8 18:53:33 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Wed Sep  8 18:06:06 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F63A7.8000405@comcast.net>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>	<413F51F2.2000002@nist.gov>
	<413F63A7.8000405@comcast.net>
Message-ID: <413F8D6D.90801@nist.gov>

Stephen Waterbury wrote:

I wrote:
>> ALL of the IRMs are essentially relational models, in which ENTITY is 
>> a synonym for Table.

Steve wrote:
> True, but they are part of the infinite class of relational
> models that would be totally impractical to use directly as
> physical relational database designs.  I'm aware that some
> experiments were done early on with using AIM-level models as
> relational database schemas, but I don't know of any that are
> used in practice, do you?

No, but I don't know what the schemas in any STEP databases look like. 
I thought the STEPTools internal form was exactly a relational version 
of the IRMs, but that is probably not, or at least not quite, correct.

I also said:
>> And if ANDOR and multiple inheritance weren't easy to do in SQL, they 
>> wouldn't be permitted in STEP models.

Steve replied:
> So you're saying that's a *requirement* that was observed in
> designing EXPRESS?  

I'm saying that what Part 11 says was to some extent influenced by the 
gang-of-four over the objections of the EXPRESS team, and what elements 
of Part 11 are used in STEP models and how they are used in STEP models 
was subject to outright dicta from the gang-of-four.  And if their prior 
experience had been in object modeling instead of data base modeling, 
they would never have allowed ANDORs.

> That's interesting, but still doesn't convince
> me that the early STEP architects really thought the issues through.

I hope I never said that. ;-) My opinion of the skills of the individual 
'early STEP architects' varies, but they blew it in several important 
ways.  No, the early STEP architects did not (probably could not) think 
the issues through.  They had a lot of modeling experience, but not a 
lot of breadth, there was internal dissension, and they were breaking 
new ground.  They agreed on a tried-and-true architectural model from 
the database world and abstracted it slightly.  But they interpreted it 
too narrowly in some ways and misapplied it in others.  Now much of this 
is hindsight, and although I can say "I told you so" with respect to two 
of the failures, I also know I would have made at least one of the same 
mistakes myself.

Steve excerpted:
>> And there are database biases in EXPRESS itself.  Requiring named 
>> SELECT types isn't a semantic notion; it is a requirement for database 
>> implementations (but only some OOPL 'union's).  The domain modelers 
>> may not be conscious of this bias, but they have been forced into it.

And went on:
> Are you kidding?  Domain modelers *love* named SELECT types!
> I disagree that it is not a semantic notion -- I think anything
> that is reified (such as a SELECT list) is nameable, even if
> it is not typically named outside of software.  If you're saying
> there's nothing in the "interpretation" that the name maps to,
> I'll agree only partially, because in some cases SELECT types are
> given names even in human discourse.

I should have left that out.  The main database bias in EXPRESS is the 
absence of a struct/record type and the equation of all aggregation 
types.  (Only in SQL can you get BAGs, by projection, and a LIST is a 
rule for maintenance of the rows in a Table.)  Semantically, there is a 
difference between a thing that is a SET or a LIST or an ARRAY, which 
should have a name, and the collection of things that satisfy a 
relationship, which is usually anonymous.  EXPRESS doesn't require any 
of them to be named, and neither does STEP modeling practice.  (In 
databases that is not a problem -- all multivalued attributes are 
separate tables.  In OOPLs and XML Schema there are various difficulties 
with this.)

Similarly, semantically there is a difference between the classes of 
instances that can satisfy an attribute, which MAY have a name, and a 
type that has instances drawn from two conjoined data types, like 
Java/XML "double" or the EXPRESS integer-or-? bounds type, which MUST 
have a name.  I think Steve and I agree on this.  Unlike aggregates, 
EXPRESS requires all SELECT data types to be named.  Why?  (In a 
database, the former SELECT types also have to be named, because you 
have to name the table that has all the keys in it.)

No semantic SELECT is ever between entities and primitive values, but it 
can be between structured values and primitive values.  And in the 
latter case, you can't share an undiscriminated union, you need a 
discriminator.  EXPRESS doesn't even allow a discriminator.  (The 
database model of an entity-select is just a key that matches the 
select-type table.  And the database model of a union is a table with 
columns headed by the type identifier -- in any row, all value columns 
but one are Null.  Note the parallel to Part 21.)

And there are bad EXPRESS models like:
   TYPE snarks = SET [0:?] OF snark;  END_TYPE;
   TYPE snark_select = SELECT(snark, snarks);  END_TYPE;
whose only excuse is economy of representation for those APs in which 
Sizeof(snarks) = 1.  (We only need a column, not a separate table.)

What I said is that EXPRESS and STEP models have a database bias, 
whether the modeler is conscious of it or not.  I first became aware of 
the database bias in information models when I first encountered the 
'foreign' modeling patterns of object modelers, who ostensibly had the 
same underlying entity/object semantic concepts at heart.  In each case, 
the natural model was being twisted somewhat to what the implementation 
found easy to represent.

>> ... That is 
>> why it is possible in 2004 to say that UML is closer to EXPRESS.
> 
> In theory perhaps;  I would say not in practice/application.

There I think David is right when he said, tongue firmly in cheek, that 
Steve should get out more. ;-)  There are now dozens of groups doing 
with UML what SC4 has traditionally done with EXPRESS.

And OBTW (subject of another email), with guidance and participation 
from Bernd Wenzel and Peter Wilson, along with some expert modelers with 
different backgrounds, one from OMG and one from CCSDS, TC211 considered 
using SC4 technologies -- EXPRESS and Part 21 -- long about 1996-7, and 
decided to use UML and the then forthcoming XML instead!  They devised 
their own UML subset with special stereotypes for some things, and their 
own mapping of that UML specialization to XML.

I wrote:
>> The problem is that EXPRESS concepts have a different 'flavor', as 
>> described in Part 11, and it takes a change of mindset to see them as 
>> expressing the OWL concepts.

Steve says:
> That seems a subjective judgment -- it didn't require a change
> of mindset for me.  I expect that to see EXPRESS concepts as
> expressing OWL concepts would seem obvious to someone who comes to 
> EXPRESS from the Semantic Web world, as well.  :)

I think Steve got this backwards.  It doesn't require much of a change 
in mindset to see how to write the basic EXPRESS constructs in OWL. 
What I said was that it takes a change in mindset (for an EXPRESS 
modeler) to see the representation of the OWL concepts in EXPRESS.  The 
OWL archictecture for describing information only partly overlaps the 
EXPRESS architecture, in characterizing the necessary properties of a 
Class.  In characterizing definitive properties of a class, and 
properties of properties, you have concepts that EXPRESS does not have 
in so many words.  OWL uses what would be EXPRESS operations on SET 
values to *define types*!  You can do much of this with Rules, but you 
have to think of these rules as "definitive" rather than "validating". 
In OWL, these rules determine "how I know this is an X and not a Y", not 
"whether this is a good X".  That's part of the mindset shift I had in mind.

>> So Steve is right in one way: there is a large overlap in what you can 
>> *declare* in EXPRESS and OWL.
> 
> In my view, there is also a huge semantic overlap.

Well, the corresponding one.  It isn't nearly so huge when you consider 
the intent of OWL.  The primary notion in EXPRESS is: When I have an X, 
it has these locally defined properties.  One primary notion in OWL is: 
when I have an X, it has these globally defined properties and these 
other locally defined ones.  The other primary notion in OWL is:
CLASS Y = QUERY(x <* Z : boolean exp); and CLASS Y = Z - X; where Z can 
be a declared type or GENERIC_ENTITY; and similar definitions.  That is, 
if x satisfies these rules, it is a Y.  And it is this combination of 
"global property" and "defined class" that are critical to the Semantic 
Web.  These ideas are critical in answering the question:  Is this 
document about the topic being searched?  The part that overlaps the 
EXPRESS model is about:  Does this document contain the information 
about that topic that is wanted?  The EXPRESS model is about ensuring 
that a conforming document contains the required information; the OWL 
model is about ensuring that a matching document contains interesting 
information.

> That's a good point; EXPRESS is not designed to deal gracefully
> with multiple namespaces, in general, whereas it is a fundamental
> requirement for OWL, which will be operating in a sea of
> homonyms!  (STEP also does, but doesn't usually acknowledge it.)

Exactly!

>  For my application, Web-search is a relatively
> lower-priority source of requirements.  However, the namespace-aware
> nature of RDF/RDFS/OWL is very useful when dealing with many standards
> and many ontologies which have to be integrated and/or reasoned over,
> which is one of the central problems facing Systems Engineering, and
> is therefore a current challenge in the STEP world, both in AP233 and
> in modularization in general.

Yup.  I think we are all entering a brave new world.  But we have to 
realize that these are baby steps, and it's a damn good thing they are!

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From golux at comcast.net  Thu Sep  9 02:30:17 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Thu Sep  9 01:48:06 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F8D6D.90801@nist.gov>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>	<413F51F2.2000002@nist.gov>	<413F63A7.8000405@comcast.net>
	<413F8D6D.90801@nist.gov>
Message-ID: <413FF879.3010601@comcast.net>

Ed,

Great points.  Also, thanks for clarifying who is saying what ...
this thread was getting a bit unwieldy!  ;)  Just a few short
comments below ...

Ed Barkmeyer wrote:

> I'm saying that what Part 11 says was to some extent influenced by the 
> gang-of-four over the objections of the EXPRESS team, and what elements 
> of Part 11 are used in STEP models and how they are used in STEP models 
> was subject to outright dicta from the gang-of-four.  And if their prior 
> experience had been in object modeling instead of data base modeling, 
> they would never have allowed ANDORs.

I assume the "gang-of-four" you refer to above are the early STEP
junta, rather than the "Software Patterns" GoF!  Heh.  :)

> ... semantically there is a difference between the classes of 
> instances that can satisfy an attribute, which MAY have a name, and a 
> type that has instances drawn from two conjoined data types, like 
> Java/XML "double" or the EXPRESS integer-or-? bounds type, which MUST 
> have a name.  I think Steve and I agree on this.

Yes!

> Unlike aggregates, 
> EXPRESS requires all SELECT data types to be named.  Why?  (In a 
> database, the former SELECT types also have to be named, because you 
> have to name the table that has all the keys in it.)

True, and I guess what you are saying is that the name usually
has no significance in the real world, to which I'd have to
agree.  In fact, even from a database point of view, although a
name is required, it's not necessary that it be specified in the
domain model (e.g., the EXPRESS), since it can be purely internal to
the database and can be generated by a mapping application that is
creating the physical database schema from the EXPRESS (or OWL ;)
schema, if necessary.  (Although in general I wouldn't take an
*arbitrary* EXPRESS or OWL model and try to generate a db schema
from it.  :)

> And there are bad EXPRESS models like:
>   TYPE snarks = SET [0:?] OF snark;  END_TYPE;
>   TYPE snark_select = SELECT(snark, snarks);  END_TYPE;
> whose only excuse is economy of representation for those APs in which 
> Sizeof(snarks) = 1.  (We only need a column, not a separate table.)

That's bizarre!  :)

> What I said is that EXPRESS and STEP models have a database bias, 
> whether the modeler is conscious of it or not.  I first became aware of 
> the database bias in information models when I first encountered the 
> 'foreign' modeling patterns of object modelers, who ostensibly had the 
> same underlying entity/object semantic concepts at heart.  In each case, 
> the natural model was being twisted somewhat to what the implementation 
> found easy to represent.

Okay, I'll concede that.  But I don't think it causes any semantic
mismatch between EXPRESS and OWL.

Ed wrote:
>>> ... That is why it is possible in 2004 to say that UML is closer to 
>>> EXPRESS.
and Steve replied:
>> In theory perhaps;  I would say not in practice/application.
to which Ed responded:
> There I think David is right when he said, tongue firmly in cheek, that 
> Steve should get out more. ;-)

Alas, he speaks the truth!  (But if I *did* get out more,
I'm not sure my first choice would be to go to OMG meetings or
UML user groups!  ;)

> There are now dozens of groups doing 
> with UML what SC4 has traditionally done with EXPRESS.

Dozens, eh?  Guess I'd better get my mapping tools honed ...
lotsa new variant schemas for the same stuff coming soon!
Ah, building the Tower of Babel offers such job security!  ;)

> And OBTW (subject of another email), with guidance and participation 
> from Bernd Wenzel and Peter Wilson, along with some expert modelers with 
> different backgrounds, one from OMG and one from CCSDS, TC211 considered 
> using SC4 technologies -- EXPRESS and Part 21 -- long about 1996-7, and 
> decided to use UML and the then forthcoming XML instead!  They devised 
> their own UML subset with special stereotypes for some things, and their 
> own mapping of that UML specialization to XML.

Good foresight.

Gee, everybody's so inventive!  I'd better get busy and devise *my*
UML subset with special stereotypes, too ... I don't want to be the
only kid on the block without one!  :)

> Ed wrote:
> 
>>> The problem is that EXPRESS concepts have a different 'flavor', as 
>>> described in Part 11, and it takes a change of mindset to see them as 
>>> expressing the OWL concepts.
> 
> Steve says:
> 
>> That seems a subjective judgment -- it didn't require a change
>> of mindset for me.  I expect that to see EXPRESS concepts as
>> expressing OWL concepts would seem obvious to someone who comes to 
>> EXPRESS from the Semantic Web world, as well.  :)

... and Ed responds:
> I think Steve got this backwards.

Wouldn't be the first time.  ;)

> It doesn't require much of a change 
> in mindset to see how to write the basic EXPRESS constructs in OWL. What 
> I said was that it takes a change in mindset (for an EXPRESS modeler)

OOoohhh -- you meant for an *EXPRESS* modeler.  Yeah, I've noticed
they tend to have a rather ... um ... "focused" mind-set.  :)

> to see the representation of the OWL concepts in EXPRESS.  The OWL 
> archictecture for describing information only partly overlaps the 
> EXPRESS architecture, in characterizing the necessary properties of a 
> Class.  In characterizing definitive properties of a class, and 
> properties of properties, you have concepts that EXPRESS does not have 
> in so many words.  OWL uses what would be EXPRESS operations on SET 
> values to *define types*!

Sometimes to "define", but sometimes as much to "describe" types as
to "define" them:  in OWL, you can declare a Class and then say
things about it without necessarily being definitive.  But by the same
token, mapping an EXPRESS model into OWL is a way of opening it up
to saying more (in descriptive logic) about it:  to compare EXPRESS
entities and their properties to other similar or dissimilar things --
in other words, to say more about the abstract, uninterpreted things
that are "specified" in an EXPRESS model, and to allow them to be
mapped to interpretations (in a model theoretic sense) in the
"real" world.

> You can do much of this with Rules, but you 
> have to think of these rules as "definitive" rather than "validating". 
> In OWL, these rules determine "how I know this is an X and not a Y", not 
> "whether this is a good X".  That's part of the mindset shift I had in 
> mind.

I'm not sure I agree completely with your characterization of the
mindset shift, but I will grant you OWL definitely brings an
additional perspective -- which is formally complementary in some
nice ways.

Ed:
>>> So Steve is right in one way: there is a large overlap in what you 
>>> can *declare* in EXPRESS and OWL.
Steve:
>> In my view, there is also a huge semantic overlap.
Ed:
> Well, the corresponding one.  It isn't nearly so huge when you consider 
> the intent of OWL.

No, I maintain that it's really huge!  Big big big.  Gigantic.
Massive.  :)

> The primary notion in EXPRESS is: When I have an X, 
> it has these locally defined properties.  One primary notion in OWL is: 
> when I have an X, it has these globally defined properties and these 
> other locally defined ones.  The other primary notion in OWL is:
> CLASS Y = QUERY(x <* Z : boolean exp); and CLASS Y = Z - X; where Z can 
> be a declared type or GENERIC_ENTITY; and similar definitions.  That is, 
> if x satisfies these rules, it is a Y.  And it is this combination of 
> "global property" and "defined class" that are critical to the Semantic 
> Web.

Yes ... in short:  Description Logic.

> These ideas are critical in answering the question:  Is this 
> document about the topic being searched?  The part that overlaps the 
> EXPRESS model is about:  Does this document contain the information 
> about that topic that is wanted?  The EXPRESS model is about ensuring 
> that a conforming document contains the required information; the OWL 
> model is about ensuring that a matching document contains interesting 
> information.

Yes, those are certainly typical use cases for each.  But
I would not say that EXPRESS is mainly about validation use cases.
EXPRESS is certainly as much about representation, navigation, and
persistence (db) use cases.  Validation is one aspect of representation,
but data access, searching, mapping, and assembly of information are
equally important use cases for EXPRESS models.  Likewise, OWL
models are intentionally designed to support all the use cases
for Description Logics, which include description, inference,
persistence, and even validation to some extent -- one heck of a
lot of overlap, in my view!  And, as I alluded to above, some nice
complementarity -- placing EXPRESS models in a real world
(and thus interpretation/verification) context.

>> That's a good point; EXPRESS is not designed to deal gracefully
>> with multiple namespaces, in general, whereas it is a fundamental
>> requirement for OWL, which will be operating in a sea of
>> homonyms!  (STEP also does, but doesn't usually acknowledge it.)
> 
> Exactly!
> 
>>  For my application, Web-search is a relatively
>> lower-priority source of requirements.  However, the namespace-aware
>> nature of RDF/RDFS/OWL is very useful when dealing with many standards
>> and many ontologies which have to be integrated and/or reasoned over,
>> which is one of the central problems facing Systems Engineering, and
>> is therefore a current challenge in the STEP world, both in AP233 and
>> in modularization in general.
> 
> Yup.  I think we are all entering a brave new world.  But we have to 
> realize that these are baby steps, and it's a damn good thing they are!

Agreed!  Thanks for a good discussion!

Cheers,
Steve

From Phil.Spiby at Eurostep.com  Thu Sep  9 05:13:26 2004
From: Phil.Spiby at Eurostep.com (Phil Spiby)
Date: Thu Sep  9 04:25:46 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413FF879.3010601@comcast.net>
Message-ID: <002a01c4964d$43b96c10$1965a8c0@ESUKPC25>

All,

What an interesting discussion!

I have resisted the urge to jump in a number of times, but feel that I would
like to put the record straight (at least to my world view!) on the history
of EXPRESS.

EXPRESS was originally defined by: 
 - a Physicist wanting to describe information
 - a computer scientist
 - an NC programmer with a background in Pascal
(I'm sure some of you can guess the individuals involved here! [I'm not one
of those!!])

EXPRESS was originally aimed at trying to describe the information to be
exchanged within an exchange file independent of the format of the exchange
file (build a better IGES!).

EXPRESS drew a lot of inspiration from ISO TR 9007 and aimed to cover at
least the static aspects of that work.

EXPRESS was always intended to be an OO language, since this has more
capability at defining class/sub-class which was believed to be needed. It
did not follow the OO paradigm of the time i.e. C++ since there were a
number of papers identifying problems with using C++ to describe real world
objects (subject to multiple classifications) and from this was born the
subtype constructs we have today. 

Steve Clark and I became involved in the 90's and tried to firm up the
definitions and logic to ensure that EXPRESS was at least implementable and
internally consistent. At the same time WG4 was making efforts to
standardize how EXPRESS should be used in SC4. When Ed refers to the Gang of
Four, I believe he means some key members from WG4 who were certainly
heavily entrenched in the relational database paradigm. There were efforts
to remove all aggregation types from the language (these can be handled with
relationships and constraints) and there was a brief effort to remove
subtyping from the language (this was quickly abandoned when the modellers
realised the amount of change that would result in their models!)

The resulting EXPRESS language is not wonderful, but then again how could it
be when defined by a number of committees, was used before it was finished,
so it could not be corrected without breaking models (a number of times we
have had to change the semantics of the language to match the intended
semantics of a particular model!).

Phil

-----Original Message-----
From: step-os-bounces@ned.gsfc.nasa.gov
[mailto:step-os-bounces@ned.gsfc.nasa.gov] On Behalf Of Stephen Waterbury
Sent: 09 September 2004 07:30
To: STEP Open-Source
Subject: Re: [step-os] Using STEPMod XML Representation of EXPRESS

Ed,

Great points.  Also, thanks for clarifying who is saying what ... this
thread was getting a bit unwieldy!  ;)  Just a few short comments below ...

Ed Barkmeyer wrote:

> I'm saying that what Part 11 says was to some extent influenced by the
> gang-of-four over the objections of the EXPRESS team, and what elements 
> of Part 11 are used in STEP models and how they are used in STEP models 
> was subject to outright dicta from the gang-of-four.  And if their prior 
> experience had been in object modeling instead of data base modeling, 
> they would never have allowed ANDORs.

I assume the "gang-of-four" you refer to above are the early STEP junta,
rather than the "Software Patterns" GoF!  Heh.  :)

> ... semantically there is a difference between the classes of
> instances that can satisfy an attribute, which MAY have a name, and a 
> type that has instances drawn from two conjoined data types, like 
> Java/XML "double" or the EXPRESS integer-or-? bounds type, which MUST 
> have a name.  I think Steve and I agree on this.

Yes!

> Unlike aggregates,
> EXPRESS requires all SELECT data types to be named.  Why?  (In a 
> database, the former SELECT types also have to be named, because you 
> have to name the table that has all the keys in it.)

True, and I guess what you are saying is that the name usually has no
significance in the real world, to which I'd have to agree.  In fact, even
from a database point of view, although a name is required, it's not
necessary that it be specified in the domain model (e.g., the EXPRESS),
since it can be purely internal to the database and can be generated by a
mapping application that is creating the physical database schema from the
EXPRESS (or OWL ;) schema, if necessary.  (Although in general I wouldn't
take an
*arbitrary* EXPRESS or OWL model and try to generate a db schema from it.
:)

> And there are bad EXPRESS models like:
>   TYPE snarks = SET [0:?] OF snark;  END_TYPE;
>   TYPE snark_select = SELECT(snark, snarks);  END_TYPE;
> whose only excuse is economy of representation for those APs in which
> Sizeof(snarks) = 1.  (We only need a column, not a separate table.)

That's bizarre!  :)

> What I said is that EXPRESS and STEP models have a database bias,
> whether the modeler is conscious of it or not.  I first became aware of 
> the database bias in information models when I first encountered the 
> 'foreign' modeling patterns of object modelers, who ostensibly had the 
> same underlying entity/object semantic concepts at heart.  In each case, 
> the natural model was being twisted somewhat to what the implementation 
> found easy to represent.

Okay, I'll concede that.  But I don't think it causes any semantic mismatch
between EXPRESS and OWL.

Ed wrote:
>>> ... That is why it is possible in 2004 to say that UML is closer to
>>> EXPRESS.
and Steve replied:
>> In theory perhaps;  I would say not in practice/application.
to which Ed responded:
> There I think David is right when he said, tongue firmly in cheek, 
> that
> Steve should get out more. ;-)

Alas, he speaks the truth!  (But if I *did* get out more,
I'm not sure my first choice would be to go to OMG meetings or UML user
groups!  ;)

> There are now dozens of groups doing
> with UML what SC4 has traditionally done with EXPRESS.

Dozens, eh?  Guess I'd better get my mapping tools honed ... lotsa new
variant schemas for the same stuff coming soon! Ah, building the Tower of
Babel offers such job security!  ;)

> And OBTW (subject of another email), with guidance and participation
> from Bernd Wenzel and Peter Wilson, along with some expert modelers with 
> different backgrounds, one from OMG and one from CCSDS, TC211 considered 
> using SC4 technologies -- EXPRESS and Part 21 -- long about 1996-7, and 
> decided to use UML and the then forthcoming XML instead!  They devised 
> their own UML subset with special stereotypes for some things, and their 
> own mapping of that UML specialization to XML.

Good foresight.

Gee, everybody's so inventive!  I'd better get busy and devise *my* UML
subset with special stereotypes, too ... I don't want to be the only kid on
the block without one!  :)

> Ed wrote:
> 
>>> The problem is that EXPRESS concepts have a different 'flavor', as
>>> described in Part 11, and it takes a change of mindset to see them as 
>>> expressing the OWL concepts.
> 
> Steve says:
> 
>> That seems a subjective judgment -- it didn't require a change of 
>> mindset for me.  I expect that to see EXPRESS concepts as expressing 
>> OWL concepts would seem obvious to someone who comes to EXPRESS from 
>> the Semantic Web world, as well.  :)

... and Ed responds:
> I think Steve got this backwards.

Wouldn't be the first time.  ;)

> It doesn't require much of a change
> in mindset to see how to write the basic EXPRESS constructs in OWL. What 
> I said was that it takes a change in mindset (for an EXPRESS modeler)

OOoohhh -- you meant for an *EXPRESS* modeler.  Yeah, I've noticed they tend
to have a rather ... um ... "focused" mind-set.  :)

> to see the representation of the OWL concepts in EXPRESS.  The OWL
> archictecture for describing information only partly overlaps the 
> EXPRESS architecture, in characterizing the necessary properties of a 
> Class.  In characterizing definitive properties of a class, and 
> properties of properties, you have concepts that EXPRESS does not have 
> in so many words.  OWL uses what would be EXPRESS operations on SET 
> values to *define types*!

Sometimes to "define", but sometimes as much to "describe" types as to
"define" them:  in OWL, you can declare a Class and then say things about it
without necessarily being definitive.  But by the same token, mapping an
EXPRESS model into OWL is a way of opening it up to saying more (in
descriptive logic) about it:  to compare EXPRESS entities and their
properties to other similar or dissimilar things -- in other words, to say
more about the abstract, uninterpreted things that are "specified" in an
EXPRESS model, and to allow them to be mapped to interpretations (in a model
theoretic sense) in the "real" world.

> You can do much of this with Rules, but you
> have to think of these rules as "definitive" rather than "validating". 
> In OWL, these rules determine "how I know this is an X and not a Y", not 
> "whether this is a good X".  That's part of the mindset shift I had in 
> mind.

I'm not sure I agree completely with your characterization of the mindset
shift, but I will grant you OWL definitely brings an additional perspective
-- which is formally complementary in some nice ways.

Ed:
>>> So Steve is right in one way: there is a large overlap in what you
>>> can *declare* in EXPRESS and OWL.
Steve:
>> In my view, there is also a huge semantic overlap.
Ed:
> Well, the corresponding one.  It isn't nearly so huge when you 
> consider
> the intent of OWL.

No, I maintain that it's really huge!  Big big big.  Gigantic. Massive.  :)

> The primary notion in EXPRESS is: When I have an X,
> it has these locally defined properties.  One primary notion in OWL is: 
> when I have an X, it has these globally defined properties and these 
> other locally defined ones.  The other primary notion in OWL is:
> CLASS Y = QUERY(x <* Z : boolean exp); and CLASS Y = Z - X; where Z can 
> be a declared type or GENERIC_ENTITY; and similar definitions.  That is, 
> if x satisfies these rules, it is a Y.  And it is this combination of 
> "global property" and "defined class" that are critical to the Semantic 
> Web.

Yes ... in short:  Description Logic.

> These ideas are critical in answering the question:  Is this
> document about the topic being searched?  The part that overlaps the 
> EXPRESS model is about:  Does this document contain the information 
> about that topic that is wanted?  The EXPRESS model is about ensuring 
> that a conforming document contains the required information; the OWL 
> model is about ensuring that a matching document contains interesting 
> information.

Yes, those are certainly typical use cases for each.  But
I would not say that EXPRESS is mainly about validation use cases. EXPRESS
is certainly as much about representation, navigation, and persistence (db)
use cases.  Validation is one aspect of representation, but data access,
searching, mapping, and assembly of information are equally important use
cases for EXPRESS models.  Likewise, OWL models are intentionally designed
to support all the use cases for Description Logics, which include
description, inference, persistence, and even validation to some extent --
one heck of a lot of overlap, in my view!  And, as I alluded to above, some
nice complementarity -- placing EXPRESS models in a real world (and thus
interpretation/verification) context.

>> That's a good point; EXPRESS is not designed to deal gracefully with 
>> multiple namespaces, in general, whereas it is a fundamental 
>> requirement for OWL, which will be operating in a sea of homonyms!  
>> (STEP also does, but doesn't usually acknowledge it.)
> 
> Exactly!
> 
>>  For my application, Web-search is a relatively lower-priority source 
>> of requirements.  However, the namespace-aware nature of RDF/RDFS/OWL 
>> is very useful when dealing with many standards and many ontologies 
>> which have to be integrated and/or reasoned over, which is one of the 
>> central problems facing Systems Engineering, and is therefore a 
>> current challenge in the STEP world, both in AP233 and in 
>> modularization in general.
> 
> Yup.  I think we are all entering a brave new world.  But we have to
> realize that these are baby steps, and it's a damn good thing they are!

Agreed!  Thanks for a good discussion!

Cheers,
Steve

_______________________________________________
step-os mailing list
step-os@step.nasa.gov http://step.nasa.gov/mailman/listinfo/step-os

From david.price at eurostep.com  Thu Sep  9 07:32:02 2004
From: david.price at eurostep.com (David Price)
Date: Thu Sep  9 06:44:34 2004
Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413F5B54.1000304@nist.gov>
Message-ID: <000001c49660$a06cfae0$2101a8c0@esukpc20>

Hi Ed,

I think you misunderstand my interests at the moment. Two responses to try
and clarify my views on this.

1-----

> > So, my question is . Are people generally comfortable with using the
> > STEPMod XML representation of EXPRESS as the de facto standard for
> > open-source STEP work?
> 
> Note how this conveniently views "open-source STEP work" as a different
> category of effort, requiring different standards, from "in-house STEP
> work" or "proprietary product STEP work".  What is sauce for the goose
> is evidently unsuitable for the gander in the UK.  (But then British
> cooking has never been highly regarded. ;-)

At the moment, I absolutely do consider my open-source work as outside the
standards world. It is of course standards-based, but it is basically a sand
box in which I play. I was trying to ask if others were comfortable using
this non-standard EXPRESS/XML in their sand box too. I don't see the problem
with experimenting outside the SC4 box in order to know what to do when
stepping back inside the box. The main point of exff today is to show what's
possible, and if I have to bend the rules temporarily, so be it. Over time,
I do expect exff translators to conform to the standards... but I'm not
worried about that just yet.

2------

> > I do not believe the text for the Part 28 E2 standard, if it is needed,
> is a
> > suitable replacement for the DTD user guide Josh proposed. I expect the
> user
> > guide would more closely resemble the text in Part 11 than anything Part
> 28
> > needs.
> 
> An interesting view:  The text that explains how to use this set of XML
> objects to convey an EXPRESS schema will be markedly different if it is
> in a technical report for the 'open-source STEP developer' community
> from what it would be in a Standard for the (unwashed?) STEP developer
> community.
> 
> Only in SC4 could such a mindset be possible:  Our standards are
> unintelligible, whereas our technical reports are lucid.  The problem,
> of course, is that this is largely valid!  ;-)  Josh's text would be a
> welcome departure.  But then David seems to think Part 11 is
> intelligible, and Martin insists that Part 21 is clear and lucid; so
> such a departure would not be so atypical for WG11.

UML is published and freely available from OMG and yet there are lots of
books, tutorials and user guides on UML. The same applies to any programming
language as well ... so I don't understand the criticism for wanting to do
the same thing for EXPRESS/XML. I've already started something along these
lines on exff ( http://www.exff.org/docs/express_guide.html ) and was hoping
to relate what Josh wrote for the DTD to that somehow. It's different from
the EXPRESS LRM/Part 28 text because it's informal and perhaps even slightly
inaccurate if glossing over complexity helps people just getting started.

Cheers,
David

From edbark at nist.gov  Thu Sep  9 10:59:43 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Thu Sep  9 10:12:11 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <413FF879.3010601@comcast.net>
References: <000001c4958c$c70489e0$2101a8c0@esukpc20>	<413F51F2.2000002@nist.gov>	<413F63A7.8000405@comcast.net>	<413F8D6D.90801@nist.gov>
	<413FF879.3010601@comcast.net>
Message-ID: <41406FDF.2070000@nist.gov>

Stephen Waterbury wrote:

> Gee, everybody's so inventive!  I'd better get busy and devise *my*
> UML subset with special stereotypes, too ... I don't want to be the
> only kid on the block without one!  :)

Of course!  Surely there must be a need for a "space electronics 
specialization" ...  This Profiles, metamodels and stereotypes stuff is 
definitely a cottage industry at OMG and in a few other IT locales. 
It's right up there with XML definition and constraint languages.

One of those trades in which the world needs about 25 experts is 
computer language design.  But we routinely teach it to computer science 
majors, and then they have to find an outlet for their creativity.  I 
have recommended music as a more worthwhile substitute.  One of my 
colleagues suggested hang gliding as offering probable net benefit to 
the trade. ;-)

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From david.price at eurostep.com  Thu Sep  9 13:55:16 2004
From: david.price at eurostep.com (David Price)
Date: Thu Sep  9 13:07:48 2004
Subject: [step-os] Seattle Session on STEP/EXPRESS and OWL/Knowledge
	Applications
Message-ID: <000801c49696$29d60850$2101a8c0@esukpc20>

All,

I've scheduled session a following-up on the one we held in Bath on
STEP/EXPRESS and how it relates to the Semantic Web activities, OWL, the OMG
UML/OWL work and knowledge applications in general.

I requested the session for TUESDAY afternoon from 1300 to 1700.

I've listed some agenda topics but others are welcome. There will be some
reporting of progress/issues/etc. since Bath as well. If anyone wants to
present anything, please let me know.

Cheers,
David

> -----Original Message-----
> From: david.price@eurostep.com [mailto:david.price@eurostep.com] 
> Sent: 09 September 2004 18:45
> To: david.price@eurostep.com
> Subject: Meeting Request For SC4 Meeting Seattle, WA, United 
> States - Requestor Copy
> 
> 
> 
> Here is the meeting request information you submitted:
> 
> Requestor: David Price
> EMail: david.price@eurostep.com
> Phone: +44 2077040499
> Organization: Eurostep	
> Meeting Name: STEP/EXPRESS and Semantic Web/OWL/UML
> Start Date: 2004-10-05
> Time(s): 
> 1:00pm - 3:00pm 3:30pm - 5:00pm 
> 
> Comments/Additional Information: 
> Agenda Inputted: 1 - Introductions
> 2 - Review results of Bath discussions
> 3 - Update on EXPRESS/OWL/UML activities
> 4 - Progress on OWL for reference data
> 5 - EXPRESS/OWL Structure mapping
> 6 - STEP-based reasoning using OWL
> 7 - Other knowledge representations
> 8 - Next actions
> Working Group: WG11		
> Number of Attendees: 10		
> AV-Option: Overhead Projector 
> 

From golux at comcast.net  Thu Sep  9 14:33:50 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Thu Sep  9 13:46:36 2004
Subject: [step-os] Fwd: Ontology Definition Metamodel Review Draft
Message-ID: <4140A20E.2040801@comcast.net>

Somewhat in the vein of the thread of the past few days,
the attached may be of interest.

- Steve
----------

>Delivered-To: daml-all-outgoing@daml.org
>Delivered-To: daml-all@daml.org
>From: "Hart, Lewis" <lewishart@att.com>
>To: daml-all@daml.org
>Subject: Ontology Definition Metamodel Review Draft
>Date: Wed, 8 Sep 2004 10:03:00 -0400
>Sender: owner-daml-all@wrath.daml.org
>
>The ODM submission team responding to the Object Management Group's (OMG)
>Ontology Definition Metamodel (ODM) RFP are pleased to announce the release
>of a draft response for review and comment.
>
>The release includes the proposed MOF meta-models for RDFS, OWL, Topic Maps,
>Entity-Relation Diagrams and generic Description Logics in several formats,
>and a PDF version of the draft text for volume one of the response which
>discusses these meta-models. Sections not provided in this draft include
>design rationale, compliance points, metamodel mappings, and UML profiles.
>The draft may be downloaded from: <http://codip.grci.com/odm/draft/>.
>
>Please direct comments on the draft to: odm-comments@att.com
><mailto:odm-comments@att.com>
>
>Please direct access or other administrative concerns to: Patrick Emery at
>patemery@att.com <mailto:patemery@att.com>
>
>Respectfully,
>Lewis Hart, for the ODM submission team.
>
>Lewis L Hart
>Chief Scientist - Intelligent Agent Systems
>------------------------------------------
>AT&T Government Solutions lewishart@att.com
>1900 Gallows Rd.       Voice (703) 506-5938
>Vienna, Va 22182         Fax (703) 556-4261

From thurman.tom at mcleod.net  Thu Sep  9 21:54:01 2004
From: thurman.tom at mcleod.net (tom thurman)
Date: Thu Sep  9 21:06:23 2004
Subject: [step-os] Re: step-os Digest, Vol 4, Issue 5
In-Reply-To: <200409090548.i895m8CK014956@ned.gsfc.nasa.gov>
References: <200409090548.i895m8CK014956@ned.gsfc.nasa.gov>
Message-ID: <41410939.3070804@mcleod.net>

wow!
Any chance of porting this discussion to a wiki?
My head hurts!
Tom Thurman

step-os-request@ned.gsfc.nasa.gov wrote:

>Send step-os mailing list submissions to
>	step-os@step.nasa.gov
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://step.nasa.gov/mailman/listinfo/step-os
>or, via email, send a message with subject or body 'help' to
>	step-os-request@step.nasa.gov
>
>You can reach the person managing the list at
>	step-os-owner@step.nasa.gov
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of step-os digest..."
>
>
>Today's Topics:
>
>   1. Re: Using STEPMod XML Representation of EXPRESS (Ed Barkmeyer)
>   2. Re: Using STEPMod XML Representation of EXPRESS
>      (Stephen Waterbury)
>   3. Re: Using STEPMod XML Representation of EXPRESS (Ed Barkmeyer)
>   4. Re: Using STEPMod XML Representation of EXPRESS
>      (Stephen Waterbury)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 08 Sep 2004 16:43:25 -0400
>From: Ed Barkmeyer <edbark@nist.gov>
>Subject: Re: [step-os] Using STEPMod XML Representation of EXPRESS
>To: STEP Open-Source <step-os@ned.gsfc.nasa.gov>
>Message-ID: <413F6EED.8050602@nist.gov>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>
>A second short note.
>
>Stephen Waterbury wrote:
>
>  
>
>>David Price wrote:
>>    
>>
>>>...
>>>OWL properties being
>>>first class concepts is also completely different from EXPRESS/UML.
>>>      
>>>
>>That is only a structural difference.  I would argue that OWL
>>properties are semantically equivalent to EXPRESS attributes.
>>In EXPRESS, a property is simply defined as part of its domain class's
>>declaration; in OWL, a property is defined in a separate declaration
>>that includes an "owl:domain" statement that specifies its domain class.
>>The information is the same, it's just presented differently.
>>    
>>
>
>I agree with Steve this time.  The syntactic characteristics are not 
>important.  But as I said before, the important feature of OWL is that I 
>can say that two properties with entirely different domains are 
>semantically equivalent.  That the OWL property declaration syntax 
>facilitates this within a namespace is nice, but it is imperative that 
>one be able to state the equivalence across namespaces (by qualifying 
>the property names).  That is the critical OWL idea.  I can qualify 
>property names in EXPRESS; but I have no way to state the semantic 
>equivalence.
>
>  
>
>>(BTW, I've always felt that EXPRESS should regard properties as first
>>class -- as they are in the IEC 61360 dictionary, for example, and
>>in PLIB, which uses the same dictionary standard.)
>>    
>>
>
>Dictionaries traditionally regard all concepts as first-class, and then 
>provide several distinct domain-specific definitions for many 
>"properties".  Ideally, you want the ability to make them either local 
>or global, like ASN.1 and XML Schema.  Then you can say what you mean.
>
>But a lot of "global properties" produce subtle semantic confusion.  The 
>problem is in agreeing on the exact characteristics of the common 
>property.  Using the common STEP 'id' attribute as an example, almost 
>all uses of 'id' have range 'identifier'.  But there is no expectation 
>that there is any syntactic commonality in the 'identifier' values.  So 
>while there may be value in modeling 'id' as a global property, there 
>may be more value in modeling 'product.id' as a local property that 
>embodies rules for product identification. The problem arises when I 
>intend the latter "extended" property and use the global term.  If I do 
>this twice and later discover instances with dual inheritance:
>  (a) when the property is single-valued, the two values may not be the 
>same (!), even though they are both stated to be THE value of the same 
>global property, because the interpretation included the context of use.
>  (b) when the property is multi-valued, the local implications of the 
>values inherited from one ancestor may not be the same as the local 
>implications of the values inherited from the other, because each 
>ancestor embodies a different local semantic extension.
>
>So when you use "global properties", you have to be very careful about 
>the common interpretation.
>
>One thing that I would like to do in OWL and can't is to "refine" a 
>"property".  E.g., captain_of(Person, Ship) is a special case of (or 
>"implies") crew_member(Person, Ship).  I can do this in ORM and UML, and 
>in EXPRESS I can do it with a RULE, but in OWL I have to reify the 
>property relationship into a class/entity and subtype the reified 
>relationship.  (And then I have to create pseudo-"properties" for 
>'relating_item' and 'related_item', etc.)
>
>-Ed
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://step.nasa.gov/pipermail/step-os/attachments/20040909/fdd8e94d/attachment-0001.html
From radack at ctc.com  Thu Sep  9 18:54:15 2004
From: radack at ctc.com (Radack, Gerald)
Date: Thu Sep  9 23:21:09 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
Message-ID: <58BD7BA1E81ED54E88F2266E149D93D6305214@ctcjst-mail1.ad.ctcgsc.org>

 
> Of course!  Surely there must be a need for a "space electronics 
> specialization" ...  This Profiles, metamodels and 
> stereotypes stuff is 
> definitely a cottage industry at OMG and in a few other IT locales. 
> It's right up there with XML definition and constraint languages.

Right on! I once heard a great keynote speech (at an XML conference) by a wise person whose message was: "Beware the danger of 'meta'." What he said was that when modelers are faced with a hard modeling problem in some domain, they are often tempted to build a meta-model instead, because it is easier and more fun. But building a meta-model can be a dangerous diversion, because it does not solve the real problem of needing a model for the domain.

> One of those trades in which the world needs about 25 experts is 
> computer language design.  But we routinely teach it to 
> computer science 
> majors, and then they have to find an outlet for their creativity.  I 
> have recommended music as a more worthwhile substitute.  One of my 
> colleagues suggested hang gliding as offering probable net benefit to 
> the trade. ;-)

Agree again. Let's teach them EXPRESS data modeling instead! :-)
 

From golux at comcast.net  Fri Sep 10 00:13:02 2004
From: golux at comcast.net (Stephen Waterbury)
Date: Thu Sep  9 23:30:45 2004
Subject: [step-os] Re: step-os Digest, Vol 4, Issue 5
In-Reply-To: <41410939.3070804@mcleod.net>
References: <200409090548.i895m8CK014956@ned.gsfc.nasa.gov>
	<41410939.3070804@mcleod.net>
Message-ID: <414129CE.7050407@comcast.net>

tom thurman wrote:
> wow!
> Any chance of porting this discussion to a wiki?
> My head hurts!
> Tom Thurman

Mine, too ... :)

It's all available in the step-os archives:

http://step.nasa.gov/pipermail/step-os/2004-September/thread.html

Thanks, Mailman (and Barry Warsaw for writing it)!
(Yet another excellent Python application!  ;)

- Steve
From edbark at nist.gov  Fri Sep 10 09:40:09 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Fri Sep 10 08:52:30 2004
Subject: [Fwd: Re: [wg11] Re: [step-os] Using STEPMod XML Representation of
	EXPRESS]
Message-ID: <4141AEB9.3080407@nist.gov>

Obviously a colleague...

-------- Original Message --------
Subject: Re: [wg11] Re: [step-os] Using STEPMod XML Representation of 
EXPRESS
Date: Fri, 10 Sep 2004 13:38:20 +0900
From: Fumiki Tanaka <ftanaka@ssi.ist.hokudai.ac.jp>
Reply-To: Fumiki Tanaka <ftanaka@ssi.ist.hokudai.ac.jp>
To: 'SC4 WG11' <wg11@steptools.com>
References: <001201c495bb$166642c0$2101a8c0@esukpc20> 
<413F5B54.1000304@nist.gov>

Dear every Part28-ed2 developers.

I'm commentator of JP5. Because of the request, I will mention about the
comments.

1) Relationship between JP4 and JP5
There is no relation between JP4 and JP5.
In JP4 I required the precise examples of the EXPRESS and XML.
On the other hand, I need only specification of the form of XML 
documents containing EXPRESS schemas using more meaningful tags in JP5.

2)Usage of Part28ed2 EXPRESS and requirement.

My plan to use Part28ed2 is as follows.

EXPRESS--<tool>-->Part28ed2 --<XSLT>-->XML Schema
 
-->(RelaxNG) : I don't have plan now.
                                                                      -->XMI
 
-->Document

I need some stable and translative representation for XSLT.

Sorry, I don't know the stepmod representation, I cannot judge the 
stepmod rep. is better or not.
However, if that representation can map to these schemas using XSLT, 
this is OK.

Graduate School of Information Science and Technology
Hokkaido University, JAPAN
Fumiki Tanaka
ftanaka@ssi.ist.hokudai.ac.jp

_______________________________________________
wg11 mailing list
wg11@steptools.com
http://lists.steptools.com/mailman/listinfo/wg11

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From edbark at nist.gov  Fri Sep 10 10:54:04 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Fri Sep 10 10:06:27 2004
Subject: [wg11] Re: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <000701c496f0$001944f0$396120ca@coin.eng.hokudai.ac.jp>
References: <001201c495bb$166642c0$2101a8c0@esukpc20>	<413F5B54.1000304@nist.gov>
	<000701c496f0$001944f0$396120ca@coin.eng.hokudai.ac.jp>
Message-ID: <4141C00C.8040700@nist.gov>

Tanaka-san,

Thank you very much for the clarification.

Fumiki Tanaka wrote:

> 2)Usage of Part28ed2 EXPRESS and requirement.
> 
> My plan to use Part28ed2 is as follows.
> 
> EXPRESS--<tool>-->Part28ed2 --<XSLT>-->XML Schema
> -->(RelaxNG) : I don't have plan now.
> -->XMI
> -->Document
> 
> I need some stable and translative representation for XSLT.
> 
> Sorry, I don't know the stepmod representation, I cannot judge the stepmod
> rep. is better or not.
> However, if that representation can map to these schemas using XSLT, this is
> OK.

I think you will find that this is very much the same kind of concern as 
that of the STEP Open Source folks, and they would probably welcome you 
into that community.

In both the Part 28 v1 markup and the STEPmod markup, Entity, Attribute, 
   Attribute-type, Rule, and so on are marked up.

The primary distinction is in those EXPRESS constructs that involve 
"expressions" of one kind or another.  The STEPmod markup makes the 
whole expression a single CDATA string value; the Part 28v1 markup 
markup makes each variable and operation and subexpression a separate 
XML element.  For example,
   ENTITY snark;
    shares_owned : INTEGER;
    boojum : BOOLEAN;
   WHERE
    wr1: NOT boojum OR shares_owned > 1;
   END_ENTITY;

The STEPmod and P28v1 markups for
   ENTITY snark;
    shares_owned : INTEGER;
    boojum : BOOLEAN;
are similar, both something like:
   <entity name="snark">
     <attribute name="shares_owned">
       <integer-type/>
     </attribute>
     <attribute name="boojum">
       <boolean-type/>
     </attribute>

But the markup for
  wr1: NOT boojum OR shares_owned > 1;

in the STEPmod case is something like:
  <Where-rule name="wr1">NOT boojum OR shares_owned &gt; 1</Where-rule>

while the markup in the P28v1 case is something like:
  <Where-rule>
   <identifier>wr1</identifier>
   <boolean-expression>
     <operation name="OR">
       <operation name="NOT">
         <attribute-ref>boojum</attribute-ref>
       </operation>
       <operation name="&gt;">
         <attribute-ref>shares_owned</attribute-ref>
         <integer-literal>1</integer-literal>
       </operation>
     </operation>
   </boolean-expression>
  </Where-rule>

Part 28v1 produces a parse of the EXPRESS per the grammar in Part 11, 
eliminating only the 1-to-1 reductions.  The STEPmod representation is 
really a representation of the EXPRESS model as captured in the 
"meta-model" of the STEPmod database -- an interpretation of the EXPRESS 
schema into the fundamental concepts of the EXPRESS language.

As David Price points out, unless your intent is to transform the 
EXPRESS to OCL, you don't need to have the expression detail, and the 
parse detail greatly complicates the representation, the processing, and 
the XSLT transforms.

For comparison, in 2000, the OMG community standardized a metamodel for 
UML, and XMI as a means of conveying just such "meta-models" of model 
schemas.  OMG is only just now working on a standard for conveying the 
"syntactic parse" of UML (called "diagram interchange").  In the UML 
model, OCL (where-) rules are attached to classes (entities) as 
'annotations', and in XMI you can choose whether to pass an annotation 
as text or as marked up content.

Personally, I see Part 25v2 as the future standard for the exchange of 
EXPRESS *models*.  But I see a standard meta-model of EXPRESS, 
represented using MOF concepts, as the way to achieve that.  Then we 
don't need to standardize XML markup for EXPRESS models; we just use 
XMI.  With that view, I would recommend that we *reject* JP-5 and 
include no such markup in Part 28.  But I'm not sure that matches David 
Price's view of Part 25, and doing nothing now risks taking another 3 
years to provide a Standard, or worse yet, taking another 4-5 years to 
agree on what the requirements for such a Standard might be.  So, in the 
absence of a clear roadmap for WG11, I am inclined to accept JP-5, pick 
a useful representation, and think of it as an 'interim solution'.

Since Masa-san will be there and David will be there, can we talk about 
this in Seattle?

-Ed

"As they say: For any engineering task, you build one and throw it away;
then you build the real one.  The ISO development process must therefore
be 'SLOW prototyping'."
   -- Brian Meek

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From edbark at nist.gov  Fri Sep 10 11:34:53 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Fri Sep 10 10:47:13 2004
Subject: [step-os] Part 28 comment JP-5 meets EXPRESS Ed.2
Message-ID: <4141C99D.40506@nist.gov>

All,

With respect to JP-5, we decided in Groton (in the absence of Japanese 
or UK or Norway representatives) to let Part 28 v1 stand as an ISO TS, 
with the "parsed exchange of EXPRESS models" as specified in Annex C of 
that Edition.

Per the previous email, that probably does not meet the intent of JP-5.

But, since Part 28 v1 Annex C is a direct explosion of the Part 11:1994 
*grammar* into XML, there is another problem.  In Part 11:2004, that 
grammar has changed in a number of places, which causes the EXPRESS Ed2 
*parse* to be somewhat different from the EXPRESS v1 parse, even for an 
EXPRESS corpus that conforms to both grammars.  That makes the use of 
Part 28 v1 Annex C very difficult to explain!

Further, because of the EXPRESS Ed.2 introduction of ABSTRACT ENTITY and 
"generic attributes", EXTENSIBLE types, and attribute RENAME, most of 
these grammar changes affect the parse of entities, attributes and data 
types!  That means that the most important use of the v1 mapping is 
disaligned with the Part11 Ed2 grammar!  So in answer to David's 
question, this is a strong reason why not.

The P28v1 mapping applies only to an EXPRESS Ed1 schema, using the now 
"provisionally retained" EXPRESS Ed1 (and its grammar) to interpret the 
XML elements.

I don't see that SC4 can continue to support the Part 28 v1 mapping as 
relevant, particularly for the exchange of "module schemas".  And I 
don't believe that "use Part 28 v1 Annex C" is in any sense a 
satisfactory resolution of JP-5.

-Ed

P.S.  Sorry for the belated epiphany.  I had to say the word "parse" in 
the email to Tanaka-san, before I realized what the problem was.

P.P.S.  Note also that this is a strong argument for the meta-model 
concept hidden in the STEPmod representation.  EXPRESS v2 is 
semantically an upward-compatible extension of EXPRESS v1, and the 
language is also an upward-compatible extension.  But the *grammar*, as 
a set of production rules, is *not* an upward-compatible extension.  And 
because the Part 28 v1 mapping represents the production rules verbatim, 
it is now useless.  (For Josh's benefit, I would say that this is a 
doc-head thing -- a grammar is a corpus model, not a content model.)

-- 
Edward J. Barkmeyer                        Email: edbark@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."

From david.price at eurostep.com  Fri Sep 10 12:17:54 2004
From: david.price at eurostep.com (David Price)
Date: Fri Sep 10 11:30:11 2004
Subject: [step-os] Part 28 comment JP-5 meets EXPRESS Ed.2
In-Reply-To: <4141C99D.40506@nist.gov>
Message-ID: <000001c49751$ba1fae00$2101a8c0@esukpc20>

Ed,

Very good point about Part 28 E1 DTD for EXPRESS not supporting EXPRESS 2.
Given that, I suggest falling back to one of my earlier suggestions:

Include the STEPMod DTD as an informative annex in Part 28 E2 - or run it
through an XML tool that translates DTDs to XML Schema and include that XML
Schema instead. As I've also mentioned, the STEPMod DTD uses very familiar
terms from Part 11 so I actually don't think there's any need for text to
describe what the elements are for... it's obvious if you know Part 11. By
definition, anyone implementing Part 28 E2 must be EXPRESS-literate. I
suggest an informative annex for two reasons: 1) other EXPRESS tool vendors
have not yet implemented the DTD and 2) the STEPMod developers will be less
concerned about SC4 standardizing something for an unintended purpose. I
grant that there are also good reasons to make it normative, but I expect
that would force people to review it seriously and want to change it.

Below is the extract of that DTD for entity data types and global rule so
you can see its approach :

<!ELEMENT entity (description?, explicit*, derived*, inverse*, unique*,
where*, graphic.element?)>
<!ATTLIST entity
	name NMTOKEN #REQUIRED
	abstract.entity (YES | NO) "NO"
	abstract.supertype (YES | NO) "NO"
	supertypes NMTOKENS #IMPLIED
	super.expression CDATA #IMPLIED
>

<!ELEMENT rule (description?, algorithm?, where+)>
<!ATTLIST rule
	name NMTOKEN #REQUIRED
	appliesto NMTOKENS #REQUIRED
>

<!ELEMENT algorithm (#PCDATA)>

Would this satisfy JP-5?

FYI, the graphic.element is an extension allowing an EXPRESS-G diagram to be
related to an entity type. As I said earlier, this DTD was aimed at being
part of a system for producing documentation. These extensions might be
useful to developers, and as long as the annex is informative, I see no
reason to remove them.

With respect to its use for other purposes, I'll add that this DTD is the
basis for the hardcoded Part 28 E2 EXPRESS-to-XML Schema that we implemented
and discussed at the STEP meetings. I've also used it for EXPRESS to UML
translations based on a subset of Part 25 and it seems sufficient.

Cheers,
David

> -----Original Message-----
> From: step-os-bounces@ned.gsfc.nasa.gov 
> [mailto:step-os-bounces@ned.gsfc.nasa.gov] On Behalf Of Ed Barkmeyer
> Sent: 10 September 2004 16:35
> To: SC4 WG11; STEP Open-Source
> Subject: [step-os] Part 28 comment JP-5 meets EXPRESS Ed.2
> 
> 
> All,
> 
> With respect to JP-5, we decided in Groton (in the absence of 
> Japanese 
> or UK or Norway representatives) to let Part 28 v1 stand as 
> an ISO TS, 
> with the "parsed exchange of EXPRESS models" as specified in 
> Annex C of 
> that Edition.
> 
> Per the previous email, that probably does not meet the 
> intent of JP-5.
> 
> But, since Part 28 v1 Annex C is a direct explosion of the 
> Part 11:1994 
> *grammar* into XML, there is another problem.  In Part 11:2004, that 
> grammar has changed in a number of places, which causes the 
> EXPRESS Ed2 
> *parse* to be somewhat different from the EXPRESS v1 parse, 
> even for an 
> EXPRESS corpus that conforms to both grammars.  That makes the use of 
> Part 28 v1 Annex C very difficult to explain!
> 
> Further, because of the EXPRESS Ed.2 introduction of ABSTRACT 
> ENTITY and 
> "generic attributes", EXTENSIBLE types, and attribute RENAME, most of 
> these grammar changes affect the parse of entities, 
> attributes and data 
> types!  That means that the most important use of the v1 mapping is 
> disaligned with the Part11 Ed2 grammar!  So in answer to David's 
> question, this is a strong reason why not.
> 
> The P28v1 mapping applies only to an EXPRESS Ed1 schema, 
> using the now 
> "provisionally retained" EXPRESS Ed1 (and its grammar) to 
> interpret the 
> XML elements.
> 
> I don't see that SC4 can continue to support the Part 28 v1 
> mapping as 
> relevant, particularly for the exchange of "module schemas".  And I 
> don't believe that "use Part 28 v1 Annex C" is in any sense a 
> satisfactory resolution of JP-5.
> 
> -Ed
> 
> P.S.  Sorry for the belated epiphany.  I had to say the word 
> "parse" in 
> the email to Tanaka-san, before I realized what the problem was.
> 
> P.P.S.  Note also that this is a strong argument for the meta-model 
> concept hidden in the STEPmod representation.  EXPRESS v2 is 
> semantically an upward-compatible extension of EXPRESS v1, and the 
> language is also an upward-compatible extension.  But the 
> *grammar*, as 
> a set of production rules, is *not* an upward-compatible 
> extension.  And 
> because the Part 28 v1 mapping represents the production 
> rules verbatim, 
> it is now useless.  (For Josh's benefit, I would say that this is a 
> doc-head thing -- a grammar is a corpus model, not a content model.)
> 
> -- 
> Edward J. Barkmeyer                        Email: edbark@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."
> 
> _______________________________________________
> step-os mailing list
> step-os@step.nasa.gov http://step.nasa.gov/mailman/listinfo/step-os
> 

From david.price at eurostep.com  Fri Sep 10 12:20:32 2004
From: david.price at eurostep.com (David Price)
Date: Fri Sep 10 11:32:47 2004
Subject: [step-os] Using STEPMod XML Representation of EXPRESS
In-Reply-To: <58BD7BA1E81ED54E88F2266E149D93D6305214@ctcjst-mail1.ad.ctcgsc.org>
Message-ID: <000101c49752$1884b800$2101a8c0@esukpc20>

All,

Gerry Radack suggested...

> 
> > One of those trades in which the world needs about 25 experts is
> > computer language design.  But we routinely teach it to 
> > computer science 
> > majors, and then they have to find an outlet for their 
> creativity.  I 
> > have recommended music as a more worthwhile substitute.  One of my 
> > colleagues suggested hang gliding as offering probable net 
> benefit to 
> > the trade. ;-)
> 
> Agree again. Let's teach them EXPRESS data modeling instead! :-)
>  

We may be successful at this if we hide it from them by using UML for the
diagrams:-) That'll be one result of the proposed Part 25 E2 content. As Ed
mentioned, at some point we'll also have more native support from OMG with a
MOF model of EXPRESS. We intend on doing that as Part 25 E3, starting work
as soon as the UML2 MOF2 and XMI 2 finalization task forces complete their
work in a couple of months.

Cheers,
David

From lubell at nist.gov  Fri Sep 10 12:25:41 2004
From: lubell at nist.gov (Josh Lubell)
Date: Fri Sep 10 11:38:02 2004
Subject: [step-os] thoughts on documenting STEPmod
Message-ID: <4141D585.8060103@nist.gov>

Orthogonal to all the discussion on the relationship between the STEPmod 
EXPRESS model XML format and the Japan ballot comment on Part 28e2, I 
have been looking at the current STEPmod DTD and existing XML-tagged 
EXPRESS models in the modules repository conforming to the DTD.

I notice that the DTD is looser than (what I believe to be) the actual 
constraints on STEPmod. Two examples:

1. The DTD permits an EXPRESS attribute to have a named type where the 
typename isn't specificed anywhere else in the XML data.

2. The DTD does not enforce EXPRESS grammar rules for bound 
specifications. For example, it allows you to specify an upper bound 
without a lower bound.

Because the STEPmod DTD alone is insufficient for constraining STEPmod 
XML format, I believe that a specification documenting the format should 
not be DTD-specific, but rather should include the DTD as an informative 
annex, along with XML Schema and RELAX NG annexes. Actually, RELAX NG is 
probably the best XML schema language for representing the STEPmod 
format. I say this because all of the information in STEPmod is in XML 
attributes, and RELAX NG is better at representing XML attribute 
co-occurrence constraints than DTDs or XML Schema.

Regards,
Josh

-- 
Joshua Lubell
National Institute of Standards and Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263
Gaithersburg MD 20899-8263, USA
Phone: 1-301-975-3563, Fax: 1-301-975-4694
Email: lubell@nist.gov

From david.price at eurostep.com  Fri Sep 10 12:59:52 2004
From: david.price at eurostep.com (David Price)
Date: Fri Sep 10 12:12:08 2004
Subject: [step-os] thoughts on documenting STEPmod
In-Reply-To: <4141D585.8060103@nist.gov>
Message-ID: <000001c49757$9719b5d0$2101a8c0@esukpc20>

Josh,

Those are all good ideas. 

How much work would that add to the Part 28 E2 project which, it appears,
will shortly be without an editor?

Also, please remember that the only reason the STEPMod DTD exists is as part
of a system for creating documentation. It assumes the validity of the
EXPRESS schema is checked by any parser that outputs an XML document
representing the schema. As I think I said in an email somewhere, it did not
need to be perfect, just good enough for its intended use.

A thought just occurred to me (it does happen occasionally), what about
including the STEPMod DTD as part of Part 25 E2? We could use it as part of
the UML/EXPRESS mapping specification. Is there any reason it must be
standardized in Part 28 E2?

Cheers,
David

> -----Original Message-----
> From: step-os-bounces@ned.gsfc.nasa.gov 
> [mailto:step-os-bounces@ned.gsfc.nasa.gov] On Behalf Of Josh Lubell
> Sent: 10 September 2004 17:26
> To: step-os@ned.gsfc.nasa.gov
> Subject: [step-os] thoughts on documenting STEPmod
> 
> 
> Orthogonal to all the discussion on the relationship between 
> the STEPmod 
> EXPRESS model XML format and the Japan ballot comment on Part 28e2, I 
> have been looking at the current STEPmod DTD and existing XML-tagged 
> EXPRESS models in the modules repository conforming to the DTD.
> 
> I notice that the DTD is looser than (what I believe to be) 
> the actual 
> constraints on STEPmod. Two examples:
> 
> 1. The DTD permits an EXPRESS attribute to have a named type 
> where the 
> typename isn't specificed anywhere else in the XML data.
> 
> 2. The DTD does not enforce EXPRESS grammar rules for bound 
> specifications. For example, it allows you to specify an upper bound 
> without a lower bound.
> 
> Because the STEPmod DTD alone is insufficient for 
> constraining STEPmod 
> XML format, I believe that a specification documenting the 
> format should 
> not be DTD-specific, but rather should include the DTD as an 
> informative 
> annex, along with XML Schema and RELAX NG annexes. Actually, 
> RELAX NG is 
> probably the best XML schema language for representing the STEPmod 
> format. I say this because all of the information in STEPmod 
> is in XML 
> attributes, and RELAX NG is better at representing XML attribute 
> co-occurrence constraints than DTDs or XML Schema.
> 
> Regards,
> Josh
> 
> -- 
> Joshua Lubell
> National Institute of Standards and Technology
> Manufacturing Systems Integration Division
> 100 Bureau Drive, Stop 8263
> Gaithersburg MD 20899-8263, USA
> Phone: 1-301-975-3563, Fax: 1-301-975-4694
> Email: lubell@nist.gov
> 
> _______________________________________________
> step-os mailing list
> step-os@step.nasa.gov http://step.nasa.gov/mailman/listinfo/step-os
> 

From edbark at nist.gov  Fri Sep 10 13:01:40 2004
From: edbark at nist.gov (Ed Barkmeyer)
Date: Fri Sep 10 12:14:02 2004
Subject: [wg11] RE: [step-os] Part 28 comment JP-5 meets EXPRESS Ed.2
In-Reply-To: <000001c49751$ba1fae00$2101a8c0@esukpc20>
References: <000001c49751$ba1fae00$2101a8c0@esukpc20>
Message-ID: <4141DDF4.9030401@nist.gov>

David Price wrote:

>  I suggest falling back to one of my earlier suggestions:
> 
> Include the STEPMod DTD as an informative annex in Part 28 E2 - or run it
> through an XML tool that translates DTDs to XML Schema and include that XML
> Schema instead. 

I agree with this, in the latter version.  Part 28 v2 should contain an 
XML Schema description of the exchange form, not a DTD.  Also I think 
you want a human expert to review the automatic translation and improve 
the resulting XML schema with the proper use of XML data types.

I agree that the Annex should be informative.

I agree that no text is required, *so long as* there is <documentation> 
in the XML schema that relates the tags to the Part 11 terms.

> Below is the extract of that DTD for entity data types and global rule so
> you can see its approach :
> 
> <!ELEMENT entity (description?, explicit*, derived*, inverse*, unique*,
> where*, graphic.element?)>
> <!ATTLIST entity
> 	name NMTOKEN #REQUIRED
> 	abstract.entity (YES | NO) "NO"
> 	abstract.supertype (YES | NO) "NO"
> 	supertypes NMTOKENS #IMPLIED
> 	super.expression CDATA #IMPLIED

Asides:

(1) ABSTRACT SUPERTYPE is a proper subtype of ABSTRACT ENTITY:  Abstract 
entities *may* have "generic attributes"; abstract supertypes are not 
permitted to.  That is the *only* difference.  An abstract entity that 
has no generic attributes is not semantically distinguishable from an 
abstract supertype.  We should actually deprecate the use of ABSTRACT 
SUPERTYPE.

(2) supertype expression *is* deprecated in EXPRESS Ed2, in favor of 
SUBTYPE_CONSTRAINT, which can carry all of the same information and 
more.  Every valid supertype expression is a valid SUBTYPE_CONSTRAINT, 
i.e.  ENTITY x <supertype expression> maps 1-to-1 to:
   SUBTYPE_CONSTRAINT FOR (x);
    <supertype expression>;
   END_SUBTYPE_CONSTRAINT;

I would recommend that you think about making that transform, since 
SUBTYPE_CONSTRAINTs for the same (x) can be *added* in other modules and 
APs that use the ENTITY type, and that gives you a uniform 
representation of the constraint set for a given (x).

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@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."
From david.price at eurostep.com  Fri Sep 10 13:12:54 2004
From: david.price at eurostep.com (David Price)
Date: Fri Sep 10 12:25:11 2004
Subject: [wg11] RE: [step-os] Part 28 comment JP-5 meets EXPRESS Ed.2
In-Reply-To: <4141DDF4.9030401@nist.gov>
Message-ID: <000601c49759$694a0a40$2101a8c0@esukpc20>

Ed,

I think the deprecated constructs in EXPRESS remain in the DTD so that the
syntactic equivalent of the original schema can be recreated from the XML
document. There are good reasons for that, and for what you propose.
However, at this point in time I'd leave the decprecated constructs in the
XML Schema for the Part 28 E2 annex. That would leave any semantic
transforms to a standardized metamodel of EXPRESS - which we both hope will
get underway before long.

Cheers,
David

> -----Original Message-----
> From: Ed Barkmeyer [mailto:edbark@nist.gov] 
> Sent: 10 September 2004 18:02
> To: David Price
> Cc: 'STEP Open-Source'; 'SC4 WG11'
> Subject: Re: [wg11] RE: [step-os] Part 28 comment JP-5 meets 
> EXPRESS Ed.2
> 
> 
> David Price wrote:
> 
> >  I suggest falling back to one of my earlier suggestions:
> > 
> > Include the STEPMod DTD as an informative annex in Part 28 
> E2 - or run 
> > it through an XML tool that translates DTDs to XML Schema 
> and include 
> > that XML Schema instead.
> 
> I agree with this, in the latter version.  Part 28 v2 should 
> contain an 
> XML Schema description of the exchange form, not a DTD.  Also I think 
> you want a human expert to review the automatic translation 
> and improve 
> the resulting XML schema with the proper use of XML data types.
> 
> I agree that the Annex should be informative.
> 
> I agree that no text is required, *so long as* there is 
> <documentation> 
> in the XML schema that relates the tags to the Part 11 terms.
> 
> > Below is the extract of that DTD for entity data types and 
> global rule 
> > so you can see its approach :
> > 
> > <!ELEMENT entity (description?, explicit*, derived*, inverse*, 
> > unique*, where*, graphic.element?)> <!ATTLIST entity
> > 	name NMTOKEN #REQUIRED
> > 	abstract.entity (YES | NO) "NO"
> > 	abstract.supertype (YES | NO) "NO"
> > 	supertypes NMTOKENS #IMPLIED
> > 	super.expression CDATA #IMPLIED
> 
> Asides:
> 
> (1) ABSTRACT SUPERTYPE is a proper subtype of ABSTRACT 
> ENTITY:  Abstract 
> entities *may* have "generic attributes"; abstract supertypes are not 
> permitted to.  That is the *only* difference.  An abstract 
> entity that 
> has no generic attributes is not semantically distinguishable from an 
> abstract supertype.  We should actually deprecate the use of ABSTRACT 
> SUPERTYPE.
> 
> (2) supertype expression *is* deprecated in EXPRESS Ed2, in favor of 
> SUBTYPE_CONSTRAINT, which can carry all of the same information and 
> more.  Every valid supertype expression is a valid 
> SUBTYPE_CONSTRAINT, 
> i.e.  ENTITY x <supertype expression> maps 1-to-1 to:
>    SUBTYPE_CONSTRAINT FOR (x);
>     <supertype expression>;
>    END_SUBTYPE_CONSTRAINT;
> 
> I would recommend that you think about making that transform, since 
> SUBTYPE_CONSTRAINTs for the same (x) can be *added* in other 
> modules and 
> APs that use the ENTITY type, and that gives you a uniform 
> representation of the constraint set for a given (x).
> 
> -Ed
> 
> -- 
> Edward J. Barkmeyer                        Email: edbark@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."
>