To all who have contributed to this long and tortuous thread (even
though I haven't even opened all of the posts, let alone studied or
analysed them...). (So please forgive me if you have already made the
same suggestions!) (01)
I outline the way the architecture underlying Ontology Chemistry deals
with the so-called problem. (02)
As background it might help if you first considered the "Hamburger
Model" that Anatoly referred us to in a different context: (Many thanks
to Anatoly Levenchuk!) (03)
AL:
> Many CAD/PLM systems and data standards use some kind of "Hamburger
> Model" of Wim Gielingh et al from 1988
(http://15926.info/functional-physical-object/GARM-paper.pdf).
Ontological analysis (from ISO 15926 point of view) of this model you
can find at http://15926.info/functional-physical-object/index.htm --
text <Functional and Physical Objects - the big picture> of Hans
Teijgeler with process plant engineering design with added
http://www.15926.info/installing-a-physical-object/index.htm -- text
<Installing a materialized physical object in a function place>. (04)
Without wanting to comment on the rest of those documents, I focus on
the figure under the heading "Functional and Plant Design" in the 2nd of
those 3 links. I presume we can take it as an indication that at least
some engineers are happy with the concept. (05)
Note its nice tight pairing of the two halves of the hamburger: FU
(Functional Unit, of which a type possibly called something like
"PumpRole" would be a subtype) and TS (Technical Solution, of which type
"Pump" or perhaps "ActualPump" would be a subtype). It emphasizes the
tight association between the two that leads engineers to "identify" the
respective entities, as Matthew commented. (06)
But the issue all along here is the appropriate "ontological" rendering
of that plain and intuitive hamburger. (07)
Now, as it happens, the solution to this very challenge is an important
aspect of The Mainstream Architecture for Common Knowledge. (I have
long labelled that architecture with single-syllable "MACK", but I have
now provisionally adopted the three-letter "TMA".) That aspect is
exactly what I have already referred to in this thread as Dynamic
Multiple Inheritance (and as it happens that "dynamic" qualification
well evokes some requirements classically addressed by 4D though easily
handled without any such sophistication). (08)
The entire doubly-inherited hamburger, the paired FU-TS or
PumpRole-ActualPump, is an instance of a new type, subtype of both
PumpRole and ActualPump. It might be spelled out as type
"ActualPumpInAPumpRole", itself optionally defined as a subtype of, say,
"UnitInARole". It would have the attributes of actual units, such as
serial number and measured dimensions with their precisions, as well as
the attributes of required units, such as required functionality and
dimensions with their tolerances. (09)
(And what happens if wearing causes an instance's actual to exceed
tolerance? Well, then of course we have an inconsistent database, a
state which could either be disallowed or preferably be flagged as a
problem to be investigated and corrected in one way or another -- more
on which in the coming wiki writeup, or perhaps post to this list.) (010)
And of course Matthew's specimen, which I here label "P101-S3356", is an
instance of the combined type. It is also very frequent in TMA to allow
such an entity to be labelled simply "P101", the actual context usually
disambiguating if required. That corresponds precisely to the real
engineering practice Matthew reported. (011)
Yes, all that may at first seem rather roundabout, so I now add some
other uses of the same pattern. They are of extremely wide application
and high practical value. (012)
Take some instance of any type and project its attributes into the
fields of a portion of a display format or template. Or better, in TMA
terms, place the entity temporarily "in the context of" the display with
its format. So here the displayed Entity is now, as in the pump
UnitInARole case, temporarily a doubly-inherited DisplayedEntity, or
even "EntityInAVisualRole", inheriting the attributes of its original or
more permanent type, such as value constraints, as well as the
attributes temporarily granted it as a function of the layout-type as
defined by the template, such as visualizable data type, dimensions and
screen coordinates. (013)
The enormous value of that simple ontologized view is that it can be
"enacted" (to use the term of another thread) by the TMA-driven AOS
(Application Operating System), and the result has a far more flexible
form of the Separation of Concerns that is implicit in the layering of
the top two tiers of the conventional 3-tier model, namely UI and
application. (There is a host of further aspects missing from that thin
or glib account, perhaps the most important of which is the precise
nature of such "enactment", but it shouldn't be difficult to see that
such agent-driven functionality is far from unconventional.) (014)
Note however that the mapping or transformation of the application
entity into the terms of the display does not of itself change the
entity. That is, there is the orthogonality required of any good
Separation of Concerns. That feature has of course long been hammered
out during the history of engineering plant and has already resulted in
the Separation of Concerns implicit in the ActualUnit/Role distribution
of specification that is implicit in all engineering diagrams. (015)
Now please, if you would, ask the questions and make the correcting
points to help refine that picture and its presentation? (Even though I
very much fear that many questions will have to remain largely
unanswered until I have the much-promised fuller writeup on the wiki.) (016)
This whole matter is however very important to TMA, as the very same
pattern is also applicable to a host of other situations, such as access
control, transaction definition and management, fact storage and very
many "meta-" matters handlable by ontology- or model-reflection. Such
Dynamic MI is absolutely key to properly representing and managing the
dynamic multi-context nature of all human knowledge and knowledge-making
processes that is at present so inadequately recognized in the present
IS mainstream, and in which Ontology is so important for its product,
namely orthogonalities and associated invariances. (017)
Thank you in anticipation!
Christopher (018)
P.S. I must throw in what I think is a nice a little gem corroborating
the use of the word "role" in the above contexts. (019)
That usage reminds that "cast in a role" very much matches, and most
probably gave rise to, the use of "cast" in C, though with an
interesting difference. (020)
Thus an integer may be cast as a pointer, as in piIntPtr =
(int*)iThisInt (where I use the Hungarian convention for variable
names). That makes the bit-pattern in iThisInt not only the integer
number it was but now also a pointer. That is, the integer is now also
playing the role of a pointer, the bit-pattern in effect (though of
course not explicitly) doubly-inheriting both integer and pointer types. (021)
For the interesting difference, let's now also note that a pointer can
also be cast as, or play the role of, an integer, as in iThisInt =
(int)piIntPtr, unlike in the pump-role/pump situation. That is, there is
a kind of symmetry missing in the usual component case. (022)
FWIW. (023)
_________________________________________________________________
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/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community Portal: http://ontolog.cim3.net/wiki/ (024)
|