Hans, (01)
Further comments intertwined with yours below. (02)
> [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. (03)
[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. (04)
> 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. (05)
[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. (06)
> 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. (07)
[EJB] Yes, and that was 10 years ago. What came of that? What "integrated
fashion" did they all agree on and implement? (08)
> And yes, until now
> ISO 15926 is used for peer-to-peer application interfacing, succesfully as I
> heard. (09)
[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.) (010)
> 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. (011)
[EJB] Not to mention the unwillingness to compromise. "Standards is politics." (012)
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. (013)
> 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. (014)
[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. (015)
> 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. (016)
[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. (017)
[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 giant 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.) (018)
[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. (019)
> 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. (020)
[EJB] Quo usque tandem? There is no profit in saying 15 years later "I told
you so". (021)
-Ed (022)
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.) (023)
--
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 (024)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (025)
_________________________________________________________________
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/ (026)
|