[OEP] and [ADTF?] [Was RE : [OEP] : first internals reading feedback (draft 3) [Was RE : Close to final draft of "classes as values" note]]

Hi,

>> 5) According to the above remarks they don't want to be oblige to
>> "write" or to think about their own piece of code to visualise the 
>> direct consequences of the differences betwen the 2 first approach for 
>> the complexity of their application : so they ask, if it is possible, 
>> to have for each note and each scenarios on a note a direct link to a 
> piece of code which concretley illustrate the text. Because, as i have 
>> written above, the argumentation didn't convinced them.

>I don't quite understand which code you refer to here. There is 
>complete OWL code for the examples in the note (in three different 
> formats). Are you talking about something else.

I refer to the code of the "application" that has to compute annotations based on the OWL code for the examples.
As readers don't visualize yet a general/typical SWA architecture, for each example, they have to "write" in their mind the piece of application that compute annotations to be sure to understand the real impact of each approach and to evaluate the real meaning of words/sentences like "Applications using this representation can directly access the information", or "will need to be aware of this appraoch",  or "A general-purpose reasoner will not be able to use this information directly" etc in order to choose, according too this particular point and their own constraints, the best solution.
I 'm going to try to be clearer. In [1] i tried to build a very simple typical SWA architectural use case, (for me the use case which will probably be the most widely "used" or "implemented" in the SW area) : what can be the architecture of a typical SWA dealing with annotations, which is, i think, the  implicit/underlying  use case in the note. (Note : this figure is based on a figure i have found in a french thesis). The main idea, and i have presented this idea to the internal readers who have been interested, is that it could be very useful to include  such a figure in the note and for each approach to give the piece of code from the ApplicationSpecificCode Box which is related to the approach described. [Note : is this figure correct ?]
Note : I'm not sure if this figure has to be included in this note or in an other [ADTF ?] but people think that this approach could be very very fruitful for them and will help them a lot to really understand the meaning of the considerations. [Note : perhaps that it could be interesting to have such very simple figures for each identified use case s for SWA in the AD note.
The note could be divided in as many sections/chapter as identified use cases whom the general architecture could be presented in introduction and concrete applications cooresponding to the use case could illustrate it.
For all the other considerations in each approach, which are not SW specifics points from their point of view,  they take them as normal or typical design choices they already have encountered in other contexts and so the don't want/or feel the need to discuss them. The general feeling, from what i could understand,  is that people want only to focus on points very specific to the SW that can be summed up with :
				- the illustrated description of the concret level of complexity and reliability of my application according the kind of the reasoner i will use.
Thanks a lot
Best regards 
[1] :  <<annotations.htm>> 

-----Message d'origine-----
De : Natasha Noy [mailto:noy@SMI.Stanford.EDU] 
Envoyé : jeudi 20 mai 2004 03:05
À : NANNI Marco FTRD/DMI/SOP
Cc : swbp
Objet : Re: [OEP] : first internals reading feedback (draft 3) [Was RE : Close to final draft of "classes as values" note]


Marco,

Thanks a lot for getting the feedback from practitioners -- I think it 
is very important. Comments in-line. I would appreciate your feedback 
on those,

> As I have proposed during a telconf some people of FTR&D have read the
> draft and I received some important comments/questions :
>
> For approach 1 it is said that :
>          "Applications using this representation can directly access
> the information needed to infer that Lion (the subject of the 
> LionsLifeInThePrideBook individual) is a subclass of Animal and that 
> AfricanLion (the subject of the TheAfricanLionBook individual) is a 
> subclass of Lion. "
>
> And for approach 2 :
>          "An application trying to utilize this relation (for example,
> to extract books about african lions when asked for books about 
> lions), will need to be aware of this specific approach "
>
> 1) People who read the doc tell me that from their point of view in
> both case applications need to be aware of the choosen approach. An 
> unless an official standard or a de facto standard has been defined, 
> they believe that applications will always need to be aware of the 
> choosen approach.So they don't understand the argument.
>
> 2) They don't know what do we mean by "general-purpose reasoner ". In
> both cases people will use the same reasoner and they don't expect to 
> find reasoner that take into account all the possibilities to "model" 
> things. And the two above scenarios are only two scenarios between 
> other. They only expect to have some common API : classify,verify 
> etc..
>
> So they don't understand why it is said that : "general-purpose
> reasoner  will not be able to use this information directly" because 
> in both case no reasoner will not be able to use the information 
> directly, because you always need to write specific code and to know 
> the choosen approach (see above), and they don't see why and if the 
> code to write is more complex in one case than in an other.

Hmm.. That's a valid point, although I am not sure how to address it. 
The difference here is that if you look at the value of dc:subject in 
Approach 1, there is a direct subclass relationship (with well-defined 
and generally-known semantics) between the values of the property. In 
approach 2, there is no such direct relation. Perhaps putting this 
somewhere more explicitly would make the case better. What do you 
think?

