MACK basics - 4th instalment: Reality and our Architected Model (01)
This instalment begins a perhaps forbidding-looking but basically
extremely simple logical construction. In the process it starts
broaching some of the really difficult questions, both technical
and philosophical, that confront the IS architect, as touched on
in my recent post to this forum, now at
http://ontolog.cim3.net/forum/cgi-bin/mesg.cgi?a=ontolog-forum&i=04d001c898b6%24f9701080%240100a8c0%40Dev, (02)
on Microsoft's view of "Being Human". It _is_ however a mere
start... (03)
As a reminder, the overall objective is "to help people simplify
complexity together", and thereby together to "Ride The
Mainstream!" with the help of the "Democratic Web" communication
and collaboration medium. You will see how such fancy (or
portentous or pretentious) phrases usefully group the most plain
and everyday or already-"mainstream" technical and sociological
notions into a coherent toolset with universal applicability to
"The Mainstream" in all its human dimensions, at least as far as
one can communicate conceptually about them. (04)
The more specific subgoal in this IT-architecture-exposition is to
see how the "3 pillars" of MACK introduced in the 1st instalment
here,
http://ontolog.cim3.net/forum/cgi-bin/mesg.cgi?a=ontolog-forum&i=00f701c872c1%2421ff1940%240100a8c0%40Dev#nid010,
combine to form a platform for the future which despite our
ambient complexity will be a powerful enabler of human creativity
with a view to effective and efficient action, while yet being not
unmanageably distorting or impoverishing in its inevitable
reductionism. (05)
(As always, I am hoping you will ask the _really_ difficult
questions, or those I haven't thought of, before the consequences
of their remaining unasked become unduly costly. For example, you
might discover inconsistencies or redundancies in my definitions.
You will I hope point out poor explanations. Or you might show
mathematically how an operation in terms of the definitions may be
implemented using alternative programmatic algorithms while only
one will be scalably efficient, and perhaps only after key
modifications of the definitions. Or of course you might point
out that some feature of MACK which I appear to think is unique
has in fact been tried, successfully or otherwise, in some other
product or design. In such cases I would like to pursue the
matter and perhaps be able to point out some key difference, or
else probably incorporate further lessons into MACK or the AOS.) (06)
The 2nd and 3rd instalments did not develop as far as had been
anticipated in the 1st, but the 3rd does provide a useful list of
the broad questions this instalment starts addressing. It's at
this point:
http://ontolog.cim3.net/forum/cgi-bin/mesg.cgi?a=ontolog-forum&i=016101c88e9e%24cd9eea20%240100a8c0%40Dev#nid010. (07)
We can nonetheless build on the concepts introduced in the actual
2nd and 3rd instalments by casting them into a very pure ER shape
and adding further dimensions to it. That could doubtless be done
very rigorously, in a manner of speaking aping Peano's postulates,
both in superficial form and in their seeming redundancy (as seen
by the layman) when considering the utter simplicity of their
everyday meaning or model. So if this seems complicated, gloss
over it and rather just think plain familiar ER. To a large
extent, therefore, I take my own advice, abetted by what I see to
be the plain programmability of all I have already built on it and
see building on it further. So at least until you show me
something important about the axiomatic approach which I should
have taken into account, I gloss over many strict logical details
here too and try to keep the ER aspect in the fore! (08)
I have nonetheless dared to complicate this introduction with many
perhaps unnecessary hesitations and qualifications, and perhaps
premature reassurances of features still to come, which surely
detract from the simplicity of the basic model. But simplicity
without backwards and forwards glances might give the impression
of an unduly facile view. So be forewarned, and do please tell me
which distractions detract duly, and, of course, which important
questions or issues I seem to ignore. (I am sure the picture does
deserve a better treatment than this first shot at it!) (09)
A1. The MACK Form consists of a coherent or interlinking set of
Relationships ("Rels"), each with a unique Type as subjecttype
(with cardinality >= 1), a unique Type as objecttype (with
cardinality >= 1), and implying its Inverse Rel. The logical
summation of their originally more abstracted subjecttypes and
objecttypes defines a resultant set of more refined Types at
precisely the abstraction level required for the given or
Form-defining set of Rels, which are themselves thereby more
refined too. (Reminder: though there is always evolutionary
sense in the groupings of properties we have gathered together and
know as types, a type is merely a predicate, in this case the
logically-summed and thereby refining set of the simple predicates
provided as more abstract Rels.) (010)
((As an aside, I used to call the MACK Form the "Typology",
defined as a coherent set of Types with their metadata. But it is
easier to build up the Form in terms of Relationships. (There
even seems to be a duality between Types and Rels, in the sense of
[1], surely worth investigating further!) However, it makes no
immediate logical difference as Types and Rels are "otherwise
undefined" notions, that is, they are defined in terms of
themselves, as we saw in the 2nd and 3rd instalments and now
pursue further:)) (011)
A2. Much as with Peano's zero, the root Rel, the root Type, and
the root Form are defined by: (012)
Entity HasRelationshipWith Entity. (013)
A3. Then much as with Peano's successor function (here applied a
few times...), a new Form may be defined as a subForm on a
baseForm by adding Rels and thereby possibly new Types but always
new subtypes. A new Rel must 'Imply' baseForm Rels. A new Rel
may be a Join of sub- or base-Form Rels, along the lines we
briefly explored towards the end of the 3rd instalment (starting
here:
http://ontolog.cim3.net/forum/cgi-bin/mesg.cgi?a=ontolog-forum&i=016101c88e9e%24cd9eea20%240100a8c0%40Dev#nid049). (014)
The potential multiplicity - even potentially indefinite
variability! - of abstraction levels for both Types and Rels calls
for a reassurance: intermediate baseForms, baseTypes and baseRels
need not necessarily be made explicit or visible, or even less be
given distinguishing names, in any particular situation. It would
however be normal for any Type or Rel to be given a name at the
first level at which it appears, that is, the most abstract or
what we might call its "essential level". That name would often
tend to be applied at more refined levels too, though qualified -
explicitly or implicitly - with some indication of context. (015)
Another reason for this multiplicity of Form levels is the
requirement of non-0 Rel cardinality. Situations where
0-cardinality Rels are traditionally allowed indicate the use of
an optional further level of subForm. You will see how, perhaps
surprisingly, that is a very simplifying and powerfully-useful
stipulation. (016)
With A3, and the examples it refers to, we can begin to glimpse
that the Form is in general a very pliable entity, and hence will
tend to be very dynamic too. That will not only be the case when
it is being defined, refined, extended and otherwise manipulated.
It will especially be the case when the CK Form, or Common
Knowledge between two Forms (or plain "CK"), is being determined,
and even more especially when new and perhaps more applicable
Forms are being sought and explored. Such processes may take
place whenever new combinations of circumstance arise, which, when
we expose ourselves to a complex world, is almost all the time.
Then, yes, with such largely-implicit searches we already find
ourselves in the market in the most general sense, with its
dynamic partnerships and varying CKs with Internet-wide
scalability issues, but, crucially, also very often producing what
will appear to the individual user as creativity applicable to his
or her own situation. (017)
((So, as an extremely and practically important aside, we may
begin to observe that the source-code + namespace approach, which
so characterizes the Web in its present manifestations, is in
contrast a tragic brake on a living knowledge model. It's a
historical exoskeleton which should be sloughed-off as soon as
possible to make way for the growth we all seek, and sense should
be possible.)) (018)
We may however also note that the above definition makes it very
easy to follow-through from a graphic drawing facility for ER
diagrams into internal representations and related explorations.
Dagrams with optionally-zero cardinalities may be produced by
merging optional subForms with Forms. (019)
That MACK/ER-diagram correspondence usefully recognizes and builds
on the IT professional's familiarity and fluency with simple ER
diagrams. And that is not coincidental at all, as it nicely
illustrates the natural character of MACK structures. (020)
Nonetheless, we are wise to reserve judgment until we see how an
architecture and associated AOS can help us simplify the
complexity of more extensive, involved and detailed situations.
We all know how ER diagrams usually soon become unmanageably
intricate and spaghettified! (021)
So let us start adding more difficulty. (And thereby, perhaps
paradoxically, we shall avoid the ER-spaghetti outcome, in what I
like to call the benefit of "grasping the nettle of complexity"!) (022)
You might for example comment that there are some very familiar
Information System (IS) notions completely absent in the above
rather thin account of the Form, such as datatypes, attributes,
ids and references. Then of course there are all the matters
which are usually missing from ER diagrams, such as notions
involving time or change, such as events, transformations,
persistence or volatility, state-changes, transactions, output,
input and messaging. (023)
I now take what at the moment seems to me to be the shortest route
to showing in broad but hopefully sufficient outline how the
promise I made in my post now at
http://ontolog.cim3.net/forum/cgi-bin/mesg.cgi?a=ontolog-forum&i=007d01c88937%2416a86380%240100a8c0%40Dev (024)
can be fulfilled, putting us on a clear road to "solving" the
enormous and clearly topical problem expressed by, for example,
this heading from the SANS Institute's "NewsBites (Vol. 10 Num.
30)" of April 15: (025)
"TOP OF THE NEWS
--Targeted Attacks Against Sensitive US Networks on the Rise" (026)
We begin with the second group just mentioned of still-outstanding
matters: we introduce time via the notion of the operation in a
semantic net, involving changes to facts compliant with one or
more Forms. That is also the quickest route to 'context', and it
is Context which - no surprise! - happily resolves the
otherwise-difficult notions of identity and reference, quite apart
from the just-mentioned problem of how to hem-in rogue
programmers, whether they are malicious or merely incompetent. (027)
Time is a measure of change, but change itself is a more primitive
notion. Regularity, on the other hand, giving quantifiable
measures of time, is a quite rare abstraction, in nature at least,
whose striking character proves the rule and thereby makes it
scientifically valuable. (028)
Change in an abstract model, whether in our minds or in our
computers, is an aspect of process or is triggered by events. For
now, we ignore process, except where it can be adequately rendered
in terms of the discrete entities that can be represented in an ER
diagram or semantic net, that is, by approximation and without
undue dissonance. (Happily, we can ignore probabilities and
statistical theories at this point!) (029)
For all the discrete and 0/1 nature of our modelled facts, we will
still be able to incorporate the usual modelling device of
realtime steps or interrupts, those handy abstractions from or
indicators or approximate measures of continuous process. (030)
(So with this eschewing of analogue or real continuous process we
have the first explicit dismissal of one of the ever-present Frame
Problem aspects which Pat H will surely be watching for from his
1969 base. So, no, let me try to state it once and for all
(though I will fail as I will be reverting to it time and again!):
I do not pretend that MACK addresses the Frame Problem! It
sidesteps it. And in thus avoiding real AI, MACK trusts in its
Democratic Web pretensions, whose fundamental and far-reaching
relevance we'll be pursuing continually. One consequence for now,
though, is that MACK's is an open world model: a fact not
derivable from recorded facts is assumed unknown, not false.) (031)
So after all that in justification of our chosen basic
abstractions or simplifications, we continue using them in our
construction of our model ("model" here is of course in the
scientific or abstract representation sense, not in the sense of
an interpretation of a logical system). (032)
Simple or primitive as it still is, the passage of time takes the
form of successions of discrete events impinging from the
realworld in which our model is situated or emanating from our
model back to the realworld. Yes, it is realistic to regard them
as successions, in the plural, grouped as related by the
presumptions and susceptibilities of our model. The successions
are concurrent yet asynchronous, though with forking and merging.
(To call it merely a partial ordering is to rather hide the rich
correspondences with the real world, in which there exists what I
glorify with the name "relativistic realtime", as we shall see
time and again in the whole sequel here.) (033)
Now, since a fact, if present, is assumed to be 100% true (at this
simple stage in our construction...) there is a limited choice of
modelled consequences of an event. (034)
A4. So here we have the next major formal reductionism (after the
basic binary ER fact at various levels of abstraction) in the
application of MACK: every event from the real world is
interpreted as a combination of assertions or retractions of those
triple-entity facts. (For present purposes we may regard revision
or modification as an atomic sequence of retraction plus
assertion.) And every output to the real world is a consequence
of such a combination. (035)
That could hardly be controversial. But what determines that
combination of single-fact or elementary operations? (036)
A5. Ha, the Context, of course! Thus the MACK Context is defined
as any number of the set of Forms (and the "Full Context" if all
of them) which is currently "active" in the specific realworld
Situation as seen or viewed in that Context. Each Form gives its
own coherence and consistency to the Context, so the relevant
factset is - or should be - coherent and consistent too. Thus the
Form is the module of semantics, and the Formed factset the module
of state, all together hopefully giving us the meaning or truth
deemed currently relevant to our Situation of the moment. (037)
However, the Situation is never fully described by its
facts-in-Context, for if we tried, the spectre of the Frame
Problem would haunt again. The Context determines or frames the
currently relevant abstraction of the Situation, as deemed
relevant to the current Situation of the User (person or other
agent), including especially the User's current dispositions and
activities. Here we capture how our conceptions have evolved
through the aeons to "cut reality at its joints." We daren't
ignore The Mainstream, or even less reject or discard it. (038)
But we can consciously evolve it further, Riding it even, and
through better abstraction "strip the fat to get closer to the
flesh and bone with its joints." (The vegetarians can relax: I
shall not pursue that metaphor ad absurdum, nor even, I hope,
further ad nauseam.) And given modular forms such evolution tends
to be easier, or at least to become a more objective and sharable
process (even for those who have little use for any notion of the
evolution of species). ((In a later instalment I shall expand on
why we find it difficult to avoid metaphors at this kind of point,
and why it is even impossible.)) (039)
Let us pursue the operation of fact assertion or insertion into
the model. In a purely abstract model with no putatively-concrete
(or humanly-visible or -measurable) attributes we must evidently,
with a view to the maintenance of consistency, at least pursue the
usual referential integrity aspects. Thus with the triangular
Form of the 3rd instalment at
http://ontolog.cim3.net/forum/cgi-bin/mesg.cgi?a=ontolog-forum&i=016101c88e9e%24cd9eea20%240100a8c0%40Dev#nid039, (040)
and in terms of the brief note a few paragraphs down, at
http://ontolog.cim3.net/forum/cgi-bin/mesg.cgi?a=ontolog-forum&i=016101c88e9e%24cd9eea20%240100a8c0%40Dev##nid048, (041)
an apparently simple assertion into the Supplier-User Rel also
demanded assertions into the two Rels between Service and those
two Types, and perhaps also the insertion of a new Service. (042)
But how can an AOS appropriately enforce or implement such
consistency-required entailments? (Or, for that matter, enforce
the other constraints for which we still need to define the
elements required for their introduction here, such as constraints
like UML OCL's invariants which were designed for just such
needs?) (043)
A6. Observe first that the requirement seems to be universal:
_whenever_ any fact at all is asserted, then the corresponding
consistency must be pursued. So we create an Assert method, at
this root level and named for convenience's sake
"HasRelationshipWith_Assert" (which for greater convenience here
we abbreviate further to "RootAssert") to ensure such referential
integrity all in one atomic operation, as a function of the Forms
in the Context. In view of that method's utter universality,
being relevant to the assertion of absolutely any fact, it is a
prime candidate for incorporation into an AOS (at least because
one of the usual functions of any operating system is to provide
very commonly required functionality). And similarly for
"RootRetract". (044)
Clearly, there are many wrinkles in the full and precise design
and specification of the Root<Operation> methods which still need
to be ironed out, but let us first generalize the notion. (045)
A7. We can generalize to create methods with a standard RelAssert
or in general <Rel><Operation> structure. For example, we shall
see a lot of them for Type-specialized HasInstance Rels. (046)
Now the <Rel> method may seem very much like some mere slot
method. But quite apart from how the HasInstance methods cater
naturally for inter-slot or inter-field dependencies that cannot
conveniently be expressed using constraint formulae or other
Business Rules, the simplistic-slot impression overlooks their
all-important Context aspect. (047)
And here we may shout out our long-awaited Corollary which is the
basis for solving the core problem and brings about that
long-sought taming of the errant programmer: METHODS ONLY HAVE
ACCESS TO FACTS-IN-CONTEXT, and absolutely nothing more. There is
no general-purpose programming, no file access and no other i/o
capability, at least not unless it is explicitly and specifically
allowed, and even such options will only be relevant during the
transitional phase before pure MACK environments without
application system legacies are finally achieved. (048)
At this stage we may ignore the physical mechanisms (and indeed,
given present operating systems and languages, they are still not
quite up to this task). And we have not yet seen the MACK
equivalent of the acl or access control list within that Context.
But it should nonetheless be clear that in principle a programmer
subject to those disciplines cannot do anything drastically
malicious or stupid with effects outside the application.
Inaccurate, perhaps, yes, but normal application design should
control that problem, and the result will always be coherent,
consistent and correct in terms of the Form. And there we have
it. (Oh, sure, we still have to look at many other issues, such
as authentication, encryption and auditing, but even there MACK
brings many further goodies to the party.) (049)
But how is all that different from a properly controlled view of a
database using standard DBMS and programming disciplines? There
are many distinctive contributions by MACK, but first we have to
elaborate the picture somewhat more, and this is already rather
much for this long-overdue and increasingly imperfect 4th
instalment! (050)
Well, at least you now have quite a lot to get your teeth into,
and I will do my best to bring out the 5th instalment shortly. It
will dive straight into the matter of orthogonality, its
remarkable source and general significance, and especially its
remarkable consequences in the logical, operating and
philosophically-founded environment as already partly outlined
above. (In fact, the above will not make all much sense until
orthogonality is integrated into the picture and we can properly
grasp that nettle of compexity in the fashion that is already so
much part of The everyday Mainstream yet without its being
appreciated!) (051)
Christopher (052)
-------------------------------------
[1] Guenter Pickert, Ebene Inzidenzgeometrie - Beispiele zur
Axiomatik mit einer Einfuehrung in die formale Logik, 1958, Otto
Salle Verlag. Here the duality (see p.25ff) is between points and
lines, but the analogy with Types and Rels is extensive,
suggesting that exact Type/Rel duality might lead immediately to
such interesting theorems as equivalence between the Classical and
Generalized Object Models in OO, or their closest equivalent in an
axiomatic construction. However, considering how the prevalent
(Classical) OO practice of method overriding is a complete
abortion of OO's principles, the immediate practical relevance of
any such equivalence would be thin indeed! (053)
_________________________________________________________________
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 (054)
|