FW: [OEP] Ontological purity, was "Classes as values" first draft + ODP basics $swbpd

Alan's remarks were intended for the whole group, as was my response. 

Mike


-----Original Message-----
From: 	Uschold, Michael F  
Sent:	Monday, April 26, 2004 1:30 PM
To:	'Alan Rector'
Subject:	RE: [OEP] Ontological purity, was "Classes as values" first draft + ODP  basics  $swbpd

From Alan's many excellent points and examples and dinstinctions, and the quality & quantity of discussion on this matter, it is clear that this topic could easily take up a 20-page document. One challenge we face as a group is getting the balance between:
* being concise enough so that our deliverables are readily accessible and usable;
* being complete enough to give the reader enough information to make an informed choice in a reasonably wide range of situations.

Mike


-----Original Message-----
From:	Alan Rector [mailto:rector@cs.man.ac.uk] 
Sent:	Saturday, April 24, 2004 10:00 AM
To:	Uschold, Michael F
Subject:	Re: [OEP] Ontological purity, was "Classes as values" first draft + ODP  basics  $swbpd

All
I would argue for getting the use cases clear and the practical advice follow from the use cases.  "How to to do X" or at least "Alternatives for doing X"
or "What to do in situation X", etc.
Plus "Consequences of the alternatives".  Those of a more purest bent need to show consequences, concrete advantages etc.
Also, to avoid confusion, let's use several examples in each case.  The problem in the "a_picture_of_a_lion" vs "Lions" case seems to me to illustrate a useful point for the group.
a)	Several examples would have been clearer than one.
b)	The issue isn't so much "Classes as  values" as "How do we do certain tasks":

i)	Find all images of lions
ii)	Find all books about lions
iii)	Find a references on lions
iv)	Find all stories about lions
v)	Advertise that this is a resource about lions
vi)	Include that this resource is about lions is a WSDL document or similar
(not at all theoretical if we substitute a specific gene or protein for 'lion')
vii)	Use a specific resource about Lions as part of a reference
viii)	Be sure that a picture of Lions is included in searches for Mammals
ix)	...Merging a two sets of resources about animals
x)	Listing dangers in Africa

And where do we go from having found "Lion".
I am not convinced I have anything like a comprehensive list of  use cases.  I would rather address a question like:
Given one or more reference ontologies on animals which contain hierarchical and other information, how including the notion of "Lion".  How do I label books, pictures, films, stories, blogs, fossils, evolutionary trees, gene sequences, ... ... as being about "Lions".  Assuming there are alternatives, what can I do if I choose one alternative over another? What can I not do?  Is it the same in all these cases, or do we need to make distinctions? If so, does everybody have to make the distinction, or is there some way of having a coarse grained solution and a fine grained solution?
Once we have lists of potential uses, then we can discuss which are in or out of scope, which are addressed by various solutions etc.
I presume we need pragmatic choices, but the basis of pragmatic, at least according to my dictionary is "use and practice".
Then if it comes to saying "This is an approximation.  An ontology purist would prefer something else, but the distinction has been lost in the approximation", we can do so.  Or maybe we can even provide transformations to recover some of what was lost.
Regards
Alan

