Re: LANG: closing issue 4.6 (was Re: ADMIN: Draf agenda for July 25 telecon)

Peter,

Thanks for this message. I think it helps clarify the issue. To further
elucidate things, could you answer a question I have about option 2?

It seems to me the option 2 leads to non-monotonicity. Consider the
following classes with extensions:

foo type Class.
bar type Class.
A type foo.
B type foo.
A type bar.
B type bar.

Since sameClassAs only means that two classes have the same extension,
then foo sameClassAs bar is a valid entailment, isn't it? 

But now what happens if I add C type bar (assuming C is a distinct
individual from both A and B)? Wouldn't that mean that foo sameClassAs
bar is no longer true? Thus, we can a statement and our entailements are
no longer a superset of the entailments of the original set of
statements, which is non-monotonic.

I admit I haven't spent too much time following this idea, so if there
is an obvious hole in my argument, please point it out. 

Jeff


"Peter F. Patel-Schneider" wrote:
> 
> The question is about the relationship between equivalentTo and the
> sameXxxAs properties, and what these four mean.
> 
> Option 1: The sameXxxAs properties are subproperties of equivalentTo.
> 
> In this option the standard way of saying that two classes have the same
> extension is to make them denote the same object.  Because they denote the
> same object, they must have the same extension.  Note that it is still
> possible to have two classes have the same extension but not denote the
> same object by using two subClassOf relationships, which then do not entail
> that the two classes are sameClassAs.
> 
> This option depends on a strong view of classes as instances (and
> properties as instances as well), because sameClassAs (and samePropertyAs)
> only work through identifying the denotation of classes (or properties).
> 
> In this option the sameClassAs and samePropertyAs properties are not
> particularly useful.  In this option equivalentTo has exactly the same
> meaning as sameIndividualAs.  (Well, I suppose that it would be possible to
> have some extra meaning for sameInvdividualAs, but I don't see any point
> for this extra meaning.)
> 
> Option 2: The sameXxxAs properties are not subproperties of equivalentTo.
> 
> In this option the standard way of saying that two classes have the same
> extension does not imply that they denote the same object.  Here
> sameClassAs is exactly the same as having two subClassOf relationships.
> 
> This option does not depend on any particular answer to the classes as
> instances issue.
> 
> I vote for option 2.
> 
> Peter F. Patel-Schneider
> 
> From: Jeff Heflin <heflin@cse.lehigh.edu>
> Subject: Re: LANG: closing issue 4.6 (was Re: ADMIN: Draf agenda for July 25    telecon)
> Date: Wed, 24 Jul 2002 12:05:33 -0400
> 
> >
> > I also use equivalentTo all the time, and never use samePropertyAs,
> > sameClassAs, or sameIndividualAs. If redundancy is the problem, let's
> > get rid of the three sameBlankAs properties instead of the one. The
> > three properties do two things:
> >
> > 1) say that two concepts are the same
> > 2) say that the two concepts are both properties, classes, or
> > individuals
> >
> > The first bit is what equivalentTo already does. The second bit is
> > virtually useless, because any reasonable ontology will have stated
> > whether a URI is a class or property elsewhere. Furthermore, these
> > properties can still cause the class/instance confusion because I could
> > say that foo is a class and then say foo sameInstanceAs bar.
> >
> > If the problem is that people somehow see equivlalentTo as having
> > meaning that is fundamentally different from the sameBlankAs properties,
> > then I could live with renaming it to "sameAs."
> >
> > Jeff
> >
> > p.s. a bit of DAML+OIL history: At first, only equivalentTo was in the
> > language. Some people argued for the need for a sameClassAs and
> > samePropertyAs, and eventually even added sameIndividualAs. I didn't
> > believe we needed them then, but didn't argue strongly because I could
> > simply ignore them as long as equivalentTo was in the language and they
> > were suproperties of it
> >
> > Dan Connolly wrote:
> > >
> > > On Wed, 2002-07-24 at 09:24, Jim Hendler wrote:
> > > [...]
> > > > Proposed:
> > > >   I propose that we CLOSE issue 4.6 with the following resolution:
> > > >
> > > > We will remove the single construct "equivalentTo" from the language,
> > > > as it is possible to use other features (sameClassAs, samePropertyAs,
> > > > sameIndividualAs) to achieve its primary effect.
> > >
> > > Ugh; I use equivalentTo all the time, and I hardly ever
> > > use samePropertyAs, sameClassAs, or sameIndividualAs.
> > >
> > > Hmm... I could perhaps live without equivalentTo.
> > > I'll have to think about it.
> > >
> > > --
> > > Dan Connolly, W3C http://www.w3.org/People/Connolly/
> > > see you in Montreal in August at Extreme Markup 2002?

Received on Wednesday, 24 July 2002 13:57:13 UTC