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: 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" >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: . > >Please direct comments on the draft to: odm-comments@att.com > > >Please direct access or other administrative concerns to: Patrick Emery at >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 >Subject: Re: [step-os] Using STEPMod XML Representation of EXPRESS >To: STEP Open-Source >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 Reply-To: Fumiki Tanaka To: 'SC4 WG11' 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---->Part28ed2 ---->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---->Part28ed2 ---->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: But the markup for wr1: NOT boojum OR shares_owned > 1; in the STEPmod case is something like: NOT boojum OR shares_owned > 1 while the markup in the P28v1 case is something like: wr1 boojum shares_owned 1 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 : 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 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 : > > where*, graphic.element?)> > 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 maps 1-to-1 to: SUBTYPE_CONSTRAINT FOR (x); ; 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 > > 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 : > > > > > unique*, where*, graphic.element?)> > 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 maps 1-to-1 to: > SUBTYPE_CONSTRAINT FOR (x); > ; > 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." >