At 5:52 PM +0200 2/21/08, Christopher Spottiswoode wrote: (01)
>The representation I gave here is NOT a direct MACK
>triple-entity fact portrayal:
>
>> User GetsFrom Supplier.
>
>whereas these fact-representations do directly portray resulting
>or conformant MACK facts:
>
>> John GetsFrom George.
>> and its inverse fact in terms of the inverse relationship:
>> George Supplies John. (02)
Yes, I understand. The first triple is what would in OWL or RDFS be
called a domain/range assertion. In COE, we also abbreviated this by
a single arc (using a graphic convention to avoid muddle) so the
usage was familiar. (03)
>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.) (04)
How are all these cardinalities and so forth actually represented?
The overall picture which is dimly emerging is something rather like
OWL, or possible (given the OO connections) UML. (05)
>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. (06)
Quite. (07)
>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. (08)
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)
>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. (010)
Similar claims have been made for RDF graphs encoded as triple stores. (011)
>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. ... (012)
Yes, well, never mind. (013)
Pat (014)
--
---------------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 cell
http://www.ihmc.us/users/phayes phayesAT-SIGNihmc.us
http://www.flickr.com/pathayes/collections (015)
_________________________________________________________________
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 (016)
|