Dear Chris, (01)
I'm honoured for your so detailed reply. I've written a similar post in
ontoworld (http://ontoworld.org/wiki/Talk:OntoClean), i will remove it.
Now it's clear that I must address instances when I state the need of an
IC and that a more relaxed interpretation of the relationship between
rigidity and identity can be adopted, as for "local identity" case. I
posted my opinions because I noticed many cases of "relaxed" use of
subsumption and partonomy looking at properties of some reference
ontologies in my current work
(http://inmobio.epistematica.org/Wiki.jsp?page=ConceptsOfBioOntologies)
and, extracting properties from ontologies, I needed to find some method
to practically be sure for a semi-rigid attribution to a property.
Anyway I focused more on the analysis of meaning rather than ontoclean
tagging.
Taking apart the exceptions relative to the asserted need to have a +R
and +O/+I reference property for subsequent attributions, I could
imagine that in some contexts (best practices) of ontology development
those exceptions could be carefully disregarded: for example, adopting a
value partition design pattern and avoiding multiple subsumption, roles
should be separed from the "backbone" of the ontology... does this make
sense, in your opinion? Anyway, as you reminded me, the practical needs
often take the ontology development far from ideals and I'm probably
too "rigid" about rigidity! (02)
Thank you again
Claudio (03)
Chris Welty ha scritto: (04)
>Hi Claudio,
>
>There is a wiki page on ontoclean at ontoworld.org. Probably I should put a
>copy
>on ontolog's wiki as well. I only maintain it in brief spurts, however.
>
>Claudio Cardone wrote:
>
>
>>Studying the OntoClean methodology, I think I have found some matter of
>>misunderstanding. I try to explain my point of view, please give me
>>some feedbacks, because I'm a novice here:
>>
>>In the OntoClean papers (e.g. see
>>http://ontolog.cim3.net/file/resource/presentation/OntoClean--ChrisWelty_20041118/guarinowelty_final_v4.pdf
>
>><http://ontolog.cim3.net/file/resource/presentation/OntoClean--ChrisWelty_20041118/guarinowelty_final_v4.pdf>)
>
>>rigid, non rigid and anti-rigid metaproperties are assigned to each
>>class (property) of a given taxonomy, isolating it from the others and
>>studying its meaning.
>>It seems to me that I can define a non rigid or an anti-rigid class only
>>if I have a rigid class of reference that has some identity criteria.
>>
>>
>
>Its a subtle issue, so excuse the convoluted reply. Rigidity as defined has
>little to do with identity, but the rigidity judgement does need to be made
>with
>some notion of identity in mind.
>
>You have to ask yourself whether an instance of the class in question can
>possibly change its membership; are there circumstances in which an entity
>exhibits the property and circumstances in which *the same* entity does not.
>As
>I believe you are suggesting below, in order to answer this often you must
>determine whether the property contributes to identity or not.
>
>We studied this in one of the first OntoClean papers ("A Formal Ontology of
>Properties"), and we determined that a property with +O and -R makes no sense,
>which again points to the relationship between rigidity and identity, but
>actually stemmed from the definition of +O, which is basically a rigid form of
>identity.
>
>Later we relaxed this a bit as we tried to account for different kinds of
>identity, in particular something we tried to call "local identity". There
>are
>identity criteria (IC) in some systems that admit to being local to some
>particular not-necessarily-rigid class. For example, a "student id" may be
>used
>as an IC for student in a system that allows a student to become an alumnus,
>and
>the "student id" may not be an IC for the alumnus class. The point is that it
>is possible for a class to introduce its own sort of IC (which is what +O is
>supposed to mean) without being rigid.
>
>The point of the +I and +O properties are that every *instance* must have
>membership in a class that is +O, not that every property subclass one. There
>are properties (especially roles) that can hold of many different types of
>entities.
>
>
>
>>In
>>fact, i can't say that "student" is an anti-rigid property if i don't
>>have in my mind the concept of human as a rigid class with some identity
>>criteria. To say that some instance of "student" can change and become
>>something else without disappearing i need to know that the instance
>>holds its identity because it belongs to another rigid property (that
>>necessarily subsumes "student"). So it can be misunderstanding to assign
>>the non-rigidity or anti-rigidity to one property if first we haven't
>>found a +R and +O (or +I) class that includes all the instances of that
>>property.
>>
>>
>
>In a sense yes, but be careful. The papers outline a clear methodology to
>establish the "backbone" (the taxonomy of +R+I classes), but you can be too
>inflexible about this. In the examples, the "Red" class is -I-R, really we
>probably meant that property in the sense that only material objects can have
>a
>color, so one may argue that Red should be a subclass of something with
>identity. But we did that intentionally, to make sure that its clear that the
>existence of -I classes does not mean there are -I instances! Every instance
>must instantiate a +O class, the -I on a property just allows a certain
>sloppiness about what classes of entities the property can be applied to.
>
>So, in that example, *anything* can be an instance of Red, but all instances
>of
>Red are also instances of some other class with a rigid IC; this is what the
>-I-R classes are - properties of anything. We called them attributions.
>
>Some people might argue against attributions in ontologies. From the
>perspective of metaphysics it is probably a fair point, as metaphysics is
>supposed to account for *everything*. But from the perspective of systems
>design, where we are not supposed to account for everything, it does introduce
>problems for reusability. Imagine this case: you have an ontology for domain
>X,
>and the property Red in it, and you pretty much want to say anything can be
>red,
>but you insist there be no attributions, so you make the class Red a subclass
>of
>some arbitrary top class, call it X-thing. Then someone else decides they
>want
>to reuse your ontology in domain Y, for which they have a top class Y-thing,
>and
>they make X-thing and Y-thing subclasses of a new class XY-thing. In this new
>merged ontology, none of the Y-things can be red, unless they do some
>complicated mapping of Y-things into X-things.
>
>This happens *all the time* on the semantic web and, again, stems from the
>fact
>that we rarely, in designing ontologies for IT systems, consider ourselves to
>be
>building a theory of the whole universe.
>
>
>
>>Instead, it seems that I can always say if a class is rigid,
>>because I "state" its rigidity in my given world, choosing a point of
>>view, except if I have already chosen another point of view: for
>>example, I can state that a student is a rigid class, except if I had
>>already defined "human" as a non rigid class, according to the
>>ontoclean's rules.
>>
>>
>
>Yes, of course - OntoClean is not an ontology, it helps you to communicate the
>point of view your ontology takes. *This* is the most common misunderstanding
>of
>OntoClean. There is no class that OntoClean dictates is rigid, or anti-rigid,
>etc. The decisions you make wrt these metaproperties communicate more
>accurately what your point of view, or rather the point of view of your
>system,
>is. There is a little more of this discussion on rigidity in the Welty &
>Andersen paper, published in JAO.
>
>
>
>>In the OntoClean papers the above mentioned difference between rigidity
>>and non/anti rigidity assignment is not underlined, so may be that this
>>has contributed for some misunderstanding in the use of the methodology.
>>What do you think about?
>>
>>
>
>There are a lot of OntoClean papers......and no real "tutorial". That
>contributes,too.
>
>-Chris
>
>
>
>
>>Thank you
>>
>>Claudio
>>
>>
>>
>>_________________________________________________________________
>>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>>Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>>Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>>Shared Files: http://ontolog.cim3.net/file/
>>Community Wiki: http://ontolog.cim3.net/wiki/
>>To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>>
>>
>>
>>
>
>
> (05)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (06)
|