Re: SUO: Re: More terminology
Pat,
Phil Jackson had set up a QuickBase mechanism for an SUO glossary over two
years ago in March 2001:
http://grouper.ieee.org/groups/suo/email/msg04107.html
*SUO Common Ontology Development Architecture (Coda)*
The purpose of this database is to implement a common ontology development
architecture for use by the IEEE Standard Upper Ontology (SUO) Working
Group, and thereby facilitate the development of the IEEE Standard Upper
Ontology.
*SUO Coda Ontology Modules*
This database supplements the IEEE Standard Upper Ontology (SUO) Common
Ontology Development Architecture (Coda), by providing a way to define
"Ontology Modules", which can be used to structure the terms defined within
Coda. Ontology modules help structure ontologies by providing namespaces
within which name clashes can be prevented, and into which terms can be
imported and reused from other namespaces.
I believe that I was the only person that submitted material.
Robert E. Kent
rekent@ontologos.org
----- Original Message -----
From: "Patrick Cassidy" <pcassidy@bellatlantic.net>
Cc: <standard-upper-ontology@ieee.org>
Sent: Sunday, June 22, 2003 7:49 PM
Subject: Re: SUO: Re: More terminology
>
> Terminology management:
>
> John F. Sowa wrote:
> > Pierre,
> >
> > PG>Are you pissed? I apologize.
> >
> > No. I'm not pissed. I'm just frustrated with the endless
> > rehashing of debates about terminology.
> >
> I agree that we need a standardized terminology list for
> this discussion group. I seem to recall that one of us proposed
> to set up such a list over a year ago, but don't recall
> whether anything concrete was decided.
> Can we use this thread to decide how to create a standard
> terminology for this group? Does anyone have experience setting
> up a WIKI? If not, I will volunteer to maintain a terminology
> page on my site (simple list-nothing fancy) until someone
> else sets up a better hypertext version.
>
> As one starting point, I would suggest a careful definition of
> the terms "class" and "relation" and "predicate" (which
> may require definition of "term" and "sentence").
>
> For "class" and "relation" I would prefer the usage that is
> given for KIF classes. It may not be the same as VNBG classes,
> but I think it is the most common use of the term - no?
> The definitions from the KIF site are attached below. Any
> dissenters? (silly question?) If the majority prefer this
> definition, and there is a minority that prefer a different
> usage, I would suggest creating a different term for the
> alternative usage.
>
> Pat
>
> --
> =============================================
> Patrick Cassidy
>
> MICRA, Inc. || (908) 561-3416
> 735 Belvidere Ave. || (908) 668-5252 (if no answer)
> Plainfield, NJ 07062-2054 || (908) 668-5904 (fax)
>
> internet: cassidy@micra.com
> =============================================
> from:
>
http://www-ksl.stanford.edu/knowledge-sharing/ontologies/html/frame-ontology
/CLASS.html
>
> CLASS
> Documentation:
> A class can be thought of as a collection of individuals. Formally, a
> class is a unary relation, a set of tuples (lists) of length one. Each
> tuple contains an object which is said to be an instance of the class.
> An individual, or object, is any identifiable entity in the universe
> of discourse (anything that can be denoted by a object constant in
> KIF), including classes themselves.
>
> The notion of CLASS is introduced in addition to the relation
> vocabulary because of the importance of classes and types in knowledge
> representation practice. The notion of class and relation are merged
> to unify relational and object-centered representational conventions.
> Classes serve the role of `sorts' and `types'.
>
> There is no first-order distinction between classes and unary
> relations. One is free to define a second-order predicate that makes
> the distinction. For example, (predicate C) could mean that the unary
> relation C should be thought of more as a property than as a
> collection of individuals over which one might quantify some
> statement. Logically, all such predicates would still be instances of
> the metaclass CLASS.
>
> The fact that an object i is an instance of class C is denoted by the
> sentence (C i). One may also use the equivalent form (INSTANCE-OF i
> C). This is not equivalent to (MEMBER i C).
> An instance of a class is not a set-theoretic member of the class;
> rather, the tuple containing the instance is a element of the set of
> tuples which is a relation.
>
> The definition of a class is a predicate over a single free variable,
> such that the predicate holds for instances of the class. In other
> words, classes are defined intentionally. Two separately-defined
> classes may have the same extension (in this case they are = to each
> other). It is possible to define a class by enumerating its instances,
> using KIF's set operations. For example, (define-class primary-color
> (?color)
> (member ?color (set red green blue)))
> Subclass-Of: Relation
>
> ========================
> RELATION
>
> Documentation:
> A relation is a set of tuples that represents a relationship among
> objects in the universe of discourse. Each tuple is a finite, ordered
> sequence (i.e., list) of objects. A relation is also an object itself,
> namely, the set of tuples. Tuples are also entities in the universe of
> discourse, and can be represented as individual objects, but they are
> not equal to their symbol-level representation as lists.
>
> By convention, relations are defined intensionally by specifying
> constraints that must hold among objects in each tuple. That is, a
> relation is defined by a predicate which holds for sequences of
> arguments that are in the relation.
>
> Relations are denoted by relation constants in KIF. A fact that a
> particular tuple is a member of a relation is denoted by
> (<relation-name> arg_1 arg_2 .. arg_n), where the arg_i are the
> objects in the tuple. In the case of binary relations, the fact can be
> read as `arg_1 is <relation-name> arg_2' or `a <relation-name> of
> arg_1 is arg_2.' The relation constant is a term as well, which
> denotes the set of tuples.
> Subclass-Of: Set
>
>