Dear Matthew, (01)
What is in Part 2 is not an ontology for process plant information. It is an
ontology for everything, and therefore an ontology for nothing in particular.
The RDL should be the reference ontology for process plant information. It
reuses such elements of the Part 2 upper ontology as are useful in
characterizing process plant elements, rather than healthcare elements or
forestry elements, for example. It is the RDL, not Part 2, that will be used
to convey industrial information. (02)
There seems to be a view that the RDL is just a 'vocabulary' to be used with
whatever axioms and facts the individual use requires. Even so, if the
classifiers and properties are carefully defined (so that reuse is meaningful),
some part of those definitions can be formally axiomatized. The important
point here is that industry has to agree on what CentrifugalPump means in terms
of structure and possible characterizing properties. The fact that it is a
"class of inanimate physical object" (part 2) is not really very interesting.
The RDL is the 'vocabulary' in a KR language whose syntax is defined by n-ary
"templates" in Part 4, and the semantics of that language is defined in terms
of Part 2 concepts (i.e., at a high-level of abstraction, which is unfortunate
for a language that has no user-defined verbs). (03)
Even worse, a "Centrifugal Pump description" is a "functional object" (Part 2),
but it may be viewed as a "subclass of" CentrifugalPump and therefore as an
"instance of" "class of class of inanimate physical object". This elegant
abstraction is so arcane to domain engineers, and to most domain modelers, that
the chance that they will use the Part 2 ideas correctly is non-existent.
Further, it is utterly irrelevant. What they need to understand is the
difference between a CentrifugalPump (the physical thing) and a
CentrifugalPumpDescription (the model element, the procurement spec), because
in the industry itself, the term "centrifugal pump" is used for BOTH! And when
the RDL introduces a term like Class_of_Centrifugal_Pump when they mean either
of the latter two, it adds to the confusion. API 610 defines "classes of
Centrifugal Pump" typically by impeller structure, but surely the plant design
spec has to provide more information than that, e.g., required flow rate and
discharge pressure, and what Emerson's catalogue contains is labeled
"Centrifugal Pumps". So the engineer will be confused if you call the design
element or the Emerson catalogue entry a "class of Centrifugal Pump". That is,
the terminology derived from the elegant upper ontology model gets in the way
of communicating with the industry experts who will develop the detailed RDL,
and with the software toolsmiths it is designed to serve! (04)
Two notes from Matthew's comments below: (05)
1. Matthew the experienced systems/knowledge engineer does not see the
commonality between the OMG Model-Driven Architecture, which is about designing
software top-down, and the STEP Architecture, which is about designing exchange
files top-down, because they use different words and have love affairs with
different modeling concepts. My upper ontology for the problem space of
software design sees them as sufficiently analogous to be instances of a common
paradigm. This difference in perception is exactly the problem that the people
who produce software to support petroleum engineering have with ISO 15926 Part
2 and the template-based language for modeling their domain. It ain't their
words, and they don't see their concepts. All of their concepts are in the RDL. (06)
2. Matthew notes that some successful applications of 15926 have in fact done
the application-specific knowledge engineering and then mapped their concepts
and representations back to ISO 15926 Part 2 and Part 4, the descriptive
process that I agree with. Unfortunately, the current approach in the
standards activity is prescriptive as to how this is to be done -- the exchange
forms are derived by rote from the templates, converting n-ary verbs to
composites of RDF triples. Any standard KR language already has a well-defined
form for the knowledge captured in that language, but SC4 is still trying to
define one (or more accurately 219 distinct patterns -- their new KR language
syntax). So, I see the standardization process following a different , and
undesirable, pattern, from the one used for successful interchange. (07)
-Ed (08)
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew West
> Sent: Wednesday, January 29, 2014 10:01 AM
> To: 'Ontology Summit 2014 discussion'
> Subject: Re: [ontology-summit] The tools are not the problem (yet)
>
> Dear Ed,
>
>
> Well, Matthew, we do seem to agree on the first bullet. What the 15926
> community most needs to do is to make a real ontology for process plant
> information, translated "improve the Reference Data Libraries (RDL)".
> Making useful OWL ontologies is either part of that process -- making a
> worthwhile reference ontology -- or it isn't, but it is not ancillary. The
>current
> RDL is a taxonomy, full stop. And instead of real DataProperties and
> ObjectProperties, it has 200 "templates" for constructing those properties
> from the 'property classes' in the RDL, which in turn leads to arguments
> about what the RDF representation of instance data should look like. With
> OWL models, the RDF instance representation is well-defined by an existing
> and widely implemented standard. So, choosing ONE suggests itself as the
> most effective way to make a Standard!
> [MW>] Well the RDL is not supposed to be used on its own. The ontology is in
> Part 2, and the RDL provides specialized uses of it, and the templates pick
>out
> particular uses of bits of Part 2 and the RDL. Also the RDL is not simply a
> taxonomy, though parts of it may be, sometimes erroneously.
>
> The underlying problem here is the Model-Driven Architecture approach, as
> formalized twice in TC184/SC4. First, you make a two-tier conceptual model
> of the space, in a language that is supposed to be suitable for conceptual
> models, independent of "platform class" (object-oriented, relational, tree
> structure, description logic). The top tier is a collection of meaningless
> abstractions that is supposed to be the basis for integrating models (in lieu
>of
> looking at the relationships among the model viewpoints and content). The
> second tier is many separate models of useful information in the problem
> space, which are forcibly coupled to the worthless top-tier concepts. Then
> you "map" the conceptual model to some implementation form, using a well-
> defined rigorous process. Of course, the implementation forms are specific
> to "platform class", and the conceptual models are not really independent of
> platform classes, because they have their own structuring rules, and the
> modelers h ave existing prejudices. So, we end up with rigorous methods
> for putting a square peg in a round hole.
> [MW>] I'm not sure I recognise this as what I understand by Model Driven
> Architecture (which I take to be a series of models, meta-models and meta-
> meta models) or even the STEP architecture, which your description more
> closely resembles. However, neither the meta modelling approach of OMG
> or the STEP architecture approach applies to ISO 15926. The approach in ISO
> 15926 arose from precisely looking at the relationships among model
> viewpoints and content, and then looking at how they could be integrated.
> There are no meaningless abstractions (i.e. just data structures to which
> meaning has to be assigned in context, by e.g. mapping tables). Though
> there are certainly some very abstract concepts.
> For what it is worth the ISO 15926 conceptual architecture is a single level
>in
> which the models, meta-models and meta-meta models all reside together
> (hence recent talk of namespaces). The only other thing is the language in
> which it is defined, which for part 2 was EXPRESS. This was not an ideal
> language for the purpose - since it essentially forced the split between data
> model and data - but it is what we had. When a more appropriate language
> emerges that can cope with ISO 15926 as a single level, I hope we will migrate
> to it. OWL shows some promise, but still had important limitations.
>
> A consequence of this approach is that the body spends a lot of time defining
> modeling conventions, and even more time defining architectures,
> methodologies, and mapping formalisms, none of which has any direct value
> to industry. And the mismatch between the conceptual structures and the
> vogue implementation structures creates ugly exchange forms for otherwise
> well-defined information concepts.
> [MW>] Yes. That does sound like STEP.
>
> Coming back to the thrust of the Subject line, I have come to the conclusion
> that this process is upside down. What you want to do is create a conceptual
> model ('ontology') for the problem space in some formal language, and
> define the XML or RDF or JSON exchange schema for THAT model. Then you
> need a mapping language that explains the relationship of the chosen
> exchange form to the conceptual model. That is, you DESCRIBE what you
> DID, rather than PRESCRIBING what you MUST DO. (In engineering, this is
> the "trace" from the design to the requirements.) The great advantage of
> this approach is that it allows engineering choices that are convenient to the
> implementer community! And it can be used to describe other engineering
> choices made by other groups defining exchange forms for the same or
> closely related concepts. This is a top-down engineering process that allows
> for tradeoff in the product design.
> [MW>] That should work in an ISO 15926 environment, and is what, as far as I
> know, many people have done. A typical project might take a look at the RDL
> and templates for coverage of their domain for simple reuse, then come up
> with its own conceptual model, then map it to the ISO 15926 data model,
> templates and RDL. Your structures are in principle, just more templates.
> Mapping to Part 2 and the RDL is really part of the analysis, which will cause
> questions to be asked about what you really mean, but that will help the
> work you have done to be reusable, as well as improve it. Almost certainly,
> you will find there are things missing that you need, (i.e. the mapping will
>be
> incomplete) so you need to add those things (usually to the RDL). The
> mapping becomes the formal definition of what you have done. One result
> of this, is that any data you create can be mapped through to the underlying
> data model for reuse in other schemas where the data overlaps.
> That is how integration happens. Developing Part 11 went somewhat like
> that.
>
> Way back in the 1980s, the ANSI 3-schema architecture for database design
> views the process of design as beginning with viewpoint schemas for the
> participating applications. These schemas are then integrated (not
> federated) into a conceptual schema that relates all the concepts in the
> viewpoint schemas. The resulting conceptual schema is the relational model
> of the stored data (the reference ontology). The formal viewpoint schemas
> (external views) are then derived from the conceptual schema by 'view
> mappings' that actually transform the stored data into the organizations
> demanded by the views (using "extended relational operators"). The SC4
> two-tier modeling mistake is failing to realize that the process begins with
>the
> view schemas that have direct VALUE to industrial applications, and that the
> integrating schema, which allows for new and overlapping applications, is
> DERIVED from them. We have confused the organization of the results with
> the organization of the enginee ring process, and once again we have
> canonized an upside-down approach.
> [MW>] Obviously I disagree. In ISO 15926 we followed closely the 3 schema
> approach, to get to the conceptual schema, which we carefully designed to
> be extensible. We went through multiple evolutions and revolutions in
> developing the conceptual schema over a 10 year period to achieve
> something that was reusable, stable and extensible.
>
> My biggest problem with 15926 is the amount of religion attached to these
> rigorous top-down approaches, and the enormous resource expenditures on
> make-work that that religion engenders.
> [MW>] If you are employing a top down process, then you are certainly
> doing it wrong - unless you really have a green field, and it's a while since
>I've
> seen one of those.
>
> The quality of the results suffers seriously from this diversion of effort.
> And I would bet that the so-called 'pre-standardization achievements' were
> accomplished using the inverted engineering process that I describe, each
> with its own agreement on exchange form.
> [MW>] I expect all benefits are achieved in that way. The cycle is supposed
> to be that you raid what you can from the larder, and add back what you
> found missing for others to use. Reducing reinvention is one of the benefits.
>
> Further, what I see appearing in the implementation community is projects
> making their own concept models and their own engineering choices and
> then tracing back to the RDL, and the required religious rites, in annexes.
> [MW>] I don't have a problem with that approach. I would hope that doing
> the mapping would add some value to the analysis process, rather than being
> a tick box exercise - which is of course a waste of space. If you have done a
> good mapping, your data is integrable with other ISO 15926 data when it is
> required to repurpose it.
>
> -Ed
>
> P.S. Yes, I agree that this whole discussion is a holdover from last year's
> Summit topic. You don't get to do top-down engineering for Big Data.
> [MW>] I think the big mistake you are making is assuming that using an upper
> ontology necessarily means you are doing top down engineering. The
> purpose of an upper ontology (at least in ISO 15926) is so that you can add
> more bits that work together to make a greater whole that can be reused by
> others. Some discipline is required to make that virtuous circle work, but it
>is
> certainly not top down engineering.
>
> Regards
>
> Matthew West
> Information Junction
> Mobile: +44 750 3385279
> Skype: dr.matthew.west
> matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> http://www.informationjunction.co.uk/
> https://www.matthew-west.org.uk/
> This email originates from Information Junction Ltd. Registered in England
> and Wales No. 6632177.
> Registered office: 8 Ennismore Close, Letchworth Garden City, Hertfordshire,
> SG6 2SU.
>
>
>
> --
> Edward J. Barkmeyer Email: edbark@xxxxxxxx
> National Institute of Standards & Technology Systems Integration Division
> 100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
>
> "The opinions expressed above do not reflect consensus of NIST, and have
> not been reviewed by any Government authority."
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> > summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew West
> > Sent: Tuesday, January 28, 2014 3:49 AM
> > To: 'Ontology Summit 2014 discussion'
> > Subject: Re: [ontology-summit] The tools are not the problem (yet)
> >
> > Dear Ed,
> > That's not what I said, and you know it...
> >
> > It does not follow from success having been achieved that there are
> > not further opportunities for investment.
> >
> > In particular, ISO 15926 was developed using a previous generation of
> > languages and technology and we should look at how to move it forward.
> > Not that this stops it being used - it was designed to be as
> > independent
> of
> > the implementation technology as possible.
> >
> > My priorities would be:
> >
> > 1. Improve the RDL. There is a lot that is useful there, but also a
> > lot of
> crud
> > that has crept in - and that is where the pesky details belong. There
> > are
> also
> > areas where it could usefully be extended. The advantage of work in
> > this area is that there are no obvious technical barriers (but there
> > do seem to
> be
> > political ones). There are quick wins here.
> >
> > 2. I would encourage development of OWL versions of ISO 15926, but in
> > particular, improvements to OWL that would make it better suited to
> > the expressiveness of ISO 15926, and for data integration as well as
> reasoning.
> >
> > 3. I would encourage the development of the IRING architecture and
> > implementations of it. In particular I would be looking for Quad store
> > technology. ISO 15926 is naturally quad based - a triple plus an
> identifier for
> > the triple.
> >
> > Whereas much of the costs of moving engineering data through the plant
> > lifecycle have been removed, there is still plenty of opportunity to
> improve
> > collaboration through the supply chain, and reduce project development
> > times (which can be worth $1m/day for larger projects).
> >
> > Specifically, I would be looking for equipment manufacturers to be
> publishing
> > data sheets as ISO 15926 linked data, as well as IRING implementations
> > to help with collaboration between owners and contractors in
> > developing requirements, and reviewing designs.
> >
> > And no, I don't think there is a need to standardise how a tool can
> implement
> > a conforming exchange for point to point exchanges. I think that is a
> tactical
> > matter. I'm not even sure you need that for IRING. What you do need is
> > an understanding of how to map data from various tools to ISO 15926,
> > and out again, but I don't see how it is appropriate to standardise
> > how that
> mapping
> > is done since that would be specific to each particular tool.
> >
> > Regards
> >
> > Matthew West
> > Information Junction
> > Mobile: +44 750 3385279
> > Skype: dr.matthew.west
> > matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> > http://www.informationjunction.co.uk/
> > https://www.matthew-west.org.uk/
> > This email originates from Information Junction Ltd. Registered in
> > England and Wales No. 6632177.
> > Registered office: 8 Ennismore Close, Letchworth Garden City,
> Hertfordshire,
> > SG6 2SU.
> >
> >
> >
> > -----Original Message-----
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > Barkmeyer, Edward J
> > Sent: 27 January 2014 19:09
> > To: Ontology Summit 2014 discussion
> > Subject: Re: [ontology-summit] The tools are not the problem (yet)
> >
> > Matthew,
> >
> > OK. 15926 is highly successful, and there is no need for further
> development
> > of access mechanisms, templates, OWL mappings or any of that stuff,
> > because the useful stuff is already in wide use in industry. So NIST
> > and
> the
> > USA need not invest further effort in the standards work on 15926,
> > except
> in
> > the development of useful 'reference data libraries', i.e., 'reference
> > ontologies for process plants'. How a plant design tool can implement
> > a conforming exchange using one of those ontologies is already
> > standardized and widely implemented, right?
> >
> > That is, after 10 years, we have standardized everything we need
> > except
> all
> > those pesky details that are actually used in designing and building
> > and operating a process plant.
> >
> > -Ed
> >
> >
> > > -----Original Message-----
> > > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> > > summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew West
> > > Sent: Sunday, January 26, 2014 1:22 AM
> > > To: 'Ontology Summit 2014 discussion'
> > > Subject: Re: [ontology-summit] The tools are not the problem (yet)
> > >
> > > Dear Ed,
> > > You are indeed rather late to the party.
> > >
> > > [EJB] I don't think I have seen an industry "success story" about
> > > 15926, even for 'peer-to-peer application interfacing'.
> > >
> > > MW: You certainly won't find them if you do not look. How about:
> > > https://d2024367-a-62cb3a1a-s-
> > > sites.googlegroups.com/site/drmatthewwest/publ
> > > ications/STEPintoTheRealWorld.PDF?attachauth=ANoY7crKMLjBQ-
> > > ztRwf87sQKcy0Tsxz
> > > 9GcjcUquJFQl3U-
> > >
> >
> r3rlNRPZQq6NCgA0Xr_yq_IXMo_oG144m4jaJXdYuLOD3q5UsI6CD_YXI8Noh
> > >
> >
> 7We_KilyxzWEwDN9iz0EKYkoIqr_WqVQDjSfzsw3eqgVlf4I81kawZoORdXC0W
> > > 0dYNWB2n2w0qdF
> > > PI7i_H6gurmjCiOQ7Rm4VDDdx-
> > > Zdw8kcEhEpuJBojpSZOV_Tn8_jGeMnts83DxVZpnhk4vWQyGDA
> > > cSHR8z1ms&attredirects=0
> > > as just one (pre-standardisation) example of delivering benefits.
> > > There are hundreds of other projects that have used ISO 15926 at
> > > different stages of development in different ways delivering
> > > hundreds of millions of dollars of benefits.
> > >
> > > But if that has been successful on a useful scale, there is no need
> > > for further work on anything but the scope of the reference
> > > ontology, because the peer-to-peer interfaces now exist. The fact
> > > is that they don't. There are no standards for them to implement.
> > > (Actually, ISO
> > > 15926-11 is a pretty good standard. It provides a very accessible
> > > ontology for the concepts in ISO 15288 (systems engineering for
> > > <something>), and a clear mapping from the ontology to an RDF
> > > exchange form for a model population. The a posteriori Part 4/Part
> > > 2 stuff is an
> > Annex in the back, if anyone cares.
> > > That is the kind of compromise that 15926 needs more of. And I
> > > think David Price and gang will do something similar in Part 12.)
> > >
> > > MW: Actually, I think the mistake is thinking that it is the
> > > interface standards that are needed. Getting data out of one system
> > > and into another has never been that big a deal in my experience.
> > > Pretty much any system has an import mechanism with a plain text
> > > format, and pretty much any system has a reporting system that can
> > > create a file to
> > more or less arbitrary layout.
> > > Job done. If there are problems, they are easily sorted out using
> > > tools like access and spreadsheets. It helps that most data
> > > waterfalls through a series of systems in the process industries,
> > > rather than there being tight integration with a lot of back and
> > > forth in real time. Those requirements have not surprisingly found
> > > themselves in
> > integrated systems.
> > >
> > > MW: Indeed the BIG IDEA in ISO 15926 was having a generic data model
> > > that enables you to say all the sorts of things that are important,
> > > and an extensible reference data library that provides the specifics
> > > to the level of detail required, and to which you can add anything
> > > you need for new domains plus templates that incorporate those
> specifics.
> > >
> > > MW: The big issue in integration and exchange between systems was
> > > not the exchange format, but the mapping between the different codes
> > > and names different systems used for the same things. The real
> > > achievement of ISO
> > > 15926 is indeed the RDL. As far as I know, by now all the major
> > > design packages for the process industries support the use of an
> > > RDL, including tailoring and extensibility. The oil majors at least
> > > that I have had contact with spend time developing their own RDLs,
> > > these being extended subsets of the ISO 15926 RDL, which they
> > > require to be deployed in their asset management systems across the
> > > lifecycle. So for example, I know that Shell has an appropriate
> > > subset of its RDL
> > embedded in SAP.
> > >
> > > MW: The big thing here is that this makes the interfacing much
> > > simpler, because the mapping - that was always the expensive and
> > > unreliable bit, has largely been confined to history. That is also
> > > where the big benefits have come from. Largely unreported, because
> > > you don't notice costs you didn't incur that you did not need to
> > > incur if you
> > did things right.
> > >
> > > MW: And yes, this is what people have been more recently calling
> > > master data management, we were just working out this was what was
> > > needed in the last century.
> > >
> > > MW: So what of IRING and other recent developments? There has
> > > certainly always been an ambition for seamless integration in
> > > developing
> > ISO 15926.
> > > The reality has been that so far the technology has always fallen
> > > short. XML Schema is OK for defining interface formats, but not
> > > integration (not surprising since it is really a document
> > > specification language). OWL has greater promise, but it is focussed
> > > on reasoning and so has restrictions that are at best inconvenient
> > > for data integration, and much of the current discussion in the ISO
> > > 15926 community is how best to work around those limitations. IRING,
> > > facades, and the possible use of triple stores is currently where
> > > the cutting edge is. I think the IRING architecture has merit in the
> > > long
> > term. I'm not sure we have the technology to implement it yet.
> > >
> > > Regards
> > >
> > > Matthew West
> > > Information Junction
> > > Mobile: +44 750 3385279
> > > Skype: dr.matthew.west
> > > matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > http://www.informationjunction.co.uk/
> > > https://www.matthew-west.org.uk/
> > > This email originates from Information Junction Ltd. Registered in
> > > England and Wales No. 6632177.
> > > Registered office: 8 Ennismore Close, Letchworth Garden City,
> > > Hertfordshire,
> > > SG6 2SU.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > > Barkmeyer, Edward J
> > > Sent: 24 January 2014 22:57
> > > To: Ontology Summit 2014 discussion
> > > Subject: Re: [ontology-summit] The tools are not the problem (yet)
> > >
> > > Hans,
> > >
> > > Further comments intertwined with yours below.
> > >
> > >
> > > > [HT] I shudder when thinking about how bad your tooth and nail
> > > > will be if what is below is apparently seen as mild comments by you.
> > >
> > > [EJB] If so, then what is sacred in your view is largely irrelevant
> > > in
> > mine.
> > > I had rather thought that we had a common goal -- successful
> > > interchange of plant data over the lifecycle.
> > >
> > > > this is not only about knowledge engineering; this is about
> > > > database engineering using triple stores. (If integrating RDBs
> > > > with triple stores and SPARQL is your goal, you should look at the
> > > > stuff Kingsley Idehen is doing.) [HT] On what would YOU base any
> > > > knowledge, other than facts about all aspects of the plant,
> > > > gathered
> > during decades?
> > > > Not
> > > from LOD I hope.
> > >
> > > [EJB] I would BASE the knowledge on the repositories of the facts
> > > about all aspects of the plant, gathered during decades. Our
> > > disagreement is about how we would FURTHER ENGINEER that
> knowledge.
> > >
> > > > What EPCs already have ...
> > > > What does your would-be triple store have to offer them?
> > > > [HT] Ignoring your patronizing last sentence this: I have worked
> > > > most of my life in such a large firm, I have been in the trenches,
> > > > I have designed the first data bases for engineering and later the
> > > > integration of data, resulting in such software. And so did my
> > > > colleagues
> > > from other large firms.
> > > > But we were faced by the fact that everybody was using something
> > > > different with different internal formats and geared to their
> > > > (different) work procedures. So when we were entering a joint
> > > > venture for a multibillion project we were discussing "your system
> > > > or
> > ours?"
> > > > in order to be able to communicate and to satisfy the growing
> > > > requirements from the side of the plant owners that they wanted
> > > > all information in an integrated fashion. That was why PIEBASE
> > > > (UK), USPI
> > > > (Netherlands) and PoscCaesar (Norway) we formed, and later
> > > > together in EPISTLE (Matthew West et al). So yes, we had our
> > > > systems, but these were,
> > > in a globalizing world, silos.
> > >
> > > [EJB] Yes, and that was 10 years ago. What came of that? What
> > > "integrated fashion" did they all agree on and implement?
> > >
> > > > And yes, until now
> > > > ISO 15926 is used for peer-to-peer application interfacing,
> > > > succesfully as I heard.
> > >
> > > [EJB] I don't think I have seen an industry "success story" about
> > > 15926, even for 'peer-to-peer application interfacing'. But if that
> > > has been successful on a useful scale, there is no need for further
> > > work on anything but the scope of the reference ontology, because
> > > the peer-to-peer interfaces now exist. The fact is that they don't.
> > > There
> > are no standards for them to implement.
> > > (Actually, ISO 15926-11 is a pretty good standard. It provides a
> > > very accessible ontology for the concepts in ISO 15288 (systems
> > > engineering for <something>), and a clear mapping from the ontology
> > > to an RDF exchange form for a model population. The a posteriori
> > > Part 4/Part 2 stuff is an Annex in the back, if anyone cares. That
> > > is the kind of compromise that 15926 needs more of. And I think
> > > David Price and gang will do something similar in Part
> > > 12.)
> > >
> > > > And as I started this thread: Standardization is finding a balance
> > > > between large ego's, commercial politics, short-term thinking,
> > > > hard-to-make paradigm shifts, and for the most lack of funding.
> > > > And I might add: the unwillingness to really understand each other
> > > > because that
> > > takes time.
> > >
> > > [EJB] Not to mention the unwillingness to compromise. "Standards is
> > > politics."
> > > What standards-making should NOT be is academic research. Except
> > > possibly in W3C, successful standards standardize something very
> > > close to what is currently in wide use, so that implementation is a
> > > marginal cost, and the return is wider market and lower cost of sale.
> > > Engineers who create new technologies seek patents, not standards.
> > > The lack of wide success with
> > > TC184/SC4 standards can largely be attributed to the creation of an
> > > unnecessarily high cost of implementation, which results from the
> > > adoption of complex mappings from concept to exchange form.
> > >
> > > > The concern is: can we develop an integrating ontology that can
> > > > be used for semantic mediation between the existing schemas, and
> > > > provide a useful exchange form based on the integrating ontology? ...
> > > > [HT] WE DON'T HAVE an "integrating ontology", other than the Part
> > > > 2 data model and the templates derived from that, where the
> > > > latters are completely data-driven and representing the smallest
> > > > possible chunk of information.
> > >
> > > [EJB] Umm... Capturing the concepts needed for particular
> > > information sets ("data driven") is in fact how ontologies are
> > > built. It helps if there are also "common lower ontologies" --
> > > quantities, time, location, identifiers, etc. -- that can be reused
> > > directly. The templates and Part 2 lend very little to the
> > > construction of ontologies for exchanging plant data. Those who see
> > > a value in it are welcome to pursue that value, but they should not
> impose it on others.
> > > As in Part 11, the template mappings can be added as an annex behind
> > > the problem domain ontologies and the specification of their
> > > exchange
> > form.
> > >
> > > > What is different is that ISO 15926 calls for explicit
> > > > information, where most data bases (and documents) carry implicit
> > > > information, making shortcuts, that is understandable for the
> > > > initiated only, but not for computers. Examples
> > > > galore: an attribute of a process boiler: "fluid category", an
> > > > attribute of a pressure vessel: "test fluid" and "test pressure",
> > > > an attribute of a centrifugal
> > > > pump: "impeller diameter", etc, etc. We are working on "patterns"
> > > > that will bridge the gap between implicit and explicit information
> > > representation.
> > >
> > > [EJB] Yes, what is different is that you are making an ontology, not
> > > a data model. But the effect is that you are trying to educate
> > > ignorant software engineers and plant engineers in the art of
> > > knowledge engineering. That is not your job, and it is the SC4
> > > mistake. The requirement for the glorious standards effort is to
> > > have participating experts with the ability to construct good formal
> > > models in the standard. Failing that, it is not your job to try to
> > > produce that expertise by teaching the otherwise experienced domain
> > > engineers your trade. It is necessary to entice more people with
> > > your expertise, or
> > scale down the project to what you have resources to do well.
> > > You, and those of you who have the background, should be developing
> > > the ontologies from these 'available knowledge' systems, leveraging
> > > the available domain expertise, instead of trying to create a strict
> > > structure in which the neophytes will be forced to get it right.
> > > They
> > > won't: fools are too ingenious. And in the process, you have
> > > created an impediment to participation by expert
> > > modelers. By comparison, you and/or the participating expert
> knowledge
> > > engineers, would make a good model, and sort out the missing objects
> > > and the mis-assigned properties, and you won't need all the overhead
> > > to get that right.
> > >
> > > [EJB] When an industry group makes an OWL domain model for a small
> > > part of the problem space, the last thing they need is a requirement
> > > to figure how to use the Part 4 templates to express that model as a
> > > derivative of the Part 2 upper ontology. It is a waste of their
> > > time, and
> > it is irrelevant to their goal.
> > > That exercise is pure cost, with no clear return. There is value to
> > > having someone knowledgeable about the related ontology quality
> > > issues read, and recommend improvements to, their model. If you see
> > > some clear return on the investment of developing a template mapping
> > > to Part 2, then you have a motive for doing that, while they don't.
> > > And ultimately, their data exchange will be mapped to their model,
> > > because that is the model the domain experts understood. If you
> > > transmogrify that OWL model into a bunch of template instances, you
> > > create an added costly learning curve for their implementers that
> > > has no RoI for them or their sponsors. The people who see RoI in
> > > the gi ant triple store can develop the technology to transmogrify
> > > the domain ontologies and data for the triple store purposes, not
> > > force the domain modelers and the domain implementers to be
> > > concerned with it. (In lieu of tooth and nail, I perceive this to
> > > be a compromise
> > > position.)
> > >
> > > [EJB] By way of defense of my position, I would point out that after
> > > a mere
> > > 15 years of working with the god-awful STEP architecture, the
> > > implementers of ISO 10303 concluded that it provided nearly no
> > > assistance in integrating the conforming models of product data and
> > > processes that were made from diverse viewpoints. That model
> > > architecture added significant cost to the creation of the exchange
> > > standards themselves and even greater cost to the implementations
> > > that had to read the transmogrified data and convert it back to
> > > product information. The theory that uniform structures will
> > > produce concept integration was proven false in ISO 10303, and the
> > > similar theory will
> > prove false for ISO 15926, even though you are using RDF instead of
> EXPRESS.
> > > In making and integrating ontologies, no set of strictures is a
> > > substitute for the application of knowledge engineering expertise.
> > >
> > > > But their critical path also involves a viable exchange form; and
> > > > a clumsy form, born of obsession with triples and upper
> > > > ontologies, will interfere with wide adoption.
> > > > [HT] Wait and see.
> > >
> > > [EJB] Quo usque tandem? There is no profit in saying 15 years later "I
> > > told you so".
> > >
> > > -Ed
> > >
> > > P.S. I chose to burden the Forum with this email only because I
> > > worry that other well-meaning standards bodies might follow
> > > TC184/SC4's model for the use of ontologies in standards, to their own
> detriment.
> > > (And yeah, that was last year's issue.)
> > >
> > > --
> > > Edward J. Barkmeyer Email: edbark@xxxxxxxx
> > > National Institute of Standards & Technology Systems Integration
> Division
> > > 100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> > > Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
> > >
> > > "The opinions expressed above do not reflect consensus of NIST, and
> > > have not been reviewed by any Government authority."
> > >
> > >
> > >
> > >
> > >
> >
> __________________________________________________________
> > > _______
> > > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > > Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> > > summit/
> > >
> > > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > > Community Files:
> > > http://ontolog.cim3.net/file/work/OntologySummit2014/
> > > Community Wiki: http://ontolog.cim3.net/cgi-
> > > bin/wiki.pl?OntologySummit2014
> > > Community Portal: http://ontolog.cim3.net/wiki/
> > >
> > >
> > >
> >
> __________________________________________________________
> > > _______
> > > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > > Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> > > summit/
> > > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > > Community Files:
> > > http://ontolog.cim3.net/file/work/OntologySummit2014/
> > > Community Wiki: http://ontolog.cim3.net/cgi-
> > > bin/wiki.pl?OntologySummit2014
> > > Community Portal: http://ontolog.cim3.net/wiki/
> >
> >
> __________________________________________________________
> > _______
> > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> > summit/
> > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> > Community Wiki: http://ontolog.cim3.net/cgi-
> > bin/wiki.pl?OntologySummit2014
> > Community Portal: http://ontolog.cim3.net/wiki/
> >
> >
> >
> __________________________________________________________
> > _______
> > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> > summit/
> > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> > Community Wiki: http://ontolog.cim3.net/cgi-
> > bin/wiki.pl?OntologySummit2014
> > Community Portal: http://ontolog.cim3.net/wiki/
>
> __________________________________________________________
> _______
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> summit/
>
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/
>
>
> __________________________________________________________
> _______
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/ (09)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/ (010)
|