"Uschold, Michael F" wrote:
> Natasha notes:
>
> Sometimes, I believe, we may just have to document that "X is a
> pragmatic choice, but one that an "ontology purist" (and I don't mean
> this in any negative sense!) would object to". As long as we are
> clearly documenting such a choice, we may still be producing useful
> advice.
>
> ---
>
> I agree with the spirit of this, with the following proviso.   Some may find if of passing interest what ontological purists think, but most I expect won't care unless there is some specific advantage.  We might just stick to the impacts of different decisions and not mention the notion of ontological purity at all, or perhaps just footnote that one approach or another is the one preferred by 'ontological purists' for those that might be interested.
>
> Mike
>
>
>  -----Original Message-----
> From:	public-swbp-wg-request@w3.org [mailto:public-swbp-wg-request@w3.org]  On Behalf Of Natasha Noy
> Sent:	Friday, April 23, 2004 6:00 PM
> To:	Aldo Gangemi
> Cc:	welty@us.ibm.com; rector@cs.man.ac.uk; Nicola Guarino; public-swbp-wg@w3.org
> Subject:	Re: [OEP] "Classes as values" first draft + ODP basics
>
> Aldo,
>
> > After paying my dues, I should say that -as is- the emerging pattern
> > is pragmatic, rather than ontological.
>
> You are right on here and I agree with you 100%.
>
> That said, I think we should keep pragmatics in mind, when possible.
> While our suggestions and patterns should be sound,  remembering that
> most people developing sw applications are pragmatic people, won't
> hurt. Sometimes, I believe, we may just have to document that "X is a
> pragmatic choice, but one that an "ontology purist" (and I don't mean
> this in any negative sense!) would object to". As long as we are
> clearly documenting such a choice, we may still be producing useful
> advice.
>
> [And I really hope this paragraph doesn't start another "philosophy of
> SWBPD" discussion. It really isn't intended to]
>
> > We could say that a pragmatic design pattern is a set of ontology
> > design patterns having a common starting generic use case, but not
> > necessarily preserving the original intended meaning.
> > In other words, a pragmatic design pattern (with alternatives) tries
> > to compare different interpretations.
> > On the other hand, an ontology design pattern provides the
> > implementation of the same interpretation. The only alternatives
> > should preserve that interpretation, even when changing the solution.
>
> Let me see if I understand this correctly: What you are saying is that
> for a particular use case, we can have several pragmatic design
> patterns, each of which will have one or more ontology design patterns,
> right? This makes a lot of sense sense to me and I like the
> distinction.
>
> However, we do have to remember who our target audience is: will people
> have patience to figure out  this two-tier architecture?  Besides,
> while you say in your later examples that the different interpretations
> say different things and you "don't accept that the original modeller
> was so ambiguous", I would posit that often times (and more so with
> these borderline cases) modellers do have a rather ambiguous notion of
> what exactly they are trying to say. And you can easily convince them
> that what they are really saying is X rather than Y. If I want to say
> that this book is about Lions, I could easily interpret this as saying
> that the subject of the book is the class Lions or some individual
> LionSubject. When pressed, most people will just throw their hands and
> say that they don't know which one of these interpretations they have
> in mind.
>
> > But where the interpretation is? it is in the core classes and
> > relations chosen to express the solution.
>
> >
> > And finally the example of what I am suggesting:
> >
> > why different interpretations? let's try to formulate the approaches
> > in terms of core classes (rdf:type will be used with inheritance, i.e.
> > including indirect types).
>
> This is an excellent suggestion! Putting rdf:type makes many
> assumptions explicit (and helped me understand where we disagree with
> these particular cases :) The fact that I didn't put those statements
> explicitly allowed you to interpret some of the things I was saying
> differently than the interpretation that I had in mind.
>
> >  I will only assume that animals are kinds of (physical) objects and
> > animal images are images (not very strong assumptions, I hope ;)).
>
> Not at all. But you are making other assumptions as well-see below.
>
> > Lion image pragmatic design pattern
> >
> > Approach 1
> > "LionImage" rdf:type Image
> > LionClass rdfs:subClass Object
> > *** "LionImage" dc:subject LionClass  ;;;a Class
> >
> > Approach 2a
> > "LionImage" rdf:type Image
> > LionClass rdfs:subClass Object
>
> if you mean "Physical object", then you are misinterpreting my approach
> 2a. Here the "animal" hierarchy is the hierarchy of subjects (as I
> point out in one of the considerations to keep in mind: you will have
> to create a different class to describe physical lions). It should be:
>
> LionClass rdf:subclassOf Subject
>
> > *** "LionSubject" rdf:type Object  ;;;(since LionSubject rdf:type Lion)
> > *** "LionImage" dc:subject "LionSubject"  ;;;an Object
>
> And we arrive at a Subject, not Object
>
> > Approach 2b
> > "LionImage" rdf:type Image
> > LionClass rdfs:subClass Object
> > *** "LionSubject" rdf:type Subject
> > *** Subject rdfs:isDefinedBy Object
> > *** "LionImage" dc:subject "LionSubject"  ;;;a Subject
>
> I agree with this one. But the use of explicit rdf:type statements
> makes it clear that 2a and 2b should really be different cases, rather
> than options of the same one. They are a lot farther apart than I
> thought (in 2a LionClass is a subclass of Subject and in 2b it is a
> subclass of Object
>
> > Approach 3
> > "LionImage" rdf:type Image
> > LionClass rdfs:subClass Object
> > *** "LionSubject" rdf:type Object
> > *** "LionSubject" parentSubject "MammalSubject"
> > *** "LionImage" dc:subject "LionSubject"  ;;;an Object
>
> We can actually build 3 either on 2a or 2b, with their respective
> interpretations of LionClass. In the current document, it is an
> extension of 2a (even though the document erroneously refers to 2b, as
> someone has already pointed out). Therefore, by the same token as
> above, we arrive to Subject.
>
> Thus, we arrive to all approaches so far pointing either to Class or
> Subject. While these are different ontological patterns (Class in
> non-DL case and Subject in all DL cases), I would argue that these are
> valid pragmatic patterns for the same problem, since most mere mortals
> would be hard-pressed to distinguish between these two cases.
>
> > Approach 4 (mine, trying to describe the "prototype" notion on OWL-DL.
> > "a" is a local namespace - see below)
> > "LionImage" rdf:type Image
> > LionClass rdfs:subClass Object
> > *** "LionSkolem" rdf:type Lion
> > *** "Prototype" rdf:type a:Role
> > *** "LionSkolem" a:plays "Prototype"
> > *** "LionImage" a:subject "LionSkolem"  ;;;an Object
> >
> > Approach 4 skolemizes (as Alan suggests) the poor anonymous lion taken
> > into the picture, but also restricts that lion to be a "prototype" of
> > its class. I don't even try to explain you how it is possible to
> > generate a meningful and consistent treatment of roles in this way (I
> > refer to my recent KR and WWW papers, email me for references). The
> > OWL-DL abstract syntax for approach 4 is included below, but before
> > that, I recap on what I have shown.
>
> Now, this one, I think,  is really saying something different-see my
> response to Alan. As I argue in that message, this one is a different
> problem.
>
> Have I grossly misinterpreted or misunderstood what you were trying to
> say?
>
> Natasha

--
Alan L Rector
Professor of Medical Informatics
Department of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL: +44-161-275-6188/6149/7183
FAX: +44-161-275-6236/6204
Room: 2.88a, Kilburn Building
email: rector@cs.man.ac.uk
web: www.cs.man.ac.uk/mig
www.opengalen.org
www.clinical-escience.org

Received on Monday, 26 April 2004 16:38:04 UTC