Pat, (01)
Thanks again! (02)
>>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 (03)
Correction again! That should have read: "where cardinality relates to
the set of instances of the Type in .the ObjectType role." (04)
>>ObjectType role. (Both cardinalities in this case would usually
>>reflect the frequent n-m situation, but more refined
>>declarations could restrict them.)
>
> How are all these cardinalities and so forth actually represented? (05)
Simple metadata. (And maybe I should have mentioned that all such
metadata is always contained in the invisible database too?) (06)
> The overall picture which is dimly emerging is something rather like
> OWL, or possible (given the OO connections) UML. (07)
One difference from UML is with MACK the MDA-like aspect is implicit, with
no need ever for anything like roundtripping. (08)
>
>>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.
>
> Quite.
>
>>I must even shout it out:
>>
>>THERE IS NO SUCH THING AS A STANDARD MACK SOURCE LANGUAGE;
>>
>>NOR IS THERE EVEN ANY INTERCHANGE 'LANGUAGE' AS SUCH.
>
> Again, like RDF, which is formally defined over abstract graphs, and can
> be encoded in a variety of 'interchange notations); also like CL's
> distinction between abstract syntax and surface dialect. A good design
> strategy, IMO. (09)
Actually, MACK's approach to all inter-database messaging may be rather
different: a message is itself a database, and can be logically merged
with its target database without being physically merged. And obviously
it is self-describing, usually mostly by reference to already
mutually-known Common Knowledge, so that different versions can coexist.
I'll mention here - but not go into it yet! - the very efficient yet
flexible strategy for managing identities and references, thinkable only
for a fully-managed data environment. (010)
>
>>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.
>
> Similar claims have been made for RDF graphs encoded as triple stores. (011)
Ah, but I haven't yet got onto MACK reflectivity based on its own internal
processing structures. The AOS is an operating system to a signifcant
extent, not only a DBMS. (012)
>
>>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. ...
>
> Yes, well, never mind. (013)
Okay... But still let's not forget the potentially simplifying effect of
metaphor, especially when continually reminded of all oversimplification
traps (and we overlook that immediate fall into one of them...). (014)
Christopher (015)
> Pat
> (016)
_________________________________________________________________
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 (017)
|