RE: OWL-S dynamics

I have had not really related responses. Still I do not understand a lot of
the documentation I have read, and each time I go through it I change my
mind. Anyway I should toroughly read all available documents (and read them
fully, not only partially as I have done until now), and also search for
additional ones outside the OWL-S site.

However, right now I am trying to do some proof of concept to test whether
OWL-S would be useful for my scenario. Right now my PoC uses only plain
Java, without a real OWL engine behind, although in January I will be able
to use next version of Ontoprise Ontobroker.

Regards

> -----Mensaje original-----
> De: Lansing, Jeff [mailto:jlansing@systechnologies.com] 
> Enviado el: domingo 12 de diciembre de 2004 1:46
> Para: Camara Melgosa, Javier; public-sws-ig@w3.org
> Asunto: RE: OWL-S dynamics
> 
> 
> Javier,
>  
> Your question is exactly the question that I have wanted to 
> ask: Yes, OWL-S is cool, but what is it good for?
>  
> Have you had any off-line response to this? I am a bit 
> surprised by how little discussion it provoked on this list, 
> which --presumably -- is populated by other then just research wonks.
>  
> Thanks,
>  
> Jeff
> 
> ________________________________
> 
> From: public-sws-ig-request@w3.org on behalf of Camara Melgosa, Javier
> Sent: Thu 12/9/2004 2:20 AM
> To: public-sws-ig@w3.org
> Subject: OWL-S dynamics
> 
> 
> Hi all. Maybe this is sort of a too basic question, but there he goes.
>  
> One of the things that most puzzles me when I read the OWL-S 
> overview is that it describes the information that can be 
> specified for existing web services, but it gives almost no 
> clue on how this information could be used, i.e. its 
> dynamics. I guess the idea is, once one has some OWL-S 
> documents, to load them into some OWL engine and then start 
> doing queries (reasoning) on them as one whishes.
>  
> (Whatever you think about the rest of this message, I reckon 
> that in order for people to better understand OWL-S you 
> should include some examples not only on representation of 
> existing services, but also on how agents would use them.)
>  
> For me, this is somewhat like having the relational model, 
> but no SQL or ODBC/JDBC. I.e. one can take some OWL / OWL-S 
> compatible product, load the OWL-S documents into it and then 
> start exploting them using the tools and APIs of the product; 
> but each such product has very different features and ways to 
> use it. It is as if UDDI would have included only the XSchema 
> models but not the API specs or the WS APIs; then one could 
> create a XML DB with this model and start querying it (well, 
> at least now there is XQuery here) - but UDDI has more than that.
>  
> I understand that this is not the goal of OWL-S, but anyway I 
> think this is needed in order for it to be a success; 
> otherwise there will be so much variety out there that OWL-S 
> descriptions may well end up having to be tailored for each case.
>  
> For example, how can discovery of web services be performed 
> if one has OWL-S? The overview does not tell. I guess it is 
> up to one to use the Profile at will. E.g. one could look 
> only at the results and effects of the profile, and leaving 
> the task of dealing with inputs and preconditions to the WS 
> compositor (e.g. if a precondition is not met, maybe by 
> calling another WS we can fulfill it - for me this is one of 
> the main goals of composition).
>  
> If one has no previous knowledge about the ontologies used 
> for results and effects, then all one can use to discover 
> services is search for things being equivalent (in OWL terms) 
> to the things we are looking for. So if we are requesting 
> results Rr, then we will look for existing profiles with 
> results Re equivalent to Rr. (At least one result being 
> equivalent, or all of them? Up to the discoverer, I guess).
>  
> However, I think this is somewhat limited and not much beyond 
> what UDDI does. E.g. maybe Re is not equivalent but part of 
> Rr, and Re can be completed later (e.g. through composition) 
> to get the full Rr. Is this part of a new relationship (to be 
> made up by every discoverer)? Or can it be achieved by 
> unionOf et al OWL constructs and so leveraged by any discoverer?
>  
> Now, if we have some previous knowledge (beyond OWL and 
> OWL-S) about the ontology of results and effects being used, 
> one can issue queries about them, e.g. "look for results 
> equivalentTo Rr, or equivalent to Re". Let's distinguish 
> between the user of the discoverer (i.e. the equivalent to a 
> UDDI client) and the discoverer itself (i.e. the equivalent 
> to a UDDI server). If this previous knowledge about Re and Rr 
> is owned by the user of the discoverer, then the discoverer 
> is not much more than sort of a OWL query engine, and then 
> every user of the discoverer must know about Re containedIn 
> Rr, so every one of them requesting Rr must issue the proper query.
>  
> However, if it is the discoverer who knows about Re 
> containedIn Rr then every user must just state that it wants 
> Rr to be performed, and leaving the discoverer deal with the 
> details, which is the way I would like a discoverer to work. 
> But assumming we want generic, not hard-wired discoverers, 
> how is this knowledge defined to them?
>  
> For example, let's take what I believe to be a realistic 
> internal corporate integration scenario: let it be Rr "the 
> department D of the person P in which it performs the role R" 
> (being P and R parameters), and Re "all the departments Di of 
> the person P" (being P a parameter). Re is useful to perform 
> Rr (the resulting Di must be filtered after retrieved, but 
> anyway the goal is met), but they are not equivalent - but 
> how does the discoverer know this, without knowing about the 
> ontology in which these results are expressed?
>  
> Can this be expressed using static relationships between OWL 
> classes or instances? Maybe a way of doing so is having Re an 
> instance of some DepartmentOfAPerson class, and Rr a instance 
> of some DepartmentOfAPersonWithARole class which is also 
> subclass of DepartmentOfAPerson . I guess a discoverer could 
> leverage this in some way (however, it is up to it). 
> Nonetheless, given the large number of different data 
> concepts (Person, Address, Name, ...) available in an 
> internal corporate integration, this does not look like 
> appealing to me.
>  
> For me, a good way of expressing all this is to have Re and 
> Rr being instances of the same Retrieval class, and then 
> having some logic condition, associated to this Retrieval 
> class (i.e. with previous knowledge about it), checking when 
> a Retrieval R1 is useful for obtaining a Retrieval R2 . And 
> then making this logic condition available to the discoverer, 
> along with the ontology in which the Retrieval class is 
> defined. And also more logic conditions like this for the composition.
>  
> This is, I would propose for OWL-S to define a basic and 
> extensible ontology for effects and results, including in 
> them these logic conditions to be invoked by discoverers and 
> compositors.
>  
> Any opinions on all that? Thank you very much for your time anyway
> --
> Javier Cámara (jcamara@softwareag.es)
> Software Architect, Software AG España, S.A.
> Ronda de la Luna, 22; 28760 Tres Cantos (Spain)
> +34 91 807 9400, fax +34 91 807 9447
>  
>

Received on Monday, 13 December 2004 14:27:26 UTC