Re: Suitable OWL-S profile

> 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
> 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.
What are the issues involved when choosing between these two approaches? 
I was under the impression that serviceCategory and serviceParameter 
were introduced because of some trouble with using subclassing and pure 
subsumption reasoning to find matches.

Similarly for serviceParameters vs just adding parameters to the Profile 
subclass. Why should one adopt one method rather than the other?


Received on Thursday, 2 December 2004 17:36:47 UTC