ontolog-forum
[Top] [All Lists]

[ontolog-forum] MACK basics - 3rd instalment - more on Form structure an

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Christopher Spottiswoode" <cms@xxxxxxxxxxxxx>
Date: Tue, 25 Mar 2008 19:36:23 +0200
Message-id: <016101c88e9e$cd9eea20$0100a8c0@Dev>
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)

<Prev in Thread] Current Thread [Next in Thread>
  • [ontolog-forum] MACK basics - 3rd instalment - more on Form structure and function, Christopher Spottiswoode <=