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)
THERE IS NO SUCH THING AS A STANDARD MACK SOURCE LANGUAGE; (010)
NOR IS THERE EVEN ANY INTERCHANGE 'LANGUAGE' AS SUCH. (011)
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)
|