Re: [OEP] "Classes as values" first draft + ODP basics


> 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 

[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 

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 

Have I grossly misinterpreted or misunderstood what you were trying to 


Received on Friday, 23 April 2004 21:00:51 UTC