Re: LEAD: making an ontology about the ontology group...

From: Dan Connolly <>
Subject: Re: LEAD: making an ontology about the ontology group...
Date: Mon, 05 Nov 2001 11:13:58 -0600

> "Peter F. Patel-Schneider" wrote:


> Let's see how many of your comments are still outstanding...


> > The ontology uses ``address'' for the relationship between a
> > ``ContactLocation'' and an ``Address'', but the relationships like
> > ``Country'' all have domain ``address''.  This is valid RDF, but probably
> > will not have the intended meaning!
> Quite... ok.. I think I've fixed that now...

Looks fine.

> > The ontology is written in alphabetical order, which, because of the RDFS
> > way of having global domains and ranges, makes the information associated
> > with a class very hard to read.  Why not group relationships with the same
> > domain together?
> Actually, it's written using a different notation altogether
> and spit out in this form by machine. 


Still not very readable, but actually quite good for machine-generated
output.  (I.e., fine.)

> > The ontology has a very strange equivalentTo, which is not going to be
> > treated very well by any formalism that tries to assign useful meaning to
> > equivalentTo.
> Hmm... I wonder where that came from. I think it's fixed now.

Not fixed.  The following isn't particularly useful

    <rdf:Description rdf:about="#vcard_list">
        <ont:equivalentTo> vCard.Cellular, vCard.Company, vCard.Department, 
vCard.Gender, vCard.Home.City, vCard.Home.Country, 
vCard.Home.Fax, vCard.Home.Phone, vCard.Home.State, 
vCard.Home.StreetAddress, vCard.Home.Zipcode, vCard.Homepage, 
vCard.JobTitle, vCard.LastName, vCard.MiddleName, 
vCard.Notes, vCard.Office,  # ??? Office what? Number?
vCard.Business.City, vCard.Business.Country, vCard.Business.Fax, 
vCard.Business.Phone, vCard.Business.State, vCard.Business.StreetAddress, 
vCard.Business.URL, vCard.Business.Zipcode</ont:equivalentTo>

> > The ontology uses a firstName, middleName, lastName grouping for names,
> > which is not very general.  Further, the example that Dan provides uses
> > familyName, givenName, and fullName, which is better, but different.


> > The ontology defines ``Address'', which I take to mean a postal address.


I divide ontologies/taxonomies into several groups:

1/ Broken
2/ Too-badly flawed to work with
3/ Flawed but workable
4/ OK

The name, email, and address stuff from pim/contact.n3 v 1.11 falls
somewhere between 1 and 3 (currently 1, but the broken parts are probably

There appears to be a serious editing artifact (double specification of

There are some problems with name and address, but one might be able to
live with them.  However, if one is just trying to do names for contact
information, then a simple CommonName/FullName representation works
exceedingly well.

The treatment of email is totally broken, on both technical and modelling
grounds.  On the technical side, DAML+OIL unambiguous properties have to be
object properties, and thus can't have literals as their objects.  On the
modelling side, the relationship between social entities and mailboxes is
many-to-many, even when restricted to persons.


Received on Monday, 5 November 2001 13:56:17 UTC