[Top] [All Lists]

[ontolog-forum] MACK basics - 4th instalment: Reality and our Architecte

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Christopher Spottiswoode" <cms@xxxxxxxxxxxxx>
Date: Wed, 23 Apr 2008 22:59:32 +0200
Message-id: <084401c8a585$9e4ae140$0100a8c0@Dev>
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 
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 
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)

 --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)

<Prev in Thread] Current Thread [Next in Thread>
  • [ontolog-forum] MACK basics - 4th instalment: Reality and our Architected Model, Christopher Spottiswoode <=