RE: Suitable OWL-S profile

Thanks for your replies, I have some further comments.

Will look forward to see the 1.1 version.

Well yes, it could be that I underspecified the objective, but then it depends
how it is defined in some domain ontology to which the agent will have access :)
When you specified the travel date, destination and orgin locations etc u gave
all the necessary information for the agent to work with, that is fine, and here
is my problem.

Will the user/agent know before hand (ie. before asking the matchmaker) that a
service requires all that information?
Now here we are talking about a common service, but in general, it is not the
case that the agent has this knowledge, unless he is a specific type of agent
that handles specialised tasks or has apriori experience of such situation.

Consider that the agent has not performed this task before, it is up to the user
to configure its behaviour and knowledge base. At this stage the agent can do a
shallow search to identify what is out there and which services provide
solutions for determinate objectives, return with a list of possibilities
(together with knowledge about the service profile) and based on some user
constraints contact the matchmaker for more specific results.

As regards the I/Os I mentioned, I got those examples from the BravoAir service.

Yes hasPrecondition and hasResult provide for more specificity when searching
for services, but again this information will only be known after some shallow
service match is done and the agent has access to the profile info, no?

thanks again for the replies

Charlie

Quoting Katia Sycara <katia+@cs.cmu.edu>:

> Charlie,
>
>  In OWL-S 1.1 the kind of concepts you are referring to are included in the
> "product/service" part of the profile. The thinking is that the product of a
> travel service is to provide travel (or travel information, it depends on
> how you model it). So, subsumption inference can be done on the product. The
> new profile ontology (that includes the product concept) will be uploaded
> within the next couple of days. As far as your example with the objective
> being travel reservation, this is not very well defined since it is not
> clear whether the objective is for the web service to make a reservation for
> you, or to give you alternative travel possibilities or display you
> information about travel to Europe (and of course it is not clear whether
> you only want information or reservations on airlines, or airlines and
> hotels etc). So, in your example the objective is underspecified. Now if you
> were to say that the input was a travel date (for going and returning), a
> destination and an origin and the output was an airline reservation, with an
> associated price, then it would mean that you wanted only information about
> flights from the origin to the destination on the particular dates. If in
> addition, in the output you had a confirmation/invoice, then it would mean
> that you wanted the service to actually buy you a ticket.
>
>
>
> Concerning the inputs and outputs, the philosophy (and practice) in OWL-S is
> that the I/O is in terms of functional capability not low level details like
> account number and password. In other words, the inputs and outputs should
> differentiate one service (e.g. buying a tennis racket) from another (e.g.
> buying shoes) whereas giving a credit card or a password does not
> differentiate between the two services. It is the role of the process model
> in OWL-S to break down the buying of a tennis racket into a login atomic
> process where account number and password are needed, and then the selection
> part where the particular type of tennis racket is input, and then the
> actual buying part where your credit card is input.
>
>
>
> Notice also that OWL-S allows for preconditions and effects that further
> refine and characterize the description of the objective. In your travel
> example, if you indeed wanted to buy a ticket (rather than be shown flights
> to Europe), you would have the invoice as an output, but you could further
> specify as an effect possession of a ticket and possibly the system could
> show you as a additional effect the fact that your bank account was debited
> the ticket price.
>
>
>
>
>
>
>
> -----Original Message-----
> From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On
> Behalf Of Monika Solanki
> Sent: Monday, November 01, 2004 3:20 PM
> To: Charlie Abela; public-sws-ig@w3.org
> Subject: Re: Suitable OWL-S profile
>
>
>
> I see your point, but I would also argue that though these concepts  are
> critical and important from discovering a service point of view, they need
> not be described in the profile model(reason: profile is suppose to work
> alongside  process, which is again a low level of service matchmaking). I
> remember that  the earlier version of profile had a  lot of additional
> information that was later on moved to other areas (separation of concerns).
> Again,  the model is extensible. Services that want to facilitate that kind
> of discovery can provide such information by all means. The profile caters
> to the most intutive concepts needed for matchmaking and therefore, for the
> purpose of definitions, it is restricted to those only.
>
> Charlie Abela wrote:
>
>
>
> Hi Monika,
>
> I did not actually mean matchmaking based on keywords, but a way for the
> profile
> to be more expressive and more near what a user would request from his
> agent.
> One should not think of a service by its I/Os only. It does not make sense
> from
> a user perspective to define a request to his agent which includes
> AccountName,
> Password or any other input or output(how will these be known before hand?).
> The profile should present features related to its usability, what is the
> nature
> of the service, what solution can it provide. Eventually if the user/or his
> agent are satisfied with these issues including other service parameters,
> then
> the I/Os can be considered.
>
> Charlie
>
> Quoting Monika Solanki  <mailto:monika@dmu.ac.uk> <monika@dmu.ac.uk>:
>
>
>
> Hi Charlie,
>
> Here are my two cents. As far as I understand, you are talking about
>  matchmaking on the basis of keyword (or context)  i.e flights, travel
> etc, which is supposed to be taken of by engines like google... :-)
>
> I think this is basically the problem of how fine (or coarse grained )
> searches can be made. In most of the technical specifications that exist
> , the objective is to go down at the very low level of matchmaking,
> leaving the job of preliminary decision making to some other entity
> (maybe something inherent provided by registry services..???? or
> conventioanl search engines ). How to automate this process  via agents
> etc. should be possible and probably loads of them already exists
>
> -Monika
>
>
>
>
>
> Charlie Abela wrote:
>
>
>
> Hi,
>
> work on service matchmaking has focused mainly on matching the inputs and
> outputs that a requester presents with those that a service stored in the
> matchmaker provides.
> I want to discuss another aspect of the service matching phase. With the
>
>
> above
>
>
> situation it seems that the agent searching for a service has to know which
> inputs/outputs the service has to provide, independently of what the service
>
>
> is
>
>
> used for.
> I want to consider an example related to an airtravelling service (like the
> BravoAir service). I want to consider the following situations:
> 1. suppose that the user is not making use of an agent to search for this
> service but is manually trying to find it tru a search engine, the keywords
> that this person enters could be similar to air travel and flights.
> 2.suppose that now the user makes use of an agent, the same type of search
>
>
> would
>
>
> apply, cause one cannot assume that the person requester knows apriori what
>
>
> the
>
>
> inputs and outputs would be so he will not instruct his agent about these.
> Even though most examples I've seen state that the user will instruct his
>
>
> agent
>
>
> tru a natural language interface, this solution seems to be quite far at the
> moment, given also that there is no means of capturing context.
>
> So given these situations, I would like to ask whether it would be more
>
>
> suitable
>
>
> to provide a way for the user to be able to instruct his agent with info
>
>
> about
>
>
> the type of service he requires and the objective he wants to reach and not
>
>
> by
>
>
> providing the I/Os (the I/Os will be considered at a later stage of the
> matching phase, since most air travel services have similar I/Os).
>
> something along these lines:
>
> serviceCategory -> air travel (points to some standard classification:
>
>
> UNSPSC or
>
>
> NAICS)
> Objective-> flight reservation (points to some air travel domain ontology)
> GeographicRadius->Europe
> QualityRating->some_rating
>
> Charlie
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
>
>
> --
> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
> Monika Solanki
> Software Technology Research Laboratory(STRL)
> De Montfort University
> Gateway building, G4.61
> The Gateway
> Leicester LE1 9BH, UK
>
> phone: +44 (0)116 250 6170 intern: 6170
> email: monika@dmu.ac.uk
> web: http://www.cse.dmu.ac.uk/~monika
> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>
>
>
>
>
>
>

> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
>
>
> --
> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
> Monika Solanki
> Software Technology Research Laboratory(STRL)
> De Montfort University
> Gateway building, G4.61
> The Gateway
> Leicester LE1 9BH, UK
>
> phone: +44 (0)116 250 6170 intern: 6170
> email: monika@dmu.ac.uk
> web: http://www.cse.dmu.ac.uk/~monika
> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>
>
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Received on Monday, 1 November 2004 23:36:39 UTC