W3C home > Mailing lists > Public > www-webont-wg@w3.org > November 2001

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

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Mon, 05 Nov 2001 10:58:11 -0500
To: connolly@w3.org
Cc: www-webont-wg@w3.org
Message-Id: <20011105105811Y.pfps@research.bell-labs.com>

I know that the group is not supposed to be making ontologies, but if we
are going to use an ontology as an example, particularly as an example of
us, I would like to have a good ontology, and the ontology that Dan is
proposing that we use (http://www.w3.org/2000/10/swap/pim/contact) is
broken in several ways and bad in other ways.  I know that if I am going to
have to eat any of my own dogfood, I want the dogfood to be superior
quality.  (Although, knowing how dogfood is made makes me very leery of
eating any dogfood at all!)


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!

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?

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.


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.  Why
not use an existing methodology, such as vCard?  [See below for my concerns
about vCard.]


The ontology defines ``Address'', which I take to mean a postal address.
It also defines a bunch of relationships that, I presume, are supposed to
represent the semantically-meaningful portions of an address.  However,
some of the relationships are semantically-meaningful, like ``country'',
and some are not, like ``Street3''.    There is also the problem that many
people have several different addresses for their offices, perhaps one used
by the postal service and one used by the delivery services.

Why not try for a fully semantic representation of Address, something like
	Recipient
	Internal - used after the delivery service delivers the object
	Local - used by the delivery service
	City - or other administrative district
	State/Province
	Country
	PostalCode - a (mostly) redundant identifier used by the delivery service
Under this scheme, my addresses would be
	PostalAddress	Recipient	Peter F. Patel-Schneider
			Internal	Lucent Technologies
					Room 2A-427
					600 Mountain Ave
			Local		PO Box 636
			City		Murray Hill
			State/Province	New Jersey
			Country		US
			Postal Code	07974-0636

	DeliveryAddress	Recipient	Peter F. Patel-Schneider
			Internal	Lucent Technologies
					Room 2A-427
			Local		600 Mountain Ave
			City		Murray Hill
			State/Province	New Jersey
			Country		US
			Postal Code	07974-0636


peter




PS: In my opinion the vCard methodology is not very good, but at least it
does exist.  Why not good?  Consider my mother, whose legal name is (close
to) Francis Jane Cressman Schneider, but everyone calls her Jane.  vCard
has the requirement that the first of one's given names is distinguished,
but that doesn't fit lots of people.  vCard also has no way of
distinguishing between the various ways that people acquire extra names.
My mother's full name is usually written F. Jane Schneider, which treats
her first name in the way that people's middle name is usually treated.
vCard does not allow the possibility of different names entirely, such as
the very common Mrs. Fred Schneider, which, by the way, is a different
person from Mrs. Frederick Schneider.  Why is this important?  Just try to
get on an international flight when the name on your ticket and the name on
your passport don't match.
Received on Monday, 5 November 2001 10:58:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:46 GMT