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

I think Alan makes a lot of excellent points (as usual). And indeed 
addressing all the issues he lists would be necessary to produce a 
complete and well-rounded document. I worry though (just as Mike does, 
it seems), that doing so will produce very long documents, and many in 
our target audience will be discouraged by their depth, actually.

If I have a simple question, like "I want to use this hierarchy of 
musical genre to annotate a music collection" (a request on the 
protege-owl mailing list just last week), I may not be motivated enough 
to read something that talks about many different tasks for annotation 
and corresponding reasoning, and answers to all the questions that this 
20-page document would contain. In many cases, users may not even be 
sure what they are going to do with their ontology and data, but they 
want to put it up (yes, from methodology perspective, that's a bad 
thing to do, but people will do it nonetheless and will look somewhere 
for advice).

I would argue for a larger number of small notes that address small 
specific questions (cross-referenced, and with an introduction that 
points into all of them, and perhaps an overarching example that 
requires many of the techniques) rather than detailed long and 
interesting notes that all of us as researchers really like to write 
and read, but many in our target audience would find overwhelming.

Then again, as with many of these arguments, its best taken by specific 
examples. So, I'll refer to something we already have in a draft form. 
In the second draft of the "classes as values " note, which I'll post 
shortly, I switched to the "books about lions" example, which narrows 
down possible interpretations significantly (and, hopefully, possible 
confusion), and keeps the note reasonably short. I would argue that 
some of the other issues that Alan raised, while related, should go in 
a different note, if someone is interested in producing it. For 
example, links to web services, annotating images that point to 
specific lions, etc. I am not trying to say that what I put together 
(with input form many others) is perfect, by any stretch of the 
imagination; but I do feel that the size and the scope is about right 
for the attention span that we can hope for.

Just my .02c


> -----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 []
> 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: 
>> []  On Behalf Of Natasha Noy
>> Sent:	Friday, April 23, 2004 6:00 PM
>> To:	Aldo Gangemi
>> Cc:;; Nicola Guarino; 
>> 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:
> web:

Received on Tuesday, 27 April 2004 15:58:25 UTC