Re: [Fwd: RE: LANG: compliance levels]

On April 28, Deborah McGuinness writes:
> 
> 
> Ziv Hellman wrote:
> 
> > >-----Original Message-----
> > >From: Deborah McGuinness [mailto:dlm@ksl.stanford.edu]
> > >Sent: Sunday, 28 April, 2002 2:37
> > >To: www-webont-wg@w3.org
> > >Subject: Re: [Fwd: RE: LANG: compliance levels]
> 
> ... portion removed
> 
> > >> 2) As recent email exchanges on the WebOnt forum indicate, the
> > >> distinction between primitive and defined classes can be tenuous, at
> > >> least with full DAML+OIL expressiveness. Will the same be true of
> > >> compliance level 1 of OWL?
> > >
> > >I guess I need more detail on the tenuous nature of
> > >defined/primitive distinction in order to address this question.
> > >I think we do not have a choice in daml+oil/owl/fowl but to
> > >solve the issue of grouping statements somehow and thus will
> > >have a mechanism for grouping an entire term definition
> > >together thus solving the problem of potentially having
> > >sufficiency conditions for membership in multiple places in a
> > >knowledge base.  If this problem is solved, do you still have
> > >other problems with the primitive/defined class
> > >distinction?
> >
> > As I understood matters, the problem with primitive vs defined classes
> > does indeed revolve around whether a class has associated with it
> > sufficiency conditions for inferring instance membership. If statement
> > grouping were strictly enforced to prevent the possibility of
> > sufficiency conditions ever appearing other than in the location in
> > which the original class definition is made, then this problem could be
> > overcome, but the price might be too high. In Web and distributed pages
> > contexts, the flexibility to refer in one document to a class defined in
> > another document somewhere else, and perhaps add new
> > conditions/definitions would seem to be of high importance. Strict local
> > grouping of definitions would run counter to this Web ambition.
> >
> > >
> 
> I agree that in web settings it is imperative to be able to refer in one
> document to a class defined in another document.  Although I think the
> option of modifying the definition of a defined class is quite dangerous -
> then all of the inferences that one could count on from the other ontology
> are potentially modified and potentially now could cause contradictions.
> I think this feature is giving users too much rope that allows them too
> easily to create problems for themselves.  I would suggest the social
> convention that additions to a defined term from another ontology be done by
> creating a new class that is a subclass of the previously defined term with
> whatever new conditions are important.
> 
> Even if I would get outvoted in our webont group though and we as a group
> thought it was imperative to allow monotonic additions to defined terms, the
> new document could require that all additions be grouped together in one
> place in the new document.

I STRONGLY suggest that we do NOT use the terms "definition" and/or
"primitive/defined". They really don't make any sense in our
setting. As I pointed out in an earlier email, even RDFS allows class
membership to be inferred, e.g., as a result of range/domain
constraints, so RDFS classes are not "primitive" in that sense (this
may not be a very difficult inference to implement, but it is an
inference). Moreover, RDFS supports multiple inclusion axioms (and
even cyclical inclusions), so we already have multiple "primitive
definitions" and inferred equivalence even at level 0 (RDFS).

Of course this does not prevent implementors from building tools that
group statements about a given class (e.g., like OilEd).

Regards, Ian



> 
> Deborah
> --
>  Deborah L. McGuinness
>  Knowledge Systems Laboratory
>  Gates Computer Science Building, 2A Room 241
>  Stanford University, Stanford, CA 94305-9020
>  email: dlm@ksl.stanford.edu
>  URL: http://ksl.stanford.edu/people/dlm
>  (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801
> 705 0941
>

Received on Sunday, 28 April 2002 16:20:25 UTC