Dear Ed,
You are indeed rather late to the party. (01)
[EJB] I don't think I have seen an industry "success story" about 15926,
even for 'peer-to-peer application interfacing'. (02)
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_WqVQDjSfzsw3eqgVlf4I81kawZoORdXC0W0dYNWB2n2w0qdF
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. (03)
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.) (04)
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. (05)
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. (06)
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. (07)
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. (08)
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. (09)
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. (010)
Regards (011)
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. (012)
-----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) (013)
Hans, (014)
Further comments intertwined with yours below. (015)
> [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. (016)
[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. (017)
> 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. (018)
[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. (019)
> 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. (020)
[EJB] Yes, and that was 10 years ago. What came of that? What "integrated
fashion" did they all agree on and implement? (021)
> And yes, until now
> ISO 15926 is used for peer-to-peer application interfacing,
> succesfully as I heard. (022)
[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.) (023)
> 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. (024)
[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. (025)
> 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. (026)
[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. (027)
> 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. (028)
[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. (029)
[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.) (030)
[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. (031)
> 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. (032)
[EJB] Quo usque tandem? There is no profit in saying 15 years later "I
told you so". (033)
-Ed (034)
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.) (035)
--
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 (036)
"The opinions expressed above do not reflect consensus of NIST, and have
not been reviewed by any Government authority." (037)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/ (038)
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/ (039)
_________________________________________________________________
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/ (040)
|