Re: Suitable OWL-S profile

I realize we've already had a number of replies on this thread, but I
just want to give a simple answer that's unreleated to many of the
earlier replies ...

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

The answer is - Sure, there's nothing that says a matchmaker must make
use of inputs and outputs.  In general, matchmaking can rely on any of
the properties of the service profile.  As Monika has pointed out, we
have defined only a few very generic properties in Profile.owl, and a
few others that are less generic in ProfileAdditionalParameters.owl.

GeographicRadius and QualityRating appear in
ProfileAdditionalParameters.owl, but let's assume you want to locate a
travel service based on some travel-related properties that don't happen
to be in there.  In that case, the Profile class can be subclassed for
the given domain (travel), and the travel-relevant properties defined
for that subclass.  This provides a very natural framework to support
matchmaking based on these domain-specific properties.

We tried to illustrate this approach in the Profile Hierarchy example,
linked from http://www.daml.org/services/owl-s/1.1/examples.html.

BTW, if you adopt this approach, based on subclassing, you don't need
the serviceCategory property, because the subclass (of Profile) itself
is the representation of serviceCategory.

Regards,
David

Received on Wednesday, 1 December 2004 23:03:19 UTC