DAML-S: example of Profile-based taxonomy

DAML-S folk --

We had some discussion on Tuesday about whether it makes sense to
build a taxonomic hierarchy of Profile. Our most clear conclusion was
that some examples are in order (as Terry has been urging for some
time).

I, for one, still think that a taxonomic hierarchy of Profile makes an
extremely attractive approach.  To my mind, it provides a very natural
way to organize the most basic properties upon which matchmaking
relies - the kinds of properties that we already associate with the
Profile.  To make this case, I have done a little exercise - starting
with Mark's upper ontology of services, I have put in most of the
existing Profile properties, and have added several others which make
sense to me. (These are just a few for illustrative purposes; I don't
claim this is a complete or final set by any means!).  Actually, all
but one of the existing Profile properties remain at the top level.
The only exception is geographicRadius, which I have renamed
geographicRegion, and moved down to several different subcategories.

(There are several of the existing Profile properties I've omitted,
mainly because I don't fully grok their appropriateness, but that's
not at all important for purposes of this message.)

In line with our discussion on Tuesday, several of the properties I've
added would almost certainly take values from other taxonomies -- for
instance, informationProduct, physicalProduct, transportationMode,
geographicRegionServed, medium.

I also think this approach ties in very naturally with what Sheila had
arrived at prior to the launch of our DAML-S coalition - and Sheila,
I'd appreciate your comments.  In fact, don't you have an existing
partial taxonomy of services?  If so, could I have a look at it?

Note that, ultimately, we don't actually have to make this decision.
That is, DAML-S user communities can choose to build a taxonomy of
Profile, or not, as they see fit.  But obviously we want to put
forward an example in whatever we consider the most useful style (or
do we perhaps want to give examples of both approaches -- with and
without subclassing of Profile?).

In summary, my intent is just to give the flavor of what a taxonomy
based on Profile might be like, and make the case that it works well.
I'm not claiming that it's not our job to create *the* taxonomy.  But
I'm in favor of setting up the Profile in such a way that it supports
such taxonomies, and I'm also in favor of putting out an example of
this type of approach.

Comments welcome!

-- Dave

------------- key to notation --------------------

Indentation indicates subclass.  (If the indentation seems screwy,
check that you are using a fixed width font.)  Non-capitalized terms
are properties.  So, for instance in these lines:

    ProductDeliveryService
      PhysicalProductService: manufacturer, deliveryRegion

PhysicalProductService is a class (and a subclass of
ProductDeliveryService); manufacturer and deliveryRegion are
properties defined at the level of PhysicalProductService.

Also, note that most properties have unlimited cardinality.  So a
property like "manufacturer" will typically have many instances, for a
given service.  (The idea here is simply that the service provider
(e.g., a B2C site) may want to list the manufacturers of the products
that it offers.)

I'm using + (1 or more), * (0 or more), and ? (0 or 1) selectively to
emphasize certain cardinality restrictions (but these choices aren't
important for this message either).

Illustrative *instances* of several classes are given in brackets.
(Citation - again, most of these classes and instances are due to
Mark.  But I don't believe that Mark was necessarily thinking of these
as subclasses of ServiceProfile, and I've added the brackets as I see
fit.)

-------------- service profile hierarchy ------------------

ServiceProfile: serviceName, textDescription, has_process, role,
domainResource, degreeOfQuality, serviceParameter, communicationThru,
qualityGuarantee, qualityRating

  ; All classes listed below are subclasses of ServiceProfile.
  ; We could add "Profile" to each of these class names if that makes
  ; things more clear.

These two classes cut across all services (that is, they form a
covering set):

  FeeBasedService: paymentMethodAccepted+ feeBasis*
  FreeService (DISJOINT-FROM FeeBasedService)

Other distinctions:

  ProductDeliveryService
    ; electronic primarily:
    InformationService: informationProduct+
      ReportingService: subject+ informationDeliveryStyle+
        [YahooWeatherService]
        [AcmeTrafficService]
        [SchwabStockQuoteService]
      ; a database-oriented query service:
      DataService: queryLanguage+
        DirectoryService
          WhitePages
          YellowPages
          NameServer
        ImageService
          MapServer: geographicRegion+
            [MapQuest]
    PhysicalProductService: physicalProduct+ manufacturer+
                            deliveryRegion* deliveryProvider*
deliveryType*

;;; these may need further organization, but it is harder to do:

  ActionService
    TransportationService: transportationMode+ geographicRegion+
    AdvisoryConsultingService: feeBasis
      LegalService
      MedicalService
    RepairService: physicalProduct+
    CommunicationsService
    EntertainmentService: medium+ ageGroupServed+
    ManufacturingService: physicalProduct+
    AdvertisingService
    AppraisalService
      PhysicalProductAppraisalService: physicalProduct+
      RealtyAppraisalService: geographicRegion+
    SalesService
      Realty: geographicRegion+ propertyType+
      AuctionService: auctionStyle+
        [EBAY]
     TravelService: transportationMode+ geographicRegion+
       [Travelocity]

-------------------- instance example 1 -------------------

CongoBuy should be an instance of PhysicalProductService (and an
instance of FeeBasedService) with properties something like these
(assuming we've followed Amazon's lead into the consumer electronics
market :-):

physicalProduct: book
physicalProduct: consumer electronics
...
manufacturer: McGraw-Hill
manufacturer: Sony
manufacturer: Samsung
...
deliveryRegion: USA
deliveryRegion: Europe
...
deliveryProvider: FedEx
deliveryProvider: UPS
...
deliveryType: ground parcel
deliveryType: overnight parcel
...
paymentMethodAccepted: Visa
paymentMethodAccepted: wire transfer
...
feeBasis: single-payment
...

-------------------- instance example 2 -------------------

SchwabStockQuoteService should be an instance of InformationService
(and an instance of FeeBasedService) with properties like these:

informationProduct: report
subject: stock-price
informationDeliveryStyle: request-response
informationDeliveryStyle: subscription (periodic)
....
paymentMethodAccepted: Visa
paymentMethodAccepted: wire transfer
....
feeBasis: single-payment
feeBasis: installment-plan
...

Received on Thursday, 9 May 2002 00:32:13 UTC