[sc34wg3] A handful of items about ontology building
Mason, James David (MXM)
sc34wg3@isotopicmaps.org
Mon, 29 Nov 2004 12:50:32 -0500
This is a multi-part message in MIME format.
------_=_NextPart_001_01C4D63B.EC27BCBF
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01C4D63B.EC27BCBF"
------_=_NextPart_002_01C4D63B.EC27BCBF
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
WG3 folks:
The IEEE group on Standard Upper Ontology (SUO) has recently been having
a discussion of principles for ontology building (one might ask why they
didn't do this three years ago before they started drafting ontologies).
I thought some of these messages and the references in them might be
interesting in the TM community while we're thinking of PSIs and other
such potentially ontological constructs. There's nothing revolutionary
there, just good advice. And I thought it might be worthwhile just to
keep up with what another standards committee is doing.
Jim M.
<<Re: Avoiding the pitfalls of ontology development>> <<RE: Avoiding
the pitfalls of ontology development>> <<Re: Avoiding the pitfalls of
ontology development>> <<Re: Avoiding the pitfalls of ontology
development>>=20
------_=_NextPart_002_01C4D63B.EC27BCBF
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>A handful of items about ontology building</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=3D2 FACE=3D"Arial">WG3 folks:</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">The IEEE group on Standard Upper =
Ontology (SUO) has recently been having a discussion of principles for =
ontology building (one might ask why they didn't do this three years ago =
before they started drafting ontologies). I thought some of these =
messages and the references in them might be interesting in the TM =
community while we're thinking of PSIs and other such potentially =
ontological constructs. There's nothing revolutionary there, just good =
advice. And I thought it might be worthwhile just to keep up with what =
another standards committee is doing.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Jim M.</FONT>
</P>
<BR>
<BR>
<BR>
<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> <<Re: Avoiding =
the pitfalls of ontology development>> </FONT><FONT FACE=3D"Arial" =
SIZE=3D2 COLOR=3D"#000000"> <<RE: Avoiding the pitfalls of =
ontology development>> </FONT><FONT FACE=3D"Arial" SIZE=3D2 =
COLOR=3D"#000000"> <<Re: Avoiding the pitfalls of ontology =
development>> </FONT><FONT FACE=3D"Arial" SIZE=3D2 =
COLOR=3D"#000000"> <<Re: Avoiding the pitfalls of ontology =
development>> </FONT></P>
</BODY>
</HTML>
------_=_NextPart_002_01C4D63B.EC27BCBF--
------_=_NextPart_001_01C4D63B.EC27BCBF
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by Y12MAIL01.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 23:43:45 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_003_01C4D2A9.588A9680"
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by exchange2.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Wed, 24 Nov 2004 23:43:57 -0500
Received: from engine.ieee.org ([140.98.193.23]) by exchange2 with trend_isnt_name_B; Wed, 24 Nov 2004 23:43:56 -0500
Received: from engine (engine [140.98.193.23]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAP4hXgb028986; Wed, 24 Nov 2004 23:43:33 -0500 (EST)
Received: from LISTSERV.IEEE.ORG by LISTSERV.IEEE.ORG (LISTSERV-TCP/IP release 1.8e) with spool id 41747 for STANDARD-UPPER-ONTOLOGY@LISTSERV.IEEE.ORG; Wed, 24 Nov 2004 23:43:33 -0500
Received: from hormel9.ieee.org (gemini3.ieee.org [140.98.193.188]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAP4hVgb028961 for <standard-upper-ontology@listserv.ieee.org>; Wed, 24 Nov 2004 23:43:31 -0500 (EST)
Received: from carmine.bestweb.net (carmine.bestweb.net [209.94.102.73]) by hormel9.ieee.org (8.12.10+Sun/8.12.10) with ESMTP id iAP4hQDb024237 for <standard-upper-ontology@listserv.ieee.org>; Wed, 24 Nov 2004 23:43:30 -0500 (EST)
Received: from [216.179.3.100] (dialin-608-tnt.nyc.bestweb.net [216.179.3.100]) by carmine.bestweb.net (Postfix) with ESMTP id 2ABEE2382C; Wed, 24 Nov 2004 23:43:25 -0500 (EST)
Content-class: urn:content-classes:message
Subject: Re: Avoiding the pitfalls of ontology development
Date: Wed, 24 Nov 2004 23:43:22 -0500
Message-ID: <41A562EA.50200@bestweb.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Avoiding the pitfalls of ontology development
Thread-Index: AcTSqVjQZ9aoxMXLRYu2M5AG0S6ZRA==
From: "John F. Sowa" <sowa@bestweb.net>
Sender: <owner-standard-upper-ontology@listserv.ieee.org>
To: "James R Schoening" <jim.s3@juno.com>
Cc: <standard-upper-ontology@listserv.ieee.org>
This is a multi-part message in MIME format.
------_=_NextPart_003_01C4D2A9.588A9680
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Jim,
I have heard some comments along the same lines:
> At my employer (US Government), I'm finding more and
> more ontology projects, but I have to wonder about
> the quality and value of them. Some start with
> taxonomies and add some basic OWL relationships.
> Others appear to take abstract/complex terms (found
> in enterprise architectures) and add relationships.
> Others are such quick efforts, one has to wonder.
> Others are developed with little or no background or
> experience in ontology development. Most projects
> appear to be starting with terms, not concepts.
Some of us have been criticizing ontologies done by
professionals. If we find problems in those, you can
imagine what kinds of disgusting flora and fauna lurk
in the ones done by amateurs.
That's why I suggested that we address the problem of
working on a document about principles for developing
and defining ontologies. I think that could be a
document that we could agree to more quickly than
a complete upper ontology, and it would be very
welcome for a very wide audience.
Without such a document, the remains of the flora and
fauna buried in those so-called ontologies are going
to smell real bad, real soon. And it will stink up
the whole field.
John
------_=_NextPart_003_01C4D2A9.588A9680
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>Re: Avoiding the pitfalls of ontology development</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Jim,<BR>
<BR>
I have heard some comments along the same lines:<BR>
<BR>
> At my employer (US Government), I'm finding more and<BR>
> more ontology projects, but I have to wonder about<BR>
> the quality and value of them. Some start with<BR>
> taxonomies and add some basic OWL relationships.<BR>
> Others appear to take abstract/complex terms (found<BR>
> in enterprise architectures) and add relationships.<BR>
> Others are such quick efforts, one has to wonder.<BR>
> Others are developed with little or no background or<BR>
> experience in ontology development. Most projects<BR>
> appear to be starting with terms, not concepts.<BR>
<BR>
Some of us have been criticizing ontologies done by<BR>
professionals. If we find problems in those, you can<BR>
imagine what kinds of disgusting flora and fauna lurk<BR>
in the ones done by amateurs.<BR>
<BR>
That's why I suggested that we address the problem of<BR>
working on a document about principles for developing<BR>
and defining ontologies. I think that could be a<BR>
document that we could agree to more quickly than<BR>
a complete upper ontology, and it would be very<BR>
welcome for a very wide audience.<BR>
<BR>
Without such a document, the remains of the flora and<BR>
fauna buried in those so-called ontologies are going<BR>
to smell real bad, real soon. And it will stink up<BR>
the whole field.<BR>
<BR>
John<BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_003_01C4D2A9.588A9680--
------_=_NextPart_001_01C4D63B.EC27BCBF
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by Y12MAIL01.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 04:25:31 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_004_01C4D2D0.B54D7780"
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by exchange2.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 04:25:38 -0500
Received: from engine.ieee.org ([140.98.193.23]) by exchange2 with trend_isnt_name_B; Thu, 25 Nov 2004 04:25:24 -0500
Received: from engine (engine [140.98.193.23]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAP9P2gd004579; Thu, 25 Nov 2004 04:25:03 -0500 (EST)
Received: from LISTSERV.IEEE.ORG by LISTSERV.IEEE.ORG (LISTSERV-TCP/IP release 1.8e) with spool id 44026 for STANDARD-UPPER-ONTOLOGY@LISTSERV.IEEE.ORG; Thu, 25 Nov 2004 04:25:02 -0500
Received: from ruebert.ieee.org (ruebert [140.98.193.10]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAP9P2gb004569 for <standard-upper-ontology@listserv.ieee.org>; Thu, 25 Nov 2004 04:25:02 -0500 (EST)
Received: from hormel7.ieee.org (gemini4.ieee.org [140.98.193.189]) by ruebert.ieee.org (Switch-3.1.0/Switch-3.1.0) with ESMTP id iAP9P1ep004156 for <standard-upper-ontology@listserv.ieee.org>; Thu, 25 Nov 2004 04:25:01 -0500 (EST)
Received: from R323.shell.com (r323.shell.com [145.26.110.69]) by hormel7.ieee.org (8.12.10+Sun/8.12.10) with ESMTP id iAP9OxaX006328 for <standard-upper-ontology@listserv.ieee.org>; Thu, 25 Nov 2004 04:25:00 -0500 (EST)
Received: from rijpat-s-325.europe.shell.com ([145.26.111.102]) by R323.shell.com with Microsoft SMTPSVC(5.0.2195.6982); Thu, 25 Nov 2004 10:24:59 +0100
Received: from rijpat-s-320.europe.shell.com ([145.26.110.66]) by rijpat-s-325.europe.shell.com with Microsoft SMTPSVC(5.0.2195.6982); Thu, 25 Nov 2004 10:24:59 +0100
Received: from Lonsc-s-029.europe.shell.com ([164.136.74.59]) by rijpat-s-320.europe.shell.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Nov 2004 10:24:59 +0100
Content-class: urn:content-classes:message
Subject: RE: Avoiding the pitfalls of ontology development
Date: Thu, 25 Nov 2004 04:24:58 -0500
Message-ID: <A94B3B171A49A4448F0CEEB458AA661F01B1D9F0@lonsc-s-029.europe.shell.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Avoiding the pitfalls of ontology development
Thread-Index: AcTSpaB+hj9bbeFaQhSC1waqM1yG0QAKM2yQ
From: "West, Matthew R SITI-ITABEI" <matthew.west@shell.com>
Sender: <owner-standard-upper-ontology@listserv.ieee.org>
To: "James R Schoening" <jim.s3@JUNO.COM>,
<standard-upper-ontology@listserv.ieee.org>
This is a multi-part message in MIME format.
------_=_NextPart_004_01C4D2D0.B54D7780
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Dear Jim,
You will be aware that my background is in data modelling, and that
data models are one way of representing an ontology.
In the early nineties we were struggling with the problems you describe,
and we identified 10 Traps that people commonly fell into in developing
data models, and following that 6 Principles that if applied would =
prevent
you falling into those traps. These were published initially as two =
internal
Shell documents:
"Reviewing and Improving Data Models" and
"Developing High Quality Data Models".
This latter also included our first attempt at an upper ontology.
The Upper Ontology was used as the start point for what eventually =
became
ISO 15926. The principles have been applied in its development - it =
would
have been hopeless without them.
The traps and principles were combined in a publicly available document:
http://www.matthew-west.org.uk/Documents/princ03.pdf
I presented the story of the development of the principles and ISO 15926 =
at
a recent workshop at EKAW04.
http://www.matthew-west.org.uk/Documents/Industrial_Experiences_in_Ontolo=
gy.pdf
I have seen the principles adopted by a number of organisations and =
consultants
both in the work they do and in their teaching.
Matthew West
Streamline Business Information Architect for Supply Chain Management
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com
http://www.matthew-west.org.uk/
> -----Original Message-----
> From: owner-standard-upper-ontology@listserv.ieee.org
> [mailto:owner-standard-upper-ontology@listserv.ieee.org]On Behalf Of
> James R Schoening
> Sent: 25 November 2004 04:15
> To: standard-upper-ontology@listserv.ieee.org
> Subject: Avoiding the pitfalls of ontology development
>
>
> All,
>
> At my employer (US Government), I'm finding more and more
> ontology projects, but I have to wonder about the quality and value of
> them. Some start with taxonomies and add some basic OWL
> relationships.
> Others appear to take abstract/complex terms (found in enterprise
> architectures) and add relationships. Others are such quick
> efforts, one
> has to wonder. Others are developed with little or no background or
> experience in ontology development. Most projects appear to
> be starting
> with terms, not concepts.
>
> Has anyone yet characterized this trend? Are there
> any names yet
> for this? What are the pitfalls? Has anyone written a
> paper on the 7
> pitfalls of ontology development? I need a polite way of
> helping these
> projects avoid such pitfalls.
>
> Jim Schoening
>
------_=_NextPart_004_01C4D2D0.B54D7780
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>RE: Avoiding the pitfalls of ontology development</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Dear Jim,<BR>
<BR>
You will be aware that my background is in data modelling, and that<BR>
data models are one way of representing an ontology.<BR>
<BR>
In the early nineties we were struggling with the problems you =
describe,<BR>
and we identified 10 Traps that people commonly fell into in =
developing<BR>
data models, and following that 6 Principles that if applied would =
prevent<BR>
you falling into those traps. These were published initially as two =
internal<BR>
Shell documents:<BR>
<BR>
"Reviewing and Improving Data Models" and<BR>
"Developing High Quality Data Models".<BR>
<BR>
This latter also included our first attempt at an upper ontology.<BR>
<BR>
The Upper Ontology was used as the start point for what eventually =
became<BR>
ISO 15926. The principles have been applied in its development - it =
would<BR>
have been hopeless without them.<BR>
<BR>
The traps and principles were combined in a publicly available =
document:<BR>
<BR>
<A =
HREF=3D"http://www.matthew-west.org.uk/Documents/princ03.pdf">http://www.=
matthew-west.org.uk/Documents/princ03.pdf</A><BR>
<BR>
I presented the story of the development of the principles and ISO 15926 =
at<BR>
a recent workshop at EKAW04.<BR>
<BR>
<A =
HREF=3D"http://www.matthew-west.org.uk/Documents/Industrial_Experiences_i=
n_Ontology.pdf">http://www.matthew-west.org.uk/Documents/Industrial_Exper=
iences_in_Ontology.pdf</A><BR>
<BR>
I have seen the principles adopted by a number of organisations and =
consultants<BR>
both in the work they do and in their teaching.<BR>
<BR>
<BR>
Matthew West<BR>
Streamline Business Information Architect for Supply Chain =
Management<BR>
Shell Information Technology International Limited<BR>
Shell Centre, London SE1 7NA, United Kingdom<BR>
<BR>
Tel: +44 20 7934 4490 Mobile: +44 7796 336538<BR>
Email: matthew.west@shell.com<BR>
Internet: <A HREF=3D"http://www.shell.com">http://www.shell.com</A><BR>
<A =
HREF=3D"http://www.matthew-west.org.uk/">http://www.matthew-west.org.uk/<=
/A><BR>
<BR>
<BR>
> -----Original Message-----<BR>
> From: owner-standard-upper-ontology@listserv.ieee.org<BR>
> [<A =
HREF=3D"mailto:owner-standard-upper-ontology@listserv.ieee.org">mailto:ow=
ner-standard-upper-ontology@listserv.ieee.org</A>]On Behalf Of<BR>
> James R Schoening<BR>
> Sent: 25 November 2004 04:15<BR>
> To: standard-upper-ontology@listserv.ieee.org<BR>
> Subject: Avoiding the pitfalls of ontology development<BR>
><BR>
><BR>
> All,<BR>
><BR>
> At my employer (US =
Government), I'm finding more and more<BR>
> ontology projects, but I have to wonder about the quality and value =
of<BR>
> them. Some start with taxonomies and add some basic OWL<BR>
> relationships.<BR>
> Others appear to take abstract/complex terms (found in =
enterprise<BR>
> architectures) and add relationships. Others are such =
quick<BR>
> efforts, one<BR>
> has to wonder. Others are developed with little or no =
background or<BR>
> experience in ontology development. Most projects appear =
to<BR>
> be starting<BR>
> with terms, not concepts.<BR>
><BR>
> Has anyone yet =
characterized this trend? Are there<BR>
> any names yet<BR>
> for this? What are the pitfalls? Has anyone =
written a<BR>
> paper on the 7<BR>
> pitfalls of ontology development? I need a polite way of<BR>
> helping these<BR>
> projects avoid such pitfalls.<BR>
><BR>
> Jim Schoening<BR>
><BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_004_01C4D2D0.B54D7780--
------_=_NextPart_001_01C4D63B.EC27BCBF
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by Y12MAIL01.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 10:52:12 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_005_01C4D306.BA2D1E00"
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by exchange2.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 10:52:12 -0500
Received: from engine.ieee.org ([140.98.193.23]) by exchange2 with trend_isnt_name_B; Thu, 25 Nov 2004 10:52:10 -0500
Received: from engine (engine [140.98.193.23]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAPFpggb019928; Thu, 25 Nov 2004 10:51:42 -0500 (EST)
Received: from LISTSERV.IEEE.ORG by LISTSERV.IEEE.ORG (LISTSERV-TCP/IP release 1.8e) with spool id 47445 for STANDARD-UPPER-ONTOLOGY@LISTSERV.IEEE.ORG; Thu, 25 Nov 2004 10:51:42 -0500
Received: from hormel9.ieee.org (gemini3.ieee.org [140.98.193.188]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAPFpfgb019907 for <standard-upper-ontology@listserv.ieee.org>; Thu, 25 Nov 2004 10:51:41 -0500 (EST)
Received: from carmine.bestweb.net (carmine.bestweb.net [209.94.102.73]) by hormel9.ieee.org (8.12.10+Sun/8.12.10) with ESMTP id iAPFpeDb001104 for <standard-upper-ontology@listserv.ieee.org>; Thu, 25 Nov 2004 10:51:40 -0500 (EST)
Received: from [216.179.3.178] (dialin-686-tnt.nyc.bestweb.net [216.179.3.178]) by carmine.bestweb.net (Postfix) with ESMTP id 81BFE2311F; Thu, 25 Nov 2004 10:51:38 -0500 (EST)
Content-class: urn:content-classes:message
Subject: Re: Avoiding the pitfalls of ontology development
Date: Thu, 25 Nov 2004 10:51:35 -0500
Message-ID: <41A5FF87.3030800@bestweb.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Avoiding the pitfalls of ontology development
Thread-Index: AcTTBrp3JNfFxNwgTXiKD834CzPXJw==
From: "John F. Sowa" <sowa@bestweb.net>
Sender: <owner-standard-upper-ontology@listserv.ieee.org>
To: "West, Matthew R SITI-ITABEI" <matthew.west@shell.com>
Cc: "James R Schoening" <jim.s3@JUNO.COM>,
<standard-upper-ontology@listserv.ieee.org>
This is a multi-part message in MIME format.
------_=_NextPart_005_01C4D306.BA2D1E00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Dear Matthew,
Those two documents contain a lot of useful
information about some successes and failures
and suggestions for how to promote the former
while avoiding the latter.
There are many other documents available
on the web that contain examples, principles,
analyses, and recommendations for how to and
how not to develop and use ontologies. And
of course, there are also the web sites that
contain ontologies, taxonomies, lexicons, and
other resources. Some of them are already on
the SUO web site, but many more are not.
As a first step, I suggest that we compile
an annotated bibliography of such resources.
For each one, there should be a brief comment
that summarizes what it contains and how it
relates to the other documents and resources.
Whether or not the SUO as a whole adopts a
project to boil that down into more concise
technical report, the bibliography itself
should become a valuable resource.
John
------_=_NextPart_005_01C4D306.BA2D1E00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>Re: Avoiding the pitfalls of ontology development</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Dear Matthew,<BR>
<BR>
Those two documents contain a lot of useful<BR>
information about some successes and failures<BR>
and suggestions for how to promote the former<BR>
while avoiding the latter.<BR>
<BR>
There are many other documents available<BR>
on the web that contain examples, principles,<BR>
analyses, and recommendations for how to and<BR>
how not to develop and use ontologies. And<BR>
of course, there are also the web sites that<BR>
contain ontologies, taxonomies, lexicons, and<BR>
other resources. Some of them are already on<BR>
the SUO web site, but many more are not.<BR>
<BR>
As a first step, I suggest that we compile<BR>
an annotated bibliography of such resources.<BR>
For each one, there should be a brief comment<BR>
that summarizes what it contains and how it<BR>
relates to the other documents and resources.<BR>
<BR>
Whether or not the SUO as a whole adopts a<BR>
project to boil that down into more concise<BR>
technical report, the bibliography itself<BR>
should become a valuable resource.<BR>
<BR>
John<BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_005_01C4D306.BA2D1E00--
------_=_NextPart_001_01C4D63B.EC27BCBF
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by Y12MAIL01.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 14:01:14 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_006_01C4D321.2288F900"
Received: from exchange2.y12.doe.gov ([134.167.250.19]) by exchange2.y12.doe.gov with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 14:01:06 -0500
Received: from engine.ieee.org ([140.98.193.23]) by exchange2 with trend_isnt_name_B; Thu, 25 Nov 2004 14:01:06 -0500
Received: from engine (engine [140.98.193.23]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAPJ0xgb007737; Thu, 25 Nov 2004 14:00:59 -0500 (EST)
Received: from LISTSERV.IEEE.ORG by LISTSERV.IEEE.ORG (LISTSERV-TCP/IP release 1.8e) with spool id 49639 for STANDARD-UPPER-ONTOLOGY@LISTSERV.IEEE.ORG; Thu, 25 Nov 2004 14:00:59 -0500
Received: from hormel5.ieee.org (gemini3.ieee.org [140.98.193.188]) by engine.ieee.org (Switch-3.1.2/Switch-3.1.2) with ESMTP id iAPJ0wgb007726 for <standard-upper-ontology@listserv.ieee.org>; Thu, 25 Nov 2004 14:00:58 -0500 (EST)
Received: from meganesia.int.gu.edu.au (meganesia.sci.griffith.edu.au [132.234.113.101]) by hormel5.ieee.org (8.12.11/8.12.11) with ESMTP id iAPJ0sqp025862 for <standard-upper-ontology@listserv.ieee.org>; Thu, 25 Nov 2004 14:00:56 -0500
Received: (from phmartin@localhost) by meganesia.int.gu.edu.au (8.11.6/8.11.6) id iAPItwh15709; Fri, 26 Nov 2004 04:55:58 +1000
Content-class: urn:content-classes:message
Subject: Re: Avoiding the pitfalls of ontology development
Date: Thu, 25 Nov 2004 13:55:58 -0500
Message-ID: <200411251855.iAPItwh15709@meganesia.int.gu.edu.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Avoiding the pitfalls of ontology development
Thread-Index: AcTTISMd4+ZGpfpRSVawFQb5L2p8fg==
From: "Philippe Martin" <phmartin@meganesia.sci.griffith.edu.au>
Sender: <owner-standard-upper-ontology@listserv.ieee.org>
To: <standard-upper-ontology@listserv.ieee.org>
Cc: <phmartin@meganesia.sci.griffith.edu.au>
This is a multi-part message in MIME format.
------_=_NextPart_006_01C4D321.2288F900
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
John Sowa wrote:
> That's why I suggested that we address the problem of
> working on a document about principles for developing
> and defining ontologies.
> ... compile an annotated bibliography of such resources.
I have put the principles I list below in
http://www.webkb.org/doc/ontologyBuildingPrinciples.html
It links to my previous "discussion on recommendations to
increase knowledge reuse".
Matthew West wrote:
> The traps and principles were combined in a publicly available =
document:
> http://www.matthew-west.org.uk/Documents/princ03.pdf
Six good principles (a list is on page 7) and the importance of
"reflecting the reality" and "generic entity modelling" is well
illustrated. Section 8.6 (page 51) asks the question "Why Stop Here?",
i.e. why not use a "binary relational model" representing all
relationships as entity types since "associations are
derived entity types". The given answer is (i) "unfortunately,
the data model that results is almost impossible to understand" and
(ii) this would not make the data models more "flexible and stable".
I won't dispute this for a data model (in a database context),
but in a knowledge base, (i) relation types may be defined and thus
used as abbreviations to give readability, (ii) this would lead to
more normalized knowledge representations (hence more comparable,
retrievable, re-usable, ...). Thus, for KBs, I propose the
following list of principles as an element for the discussion:
I Structural/ontological principles
1) Each introduced relation should be defined. If contexts (i.e.
meta-statements) can be used, only one primitive relation is
needed and it is binary (John Sowa called it LINK in his 1984 book).
If contexts are not used, a ternary primitive relation may be
useful.
I am not sure but I think this covers (and extends) the
first 4 of the 6 above refered principles, when adapted to KBs.
2) There should be one subtype hierarchy (hence with one one top)
which include all the declared concept type.
This is my reformulation of the last of the 6 above refered
principles.
3) The meaning of the subtype and instance relations should
be respected. The criterias of the <a =
href=3D"http://www.loa-cnr.it/Papers/CACM2002.pdf">OntoClean =
methodology</a>
(e.g. identity, unity, ...) help to check that.
4) The "proper_subtype" relation and the "identity" or "equivalence"
relations should be prefered to the general "subtype" relation.
Same note for other partial order relations.
5) Organizing types via the "subtype" relation should be prefered
to organizing via the "instance" relations, whenever adequate.
6) The classic knowledge representation structures (relation
signatures and cardinalities, open/complete subtype partitions,
exclusion links, ...) should be used whenever adequate.
7) New ontologies should re-use directly or indirectly reuses a
top-level ontology that defines notions of collection, state,
process, event, spatial_entity, physical_entity, temporal_entity,
information_entity, property and measure.
The ontological assumptions (e.g. see the <a =
href=3D"http://wonderweb.semanticweb.org/deliverables/D18.shtml">WonderWe=
b D18</a>
for a nice summary) should be explicit.
8) If a 3D approach is used (instead of a 4D approach), temporal
constraints should be represented in the statements that require
them. Temporal constraints may be represented using contexts, or
adding a time parameter to some relations type. The first option
seems easier for people to represent natural language sentences. The
second option is easier for current theorem provers to reason with.
II Naming principles
1) "Entity types should represent, and be named after, the
underlying nature of an object, not the role it plays in a
particular context" (this is the 5th of the 6 above refered
principles).
2) The <a =
href=3D"http://www.webkb.org/doc/conventions.html#relationArguments">read=
ing and naming convention generally advocated by
frame-based or graph-based languages</a> should be preferred
(hence the use of a noun or a nominal form for an identifier,
without "has_", "is_" or "_of" inside this identifier; e.g.
"parent", not "child_of", not "has_parent" nor the verbal forms
"parenting" and "parents").
However, if this convention is not respected, it is better to
use "_of" to make the parameter ordering explicit than to use
a different parameter ordering without signaling it in the
identifier.
3) Identifiers that reuse common words should use the same
capitalization. To separate words, it is <a =
href=3D"http://www.webkb.org/doc/conventions.html#interCapStyle">better =
to use
underscore than the Intercap style</a>. When European words
are re-used, a first capitalized letter should be the mark of
an individual (not a type). Thus, "member_of_the_ONU" is better
than "MemberOfTheONU", "memberOfTheONU", "ONU_member" and
"ONUMember".
4) Identifiers for second-order types should include "_type" or
"_class" at the end, as in "binary_relation_type" (intead of
"Property").
Philippe
------_=_NextPart_006_01C4D321.2288F900
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">
<TITLE>Re: Avoiding the pitfalls of ontology development</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>John Sowa wrote:<BR>
> That's why I suggested that we address the problem of<BR>
> working on a document about principles for developing<BR>
> and defining ontologies.<BR>
> ... compile an annotated bibliography of such resources.<BR>
<BR>
I have put the principles I list below in<BR>
<A =
HREF=3D"http://www.webkb.org/doc/ontologyBuildingPrinciples.html">http://=
www.webkb.org/doc/ontologyBuildingPrinciples.html</A><BR>
It links to my previous "discussion on recommendations to<BR>
increase knowledge reuse".<BR>
<BR>
<BR>
<BR>
Matthew West wrote:<BR>
> The traps and principles were combined in a publicly available =
document:<BR>
> <A =
HREF=3D"http://www.matthew-west.org.uk/Documents/princ03.pdf">http://www.=
matthew-west.org.uk/Documents/princ03.pdf</A><BR>
<BR>
Six good principles (a list is on page 7) and the importance of<BR>
"reflecting the reality" and "generic entity =
modelling" is well<BR>
illustrated. Section 8.6 (page 51) asks the question "Why Stop =
Here?",<BR>
i.e. why not use a "binary relational model" representing =
all<BR>
relationships as entity types since "associations are<BR>
derived entity types". The given answer is (i) =
"unfortunately,<BR>
the data model that results is almost impossible to understand" =
and<BR>
(ii) this would not make the data models more "flexible and =
stable".<BR>
I won't dispute this for a data model (in a database context),<BR>
but in a knowledge base, (i) relation types may be defined and thus<BR>
used as abbreviations to give readability, (ii) this would lead to<BR>
more normalized knowledge representations (hence more comparable,<BR>
retrievable, re-usable, ...). Thus, for KBs, I propose the<BR>
following list of principles as an element for the discussion:<BR>
<BR>
<BR>
I Structural/ontological principles<BR>
<BR>
1) Each introduced relation should be defined. If contexts (i.e.<BR>
meta-statements) can be used, only one primitive relation =
is<BR>
needed and it is binary (John Sowa called it LINK in his =
1984 book).<BR>
If contexts are not used, a ternary primitive relation may =
be<BR>
useful.<BR>
I am not sure but I think this covers (and extends) the<BR>
first 4 of the 6 above refered principles, when adapted to =
KBs.<BR>
<BR>
2) There should be one subtype hierarchy (hence with one one top)<BR>
which include all the declared concept type.<BR>
This is my reformulation of the last of the 6 above =
refered<BR>
principles.<BR>
<BR>
3) The meaning of the subtype and instance relations should<BR>
be respected. The criterias of the <a href=3D"<A =
HREF=3D"http://www.loa-cnr.it/Papers/CACM2002.pdf">http://www.loa-cnr.it/=
Papers/CACM2002.pdf</A>">OntoClean methodology</a><BR>
(e.g. identity, unity, ...) help to check that.<BR>
<BR>
4) The "proper_subtype" relation and the "identity" =
or "equivalence"<BR>
relations should be prefered to the general =
"subtype" relation.<BR>
Same note for other partial order relations.<BR>
<BR>
5) Organizing types via the "subtype" relation should be =
prefered<BR>
to organizing via the "instance" relations, =
whenever adequate.<BR>
<BR>
6) The classic knowledge representation structures (relation<BR>
signatures and cardinalities, open/complete subtype =
partitions,<BR>
exclusion links, ...) should be used whenever adequate.<BR>
<BR>
7) New ontologies should re-use directly or indirectly reuses a<BR>
top-level ontology that defines notions of collection, =
state,<BR>
process, event, spatial_entity, physical_entity, =
temporal_entity,<BR>
information_entity, property and measure.<BR>
The ontological assumptions (e.g. see the <a =
href=3D"<A =
HREF=3D"http://wonderweb.semanticweb.org/deliverables/D18.shtml">http://w=
onderweb.semanticweb.org/deliverables/D18.shtml</A>">WonderWeb =
D18</a><BR>
for a nice summary) should be explicit.<BR>
<BR>
8) If a 3D approach is used (instead of a 4D approach), temporal<BR>
constraints should be represented in the statements that =
require<BR>
them. Temporal constraints may be represented using =
contexts, or<BR>
adding a time parameter to some relations type. The first =
option<BR>
seems easier for people to represent natural language =
sentences. The<BR>
second option is easier for current theorem provers to =
reason with.<BR>
<BR>
<BR>
II Naming principles<BR>
<BR>
1) "Entity types should represent, and be named after, the<BR>
underlying nature of an object, not the role it plays in =
a<BR>
particular context" (this is the 5th of the 6 above =
refered<BR>
principles).<BR>
<BR>
2) The <a href=3D"<A =
HREF=3D"http://www.webkb.org/doc/conventions.html#relationArguments">http=
://www.webkb.org/doc/conventions.html#relationArguments</A>">read=
ing and naming convention generally advocated by<BR>
frame-based or graph-based languages</a> should be =
preferred<BR>
(hence the use of a noun or a nominal form for an =
identifier,<BR>
without "has_", "is_" or =
"_of" inside this identifier; e.g.<BR>
"parent", not "child_of", not =
"has_parent" nor the verbal forms<BR>
"parenting" and "parents").<BR>
However, if this convention is not respected, it is better =
to<BR>
use "_of" to make the parameter ordering explicit =
than to use<BR>
a different parameter ordering without signaling it in =
the<BR>
identifier.<BR>
<BR>
3) Identifiers that reuse common words should use the same<BR>
capitalization. To separate words, it is <a =
href=3D"<A =
HREF=3D"http://www.webkb.org/doc/conventions.html#interCapStyle">http://w=
ww.webkb.org/doc/conventions.html#interCapStyle</A>">better to =
use<BR>
underscore than the Intercap style</a>. When European =
words<BR>
are re-used, a first capitalized letter should be the mark =
of<BR>
an individual (not a type). Thus, =
"member_of_the_ONU" is better<BR>
than "MemberOfTheONU", =
"memberOfTheONU", "ONU_member" and<BR>
"ONUMember".<BR>
<BR>
4) Identifiers for second-order types should include "_type" =
or<BR>
"_class" at the end, as in =
"binary_relation_type" (intead of<BR>
"Property").<BR>
<BR>
<BR>
<BR>
Philippe<BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_006_01C4D321.2288F900--
------_=_NextPart_001_01C4D63B.EC27BCBF--