The 1st instalment of "MACK basics", now at
http://ontolog.cim3.net/forum/ontolog-forum/2008-02/msg00277.html,
introduced the "three pillars" of The Mainstream Architecture
for Common Knowledge: one abstract and logical, the second
noting the very concrete IT context, the third setting the scene
for the marriage of the first two by promising some special
vigilance over that hazardous pairing, both now and later. (01)
Nonetheless, it expressed confidence that such vigilance has
already had some good effect. You shall of course be the judge
... and please be merciless, even if you aren't sure if you've
read me right! I'll at least try to explain or rephrase myself
where necessary. (That's the least I can do, considering these
rather hasty jottings... (It is still planned that Metaset, the
long-worked-on but still incomplete first implementation of
MACK, or rather the Democratic Web which Metaset is designed to
seed, will be the preferred medium for introducing both itself
and MACK, "in any user's own contexts" and all that, as you'll
see in some detail before long if you're patient with me. And
of course in a groupware way that Democratic Web medium will
host its own further evolution by the widest market. Both
requirements are indeed good examples of complexities the medium
should help us simplify together. (All that good intention also
helps explain this hellish ad hoc verbal road I am laying out
for you with my present uses and abuses of this mailinglist
medium -- sorry ... for now!))) (02)
So this 2nd instalment is a quick glimpse at the special MACK
concept of the ontology, the "Form". And now I must apologize
again, as the "quasi-axiomatic construction" I had promised was
becoming too long as usual, so I have cut many corners here so
as to highlight some of MACK's more unique features, and sooner
note some fundamental dissonances with most conventional
application architectures. Then it will sooner be clearer how
we shall together look forward to the resulting technical
revolutions and laying the infrastructure for present human
mainstreams and fringes to rationalize themselves more fluidly
and collaborate more productively. (03)
A quick introduction with some simple examples will set the
scene. Properly amplifying and stabilizing the picture with the
other two pillars will take rather longer. (04)
The examples are taken mostly from the familiar IS application
domain of sales order processing and associated planning,
logistic and accounting functions. That will give us a start in
building on the basis of the second pillar, after a few
instalments to address all aspects of application development
within the business and general administrative world, and in an
industrial-strength way despite vexed issues such as identity,
privacy, security, data integrity, processing correctness and
application resilience and evolvability in general. Also, and
more interestingly, perhaps, order-processing leads to the
market in general, which will itself play an important technical
role and be a key aspect of the more fully philosophical picture
to come. That will be useful as a basis for expanding on the
role and contributions of the third pillar, before we finally
venture into more personal and social application domains.
Right, let's dive in properly now (for some very brief respite
from my promises, my hyperbole ... and my apologies): (05)
All formal MACK statements are triple-entity binary
entity-relationship facts. So, glossing over a few less
important details, here is a depiction of a well-formed though
minimalist ("elementary" or "atomic"?) Form: (06)
User GetsFrom Supplier. (07)
In its terms you Form (or "inForm"?) relevant situations into
facts like: (08)
John GetsFrom George.
and its inverse fact in terms of the inverse relationship:
George Supplies John. (09)
The Form's components are still implicitly defined here but are
identified in this writeup as formal Entities by the un-English
initial capitals (yes, even for Relationships). (010)
Pat Hayes had earlier insisted (now at
http://ontolog.cim3.net/forum/ontolog-forum/2008-01/msg00385.html)
that (011)
> The ideal ontology framework is one in which all
> contextual sensitivity has been _eliminated_ as far as
> possible. (012)
So note that our first Form is contextless and timeless. More
strictly, like most such basic Forms and many highly-refined
ones too, it would have been defined as a Form with time
"Anytime". It could even be given completely tenseless
semantics (but we'll see more of MACK's simple semantic picture
later, and also what lies behind the reference in one of my 1997
web pages to "our shared occupancy of a richly textured time and
space". (013)
Is it too early, Pat, to say if that Form meets - or may seem to
meet - your ideal (ignoring all other apparent aspects of the
Form)? (014)
The main facts implicit in that definition are: User IsA Type;
Supplier IsA Type; and GetsFrom IsA Relationship. Already
assumed are facts like these: IsA IsA Relationship;
Relationship IsA Type; even Type IsA Type; and all their
inverse facts. (Let's not discuss names such as "Type" and
"Entity" just yet! Nor how this linear exposition obscures how
much easier and more natural Form definion and fact declaration
will be in the online environment the second pillar will grow
into.) (015)
But we have the beginnings of some important MACK-unique
features here already! Please bear with me: (016)
User and Supplier have no properties other than the usually
implicit ones indicated and the fact that they bear the
thereby-defined Relationship with each other. They are at the
highest or most abstract level at which they make sense. A User
is nothing except that one of them may get from a Supplier (and
usually implicitly also be in the InverseRelationship with a
Supplier). It doesn't even have to have a name or tag. (017)
So in a sense the relationship is the primary idea.
Non-Relationship Entities exist solely by virtue of their
Relationships with other Entities. (I can't resist noting that
a refinement is our South African notion of "Ubuntu": "We are
who we are through other people.") There is no such thing in
MACK as a standalone Entity, though it may be known with nothing
more than an IsA fact, even as in X IsA Entity. But none of all
that is new, of course. The unique bit starts now: (018)
More than somewhat analogous to introducing RDF's subproperty,
we now start building up to the "filthy-lucre" or commercial
market by defining a Subform of our first one: (019)
Customer BuysFrom Vendor. (020)
So, clearly, Customer IsSubtypeOf User and Vendor IsSubtypeOf
Supplier, but more noteworthy is that BuysFrom Implies GetsFrom
(in which you may also note why I suggest capitalizing
Relationship names/tags) (021)
But does that mean that (in a manner of speaking)
{Anne-as-Customer BuysFrom Lynne-as-Vendor} Implies
{Anne-as-Customer GetsFrom Lynne-as-Vendor}? Yes and no. There
is only one Anne and only one Lynne, so yes, of course Anne
GetsFrom Lynne, so OO-inheritance's substitutability has its
parallel here (as in the Liskov Substitution Principle). But
no, the GetsFrom fact is an abstracted fact, about the more
abstracted subjects and objects. What are the practical
implications of that apparently rather fine distinction? Well,
a neat example here is that the filthy-lucre activities of Anne
and Lynne are hidden from those who have access only to the more
abstract and perhaps more anodyne facts. But that's still not a
unique feature, as DBMS Views can be a basis for the same
non-disclosure of more refined facts. (Well, maybe, if you
really work at it...) (022)
More redolent of absolutely key and unique further implications,
though (as far as I know...), is the "Common Knowledge" use of
such finely-layered Form distinctions or "Form deltas". Let's
pop back a bit. I had said entities don't need names. Ignore
for now how we are supposed to say our things and find our ways.
But it is easier to see that the most-refined Common Knowledge
Form (Forms, actually) between two interacting parties, or
between two of one party's activities, or even between one of
your things now and the "same" thing later, is often usefully
determined dynamically and may result in hitherto-undeclared
levels with their own fine-distinction implications. And that
is the start of the secret (that is, secret up to this series of
posts to this list) of much of the so-vaunted interoperability
support to result from MACK. (023)
Much less obviously still, though, is that detailed
MACK-AOS-driven processing within any one stream or thread will
also build on such fine distinctions. But that last sentence is
certainly too much a mouthful for you to grasp just yet, without
reading more of the sequel first, as I haven't even started
introducing the basics of any "processing" yet! I would however
like to record at this point that the MRCL, or Most Refined
Common Level, between two situations will be the basis of many
miracles which ordinary people-users will perform on a daily
basis. (024)
But do definitely note this now too: I referred to OO above,
and the MACK "parallel" with the LSP. Why? Well, if you look
carefully you will see that while the LSP, as with virtually all
present OO, is shoe-horned into the Classical Object Model (in
which messages are always sent to single-type/class objects),
here MACK as we have seen it thus far is clearly aligned to be
of the Generalized kind. That results from the multi-type
nature of the relationship and hence of even the atomic Form.
We shall also quite shortly develop that strand of thought, and
see how natural and elegant that is, and for many kinds of
reason. Such aspects will also help explain why, like Classical
OO, XML too, with its single root element, should be "considered
harmful". (025)
This 2nd instalment has developed far enough for now. In the
3rd instalment I'll draw strands out of the above basics, weave
some more strands in (pulled mainly from the second pillar), and
then you'll more easily see a fabric developing which you
haven't dreamed of yet. For example, we'll see how we do things
with the relational join which I suspect would have delighted
Codd himself. Anyway, those join-derived things are of prime
importance to all three pillars. (026)
Now it is surely true that Pat or Chris or any one of the rest
of you logicians could easily render all of the above examples
into IKL or whatever other more usual symbolic-logical form you
choose, and in about half a minute flat. But I would bet,
giving you long odds, that on such a basis you wouldn't be able
to do any application development with any such rendering, not
before those monkeys have produced Shakespeare's collected
works, like what ordinary people will soon be able to do with
what we can easily complete building on the above. And please
don't take that as a personal insult! As you will see, "The
medium is the message." (027)
(That can also be the case in mathematics, as you know.
Consider, for example, how an otherwise analytically unsolvable
differential equation can often be solved very simply via
Laplace transforms (if I recall correctly?). And, oh, that
reminds me: I might now also mention that the basis of all
MACK-based processing is transformations, as we'll see as the
second pillar is incorporated. (Hence also my fascination with
Category Theory, albeit still from a respectful distance, and
rather on and off.) So I do also expect that a proper
"logicization" of MACK will produce many useful insights and
processes too.) (028)
Cocky, am I? Yes, I suppose I am. (But maybe one has to be, to
persist with a story for as long as I have been doing with this
one?) (And that prompts a related request: please do take the
greatest care not to take any of my statements out of its
contexts with my other words here, extremely difficult though
that surely is at this stage, so unfamiliar as many of those
contexts must be to you still, or at least incongruous in your
usual professional contexts!) (029)
So this is a good time to add that I shall soon start with far
more important calls for your help than I have issued so far.
So I hope you stick it out here and through the next few
instalments too. Then that "together" word in this project's
goal could already start to really mean something. You might
also consider the opening headings and verse on my first web
page (http://jeffsutherland.com/oopsla96/spottisw.html). They
still apply (as does the rest of that web page, including on the
Classical/Generalized Object Model issue as raised above). (030)
Christopher (031)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (032)
|