[Top] [All Lists]

Re: [ontolog-forum] MACK basics - 2nd instalment clarifications & amplif

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Christopher Spottiswoode" <cms@xxxxxxxxxxxxx>
Date: Thu, 21 Feb 2008 17:52:57 +0200
Message-id: <05fa01c874a1$dff3e980$0100a8c0@Dev>
Oops:  In this 2nd instalment, now at 
http://ontolog.cim3.net/forum/ontolog-forum/2008-02/msg00291.html, I 
sloppily misrepresented the MACK Form in the very first example 
I gave.  (Not a good omen, one might say!)  I was using my own 
habitual compressed or mnemonic representation, which I must now 
explain:    (01)

The representation I gave here is NOT a direct MACK 
triple-entity fact portrayal:    (02)

> User GetsFrom Supplier.    (03)

whereas these fact-representations do directly portray resulting 
or conformant MACK facts:    (04)

> John GetsFrom George.
> and its inverse fact in terms of the inverse relationship:
> George Supplies John.    (05)

The Relationship itself defines the atomic Form thanks to its 
own properties of SubjectType and ObjectType (aka domain and 
range, which MACK avoids for solid reasons we'll look at later), 
as well as cardinality and inverse relationship with its own 
cardinality, where cardinality relates to the Type in the 
ObjectType role.  (Both cardinalities in this case would usually 
reflect the frequent n-m situation, but more refined 
declarations could restrict them.)    (06)

My representation in that example is obviously a mere stylized 
abbreviation and compression of that data, and not 
coincidentally maps (at the obvious higher level of abstraction) 
to a node-arrow-node segment of almost any familiar 
Entity-Relationship or ER type of diagram.    (07)

My apologies for the confusion this slip would have caused any 
careful reader.    (08)

But I see now that I should at this stage give you some advance 
notice of some further important background behind that sloppy 
or ill-presented use of shorthand in this introductory context. 
I must even shout it out:    (09)



Input, interchange and output take place in more 
correctly-absorbable, digestible and already-digested or 
linked-in forms.  More significantly, the highly general-purpose 
yet flexible representation and structuring in this single 
architecture lead naturally to cleaner management of all 
internal affairs than we can easily imagine, given the muddled 
history and bloat of so much of what we have become accustomed 
to accept.    (012)

I realize that such decisions go against all the text-stream 
habits and conventions embodied in markup languages and even 
older stdin/stdout and other streaming interfaces, but I believe 
our needs and technologies can move on to more understandable, 
more integrated, more efficient and in the end more resilient 
and evolvable modes of interaction and interoperation.  And none 
of them need preclude serialized formats, for example, for more 
synchronized reception and rendering or other transformations. 
One major benefit, as we shall see in more detail, is that 
application-optimized distributed caching is the sort of 
function which a semantics-based and -driven AOS can manage in 
ways that cohere neatly with the overall framework (to use terms 
which can only be rather cryptic at this stage in this 
introduction, hence my resort to metaphors here).    (013)

The key aspect of the MACK universal medium (if I may assume 
already that such a Democratic Web will materialize so that I 
can use the present tense here...) is that it can be seen as a 
living organism, dividing and propagating continually and even 
evolving.  So it's a feeding one too, and all the users' and 
sensors' inputs are its food, which it ingests and digests, 
ultimately integrating most of it into the myriads of individual 
databases which comprise it, according to the various respective 
needs.  Those databases, like in an animal body, are like the 
cells and micro-organisms of all types in a more or less tight 
federation.  The aspect of Hobbes' Leviathan which that metaphor 
conjures up is not very pleasant (We'll replace that threatening 
aspect of the metaphor with a better one later!), but it does 
tell us that "You [the universal database] are what you eat!"    (014)

So MACK turns that view around and says that what input really 
means in practice can best be seen from what it becomes in that 
body.  More than that, it means that the best way to feed it is 
to fit it in for best effect in that body, in designedly-full 
view of what is there already, all in a situation-dependent way 
too, quite naturally!  So interactive and data-based methods 
predominate, all in much neater yet user-congenial ways than you 
can easily imagine yet.    (015)

But all that will become more meaningful once the structuring of 
a single database is clearer.  So I shall leave this discussion 
for the next two instalments at least, and post this correction 
before you are too confused by the error it corrects.    (016)

Christopher     (017)

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

<Prev in Thread] Current Thread [Next in Thread>