This 3rd instalment follows the 1st and 2nd, now respectively at: (01)
http://ontolog.cim3.net/forum/ontolog-forum/2008-02/msg00277.html (02)
and (03)
http://ontolog.cim3.net/forum/ontolog-forum/2008-02/msg00291.html, (04)
which were themselves preceded by an introduction now at (05)
http://ontolog.cim3.net/forum/ontolog-forum/2008-01/msg00453.html. (06)
In follow-up messages to the 2nd, Pat Hayes quite correctly and
usefully started pursuing the evident parallels with the W3C's
RDF. I noted their common foundation on fact triples and levels
of abstraction but warned or promised that there were many
significant divergences, especially from the emphasis on the
notion of levels of abstraction of which I had introduced about
the simplest possible kind of MACK example. (Let's ignore for now
the various loose ends we left untied in our brief discussion in
the 2nd instalment's thread.) (07)
We now dive straight into the core technical points of MACK. For
a while still we are mainly in the "pillar 1" of MACK as set out
in the 1st instalment at this point:
http://ontolog.cim3.net/forum/ontolog-forum/2008-02/msg00277.html#nid010,
but pillars 2 and 3 do make their appearance and start playing
some key roles. (08)
I have not coded it all into a running AOS - far from it! - so I
can certainly not guarantee that I have covered all bases. I'll
tell you what I have coded so far when we get to those areas, but
I can say that I see no great programming problem remaining
between here and a running proof of concept or even a universally
extensible platform. (After the programming of the basic AOS
there will however still be much capturing and canonical
Form-encoding of what one might call "design patterns", many of
which will already be familiar to IS-development practitioners
even without the special MACK flavours we'll give them.) So I ask
you once again, please, to tell me what aspects of the design you
think need modification or more radical correction, and what
important issues or details I seem to ignore. (09)
Here are some of the themes for the coming instalments (though
they are not covered completely in this order):: (010)
1. the nature and role of the Form; (011)
2. Form Common Knowledge and mutual orthogonality, and the
significance of that pair, Ontologically, epistemologically, as
well as in detailed implication and effect in Information Systems; (012)
3. how multiple Forms may constitute a Context (and by the way
completely supersede AOP or Aspect-Oriented Programming); (013)
4. the logical status of facts in Context, MACK "semantics", and
the meaning of MACK "relativity"; (014)
5. how the MACK Form contrasts with the currently conventional
IT-notion of an ontology, and some of the operational
data-consistency benefits; (015)
6. how the genericity of the Form gives easy reflectivity hence
automatic yet adaptive manipulation of Forms, though with managed
user-involvement wherever applicable; (016)
7. how processing takes place 100% through Form-driven
Context-switching transformations (a process which I call
"Koestler creativity"), and why, with authentication in terms of
Forms too, we have the very fundamental yet very practical basis
for solving "the" security problem; (017)
8. how Forms may be extended using procedural coding modules
while yet preserving their required clean logical properties, and
how the AOS is itself already completely structured that way, thus
paving the way for the universal applicability of the
architecture; (018)
9. how the fundamentals of OO come into their own in what is in
effect a Generalized Object Model, (019)
10. how messaging is structured and implemented (and why XML is
neither suited to the job nor needed for it); (020)
11. how screen projections or views are structured, and how input
is handled, all of which is very mashup-like, largely
automatically making extensive reuse of often extremely general
components; (021)
12. how local and remote search is given a much sharper edge by
usually taking place in a market Context, and often implicitly
(i.e. automatically); (022)
13. how data persistence fits into the picture, and why all
present DBMS architectures will rapidly be obsoleted while yet
respecting their objectives; (023)
14. transaction design and management, and how real application
resilience suddenly becomes much easier (as does Information
System "industrial strength" in general); (024)
15. the core mechanisms of application evolution, and how they are
uniquely suited to a Democratic Web; (025)
16 how legacy applications may interoperate with a MACK world at
various levels, and how databases, XML documents, and even
workflows, etc might surprisingly easily be re-engineered into
MACK-compliance and -leveraging; (026)
17. the unique Open-Source model canonical to MACK, and the
evolvability of MACK and MACK AOSs; and (027)
18. how a simple Boot or Seed AOS will be a platform from which
the open market will bootstrap the communication medium's own
universalization or inclusive coverage of The Mainstream. (028)
Clearly, that is an enormous bill to fit, even before we start
enjoying the consequences out there in the world of real people
with their own needs leading to applications that people can live
through. (Yet again I invoke the words of Heinz Zemanek, a past
president of IFIP, "An architect does not tell people how to live,
he creates an environment in which people may live their own lives
creatively".) (029)
So I try to reassure before we start that the whole picture is in
fact very natural, even close to the way we think and live in our
organic lives, whether or not we try to see past its deformations
by civilization (and its architectures) with its ubiquitous
artifacts and artifices. So I shall try to keep the 'natural way'
in the picture as we proceed. Hence also some of the historical
dimensions of "The Mainstream", of course, whose definition in the
1st instalment portraying the widest human context generalizes to
cover the evolution of all life on Earth. (030)
So if any of my explanations is not clear, the problem is in my
rendering here. Please do bear in mind that this is first time I
have ever tried to set out these internal details in writing (I
have merely been programming them - or some of them - so far).
But the problem will not be MACK at its more abstract levels,
which I dare say are certainly relevant and applicable. The AOS
and the whole future market infrastructure in general will make
the introduction job much easier by helping to make every point
more accessible to each user via its relevances to fuller user
contexts, but we're not there yet! Therefore once again I ask you
please to help me better elaborate the broader MACK picture with
its relevant details, as well as present it more clearly for
everybody? (031)
The self-consistent and self-coherent nature of the Form is the
main logical ingredient in the strength of our whole construction,
as it is in any axiomatic system. We have already seen its
beginnings in the 2nd instalment, where in the single-Relationship
Form (032)
User GetsFrom Supplier (033)
"a User is nothing except that one of them may get from a
Supplier." And vice versa in terms of the inverse Relationship,
Supplies. (034)
Thus the three concepts introduced (where we may regard Rel plus
InvRel as one concept) have no abstract meaning beyond their
self-coherence, given self-consistent use of satisfying entities,
or values for the variables. And we may imagine any "real
entities" substituting for those values as long as we are
consistent in such application, and, of course, such substitutions
do result in true facts about our real world. (So the notion of
applying an axiomatic system, or abstract system in general, is
clearly the model of the MACK Form (if you will accept yet another
rather handwaving "clearly" from me!)) (035)
However (to stray again onto pillar 3, long before we really build
it up), we may note that from an Ontological and epistemological
point of view, such working abstraction is the key to the
orthogonality between Forms that the real and practical power of
MACK derives from. That is still the case even though such power
is really the inherited wealth from the eons of evolution of our
concretely-applicable concepts, as in the definition of "The
Mainstream" at the end of the 1st instalment. (036)
"Orthogonality"? We'll look later at its detail with its very
plain but far-reaching significance in MACK, but meanwhile - with
many thanks to Sean Barker! - see his excellent answer to this
list on March 6 and now at
http://ontolog.cim3.net/forum/ontolog-forum/2008-03/msg00058.html. (037)
Another result of that abstract nature of the Form is that it is
closer to the database subschema than to the database schema.
That is an already-evident aspect of MACK's "relativity", or
Context- or user-viewpoint-dependence. We shall look later at the
consequences to the structuring, use and management of shared
data, which is what a full schema traditionally addresses. But
first let's look at making Forms themselves more interesting! (038)
We now add a third Type, Service (of which something like Product
or ProvidingProduct will usually be a subtype), and we close the
coherence with two obvious new Relationships plus a key
Relationship between them: (039)
User AvailsOf Service; (040)
Service IsSuppliedBy Supplier; (041)
GetsFrom IsJoinOf AvailsOf, IsSuppliedBy. /* here the objects are
in an ordered list as well as in the usual set */ (042)
Sketch your own triangular ER diagram of that, with arrows in the
directions which show how there are now two logical paths across
the triangle from User to Supplier, one direct, the other via
Service. The Join is the relational inner join, and more
specifically an equijoin. (043)
Given the usual cardinalities (which show how the original
base-Form's n-m relationship is rendered in the subform into a 1-m
and a n-1), there is surely a simple quantified symbolic-logical
rendering of that join. But I am happy to leave it as an easy
exercise for the Mathematical Logic 101 students among you as I
have never (yet.) felt the need to produce one myself. (044)
We now have a new Form which is a subform of our original one.
Assuming that both Forms have always been in-Context and there is
no other subform, every fact in the base-Form is derivable from
those in the subform. (045)
Now, whereas in the first Form the Type User had only one Rel, the
Type still called "User" now has two. So it is *not* the same
User Type! The second one is a subtype of the first, now with two
functional properties or "Required Relationships" (or "ReqRels",
where I continue with the more colloquial wording). (046)
Is that Type-name inheritance and reuse not confusing? No,
because the respective denotations are clear from whatever the
Context of their use! And an AOS will always make it clear, and
of course interpret any name-using input in that way too, checking
for any possible ambiguity. That is yet another reason for
subtyping: it cuts down on names, and if you think about it a bit
you will see that in everyday talk we perform this very same
type-name-reuse-across-abstraction-levels all the time. That
elision process is yet another reason for the MACK reliance on its
internal database interpreted in terms of Context, rather than on
source files and namespaces. You will see in much further detail
later how such reliance is indispensible when abstraction levels
are determined and applied dynamically. "Applied"? Yes, and here's
an example in the handy Context of our simple triangular Form: (047)
Thanks to now being richer in properties, the subtype User has
gained some synergy, involving extra implications to previously
bare facts. For example, when asserting what was the bare fact
"John GetsFrom George" now in this wider Context necessarily
demands, for consistency's sake, that John be related by AvailsOf
to a Service which IsSuppliedBy George. That is of course a
simple case of familiar "referential integrity", but in a MACK
environment its imposition will all just take place automatically,
though with Context-dependent consequences possibly requiring user
involvement. (048)
Before we continue building up the notion of the Form and seeing
more of what it implies, let's first look at another example of
the use of the Join, and at the same time start enriching the bare
fact in other ways. Consider these Rels: (049)
Customer HasAddress Address; (050)
Address HasWords AddressWord; /* usually giving a set of words,
possibly filtered, soundexed or otherwise massaged, generated by
easy parsing of Addresses */ (051)
Customer Buys Product; (052)
Product HasName ProductName; (053)
ProductName HasWords ProductNameWord; // as above (054)
Then by simple inversion of those facts in terms of the evident
inverse Rels, and adding the obvious three Joins with their
inverses, an AOS can automatically derive facts involving Rels
such as these (though of course without having to actually name
them because they would typically have been generated from
base-Forms, as in the case of the new "User" above!): (055)
AddressWord IsWordInNameOfCustomer Customer; (056)
ProductNameWord IsWordInNameOfProductBoughtBy Customer; (057)
Then if those inverted facts, already implicit in the
user-provided facts, are in addition maintained stored in the
database, simple and-ing of resulting lists of Customers gives
extremely fast access to e.g. those Customers in Main Road or Main
Street who have bought products in brass. And that is of course a
simple example of word-search-in-context. The speed issue is
especially important if the joins are long or the fields indexed
are big text blobs on which SQL's "in predicate" is too
inefficient (despite Boyer-Moore and variants). (058)
I might just mention that we wrote and sold a package, called
"Metakey", doing just that kind of thing, parameterized using SQL
join statements. We installed it on 3 different operating
systems. As you can see by finding "1991" in
http://jeffsutherland.com/oopsla98/SpottBioComp.html, that whole
experience gave significant impetus to the seemingly crazy idea of
dispensing with DBMS packages. (059)
That last little story might help give some credence to my belief
that I do have some of the practical experience required by the
Metaset/MACK kind of project. Not surprisingly, then,
DBMS-replacement is one of the two main areas where I have already
done some significant C coding for Metaset with the functional and
operational requirements in the above 18-item list in mind.
Detailed or technical requirements such as blinding speed do so
far seem to be eminently meetable. (060)
Then, since the other main area of my existing C coding is in
Form-based techniques for dynamic window creation and control
(that is, MACK Forms, not paper or screen forms), I am quite
emboldened in asserting that MACK's "AOP-like" replacement (cf.
item 3 above) of the traditional 3-tier architecture by the use of
orthogonal MACK Forms will be no great problem. (061)
Layered architectures have in many cases, including at both
boundaries of the 3-tier or data-logic-presentation architecture,
failed to have good or easy results. Why so? One of my favourite
theories was introduced in my first web page of 1996
(http://jeffsutherland.com/oopsla96/spottisw.html), and it once
again revolves around time issues! Briefly, there are too easily
mismatches between real time and algorithm time, and the
agent-structured and Form-driven AOS does not have that problem as
it is entirely realtime-driven. In 1996 my criticism was focussed
on the OMG's CORBA and OMA (Object Management Architecture), but
it remains as valid in respect of today's manifestation as SOA. (062)
But, considering network delays, can realtime-drivenness meet
calls for distribution-independence of application specification?
Ah, that is another question, and the MACK answer is that
so-called distribution independence is in effect tantamount to
"naïve realtime" while what is more appropriate to our
people-chunked organization of society is "relativistic realtime"
... as we shall see in much detail much later in this series. (063)
Well, I would guess that all that is already too much of a
mouthful from me for this 3rd instalment!? The next instalment
might well best be led by your hoped-for responses to the above,
if any. But in the meantime I will be working on extending the
definition of the Form and of the function of an AOS so that any
kind of application requirement can be addressed within its ambit
while yet well satisfying all those usual application "-ilities"
such as learnability, configurability, reliability,
distributability, flexibility, etc etc, while still having a major
advance in plain functional correctness at the top of the list. (064)
Christopher (065)
_________________________________________________________________
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 (066)
|