> 3) For approach 2 it is said that : "Note however that the individual
> AfricanLionSubject is also an instance of the Lion class. Therefore, 
> if we ask [..]".
>
>                  - They think that there is  contradiction between
> this sentence and the 2 sentences immediatly preceding it  above in 
> the doc. Why ? : see the two points above. An other reason is that 
> according to what they have understood about the distinction between 
> OWL Lite/DL/Full it is more difficult to find a OWL Full reasoner than 
> OWL Lite/DL reasoner (they even believe that OWL Full reasoner won't 
> never exist) and so that to implicitly say with this sentence that one 
> of the positive point of the approach 1 is that you can use 
> general-purpose reasoner is very strange/funny.

I am not really qualified to take up the argument what type of 
reasoners do, and, more important, will exist. I do believe that there 
is more to the world than just DL reasoners though. I could  easily see 
a simple OWL Full reasoner that can do the reasoning along the lines of 
approach 1, reasoning with classes as values. It will not reason about 
everything in OWL Full (or even be a superset of an OWL DL reasoner), 
but to say that OWL Full reasoners don't exist is misleading. I think, 
for example, that  a rule-based system such as Jess can reason about 
classes as values and classes as instances without much trouble (and 
the JessTab plugin for Protege works fine with OWL ontologies) while 
not being able to do classification. So, you may want to clarify this 
point to your users, but it's probably outside the scope of this note.

> 4) They would like to know exactly if according to the real
> probability to have OWL Full reasoner,  approach one is reasonable IF 
> YOU want to do some reasoning tasks : in other words they want to know 
> if when they will use a non-Full reasoner with a OWL FULL Ontology  
> they will have some crash or if they will only have some minor 
> problems ?

Actually, I think that at the moment, most if not all DL classifiers 
will simply reject an OWL Full ontology (I could be wrong on this point 
and would welcome examples of DL reasoners that would prove me wrong).

> 5) According to the above remarks they don't want to be oblige to
> "write" or to think about their own piece of code to visualise the 
> direct consequences of the differences betwen the 2 first approach for 
> the complexity of their application : so they ask, if it is possible, 
> to have for each note and each scenarios on a note a direct link to a 
> piece of code which concretley illustrate the text. Because, as i have 
> written above, the argumentation didn't convinced them.

I don't quite understand which code you refer to here. There is 
complete OWL code for the examples in the note (in three different 
formats). Are you talking about something else.

> 6) They don't really see, in a concrete way , what do we mean with :
> to annotate music CDs, book, classes etc.. : in fact they don't have 
> any ideas of the architecure of a real application which use 
> annotations :
>
>                  - do we have to directly annotate the datas (video
> streams, HTML pages) How is it possible ? They don't really understand 
> how it is possible to annotate books ? Does that mean that we need 
> "annotations DB" etc....
>
>                 In fact i think that they would like to have a note on
> the annotation subject : how to annotate datas according to their 
> nature, what is a good architecture ? Etc...
>
>                 Don't you think that a explicit Task Force on this
> topic will be usefull ?

I am not sure you need a separate task force on this. Doesn't it fall 
under OEP? Someone could certainly write such a note. Alan suggested in 
an earlier message (sorry, don't have a reference since I am working 
off-line now) to do just that.

> 7) They ask for a set of rules to quiclky evaluate the work they could
> have to transform an OWL FULL ontology in an DL/LITE one. The would 
> like to have a tool that could concretly help them for this task and 
> also to know the "CLASS" of an ontology (a real one : a big one). They 
> ask if it is possible to be exhaustive and if  there are some chances 
> to have such a tool ?

I would suggest they take a look at the OWL Plugin for Protege 
(protege.stanford.edu). You can have it flag all the things that are 
out of the DL case. It will also do conversion fort some of the cases 
(as the use of classes as instances), mostly by stripping out the 
offending statements. It will not do conversion for FULL-ness of 
approach one though, for a good reason: just stripping out the values 
may be very unwelcome and there is no single root to take to put it in 
the DL (at least 4 :) More conversion options may work in the future.

> They also ask if it is possible to have an Ontology with one part
> being LITE/DL an an other being FULL or if the fact to use, for 
> example approach 1, in a very small part of an ontology as a general 
> impact on the "Class" of whole Ontology ?

Ah -- excellent question (I am sure Alan would want to chime in if he 
ever gets this far in this message). The simple answer is "no". A 
single property that has a class as its value for a single individual 
will make your ontology OWL Full. You can try to partition your 
ontology putting all the Lite/DL stuff in one ontology, then importing 
it (owl:imports) to another ontology that would introduce OWL Full 
stuff. You can then use a DL reasoner on your first ontology, while 
still having the advantage of non-DL-ness of the latter. What we really 
need is a good tool support to make doing these kinds of things easier.

> PS : other comments on this note and the n-ary note will follow.

The n-ary not may have been somewhat premature to show outside the TF.

Natasha