RE : [OEP,ALL] Potential topics for OEP notes

Hi,

1) Multiple instantiation is a very interesting feature for us, because from our OOLP point of view, we see it like the best way to "implement" (perhaps we must not use this term here) the very useful (at least for us) concept of point of view.

This concept can of course be "simulated" sometimes with (multi)inheritance and it is easy to build a GUI tool to switch from one 
Point-of view (a super class a the same level or in the ancestor path) to an other. But, by experience, we have seen that using multi-inheritance in that way gives strange ontologies where things are confused.There are also some other problems because the point of views from which an individual can be seen change very often during the life of the individual and of course individual belongings to the same classes can have different point of views during their life. In this case it very easy to understand that using (multi)inheritance is not the good solution.

Of course, an other way to implement this is to use Role associated with the notion of "validity" of a relation during a certain amount of time etc..., but this solution have some other negative aspect.

 I know that it is perhaps out of the scope because we consider perhaps  that OWL  ontologies are not to be used "as they are" in a real program but an other very concret problem is when we want to use the concept of point of view in a "real" program. This problem is very simple and is due to the fact that it is not very rare to  use the same name for a ROLE/Method in different point-of-view, so in this case we have to developp a proprietary system where it is possible to choose the current point of view to adopt for an individual to be sure to use the good ROLE/method (that is exactly what we have done here)

So I think that perhaps a note where multi-instantiation is presented through the multi-point-of view USE CASE could be very useful.

2) An other question perhaps very trivial I can hear very often is that for OOLDesigners (UML users) - and even OOLProgrammers 
They think that they build ontologies when the build a UML modelizations, so they think that they can do almost the same work with OWL but the question is : where can we define "methods" ? A response to this is to say that OWL ontologies are only to exchange datas through the web and not to build programs. But an argument against this is that if Semantic Web is a solution to write intelligent piece of code (agents) that can do some real work, there is a moment where some piece of code 
Will be executed somewhere and developpers are afraid by the perspective to be  constrained to design the same Datas (ontology) twice : the first in OWL and the second in an other language to define the methods. In this case how to do the link properly between the two versions ?

Perhaps it could be interesting to give some guidelines to help people with this kind of problem ?


Thanks a lot


Best regards

Marco NANNI

-----Message d'origine-----
De : public-swbp-wg-request@w3.org [mailto:public-swbp-wg-request@w3.org] De la part de Bernard Vatant
Envoyé : mercredi 20 octobre 2004 10:39
À : Fabien Gandon; public-swbp-wg@w3.org
Objet : RE: [OEP,ALL] Potential topics for OEP notes




Fabien, and all

A few remarks about multiple instantiation, since uncontrolled usage of it by data providers lately caused some severe problems lately in one of our customer's data base.

Not to speak about consistency issues involved, some (many? most?) ontology-driven GUI (e.g. Mondeca ITM, Protégé ... ) have  interfaces built dynamically, for each class of objects, from the properties of which domain contains the class. For such GUI, multiple instantiation is really a no-no, at least in edition. Try to import in Protégé an individual with multiple rdf:type declarations. It might be imported successfully, most of the time it will, you will *see* it in all the relevant classes, but you won't be able to
*edit* it (only to delete it). We have the same behavior in ITM GUI.

And of course, through those interfaces, you can't create an individual with multiple classes ...

Another thing is that identification of individuals is often a two-step process involving the class where two objects are considered identical if: 1. They are instances of the same or equivalent class(es) and 2. Some set of "identifying properties" is the same. In such process, multiple instantiation can be an issue by blocking step 1.

So, if multiple instantiation is possible, users need to be aware of the consequences in terms of applications able to manage it. As for your example, note that in Topic Maps ontologies, roles and classes are different animals, which allows to deal with multiple roles without without using multiple instantiation :)

So I would suggest to put multiple instantiation in a note for "advanced users", with all the needed caveats.

Regards

Bernard


**********************************************************************************

Bernard Vatant
Senior Consultant
Knowledge Engineering
bernard.vatant@mondeca.com

"Making Sense of Content" :  http://www.mondeca.com
"Everything is a Subject" :  http://universimmedia.blogspot.com

**********************************************************************************

> -----Message d'origine-----
> De : public-swbp-wg-request@w3.org 
> [mailto:public-swbp-wg-request@w3.org]De la part de Fabien Gandon 
> Envoyé : mercredi 20 octobre 2004 09:48 À : public-swbp-wg@w3.org
> Cc : public-swbp-wg-request@w3.org
> Objet : Re: [OEP,ALL] Potential topics for OEP notes
>
>
>
> Hi,
>
> Christopher Welty a écrit :
> >  > - a design pattern on the "usage of multiple instantiation": 
> > avoid  > artificial multiplication of common subtypes, useful to 
> > model roles, can  > be used for boolean properties in closed worlds, 
> > etc.
> >
> > I'm not sure what you mean - do you mean that an individual can be 
> > an instance of more than one class?
>
> Exactly. Students are puzzled by this ability to declare multiple 
> classes for an object and they were struggling to understand why and 
> when it should be used.
>
> Examples using roles worked well: we instantiated a "abc:Firm" and 
> reused its URI to instantiate its roles in business exchanges 
> "abc:Provider", "abc:Customer".
>
> We also saw that multiple instantiation allows us to formalize Boolean 
> attributes as classes (since they are unary predicates) without 
> creating all the possible combinations of sub classes: 
> "abc:FirmWithRAndDDepartment", "abc:RegisteredFirm", etc. And we 
> talked about the closed world assumption one must make if one wants to 
> use negation as failure to determine those instances for which the 
> property is false.
>
> I am sure there exist good practices in using multiple instantiation 
> and typical situations where it offers elegant solutions; however, in 
> my experience, students with a background in object-oriented 
> programming rarely envisage this option since they are not familiar 
> with it. I was wondering if it wouldn't be a good idea to have one or 
> more design patterns showing typical modelling situations (ex: roles) 
> were multiple instantiation is both natural and elegant.
>
> Just my 2 cents,
>
> Fabien
> --
> "Proving that I am right would be admitting that I
>   could be wrong."                 -- Beaumarchais.
>   ____________
> |__ _ |_  http://www-sop.inria.fr/acacia/personnel/Fabien.Gandon/
> |  (_||_) INRIA Sophia Antipolis - ph# (33)(0)4 92 38 77 88
>

Received on Wednesday, 20 October 2004 09:30:13 UTC