- From: David Martin <martin@AI.SRI.COM>
- Date: Thu, 14 Oct 2004 23:59:25 -0700
- To: Olivier Dameron <dameron@smi.stanford.edu>
- CC: public-sws-ig@w3.org
Olivier Dameron wrote: > Hello, > I am not sure what is the best practice for modelling a kind of > services (e.g. BankingService that would subsume Deposit, Withdrawal or > Loan) > > Alternative 1: > --------------- > BankingService is a subclass of service:Service > No constraint is specified on the profiles presented by BankingService > > Alternative 2: > --------------- > BankingProfile is a subclass of profile:Profile > We only create an instance of serviceService, that presents some > instances of BankingProfile (and possibly some other instances of > profile:Profile) > This is the approach taken by BravoAir > > Alternative 3: > --------------- > Combine the previous two by defining BankingService as a subclass of > service:Service, and BankingProfile as a subclass of profile:Profile. > Moreover, we enforce that a banking service must present at least one > banking profile (and respectively that a DepositService must present at > least one DepositProfile...) > > > The last alternative seems to be the most complete, but requires to > maintain some similar taxonomical hierarchies for the service and the > profile (e.g. DepositService < BankingService; WithdrawalService < > BankingService; LoanService < BankingService; DepositProfile < > BankingProfile; WithdrawalProfile < BankingProfile; LoanProfile < > BankingProfile). > So, is the service taxonomy useful, or are service just meant to be > container for their profiles, their model and their groundings ? There are no hard-and-fast rules; that is, this is largely a matter of style. But in my view there is no need for a service taxonomy. As you say, services are just meant to be containers for their profiles, their model and their groundings ? I recommend Alternative 2. Regards, David
Received on Friday, 15 October 2004 06:59:45 UTC