W3C home > Mailing lists > Public > public-sws-ig@w3.org > November 2004

Re: Suitable OWL-S profile

From: Charlie Abela <charlie@semantech.org>
Date: Tue, 2 Nov 2004 04:47:19 +0800
Message-ID: <1099342039.4186a0d78d61f@202.157.161.163>
To: Monika Solanki <monika@dmu.ac.uk>
Cc: public-sws-ig@w3.org

Monika,

I cannot understand how one can consider low level service inputs and outputs as
intuitive. I agree that for a matchmaking purpose the profile is more
expressive then a wsdl description, and its because of this that we also have
to consider the first part of this discovery process. Where does it all
start...that is the user/agents request.

Charlie

Quoting Monika Solanki <monika@dmu.ac.uk>:

> 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 <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 20:57:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:58 GMT