Re: SUO: Starter Ontology Version 2
> >(AUTHOR ?INS ?WHO)
> > - the name of the person as a string ?WHO who added
> > the individual ?INS to the Standard Upper Ontology
Adam Pease commented:
> I'd suggest making ?WHO of type Person (or maybe Agent?). That instance of
> Person could have a 'name-of' assertion.
>
Another option is to use email addresses to identify persons.
As you can tell by reviewing this ontology, I never defined
STRING as a class. I was planning on doing so, if necessary,
but thought I was getting too close to an implementation model.
What are the characteristics we want to use for Agents?
John Sowa's page at http://www.bestweb.net/~sowa/ontology/agents.htm
describes an agent as:
An agent is an animate entity that is capable of doing something
on purpose. (and then describes what is meant by those terms).
We will need to have some way to represent people, should we
go ahead and add AGENT as a class, or is that opening a can of
worms we wanted to keep nailed shut for right now?
> >(REVISION ?INS ?ID)
> > - the revision identified by the string ?ID is the
> > initial one in which the individual ?INS was part
> > of the Standard Upper Ontology
Adam Pease commented:
> I'd prefer something like 'revisionDate' taking a date as an argument,
> which I think would be more meaningful than a revision number.
I agree that a date with time (defaulting to GMT, or including timezone?)
would be more meaningful. Will we need a simple model of time
identifiers as elements in a sequence, (as I did for NUMBER)?
> >(NUM-< ?NUM-PREV ?NUM-NEXT)
> > - the number ?NUM-PREV
> > is eventually followed by
> > ?NUM-NEXT in numerical order
Adam Pease commented:
> why not 'num-prev' rather than 'num-<' ?
I chose NUM-< because it was the 'less than' relation on numbers.
the name NUM-PREV doesn't mean the same thing to me.
Of course, it is possible that I didn't axiomatize the 'less than'
relation properly. The rules in question are:
R115: (TRANSITIVE-THROUGH NUM-< NUM-SUCC)
R116: (TRANSITIVE-THROUGH NUM-< NUM-<)
R117:
(forall (?X ?Y)
(=>
(INSTANCE-OF ?X NUMBER)
(INSTANCE-OF ?Y NUMBER)
(NUM-SUCC ?X ?Y)
(NUM-< ?X ?Y)))
> >POSITION
> > - class of positions in an assertion
>
> I'm not clear on why the position which numbers the place of an argument in
> a relation needs to be its own class rather than just an Integer.
I made POSITION a separate class to handle
cases where positions had extra axioms that
weren't shared by COUNT. I didn't come up with
any. We could remove POSITION and COUNT as classes
if no one else can see a need for the distinction.
They do represent different ways to use a number,
but I'm not sure what needs to be stated to make
that difference explicit in the ontology.
One difference I can think of is that it doesn't
really make sense to arithmetically sum or multiply
two positions. It may make sense to do that for a
numeric count, but the starter structural ontology
hasn't made that explicit yet.
> >INDIVIDUAL
> > - class of individuals in the KB which
> > are the possible values of variables.
> > coextensional with TOP
There are currently no axioms stating formally
what it means to be coextensional with TOP.
This is because the group has not decided our
Set and Collection ontology as yet. We will need
to work on that soon.
> >ASSERTION
> > - class of all assertions
> > expressing a sentence
>
> Would it be more proper to call this 'Sentence' ? 'Assertion' seems to
> imply a form of usage. Just a quibble over a name though.
I think of an assertion as actually being present in the Knowledge
Base. I think of a sentence as only potentially being present.
Thus using a universal quantifier or existential quantifier over
assertions would be weakly second order, if I understand
Chris Menzel's terminology.
In reviewing (rather quickly) the rules that use the ASSERTION
class, I don't think I make the distinction that I just described.
Since in my mind, Assertions have an associated truth value,
I will rename this class to SENTENCE in the next version.
That also points to the need to include a relation for well-formedness
in the next version as well.
> We could use this class to associate comments with statements. That
> might make things easier for storing in a knowledge base although it would
> make commenting a bit more cumbersome. For example, instead of
>
> R005: ;; There exists something
> (exists (?ONE)
> (INSTANCE-OF ?ONE TOP))
>
> we could have
>
> (comment "There exists something"
> (exists (?ONE)
> (INSTANCE-OF ?ONE TOP)))
I didn't include any of the comment relations we discussed on another
thread because I didn't know if the group was in agreement.
another way of stating the above would be to use:
(NAME-OF (exists (?ONE)
(INSTANCE-OF ?ONE TOP))
R005)
(COMMENT R005 "There exists something")
> >R003:
> >(forall (?X ?Y)
> > (not (and
> > (= ?ANY ?ANY)
> > (\= ?X ?Y))))
>
> What about instantiating as
>
> (not
> (and
> (= Chair01 Chair01)
> (/= Bob Sue)))
>
> I'm probably missing something obvious
The obvious you missed is that it should have
been:
R003:
(forall (?X ?Y)
(not (and
(= ?X ?Y)
(\= ?X ?Y))))
I'll plead simple tiredness. I obviously should have
editted a line after I cut and pasted.
Likewise for having two rules R004.
> >R031:
> >(forall (?INS ?STR)
> > (=> (AUTHOR ?INS ?STR)
> > (\= ?STR "")))
>
> It might be worth having the ability to track multiple authors with
> something like
>
> (previousAuthor ?ASSERT ?WHO ?EARLIER-WHO)
>
> You could then have a whole chain of authors.
Would it be better to combine the AUTHOR and REVISION-DATE
relations into a relation like:
(REVISION-INFO ?INS ?WHO ?WHEN ?REV-ID) ?
that would allow creation of the chain of authors, and
the chain of editing date-times, or even the chain of
revision id strings for any instance.
Another argument might be that these are book-keeping
meta-relations, and should only be in the SUO
'behind the scenes' and not in the basic structural SUO.
What is the consensus of the group?
David (whitten@lynx.eaze.net) (713) 791-1414 ext 6116