Dear Matthew, Steven, and David, (01)
The critical issue is the distinction between normative and descriptive
ontologies. If we could limit the discussion to normative ontologies
that are *legislated* for a specific domain, we would all be in violent
agreement except for a few easily resolved differences in terminology. (02)
The problems arise when we face the requirement to design systems that
can interoperate with one another and with legacy systems -- even though
they have different ontologies or no explicit ontologies of any kind. (03)
MW
> If a top level ontology is underspecified, then it means that different
> interpretations can be made. That does nothing to help consistency. (04)
My only qualification is about the word 'nothing'. I would say that
*total* consistency on *all* possible data is only possible with a
rigidly legislated normative ontology. (05)
MW
> The integrating ontology is the one you translate the sources into,
> not something that can just put loads of other stuff together in.
> It therefore needs to be rigorous to minimize the chances of people
> translating into it inconsistently. (06)
Now I see the point that is causing all the confusion. It's the phrase
"minimize the chances of people translating into it inconsistently."
I would make that point even stronger: I would change the word
'minimize' to 'eliminate'. (07)
Successful legacy systems address that point with a simple solution:
They never translate anything from the outside into their internal
formats without performing at least a syntactic check. For anything
that could create irreversible errors, they also perform as many
semantic checks as required. Those that don't aren't successful
-- or at least not as successful as they could be. (08)
I recommend that all systems based on a normative ontology perform
at least the same level of checking that is currently done by the
successful legacy systems. With an explicit ontology, it should be
much easier to generate the constraints that need to be checked. (09)
But this requirement definitely does *not* require the normative
ontology to be the upper level for any systems that do not abide
by the same norms. (010)
SEZ
> your claim amounts to saying that in software, for "any and every"
> useful application, there is a schema, explicitly stated or not,
> that describes data layout and a semantics upon that schema, i.e.,
> rules for the transformation of this schema from one form to another. (011)
No. I believe that you are using the word 'schema' in the sense of
a single globally consistent normative ontology for all components
of the system. I don't believe that there is any large system
that could satisfy that definition. (012)
SEZ
> including SAP R3/R4, Oracle, operating systems, compilers, interpreters
> and numerous application programs of one form or another. (013)
I certainly agree that none of those systems would have a single schema
(i.e., globally consistent normative ontology) for all components. (014)
But I believe that those systems interoperate internally in much the
same way that independently developed legacy systems interoperate: (015)
1. The global assumptions that are shared by all components can be
specified in an underspecified upper-level ontology. (016)
Perhaps that ontology was once specified as a normative ontology,
but over time it has become a much more loosely defined descriptive
ontology. For example, consider the problem of running Windows 95
applications on Windows 8. For some applications, that can be
done, but don't expect everything to work as it did in the 1990s. (017)
2. Various components of the system that are more or less unified
may have their own normative ontologies that are consistent with
the underspecified upper level, but possibly inconsistent with
the details of the normative ontologies of other components. (018)
3. As Matthew said, no component can depend on translating anything
that comes from other components *into* its own formats without
performing the necessary syntactic and semantic checks. (019)
SEZ
> My suspicion is that any schema produced will contain both redundancies
> and inconsistencies that are, at best, difficult to resolve. You will
> also reveal that the semantics are ambiguous. (020)
I would replace the word 'suspicion' with 'certainty'. (021)
DE
> I don't really grok "normative" in the context of legacy systems, since
> to my experience the chaotic content of legacy systems typically does
> not adhere to any sort of standards. The "standards" are often the
> programming style of the last programmer. Over time gets very ugly. (022)
We are in violent agreement. (023)
When you get to large systems -- SAP, Windows 8, or a large application
system -- the semantics is much, much closer to the semantics of a
natural language. (By the way, I'm not making any value judgments.
I am just observing the inevitable course of creeping entropy.) (024)
You can have rigid normative ontologies (or formal schemata) only for
tightly controlled components. (025)
DE
> I have a so-called "data dictionary" in my basement from a 1980s banking
> application. Its form factor is 2 4" 3 ring binders, with a page per
> "data element." Some pages are less than complete. Major problem is that
> it's manually prepared documentation & thus contains many errors & omissions. (026)
Of course. The legacy re-engineering application discussed in my slides
had software developed, maintained, and revised by a rotating crew of
programmers over a period of up to 40 years. That VivoMind software
found a huge number of discrepancies between the many versions of the
software and the many versions of the documentation. (027)
DE
> The language/lexicon/jargon/acronyms in the system MUST be preserved,
> represented & accessible, not the human (typically a totally disinterested
> clerk or even worse, programmer who knows such work is beneath them)
> interpretation of the what they think the documentation should say. (028)
Absolutely. For that legacy re-engineering project, the VivoMind
software produced an English glossary of all the terms that had been
used over the previous 40 years with all the changes in the terms and
definitions over the years. Each term was cross-referenced to all
the documents and programs that used it. Every definition was
time-stamped with the date of the document from which it came. (029)
John (030)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (031)
|