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

[Pat Hayes <phayes@xxxxxxx>]

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
> Form)?

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

>  Already
> 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
> into.)
>
> 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.

Pat

-- 

---------------------------------------------------------------------
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

_________________________________________________________________
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)