I agree generally with what Leo has suggested below (thanks for the
good summary). In particular, agreeing on the upper ontology
we will use is important. But I think that we should attempt to
map these concepts to more than one upper ontology, such as
SUMO, OpenCYC and even look for a mapping to WordNet, not
really an upper ontology. Since we have already agreed on step
1 (of Leo's 8), and Leo will provide a list to permit us to
work on step 2, I would suggest that we commence to discuss
step 3: what are the important terms that we need to represent
in the ontology? (01)
I see that two areas (invoice and purchase-order) have been
selected as starting areas. Would it be possible for the
people who have volunteered to work on them to provide
a simple non-redundant list of all of the concept classes
(would these correspond to ebXML "Basic Core Components"??) that
would be included in those structures and the items they
reference? I would like to see how divergent these terms
look from the perspective of more than one ontology. (02)
Pat (03)
================================== (04)
Leo Obrst wrote:
> Over the course of our last two telecons, we've raised some issues (and
> satisfied ourselves with some discussion), but we want to open these
> issues up to discussion among the larger membership.
>
> 1) Ontology Methodology
>
> We are going to follow steps 1-5 in the Noy & McGuinness Ontology 101
> methodology. Why? Because it is relatively simple and we are trying to
> adopt a KISS (Keep It Simple, Stupd) meta-methodology. The fused
> Methontology-OntoClean methodology is more complicated, because it tries
> to create an engineering discipline for the development of ontologies,
> an ontological engineering, borrowing from the more evolved software
> engineering/development lifecycle methodologies (Methontology) and from
> formal ontology analysis (OntoClean).
>
> We are going to follow steps 1-5 only (and really, part of 5) because
> these are generic and make no assumptions about knowledge
> representation/ontology language. When you talk about "slot" and
> "facet", in particular, you are oriented toward a "frame-based" KR
> language, and we didn't want to force that perspective yet. [Aside:
> however, when we talk about KR languages and prospective tools based on
> those languages, we will possibly re-introduce these frame notions -- so
> stay tuned!]
>
> Step 1. Determine the domain and scope of the ontology
> Step 2. Consider reusing existing ontologies
> Step 3. Enumerate important terms in the ontology
> Step 4. Define the classes and the class hierarchy
> Step 5. Define the properties of classes—slots
> * Step 6. Define the facets of the slots
> * Step 7. Create instances
>
> I'll reword the above to be the following, and probably we can adopt all
> seven steps with this rewording (and I'll add a distinct step 8, even
> though this step is partially included in steps 4-7, about which we'll
> have more discussion later):
>
> Step 1. Determine the domain and scope of the ontology
> Step 2. Consider reusing existing ontologies
> Step 3. Enumerate important terms in the ontology
> Step 4. Define the classes and the class hierarchy
> Step 5. Define the properties of classes
> Step 6. Define the additional properties related to or necessary for
> properties (i.e., cardinality, bidirectionality/inverse, etc.)
> Step 7. Create instances
> Step 8: Create axioms/rules
>
> Question: are these revised 8 steps reasonable to folks?
>
> 2) Upper Ontology/ies
>
> It is much easier to develop domain ontologies (domain defined as a
> subject area or area of knowledge, e.g., business-to-business
> e-commerce) when these can use upper ontologies. In our experience,
> developing domain ontologies without upper ontologies causes you to
> spend a good portion of your time creating what should be in an upper
> ontology (if you had one), i.e., time, space, part-hood, abstract vs.
> concrete, organization, process, state, task, product, location, role,
> contiguity, synchronization, dependency, physical property, scalar
> measures, unit of measure, etc.
>
> So it is useful at the beginning of the process in developing domain
> ontologies to have and use a set of upper ontologies. SUMO (Suggested
> Upper Merged Ontology) has been offered as one candidate by Adam Pease.
> He has mapped one of our targeted areas of focus (Invoicing) to the SUMO
> -- a very useful exercise.
>
> This is an issue we need to address: let's pull in an Upper Ontology or
> set of upper ontologies, so we don't spin our wheels re-inventing stuff
> that may already be available. Which ones? Well, currently there are a
> few out there. SUMO, Upper Cyc, and some others probably not as
> extensive. I will try to dig up a summary.
>
> Leo
> --
> _____________________________________________
> Dr. Leo Obrst The MITRE Corporation
> mailto:lobrst@xxxxxxxxx Intelligent Information Management/Exploitation
> Voice: 703-883-6770 7515 Colshire Drive, M/S H305
> Fax: 703-883-1379 McLean, VA 22102-7508, USA
>
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
>mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>
> (05)
--
=============================================
Patrick Cassidy (06)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (07)
internet: cassidy@xxxxxxxxx
============================================= (08)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
mailto:ontolog-forum@xxxxxxxxxxxxxxxx (09)
|