[Top] [All Lists]

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

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Pat Hayes <phayes@xxxxxxx>
Date: Thu, 21 Feb 2008 11:23:40 -0600
Message-id: <p06230900c3e35ec6839d@[]>
At 9:03 AM +0200 2/21/08, Christopher Spottiswoode wrote:

All formal MACK statements are triple-entity binary
entity-relationship facts.  So, glossing over a few less
important details, here is a depiction of a well-formed though
minimalist ("elementary" or "atomic"?) Form:

User GetsFrom Supplier.

In its terms you Form (or "inForm"?) relevant situations into
facts like:

John GetsFrom George.
and its inverse fact in terms of the inverse relationship:
George Supplies John.

What specifies that GetsFrom is the inverse of Supplies? Is this fact also a Form? In OWL/RDF for example one could write (in N3 notation, using URI syntax to be legal)

ex:GetsFrom owl:inverseOf ex:Supplies .

Is it too early, Pat, to say if that Form meets - or may seem to
meet - your ideal (ignoring all other apparent aspects of the

So far it seems rather similar to RDF, which isn't a bad start, but needs supplementation with more expressive notations. IN particular, one will need something like a universal quantifier and something like negation and implication.

The main facts implicit in that definition are:  User IsA Type;
Supplier IsA Type;  and GetsFrom IsA Relationship.

To translate to RDF use this table:

IsA             rdf:type
Type            rdfs:Class (or possibly owl:Class)
Relationship    rdf:Property

assumed are facts like these:  IsA IsA Relationship;
Relationship IsA Type;  even Type IsA Type;  and all their
inverse facts.  (Let's not discuss names such as "Type" and
"Entity" just yet!  Nor how this linear exposition obscures how
much easier and more natural Form definion and fact declaration
will be in the online environment the second pillar will grow

But we have the beginnings of some important MACK-unique
features here already!  Please bear with me:

User and Supplier have no properties other than the usually
implicit ones indicated and the fact that they bear the
thereby-defined Relationship with each other.

Have no other, or are not asserted to have any other? That is, is it *prohibited* for these to have any other properties? (OWL-DL would say yes to this question, RDF would say no. A basic difference in knowledge-architectural style.)

 They are at the
highest or most abstract level at which they make sense.  A User
is nothing except that one of them may get from a Supplier (and
usually implicitly also be in the InverseRelationship with a
Supplier).  It doesn't even have to have a name or tag.

Like a blank node in RDF.

So in a sense the relationship is the primary idea.
Non-Relationship Entities exist solely by virtue of their
Relationships with other Entities.

Quite. A basic insight of relational logic since Tarski.
 (I can't resist noting that
a refinement is our South African notion of "Ubuntu":  "We are
who we are through other people.")  There is no such thing in
MACK as a standalone Entity, though it may be known with nothing
more than an IsA fact, even as in X IsA Entity.  But none of all
that is new, of course.  The unique bit starts now:

More than somewhat analogous to introducing RDF's subproperty,
we now start building up to the "filthy-lucre" or commercial
market by defining a Subform of our first one:

Customer BuysFrom Vendor.

So, clearly, Customer IsSubtypeOf User and Vendor IsSubtypeOf
Supplier, but more noteworthy is that BuysFrom Implies GetsFrom

Is that stated somehow (how?) or is it implicit? On what basis? If I write any triple

Customer Foodle Vendor

does it follow that Foodle implies GetsFrom?

(in which you may also note why I suggest capitalizing
Relationship names/tags)

But does that mean that (in a manner of speaking)
{Anne-as-Customer BuysFrom Lynne-as-Vendor} Implies
{Anne-as-Customer GetsFrom Lynne-as-Vendor}?

What does the -as- connective mean? Is Anne the same entity as Anne-as-Customer? If so, what is the meaning attached to the longer form? If not, what is the difference between them?

 Yes and no.  There
is only one Anne and only one Lynne, so yes, of course Anne
GetsFrom Lynne, so OO-inheritance's substitutability has its
parallel here (as in the Liskov Substitution Principle).  But
no, the GetsFrom fact is an abstracted fact, about the more
abstracted subjects and objects.

Tell us what you mean by 'abstracted subjects'.

You seem here to have contradicted yourself. If there is only one Anne then
Anne = Anne-as-Customer
so the 'more abstracted' Anne is the same as the plain Anne. You need to state what you mean more clearly.

 What are the practical
implications of that apparently rather fine distinction?  Well,
a neat example here is that the filthy-lucre activities of Anne
and Lynne are hidden from those who have access only to the more
abstract and perhaps more anodyne facts.

Well, sure, but that is trivial and does not require dividing Anne into parts.

Much less obviously still, though, is that detailed
MACK-AOS-driven processing within any one stream or thread

What do you mean by 'stream or thread' here?

Now it is surely true that Pat or Chris or any one of the rest
of you logicians could easily render all of the above examples
into IKL or whatever other more usual symbolic-logical form you
choose, and in about half a minute flat.

So far it seems to just be RDF in a different notation, insofaras I can follow it at all.

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

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

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