DAML-S: SemanticMarkup For WebServices

TheDAML ServicesCoalition:AnupriyaAnkolekar

�, Mark Burstein

�, JerryR. Hobbs

�, OraLassila

�,

David L. Martin�, SheilaA. McIlraith

�, Srini Narayanan

�, MassimoPaolucci

�,

TerryPayne�, KatiaSycara

�, HongleiZeng

��� �Abstract.

TheSemanticWebshouldenablegreateraccessnotonly tocontentbut alsoto serviceson theWeb. Usersandsoftwareagentsshouldbeableto discover,invoke, compose,andmonitorWebresourcesoffering particularservicesandhaving particularproperties.As partof theDARPA AgentMarkupLanguageprogram,we have begun to develop an ontologyof services,calledDAML-S, thatwill make thesefunctionalitiespossible.In this paperwe describetheoverall structureof the ontology, the serviceprofile for advertisingservices,andtheprocessmodelfor thedetaileddescriptionof theoperationof services.WealsocompareDAML-S with severalindustryefforts to definestandardsforcharacterizingserviceson theWeb.

1 Intr oduction: Serviceson the SemanticWeb

Efforts toward thecreationof theSemanticWebaregainingmomentum[2]. Soonit will bepossibletoaccessweb resourcesby contentratherthanjust by keywords. A significantforce in this movementisthedevelopmentof DAML—the DARPA AgentMarkupLanguage[10]. DAML enablesthecreationofontologiesfor any domainandtheinstantiationof theseontologiesin thedescriptionof specificwebsites.

Amongthemostimportantwebresourcesarethosethatprovideservices.By “service”we meanWebsitesthat do not merelyprovide static informationbut allow oneto effect someactionor changein theworld, suchasthesaleof a productor thecontrolof a physicaldevice. TheSemanticWebshouldenableusersto locate,select,employ, compose,andmonitorWeb-basedservicesautomatically.

To make useof a Web service,a software agentneedsa computer-interpretable descriptionof theservice,and the meansby which it is accessed.An importantgoal for DAML, then, is to establishaframework within which thesedescriptionsaremadeandshared. Web sitesshouldbe able to employa setof basicclassesandpropertiesfor declaringanddescribingservices,andthe ontologystructuringmechanismsof DAML provide theappropriateframework within which to do this.

Thispaperdescribesacollaborative effort by BBN Technologies,Carnegie Mellon University, Nokia,StanfordUniversity, andSRIInternationalto definejustsuchanontology. Wecall thislanguageDAML-S.Wefirst motivateoureffort with somesampletasks.In thecentralpartof thepaperwedescribetheupperontologyfor servicesthatwe have developed,including theontologiesfor profiles,processes,andtime,andthoughtstowarda futureontologyof processcontrol. We thencompareDAML-S with a numberofrecentefforts in industryto standardizeamarkuplanguagefor services.�

TheRoboticsInstitute,CarnegieMellon University, Pittsburgh,PABBN Technologies,Cambridge,MassachusettsArtificial IntelligenceCenter, SRI International,Menlo Park,California�NokiaResearchCenter, Burlington,Massachusetts�KnowledgeSystemsLaboratory, Stanford,California Authors’ namesarein alphabeticalorder.

2�

SomeMoti vating Tasks

Servicescanbeprimitive in thesensethat they invoke only a singleWeb-accessiblecomputerprogram,sensor, or device thatdoesnot rely uponanotherWebservice,andthereis noongoinginteractionbetweentheuserandtheservice,beyondasimpleresponse.For example,aservicethatreturnsapostalcodeor thelongitudeandlatitudewhengivenanaddresswouldbein thiscategory. Or servicescanbecomplex, com-posedof multiple primitive services,oftenrequiringan interactionor conversationbetweentheuserandtheservices,so that theusercanmake choicesandprovide informationconditionally. One’s interactionwith www.amazon.comto buy a bookis like this; theusersearchesfor booksby variouscriteria,perhapsreadsreviews, mayor maynot decideto buy, andgivescreditcardandmailing information.DAML-S ismeantto supportbothcategoriesof services,but of course,complex serviceshave provided theprimarymotivationsfor thefeaturesof thelanguage[13, 14]. Thefollowing four sampletaskswill give thereaderanideaof thekindsof taskswe expectDAML-S to enable.

1. Automatic Web service discovery. AutomaticWebservicediscovery involvestheautomaticloca-tion of Webservicesthatprovide a particularserviceandthatadhereto requestedconstraints.Forexample,theusermaywant to find a servicethatsellsairline ticketsbetweentwo givencitiesandacceptsa particularcreditcard.Currently, this taskmustbeperformedby a humanwho might useasearchengineto find aservice,readtheWebpage,andexecutetheservicemanually, to determineif it satisfiestheconstraints.With DAML-S markupof services,theinformationnecessaryfor Webservicediscovery couldbespecifiedascomputer-interpretable semanticmarkupat theserviceWebsites,andaserviceregistryor ontology-enhancedsearchenginecouldbeusedto locatetheservicesautomatically. Alternatively, a server could proactively advertiseitself in DAML-S with a serviceregistry, alsocalledmiddleagent[4, 23, 12], sothatrequesterscanfind it whenthey querythereg-istry. Thus,DAML-S mustprovidedeclarative advertisementsof servicepropertiesandcapabilitiesthatcanbeusedfor automaticservicediscovery.

2. Automatic Web service invocation. Automatic Web serviceinvocation involves the automaticexecutionof anidentifiedWebserviceby acomputerprogramor agent.For example,theusercouldrequestthepurchaseof anairline ticket from aparticularsiteonaparticularflight. Currently, ausermustgo to theWeb site offering that service,fill out a form, andclick on a button to executetheservice.AlternatelytheusermightsendanHTTPrequestdirectlyto theservicewith theappropriateparametersin HTML. In eithercase,a humanin theloop is necessary. Executionof a Webservicecanbe thoughtof asa collectionof function calls. DAML-S markupof Web servicesprovidesadeclarative, computer-interpretable API for executingthesefunctioncalls.A softwareagentshouldbe able to interpret the markupto understandwhat input is necessaryto the servicecall, whatinformationwill bereturned,andhow to executetheserviceautomatically. Thus,DAML-S shouldprovide declarative APIs for Webservicesthatarenecessaryfor automatedWebserviceexecution.

3. Automatic Web service composition and interoperation. This task involves the automaticse-lection,compositionandinteroperationof Web servicesto performsometask,given a high-leveldescriptionof an objective. For example,the usermay want to make all the travel arrangementsfor a trip to aconference.Currently, theusermustselecttheWebservices,specifythecompositionmanually, andmake surethat any softwareneededfor the interoperationis custom-created.WithDAML-S markupof Webservices,the informationnecessaryto selectandcomposeserviceswillbeencodedat theserviceWebsites. Softwarecanbewritten to manipulatetheserepresentations,togetherwith a specificationof theobjectivesof the task,to achieve the taskautomatically. Thus,DAML-S mustprovide declarative specificationsof theprerequisitesandconsequencesof individ-ualserviceusethatarenecessaryfor automaticservicecompositionandinteroperation.

4. Automatic Web service executionmonitoring. Individual servicesand,evenmore,compositionsof services,will oftenrequiresometimeto executecompletely. Usersmaywantto know duringthisperiodwhatthestatusof theirrequestis, or theirplansmayhavechangedrequiringalterationsin theactionsthesoftwareagenttakes.For example,usersmaywantto make suretheir hotelreservationhasalreadybeenmade.For thesepurposes,it would begoodto have theability to find out wherein theprocesstherequestis andwhetherany unanticipatedglitcheshave appeared.Thus,DAML-Sshouldprovidedescriptorsfor theexecutionof services.Thispartof DAML-S is agoalof ours,butit hasnot yetbeendefined.

Any Web-accessibleprogram/sensor/device thatis declaredasa servicewill beregardedasa service.DAML-S doesnotprecludedeclaringsimple,staticwebpagesto beservices.But ourprimarymotivationin definingDAML-S hasbeento supportmorecomplex taskslike thosedescribedabove.

3 An Upper Ontology for Services

TheclassServicestandsatthetopof ataxonomyof services,andits propertiesarethepropertiesnormallyassociatedwith all kinds of services.The upperontologyfor servicesis silent asto what theparticularsubclassesof Serviceshouldbe, or even the conceptualbasisfor structuringthis taxonomy, but it isexpectedthatthetaxonomywill bestructuredaccordingto functionalanddomaindifferencesandmarketneeds. For example,one might imaginea broadsubclass,B2C-transaction, which would encompassservicesfor purchasingitemsfrom retailwebsites,trackingpurchasestatus,establishingandmaintainingaccountswith thesites,andsoon.

Ourstructuringof theontologyof servicesis motivatedby theneedto provide threeessentialtypesofknowledgeaboutaservice(shown in figure1), eachcharacterizedby thequestionit answers:

� Whatdoestheservicerequire of theuser(s),or otheragents,andprovidefor them?Theanswertothis questionis givenin the“profile”7. Thus,theclassServicepresentsaServiceProfile

� How doesit work? Theanswerto this questionis given in the“model”. Thus,theclassServiceisdescribedByaServiceModel

� How is it used?Theanswerto this questionis given in the “grounding”. Thus,theclassServicesupportsaServiceGrounding

Thepropertiespresents, describedBy, andsupportsarepropertiesof Service. TheclassesServicePro-file, ServiceModel, andServiceGroundingarethe respective rangesof thoseproperties.We expectthateachdescendantclassof Service, suchasB2C-transaction, will presenta descendantclassof Service-Profile, be describedBya descendantclassof ServiceModel, andsupporta descendantclassof Service-Grounding. Thedetailsof profiles,models,andgroundingsmayvary widely from onetypeof servicetoanother—thatis, from onedescendantclassof Serviceto another. But eachof thesethreeclassesprovidesanessentialtypeof informationabouttheservice,ascharacterizedin therestof thepaper.

The serviceprofile tells “what the servicedoes”; that is, it givesthe type of informationneededbya service-seekingagentto determinewhetherthe servicemeetsits needs(typically suchthingsasinputandoutput types,preconditionsandpostconditions,andbinding patterns). In future versions,we willuselogical rulesor their equivalentin sucha specificationfor expressinginteractionsamongparameters.For instance,a rule might saythat if a particularinput argumentis boundin a certainway, certainotherinput argumentsmaynot beneeded,or maybe provided by theserviceitself. As DAML andDAML-S�

A serviceprofile hasalsobeencalledservicecapabilityadvertisement[19]

�� � �� � �� � � �� � � �� �

� � �� � �� � � � �� ! " # $ % & ' ( )(

* + , - . / 0 1 21 2 3

4 5 6 7 87 89 : ; < = > ?> ? @ AB C D E F G C H I J C K

B C D E F G C L D I M N J F N O

B C D E F G C P D I Q F K CR S T U V W X S

Y Z [ \ ] ^ Z

__ ` a b cb c

Figure1: Top level of theserviceontology

andtheir applicationsevolve, logical rulesandinferentialapproachesenabledby themarelikely to playan increasinglyimportantrole in modelsandgroundings,aswell as in profiles. See[5] for additionalexamples.

Theservicemodeltells “how theserviceworks”; thatis, it describeswhathappenswhentheserviceiscarriedout. For non-trivial services(thosecomposedof severalstepsover time), this descriptionmaybeusedby a service-seekingagentin at leastfour differentways:(1) to performa morein-depthanalysisofwhethertheservicemeetsits needs;(2) to composeservicedescriptionsfrom multipleservicesto performa specifictask;(3) duringthecourseof theserviceenactment,to coordinatetheactivities of thedifferentparticipants;(4) to monitortheexecutionof theservice.For non-trivial services,thefirst two tasksrequireamodelof actionandprocess,thelasttwo involve, in addition,anexecutionmodel.

A servicegrounding(“grounding” for short)specifiesthedetailsof how anagentcanaccessaservice.Typically a groundingwill specifya communicationsprotocol(e.g.,RPC,HTTP-FORM,CORBA IDL,SOAP, Java RMI, OAA ACL [12]), andservice-specificdetailssuchasport numbersusedin contactingtheservice.In addition,thegroundingmustspecify, for eachabstracttypespecifiedin theServiceModel,an unambiguousway of exchangingdataelementsof that type with the service(that is, the marshal-ing/serializationtechniquesemployed). The likelihood is that a relatively small setof groundingswillcometo be widely usedin conjunctionwith DAML services. Groundingswill be specifiedat variouswell-known URIs.

Generallyspeaking,the ServiceProfileprovides the information neededfor an agentto discover aservice.Takentogether, theServiceModelandServiceGroundingobjectsassociatedwith aserviceprovideenoughinformationfor anagentto make useof aservice.

The upperontology for servicesdeliberatelydoesnot specify any cardinalitiesfor the propertiespresents, describedBy, andsupports. Although, in principle, a serviceneedsall threepropertiesto befully characterized,it is possibleto imaginesituationsin which a partial characterizationcould be use-ful. Hence,thereis no specificationof a minimum cardinality. Further, it shouldcertainlybe possiblefor a serviceto offer multiple profiles,multiple models,and/ormultiple groundings.Hence,thereis nospecificationof amaximumcardinality.

In general,thereneednotexist aone-to-onecorrespondencebetweenprofiles,models,and/orground-ings.Theonly constraintamongthesethreecharacterizationsthatmightappropriatelybeexpressedat theupperlevel ontologyis thatfor eachmodel,theremustbeat leastonesupportinggrounding.

In the following two sectionswe discussthe serviceprofile and the servicemodel in greaterdetail(Servicegroundingsarenot discussedfurther, but will becoveredin greaterdepthin a subsequentpubli-cation.)

4 ServiceProfiles

A serviceprofile provides a high-level descriptionof a serviceand its provider [20, 19]; it is usedtorequestor advertiseserviceswith discovery/locationregistries. Serviceprofilesconsistof threetypesofinformation: a humanreadabledescriptionof the service;a specificationof the functionalitiesthat areprovided by the service;and a host of functional attributeswhich provide additional information andrequirementsabouttheservicethatassistwhenreasoningaboutseveralserviceswith similar capabilities.Servicefunctionalitiesarerepresentedasa transformationfrom the inputsrequiredby theserviceto theoutputsproduced.For example,a news reportingservicewould advertiseitself asa servicethat,givenadate,will returnthenewsreportedon thatdate.Functionalattributesspecifyadditionalinformationabouttheservice,suchaswhatguaranteesof responsetimeor accuracy it provides,or thecostof theservice.

While serviceprovidersusethe serviceprofile to advertisetheir services,servicerequestersusetheprofile to specify what servicesthey needand what they expect from sucha service. For instance,arequestermaylook for a news servicethatreportsstockquoteswith no delaywith respectto themarket.The role of the registries is to matchthe requestagainstthe profiles advertisedby other servicesandidentify whichservicesprovide thebestmatch.

Implicitly, theserviceprofilesspecifythe intendedpurposeof theservice,becausethey specifyonlythosefunctionalitiesthat arepublicly provided. A book-sellingservicemay involve two different func-tionalities: it allows otherservicesto browseits site to find booksof interest,andit allows themto buythebooksthey found. Thebook-sellerhasthechoiceof advertisingjust thebook-buying serviceor boththebrowsingfunctionalityandthebuying functionality. In thelattercasetheservicemakespublic that itcanprovide browsingservices,andit allows everybodyto browseits registry without buying a book. Incontrast,by advertisingonly the book-sellingfunctionality, but not the browsing, the agentdiscouragesbrowsing by requestersthat do not intendto buy. The decisionasto which functionalitiesto advertisedetermineshow theservicewill beused:a requesterthat intendsto browsebut not to buy would selectaservicethatadvertisesbothbuying andbrowsingcapabilities,but notonethatadvertisesbuying only.

Theserviceprofilecontainsonly theinformationthatallows registriesto decidewhichadvertisementsarematchedby a request.To thisextent,theinformationin theprofile is asummaryof theinformationintheprocessmodelandservicegrounding.Where,asin theabove example,theservicedoesnot advertisesomeof its functionalities,they will not be part of the serviceprofile. But they are part of the servicemodelto theextent that they areneededfor achieving theadvertisedservices.For example,looking fora book is an essentialprerequisitefor buying it, so it would be specifiedin the processmodel,but notnecessarilyin theprofile. Similarly, informationaboutshippingmayappearwithin theprocessmodelbutnot theprofile.

4.1 Description

Informationaboutthe service,suchasits provenanceor a text summary, is provided within the profile.This is primarily for useby humanusers,althoughthesepropertiesareconsideredwhenlocatingrequestedservices.

4.2 FunctionalityDescription

An essentialcomponentof theprofile is thespecificationof whattheserviceprovidesandthespecificationof the conditionsthat have to be satisfiedfor a successfulresult. In addition,the profile specifieswhatconditionsresultfrom theserviceincludingtheexpectedandunexpectedresultsof theserviceactivity.

Theserviceis representedbyinput andoutput propertiesof theprofile. Theinputpropertyspeci-fiestheinformationthattheservicerequiresto proceedwith thecomputation.For example,abook-selling

servicecouldrequirethecredit-cardnumberandbibliographicalinformationof thebookto sell. Theout-putsspecifythe resultof the operationof the service. For the book-sellingagentthe outputcould be areceiptthatacknowledgesthesale.

<rdf:Property rdf:ID="input"><rdfs:comment>

Property describing the inputs of a service in the Service Profile</rdfs:comment><rdfs:domain rdf:resource="#ServiceProfile"/><rdfs:subPropertyOf rdf:resource="#parameter"/>

</rdf:Property>

While inputsandoutputsrepresenttheservice,they arenot theonly thingsaffectedby theoperationsof the service. For example,to completethe salethe book-sellingservicerequiresthat the credit cardis valid andnot overdrawn or expired. In addition,the resultof thesaleis not only that thebuyer ownsthebook(asspecifiedby theoutputs),but that thebookis physicallytransferredfrom thethewarehouseof thesellerto thehouseof thebuyer. Theseconditionsarespecifiedby precondition andeffectpropertiesof theprofile. Preconditionspresentoneor morelogicalconditionsthatshouldbesatisfiedpriorto theservicebeingrequested.Theseconditionsshouldhave associatedexplicit effectsthatmayoccurasa resultof theservicebeingperformed.Effectsareeventsthatarecausedby thesuccessfulexecutionof aservice.

<rdf:Property rdf:ID="preconditions"><rdfs:domain rdf:resource="#ServiceProfile"/><rdfs:range rdf:resource="#Thing"/>

</rdf:Property>

Theserviceprofile alsoprovidesa specifictypeof preconditionscalledaccessConditions thatareexpectedto betruefor theserviceto succeed,but they arenot modifiedby theactivity of theservice.Accessconditionsareusedwhentheaccessto theserviceis restrictedto only someusers:as,for example,servicesthat are restrictedto usersaffiliated to someorganization. For instance,to accessa classifiednews servicea userneedsto have somelevel of clearance,detailsabout it would be specifiedas anaccessCondition.

Finally, theProfileallowsthespecificationof whatdomainResources areaffectedby theuseof theservice.Thesedomainresourcesmay includecomputationalresourcessuchasbandwidthor disk spaceaswell asmorematerialresourcesconsumedwhenthe servicecontrolssomemachinery. This type ofresourcemayincludefuel, or materialsmodifiedby themachine.

4.3 FunctionalAttributes

In the previous sectionwe introducedthe functionaldescriptionof services.Yet thereareotheraspectsof servicesthat the usersshouldbe awareof. While a servicemay be accessedfrom anywhereon theInternet,it may only be applicableto a specificaudience.For instance,althoughit is possibleto orderfood for delivery from a Pittsburgh-basedrestaurantwebsitein general,onecannotreasonablyexpecttodothisfrom California.Functionalattributesaddresstheproblemthattherearepropertiesthatcanbeusedto describeaserviceotherthanasa functionalprocess.Thesepropertiesaredescribedbelow.

geographicRadius Thegeographicradiusrefersto thegeographicscopeof theservice.This maybeattheglobalor nationalscale(e.g.for e-commerce)or ata local scale(eg pizzadelivery).

degreeOfQuality This propertyprovide qualificationsabout the service. For example, the followingtwo sub-propertiesareexamplesof differentdegreesof quality, andcouldbedefinedwithin someadditionalontology.

serviceParameter An expandablelist of propertiesthatmayaccompany aprofiledescription.

communicationThru This propertyprovidesa high-level summaryof how a servicemaycommunicate,suchaswhatagentcommunicationlanguage(ACL) is used(e.g.,FIPA, KQML, SOAP). Thissum-marizesthedescriptionsprovided by theservicegroundingandareusedwhenmatchingservices;but is not intendedto replacethedetailprovidedby theservicegrounding.

serviceType Theservicetype refersto a high level classificationof theservice,for exampleB2B, B2Cetc.

serviceCategory Theservicecategory refersto anontologyof servicesthatmaybeon offer. High levelservicescould include Productsas well as ProblemSolving Capabilities,CommercialServices,Informationandsoon.

qualityGuarantees Theseareguaranteesthat the servicepromisesto deliver, suchasguaranteeingtoprovide thelowestpossibleinterestrate,or a responsewithin 3 minutes,etc.

qualityRating The quality rating propertyrepresentsan expandablelist of rating propertiesthat mayaccompany a serviceprofile. Theseratingsrefer to industryacceptedratings,suchastheDun andBradstreetRatingfor businesses,or theStarratingfor Hotels.For example:

<!-- Dun and Bradstreet Rating --><rdf:Property rdf:ID="dAndBRating"><rdfs:subPropertyOf rdf:resource="#qualityRating" />

</rdf:Property>

As a resultof theserviceprofile, theuser, beit a human,a programor anotherservice,would beableto identify what theserviceprovides,whatconditionsresultfrom theserviceandwhethertheserviceisavailable,accessibleandhow it compareswith otherfunctionallyequivalentservices.

5 Modeling ServicesasProcesses

A moredetailedperspective on servicesis thata servicecanbeviewedasa process. We have definedaparticularsubclassof ServiceModel, the ProcessModel(asshown in figure 2), which draws uponwell-establishedwork in a variety of fields, suchas AI planningand workflow automation,and which webelieve will supporttherepresentationalneedsof avery broadarrayof serviceson theWeb.

Thetwo chiefcomponentsof aprocessmodelaretheprocess, whichdescribesaservicein termsof itscomponentactionsor processes,andenablesplanning,compositionandagent/serviceinteroperation;andtheprocesscontrol model, whichallowsagentsto monitortheexecutionof aservicerequest.Wewill referto thefirst partastheProcessOntologyandthesecondastheProcessControlOntology. Only theformerhasbeendefinedin the currentversionof DAML-S, but below we briefly describeour intentionswithregardto thelatter. We have defineda simpleontologyof time, describedbelow; in subsequentversionsthiswill beelaborated.Wealsoexpectin a futureversionto provide anontologyof resources.

d e f g h i e j k l e m

n f k i e o o p k q r f k m

n f k i e o o j k l e m

s t u v t w x y z { | t } z w w

~ z v z � y � � y x �� v � x y� z � � z � } z

�� ��� � � ��

� � � � ���

� � �� � � � � � � � � � � �

� � � � � � � � ��� �� � � � � �

� � � � � � � � � � � � �   � ¡ � � � � � � � � � ¢� � � � � � � � � � �   � ¡ � � � �� �� � � � � � � � � � �   � ¡ � � �� �� �� � � � � � � � � � �   � ¡ � �£ � � � � �£ � � � � � �£ � � � � � � � � � � �

{ | t } z w w

Figure2: Top level of processmodelingontology

5.1 TheProcessOntology

Weexpectourprocessontologyto serveasthebasisfor specifyingawidearrayof services.In developingthe ontology, we drew from a variety of sources,including work in AI on standardizationsof planninglanguages[9], work in programminglanguagesanddistributedsystems[16, 15], emerging standardsinbusinessprocessandworkflow technology(http://www.aiim.org/wfmc/mainframe.htm),work on model-ing verbsemanticsandevent structure[17], work in AI on modelingcomplex actions[11], andwork inagentcommunicationlanguages[12, 8].

The primary kind of entity in the ProcessOntology is, unsurprisingly, a “process”.8 A processcanhave any numberof inputs,representingthe informationthat is, undersomeconditions,requiredfor theexecutionof the process.It canhave any numberof outputs,the informationthat the processprovides,conditionally, after its execution. Participantsandotherparametersmay be specified;for example,theparticipantsmayincludetherolesin theeventframe,suchastheagents,patient,andinstrument,whereasotherparameters,especiallyfor physicaldevices,might be rates,forces,andknob-settings.Therecanbeany numberof preconditions,which mustall hold in orderfor theprocessto be invoked. Finally, theprocesscanhave any numberof effects.

A processcanoftenbeviewedeitherasa primitive, undecomposableprocessor asa compositepro-cess,decomposableinto a complex of otherprimitive or compositeprocesses.Either perspective maybe the more useful in somegiven context. Thus, a top-level PROCESS classhas,as its sole subclass,COMPOSITEPROCESS, which in turn is subclassedby avarietyof controlstructures.

Moreprecisely, in DAML-S:¤This term waschosenover the terms“event” and“action”, in part becauseit is moresuggestive of internal

structurethan“event” andbecauseit doesnot necessarilypresumeanagentexecutingtheprocessandthusis moregeneralthan“action”. Ultimately, however, thechoiceis arbitrary. It is modeledaftercomputationalproceduresorplanningoperators.

� Process

<rdfs:Class rdf:ID="Process"><rdfs:comment> Top-level class for describing how a service works</rdfs:comment>

</rdfs:Class>

ClassPROCESS hasrelatedpropertiesparameter, input, output, participant, precondition, and(con-ditional) effect. Eachof thesepropertiesrangesover a DAML object,which,at theupperontologylevel, is notrestrictedatall. Thepropertiesinput, output, andparticipantarecategorizedassubprop-ertiesof parameter. Subclassesof Processfor specificdomainscanuseDAML languageelementsto indicatemorespecificrangerestrictions,aswell ascardinalityrestrictionsfor eachof theseprop-erties.

Thefollowing is anexampleof apropertydefinition:

<rdf:Property rdf:ID="parameter"><rdfs:domain rdf:resource="#Process"/><rdfs:range rdf:resource=""http://www.daml.org/2001/03/daml+oil#Thing"/>

</rdf:Property>

In additionto its action-relatedproperties,a Processhasa numberof bookkeepingpropertiessuchasname(rdf:literal), address(URI), documentsread(URI), documentsupdated(URI), andsoon.

� CompositeProcess

<daml:Class rdf:ID="CompositeProcess"><daml:intersectionOf rdf:parseType="daml:collection">

<daml:Class rdf:about="#Process"/><daml:Restriction daml:minCardinality="1">

<daml:onProperty rdf:resource="#components"/></daml:Restriction>

</daml:intersectionOf></daml:Class>

<rdf:Property rdf:ID="components"><rdfs:comment>Holds the specific arrangement of subprocesses.

</rdfs:comment><rdfs:domain rdf:resource="#CompositeProcess"/>

</rdf:Property>

Compositeprocessesareprocessesthathaveadditionalpropertiescalledcomponentsto indicatetheorderingandconditionalexecutionof thesubprocessesfromwhichthey arecomposed.For instance,thecompositeprocess,SEQUENCE, hasacomponentspropertythatrangesovera PROCESSL IST (alist whoseitemsarerestrictedtobesimpleorcompositeprocesses).In theprocess“upperontology”,we have attemptedto comeup with a minimal set of processclassesthat can be specializedto

describea variety of Web services. This minimal set consistsof Sequence,Split, Split + Join,Choice,Unordered,Condition,If-Then-Else,Iterate,Repeat-While,andRepeat-Until.

Note thatwhile a compositeprocessis a process,andthushasslotsfor preconditionsandeffects,theremay be no easyway to computethesevaluesfor an arbitrarycompositeprocess,given itscomponentsub-processes.

Thereare two fundamentalrelationsbetweenprocessesandcompositeprocesses.The EXPAND

relation associatesa Processwith the CompositeProcessdescribingits componentsubprocesses,while its inverse,the COLLAPSE relationrepresentstheassociationof theCompositeProcessto itsatomicProcessform. Expandingis intendedto provide a “glassbox”andcollapsinga “blackbox”view of theprocess.Theexpandedversionis likely to beusedfor servicecomposition(bothoff-lineandruntime)andthecollapsedversionfor serviceexecution.

Theminimalsetof compositiontemplates(subclassesof CompositeProcess) is asfollows:

Sequence: A list of Processesto be donein order. We usea DAML restrictionto restrict thecomponentsof aSequenceprocessto beaList of subprocesses(simpleand/orcomposite).

<rdfs:Class rdf:ID="Sequence"><daml:intersectionOf rdf:parseType="daml:collection"><rdfs:Class> rdf:about="#Process" </rdfs:Class><daml:Restriction><daml:onProperty rdf:resource="#components"/><daml:toClass rdf:resource="#ProcessList"/>

</daml:Restriction><daml:intersectionOf></rdfs:Class>

Split : Thecomponentsof a Split processarea bagof sub-processesto beexecutedconcurrently.No furtherspecificationaboutwaiting or synchronizationis madeat this level.

<rdfs:Class rdf:ID="Split"><daml:intersectionOf rdf:parseType="daml:collection"><rdfs:Class> rdf:about ="#Process" </rdfs:Class><daml:Restriction><daml:onProperty rdf:resource="#components"/><daml:toClass rdf:resource="#ProcessBag"/>

</daml:Restriction><daml:intersectionOf></rdfs:Class>

Split is similar to otherontologies’useof Fork, Concurrent,or Parallel. We usetheDAMLsameClassAsfeatureto accommodatethedifferentstandardsfor specifyingthis.

Unordered : Herea bagof processescanbe executedin any order. No further constraintsarespecified.All processesmustbeexecuted.

Split+Join : Heretheprocessconsistsof concurrentexecutionof a bunchof sub-processes.withbarriersynchronization.With Split andSplit andJoin,wecandefineprocessesthathavepartialsynchronization(e.g.,split all andjoin somesub-bag).

Choice : Choiceis a compositeprocesswith additionalproperties“chosen”and“chooseFrom”.Thesepropertiescanbeusedbothfor processandexecutioncontrol(e.g.,choosefrom“choose-From” anddo“chosen”in sequence,or choosefrom “chooseFrom”anddo“chosen”in paral-lel) aswell for constructingnew subclasseslike “chooseat leastn from m”, “chooseexactlynfrom m”, “chooseatmostn from m”9, andsoon.

Condition : Conditionsarecompositeprocesseswith anoutputproperty(conditionValue)whoserangeis a binaryvalue.Conditionsusuallycorrespondto testactions,but they maybeworldstates,resourcelevels,timeoutsor otherthingsaffectingtheevolution of processes.

If-Then-Else : The If-Then-ElseClassis a compositeprocessthat haspropertiescondition,thenand elseholding different aspectsof the If-Then-Elsecompositeprocess. Its semanticsisintendedas“TestIf-condition; if TruedoThen, if Falsedo Else.”

<rdf:Property rdf:ID="ifCondition"><rdfs:comment> The if condition of an if-then-else</rdfs:comment><rdfs:domain rdf:resource="#If-Then-Else"/><rdfs:range> rdf:resource ="#Condition" </rdfs:range>

</rdf:Property>

<rdf:Property rdf:ID="then"><rdfs:domain rdf:resource="#If-Then-Else"/><rdfs:range rdf:resource="#CompositeProcess"/>

</rdf:Property>

<rdf:Property rdf:ID="else"><rdfs:domain rdf:resource="#If-Then-Else"/><rdfs:range rdf:resource="#CompositeProcess"/>

</rdf:Property>

Iterate : Iterateis a compositeprocesswhosenext processpropertyhasthe samevalue as thecurrentprocess.Repeatis definedasa synonym of the iterateclass. The repeat/iteratepro-cessmakesno assumptionabouthow many iterationsaremadeor whento initiate, terminateor resume. The initiation, terminationor maintainanceconditioncould be specifiedwith awhileConditionor anuntilConditionasbelow.10

Repeat-Until : TheRepeat-Untilclassis similar to theRepeat-Whileclassin thatspecializestheIf-Then-Elseclasswherethe “ifCondition” is the sameas the untilCondition and differentfrom theRepeat-Whileclassin that the “else” (comparedto “then”) propertyis the repeatedprocess.Thustheprocessrepeatstill theuntilConditionbecomestrue.

5.2 ProcessControl Ontology

A processinstantiationrepresentsa complex processthat is executing in the world. To monitor andcontrol the executionof a process,an agentneedsa modelto interpretprocessinstantiationswith three¥

This canbe obtainedby restrictingthe sizeof the ProcessBag that correspondsto the “components”of thechosenandchooseFromsubprocessesusingcardinality, min-cardinality, max-cardinalityto get choose(n,m)(¦¨§© §«ª ¬®­°¯²±³­ ©µ´�©·¶¹¸»º ¬½¼³­¾­ ¸�´°¿ÁÀ ­°¯Ã½ªÅÄƦÈÇɯʧ˪ ¬®­°¯²±³­ ©µ´�©·¶¹¸»º ¬Ì¼Í­ ¸�´�© ½ª ).�ÏÎ

Anotherpossibleextensionis to ability to definecountersandusetheir valuesasterminationconditions.Thiscouldbepartof anextendedprocesscontrolandexecutionmonitoringontology.

characteristics:

1. It shouldprovide themappingrulesfor thevariousinput stateproperties(inputs,preconditions)tothecorrespondingoutputstateproperties.

2. It shouldprovide a modelof the temporalor statedependenciesdescribedby the sequence,split,split+join,etcconstructs.

3. It shouldprovide representationsfor messagesabouttheexecutionstateof atomicandcompositeprocessessufficient to do executionmonitoring.This allows anagentto keeptrackof thestatusofexecutions,includingsuccessful,failedandinterruptedprocesses,andto respondto eachappropri-ately.

Wehavenotdefinedaprocesscontrolontologyin thecurrentversionof DAML-S, but we planto in afutureversion.

5.3 Time

For theinitial versionof DAML-S we have defineda very simpleupperontologyfor time. Therearetwoclassesof entities—instantsandintervals. Eachis a subclassof temporal-entity.

Thereare threerelationsthat may obtain betweenan instantand an interval, definedas DAML-Sproperties:

1. TheStart-ofpropertywhosedomainis theInterval classandwhoserangeis anInstant.

2. TheEnd-ofpropertywhosedomainis theInterval classandwhoserangeis anInstant.

3. TheInsidepropertywhosedomainis theInterval classandwhoserangeis anInstant.

No assumptionis madethatintervalsconsistof instants.Therearetwo possiblerelationsthatmayobtainbetweena processandoneof the temporalobjects.

A processmay be in an at-time relation to an instantor in a during relation to an interval. Whethera particularprocessis viewed asinstantaneousor asoccuringover an interval is a granularitydecisionthat may vary accordingto the context of use. Theserelationsaredefinedin DAML-S aspropertiesofprocesses.

1. TheAt-time property:its domainis theProcessclassandits rangeis anInstant.

2. TheDuringproperty:its domainis theProcessclassandits rangeis anInterval.

Viewedasintervals, processescould have propertiessuchasstartTime andendTime which aresyn-onymous(daml:samePropertyAs)with theStart-OfandEnd-Ofrelationthatobtainsbetweenintervalsandinstants.

Onefurther relationcanhold betweentwo temporalentities—thebefore relation. The intendedse-manticsis that for an instantor interval to bebeforeanotherinstantor interval, therecanbe no overlapor abutmentbetweenthe former and the latter. In DAML-S the Beforepropertywhosedomainis theTemporal-entityclassandwhoserangeis aTemporal-entity.

Differentcommunitieshavedifferentwaysof representingthetimesanddurationsof statesandevents(processes).For example,statesandeventscanboth have durations,andat leasteventscanbe instan-taneous;or eventscanonly be instantaneousandonly statescanhave durations.Eventsthat onemightconsiderashaving duration(e.g.,heatingwater)aremodeledasa stateof thesystemthat is initiatedand

terminatedby instantaneousevents. That is, thereis the instantaneousevent of the startof the heatingat thestartof an interval, that transitionsthesysteminto a statein which thewateris heating.Thestatecontinuesuntil anotherinstantaneousevent occurs—thestoppingof theevent at theendof the interval.Thesetwo perspectiveson eventsarestraightforwardly interdefinablein termsof the ontologywe haveprovided.Thus,DAML-S supportsboth.

Thevariousrelationsbetweenintervalsdefinedin Allen’s temporalinterval calculus[1] canbedefinedin a straightforward fashionin termsof before andidentity on thestartandendpoints.For example,twointervals meetwhenthe endof oneis identical to the startof the other. Thus, in the nearfuture, whenDAML is augmentedwith thecapabilityof defininglogical rules,it will beeasyto incorporatetheintervalcalculusinto DAML-S. In addition,in futureversionsof DAML-S wewill defineprimitivesfor measuringdurationsandfor specifyingclock andcalendartime.

6 ExampleWalk-Thr ough

To illustrate the conceptsdescribedin this paper, we have developedan exampleof a fictitious book-buying serviceoffered by the Web serviceprovider, CongoInc. Congohasa suite of programsthatthey aremakingaccessibleon the Web. Congowishesto composetheseindividual programsinto Webservicesthat it offersto its users.We focushereon theWebserviceof buying a book,CongoBuy. In theDAML-S release,we presenta walk-throughthatstepsthroughtheprocessof creatingDAML-S markupfor Congo11.

We take theperspective of the typical Webserviceprovider andconsiderthreeautomationtasksthata Web serviceprovider might wish to enablewith DAML-S: 1) automaticWeb servicediscovery, 2)automaticWebserviceinvocation,and3) automaticWebservicecompositionandinteroperation.For thepurposesof thispaper, we limit ourdiscussionto thesecondandthird tasks.

6.1 WebServiceInvocation

ToautomateWebServiceInvocation,DAML-S markupmusttell aprogramhow toautomaticallyconstructan(http)call to executeor invoke aWebservice,andwhatoutput(s)maybereturnedfrom theservice.Toenablesuchfunctionality, theprocessontologyin DAML-S providesmarkupto describeindividual andcompositeWeb-accessibleprogramsaseithersimpleor compositeprocesses.

6.1.1 DefinetheServiceasa Process

CongoInc. providestheCongoBuyWebserviceto its customers.Weview theCongoBuyWebserviceasaProcess,i.e., it is asubclassof theclassProcessin theprocessontology.

<rdfs:Class rdf:ID="CongoBuy"><rdfs:subClassOf rdf:resource=

"https://www.www.daml.org/services/daml-s/2001/05/Process#Process"/></rdfs:Class>

AlthoughtheCongoBuyserviceis actuallya predeterminedcompositionof severalof Congo’s Web-accessibleprograms,it is usefulto initially view it asa black-boxprocess.Theblack-boxprocess,Con-goBuyhasavarietyof invocation-relevant properties,includinginput,(conditional)outputandparameter.For example,input to theCongoBuybook-buying serviceincludesthenameof thebook(bookName),thecustomer’s creditcardnumber, andtheir accountnumberandpassword. If theservicebeingdescribedissimplein thatit is not thecompositionof otherservicesor programs,thentheserviceinputsaresimply the�Ð�

TheCongoexamplecanbefoundat https://www.www.daml.org/services/daml- s/2001/05/Congo.daml.

setof inputsthatmustbeprovidedin theserviceinvocation.Theoutputsaretheoutputsreturnedfrom theserviceinvocation.Notethattheseoutputsmaybeconditional.For exampletheoutputof a book-buyingservicewill vary dependinguponwhetherthebookis in or outof stock.

In contrast,if theserviceiscomposedof otherservices,asis thecasewith CongoBuy, thentherationalefor specificationof theinputs,outputsandparametersis moredifficult, andtheutility of thesepropertiesis limited. In thesimplestcase,the inputsandoutputsof theblack-boxprocesscanbedefinedto be thecompositionof all thepossibleinputsandall thepossible(conditional)outputsof thesimpleservicesthattheblack-boxprocessmayinvoke, takingeverypossiblepaththroughthecompositionof simpleservices.Note however that this is not a very exactingspecification.In particular, the collectionof outputsmaybecontradictory(e.g.,onepathof CongoBuymayleadto confirmationof a purchase,while anothermayleadto confirmationof no purchase).The conditionsunderwhich inputsandoutputsariseareencodedexactly in the expandof this black-boxprocess,andcanbe retrieved from the expandedprocess.Theinputs,outputsandparametersfor theblack-boxprocessaredesignedto bea usefulshorthand.Thus,itcouldbearguedthattheinputsandoutputsshoulddescribethemostlikely inputsandoutputsthroughthesystem.However, in somecases,eventhis is difficult to define.For now, DAML-S leavesthisdecisionupto theWebserviceprovider.

Thefollowing is anexampleof oneinput to CongoBuy. Note that it is a subpropertyof thepropertyinput of Process,from theprocessmodel.

<rdf:Property rdf:ID="bookName"><rdfs:subPropertyOf rdf:resource="https://www.www.daml.org/services/daml-s/2001/05/Process#input"/><rdfs:domain rdf:resource="#CongoBuy"/><rdfs:range rdf:resource="rdfs:Literal"/>

</rdf:Property>

An outputcansimilarly bedefinedasa subpropertyof thepropertyoutputof Process.In a realbook-buying service,this output would likely be conditionedon the book being in stock,or the customer’scredit cardbeingvalid, but to simplify our example,we assumeCongohasan infinite supplyof books,andinfinite generosity.

<rdf:Property rdf:ID="eReceiptOutput"><rdfs:subPropertyOf rdf:resource="https://www.daml.org/services/daml-s/2001/05/Process#output"/>

<rdfs:range rdf:resource="#EReceipt"/></rdf:Property>

In addition to input and output properties,eachservicehasparameterproperties. A parameterissomethingthat affectstheoutcomeof theprocess,but which is not an input provided by the invoker oftheprocess.It maybeknown by theservice,or retrievedby theservicefrom elsewhere.For example,thefactthatthecustomer’s creditcardis valid, is aparameterin ourCongoBuyprocess,andis relevantwhenconsideringtheuseof theCongoBuy, but it is notaninputor outputof CongoBuy.

<rdf:Property rdf:ID="creditCardValidity"><rdfs:subPropertyOf rdf:resource="https://www.daml.org/services/daml-s/2001/05/Process.daml#parameter"/>

<rdfs:range rdf:resource="#ValidityType"/></rdf:Property>

6.1.2 DefinetheProcessasa Compositionof Processes

Given thevariability in thespecificationof inputs,outputsandparameters,it is generallyinsufficient tosimply specifya serviceasa black-boxprocess,if the objective is to automateserviceinvocation. Wemustexpandtheblack-boxserviceto describeits compositeprocesses.This is achievedby first definingtheindividual processesandthendefiningtheir compositionasacompositeprocess.

Definethe Indi vidual ProcessesWefirst defineeachof thesimpleservicesin CongoBuy, i.e.,LocateBook,PutInCart,etc.

<rdfs:Class rdf:ID="LocateBook"><rdfs:subClassOf rdf:resource="#Process"/>

</rdfs:Class>

<rdfs:Class rdf:ID="PutInCart"><rdfs:subClassOf rdf:resource="#Process"/>

</rdfs:Class>

<rdf:Property rdf:ID="bookSelected"><rdfs:subPropertyOf rdf:resource="&process;#input"/><rdfs:domain rdf:resource="#PutInCart"/><rdfs:range rdf:resource="rdfs:Literal"/>

</rdf:Property>\footnote{https://www.daml.org/services/daml-s/2001/05/Congo.daml.Additional DAML code is needed here to specify the relationshipbetween the bookName property of CongoBuy and the bookSelectedproperty of PutInCart. As of this writing, discussions are underwayto determine the best way to indicate this relationship in DAML+OIL.}.

Definethe Composition of the Indi vidual ProcessesThe compositionof eachof our simpleservicescanbe definedby usingthe compositionconstructs

createdin the processontology, i.e., Sequence,Split, Split + Join, Unordered,Condition,If-Then-Else,Repeat-While,Repeat-Until.We first createanexpandclassandthenconstructtheoverall expandclassrecursively in a top-down manner.

<expand><rdfs:Class> rdfs:about ="#CongoBuy"</rdfs:Class><rdfs:Class> rdfs:about ="#ExpandedCongoBuy"</rdfs:Class>

</expand>

Eachprocesshasa propertycalledcomponents(itself a bagof processes).Theprocessesin thebagmaybeothersimpleor compositeprocesses.As such,they recursively definethecompositionof simpleprocessesthatdefinestheblack-boxprocessCongoBuy.

TheexpandedCongoBuyprocess(ExpandedCongoBuy)is comprisedof asequenceof two processes,a simpleprocessthat locatesa book(LocateBook),anda complex processthatbuys thebook(CongoB-uyBook).Wedefinethemasfollows:

<rdfs:Class rdf:ID="ExpandedCongoBuy"><daml:subClassOf rdf:resource="https://www.daml.org/services/daml-s/2001/05/Process.daml#Sequence"/><daml:subClassOf><daml:Restriction><daml:onProperty rdf:resource=

"https://www.daml.org/services/daml-s/2001/05/Process.daml#components"/><daml:toClass><daml:subClassOf><daml:unionOf rdf:parseType="daml:collection"><rdfs:Class rdfs:about="#LocateBook"/><rdfs:Class rdfs:about="#CongoBuyBook"/>

</daml:unionOf></daml:subClassOf></daml:toClass>

</daml:Restriction></daml:subClassOf>

</rdfs:Class>

In thefull Congo.damlexample,CongoBuyBookis a compositeprocessthat is furtherdecomposed,eventuallyterminatingin a compositionof simpleprocesses.With this markupwe completeour markupto enableautomatedserviceinvocation.

6.1.3 AutomatedServiceCompositionandInteroperation

TheDAML-S markuprequiredto automateservicecompositionandinteroperationbuilds directly on themarkupfor serviceinvocation.In orderto automateservicecompositionandinteroperation,wemustalsoencodethe effectsa servicehasuponthe world, andthe preconditionsfor performingthat service. Forexample,whenahumanbeinggoesto www.congo.comandsuccessfullyexecutestheCongoBuyservice,thehumanknows thatthey havepurchasedabook,thattheircreditcardwill bedebited,andthatthey willreceive a bookat theaddressthey provided. Suchconsequencesof Webserviceexecutionarenot partoftheinput/outputmarkupwecreatedfor automatingserviceinvocation.

The processontologyprovidespreconditionandeffect propertiesof a processto encodethis infor-mation. As with our markupfor automatedserviceinvocation,we definepreconditionsandeffectsbothfor the black-boxprocessCongoBuyandfor eachof the simpleprocessesthat defineits composition,andaswith defininginputsandoutputs,it is easiestto definethe preconditionsandeffects for eachofthesimpleprocessesfirst, andthento aggregatetheminto preconditionsandeffectsfor CongoBuy. Themarkupis analogousto themarkupfor inputand(conditional)output,but is with respectto thepropertiespreconditionand(conditional)effect, instead.

7 RelatedEfforts

Industry efforts to develop standardsfor electroniccommerce,and in particularfor the descriptionofWeb-basedservicescurrently revolve aroundUDDI, WSDL, and ebXML [22]. Therehave also beencompany-specificinitiativesto definearchitecturesfor e-commerce,mostnotablyE-speakfrom Hewlett-Packard.

Nevertheless,we believe that DAML-S providesfunctionality that the otherefforts do not. In com-parisonto theDAML-S characterizationof services,the industrystandardsmostly focuson presentingaServiceProfileandaServiceGroundingof services(to useDAML-S terminology).ServiceGroundingsaresupportedby all the standards.However, they arelimited with respectto DAML-S profilesin that theycannotexpresslogical statements,e.g. preconditionsandpostconditions,or rulesto describedependen-ciesbetweentheprofile elements.Input andoutputtypesaresupportedto varyingextents.Furthermore,DAML-S supportsthedescriptionof certainfunctionalattributesof services,whicharenotcoveredin theotherstandards,suchasqualityGuaranteesandserviceType.

With respectto thefour tasksof automaticWebservicediscovery, automaticWebserviceinvocation,automaticWebserviceinteroperationandcomposition,andautomaticWebserviceexecutionmonitoring

thatDAML-S is meantto support,thestandardsprimarily enablethefirst andthesecondtasksto acertainextent. Thesestandardsarestill evolving andit is unclearat presentto what extentcompositionwill beaddressed.At themoment,thestandardsdonotconsidertheServiceModelof aserviceandthus,they alsodo not supportexecutionmonitoring,asdefinedin this paper.

In thefollowing sections,we look in greaterdetailat eachof thesetechnologiesin turn andcomparethemto DAML-S.

7.1 UDDI

UDDI(UniversalDescription,Discovery andIntegration)is aninitiative proposedby Microsoft, IBM andAriba to developastandardfor anonlineregistry, to enablethepublishinganddynamicdiscovery of Webservicesofferedby businesses[21]. UDDI allows programmersandotherrepresentativesof abusinesstolocatepotentialbusinesspartnersandform businessrelationshipsonthebasisof theservicesthey provide.It thusfacilitatesthecreationof new businessrelationships.

Theprimarytargetof UDDI seemsto beintegrationandat leastsemi-automationof businesstransac-tions in B2B e-commerceapplications.It providesa registry for registeringbusinessesandtheservicesthey offer. Thesearedescribedaccordingto anXML schemadefinedby theUDDI specification.A Webserviceprovider registersits advertisementsalongwith keywordsfor categorisation.A Webservicesuserretrievesadvertisementsoutof theregistrybasedonkeywordsearch.TheUDDI searchmechanismrelieson pre-definedcategorisationthroughkeywordsanddoesnot refer to thesemanticcontentof theadver-tisements.Theregistry is supposedto functionin a fashionsimilar to white pagesor yellow pages,wherebusinessescanbelookedup by nameor by a standardservicetaxonomyasis alreadyusedwithin thein-dustry. UDDI attemptsto coverall kindsof servicesofferedby businesses,includingthosethatareofferedby phoneor e-mailandsimilarmeans;in principle,DAML-S coulddo this,but it hasnotbeenour focus.

Technicallyspeaking,eachbusinessdescriptionin UDDI consistsof a businessEntityelement,akinto a White Pageselementdescribingthecontactinformationfor a business.A businessEntitydescribesa businessby name,a key value,categorisation,servicesoffered(businessServiceelements)andcontactinformationfor thebusiness.A businessServiceelementdescribesa serviceusinganame,key value,cat-egorisationandmultiple bindingTemplateelements.This canbeconsideredto beanalogousto a YellowPageselementthatcategorisesabusiness.A bindingTemplateelementin turndescribesthekind of accesstheservicerequires(phone,mailto, http, ftp, fax etc.),key valuesandtModelInstances.tModelInstancesareusedto describetheprotocols,interchangeformatsthattheservicecomprehends,thatis, thetechnicalinformationrequiredto accesstheservice.It is alsousedto describethe“namespaces”for theclassifica-tionsusedin categorisation.Many of theelementsareoptional,includingmostof theonesthatwould berequiredfor matchmakingor servicecompositionpurposes.

UDDI aimsto facilitatethediscovery of potentialbusinesspartnersandthediscovery of servicesandtheirgroundingsthatareofferedby known businesspartners.Thismayor maynotbedoneautomatically.Whenthisdiscovery occurs,programmersaffiliatedwith thebusinesspartnersprogramtheirown systemsto interactwith theservicesdiscovered.This is alsothemodelgenerallyfollowedby ebXML. DAML-Senablesmoreflexible discovery by allowing searchesto take placeonalmostany attributeof theService-Profile.UDDI, in contrast,allows technicalsearchesonly on tModelKeys, referencesto tModelInstances,which representfull specificationsof akind of service.

UDDI, of itself, doesnot supportsemanticdescriptionsof services.Thus,dependingon thefunction-ality offeredby thecontentlanguage,althoughagentscansearchtheUDDI registry andretrieve servicedescriptions,a humanneedsto beinvolved in theloop to make senseof thedescriptions,andto programtheaccessinterface.

UDDI doesnotprovideor specifycontentlanguagesfor advertisementsofar. AlthoughWSDL is mostcloselyassociatedwith UDDI asacontentlanguage,thespecificationrefersto ebXML andXML/edi also

as potentialcandidates.Contentlanguagescould be a possiblebridge betweenUDDI and DAML-S.DAML-S is alsoa suitablecandidatefor a contentlanguageandin this sense,DAML-S andUDDI arecomplementary. A higher-level serviceor standarddefinedon top of UDDI could take advantageof theadditionalrichnessof contentDAML-S hasto offer within theUDDI registries.

7.2 WSDL

WSDL (Web ServicesDescriptionLanguage)is an XML format, closelyassociatedwith UDDI as thelanguagefor describinginterfacesto businessservicesregisteredwith a UDDI database.It is thuscloserto DAML-S in termsof functionalitythanUDDI. LikeDAML-S, it attemptstoseparateservices,definedinabstractterms,from theconcretedataformatsandprotocolsusedfor implementation,anddefinesbindingsbetweentheabstractdescriptionandits specificrealization[3]. However, theabstractionof servicesis ata lower level thanin DAML-S.

Servicesaredefinedassetsof ports,that is network addressesassociatedwith certainprotocolsanddataformatspecifications.Theabstractnatureof aservicearisesfrom theabstractnatureof themessagesand operationsmappedto a port and defineits port type. Port typesare reusableand can be boundto multiple ports [18]. Operationsareof four basickinds in WSDL: a one-way, a (two-way) request-response,a (two-way) solicit-responseanda (one-way) notificationmessage.A messageitself is definedabstractlyasa request,a responseor evena parameterof a requestor responseandits type,asdefinedina typesystemlike XSD. They canbebrokeninto partsto definethelogicalbreak-down of amessage.

Messagesandoperationsaredefinedabstractlyandarethusreusableandextensibleandcorrespondroughlyto theDAML-S ServiceProfile.Theserviceelementitself incorporatesbotha ServiceProfileandServiceGroundinginformation. WSDL servicedescriptionsarenot asexpressive asDAML-S profiles.Preconditions,postconditionsandeffectsof serviceaccesscannotbeexpressedwithin WSDL.

LikeUDDI, WSDL doesnot supportsemanticdescriptionof services.WSDL focuseson theground-ing of servicesandalthoughit hasa conceptof input andoutput typesasdefinedby XSD, it doesnotsupportthedefinitionof logical constraintsbetweenits input andoutputparameters.Thusits supportfordiscovery andinvocationof servicesis lessversatilethanthatof DAML-S.

7.3 E-speak

Hewlett-Packardis collaboratingwith the UDDI consortiumto bring E-speaktechnologyto the UDDIstandard.It is thusfairly likely thatE-speakwill besubsumedby UDDI. E-speakandUDDI have similargoalsin that they bothfacilitatetheadvertisementanddiscovery of services.E-speakis alsocomparableto WSDL in that it supportsthe descriptionof serviceanddatatypes[6]. It hasa matchingservicetocompareservicerequestandservicedescriptions,which it doesprimarily on thebasisof input-outputandservicetypesmatching.

E-speakdescribesservices(Resourcesin thee-speakworld) asa setof attributeswithin several Vo-cabularies. Vocabulariesaresetsof attributescommonto a logical groupof services.E-speakmatcheslookuprequestsagainstservicedescriptionswith respectto theseattributes.AttributestakecommonvaluetypessuchasString,Int, BooleanandDouble. Thereis a basevocabulary which definesbasicattributessuchasName,Type (of valueString only), Description,KeywordsandVersion. Currently, thereis nosemanticmeaningattachedto any of the attributes. Any matchingwhich takes placeis doneover theservicedescriptionattributeswhich doesnot distinguishbetweenany further subtypes.DAML-S hadamuchrichersetof attributes,in DAML-S terminology, theinput/outputparameters,effectsandadditionalfunctionalattributes.In addition,dependenciesbetweenattributesandlogical constraintson themarenotexpressiblewithin E-speak.

UnlikeUDDI, whichwasintendedto beanopenstandardfrom thebeginning,e-speakscoresrelativelylow on interoperability. It requiresthat an e-speakenginebe run on all participatingclient machines.Furthermore,althoughe-speakis designedto be a full platform for Web servicesandcould potentiallyexposea executionmonitoringinterface,serviceprocessesremaina black-boxfor the e-speakplatformandconsequentlynoexecutionmonitoringcanbedone.

7.4 ebXML

ebXML, beingdevelopedprimarily by OASIS andthe United Nations,approachesthe problemfrom aworkflow perspective. ebXML usestwo views to describebusinessinteractions,a BusinessOperationalView (BOV) andaFunctionalServiceView (FSV)[7] [22]. TheBOV dealswith thesemanticsof businessdatatransactions,which includeoperationalconventions,agreements,mutualobligationsandthelike be-tweenbusinesses.TheFSVdealswith thesupportingservices:theircapabilities,interfacesandprotocols.AlthoughebXML doesnotconcentrateononly Webservices,thefocusof thisview is essentiallythesameasthatof thecurrentDAML-S effort.

It hasthe conceptof a CollaborationProtocolProfile (CPP)“which allows a TradingPartnerto ex-presstheir supportedBusinessProcessesandBusinessServiceInterfacerequirements[suchthat they areunderstood]by otherebXML compliantTradingPartners”,in effectaspecificationof theservicesofferedby theTradingPartner. A BusinessProcessis a setof businessdocumentexchangesbetweentheTradingPartners.CPPscontainindustryclassification,contactinformation,supportedBusinessProcesses,inter-facerequirementsetc.They areregisteredwithin anebXML registry, in which thereis discovery of otherTradingPartnersandthe BusinessProcessesthey support. In this respect,UDDI hassomesimilaritieswith ebXML. However, ebXML’s scopedoesnot extendto themannerin which thebusinessdocumentsarespecified.This is left to theTradingPartnersto agreeupona priori by thecreationof a CollaborationProtocolAgreement.

In conclusion,thekind of functionality, interoperabilityanddynamicmatchmakingcapabilitiespro-vided by DAML-S is only partially supported,asthe standardsarecurrentlypositioned,by WSDL andUDDI. UDDI may becomemoresophisticatedasit incorporatese-speak-like functionalities,but it willnotallow automaticserviceinteroperabilityuntil it incorporatestheinformationprovidedby DAML-S.

8 Summary and Curr ent Status

DAML-S is anattemptto provide anontology, within theframework of theDARPA AgentMarkupLan-guage,for describingWeb services.It will enableusersandsoftwareagentsto automaticallydiscover,invoke, compose,and monitor Web resourcesoffering services,underspecifiedconstraints. We havereleasedaninitial versionof DAML-S. It canbefoundat theURL: http://www.daml.org/services/daml-s

We expectto enhanceit in the future in waysthatwe have indicatedin thepaper, andin responsetousers’experiencewith it. We believe it will help make theSemanticWeba placewherepeoplecannotonly find out informationbut alsogetthingsdone.

Acknowledgments

Theauthorshaveprofitedfrom discussionsaboutthiswork with RonFadel,RichardFikes,JamesHendler,Mark Neighbors,Tran CaoSon,andRichardWaldinger. The researchwasfundedby the DefenseAd-vancedResearchProjectsAgency as part of the DARPA Agent Markup Language(DAML) programunderAir Force ResearchLaboratorycontractF30602-00-C-0168to SRI International,F30602-00-2-0579-P00001to StanfordUniversity, andF30601-00-2-0592t0 Carnegie Mellon University. Additionalfundingwasprovidedby NokiaResearchCenter.

ReferÑ

ences

[1] J.F. Allen andH. A. Kautz. A modelof naive temporalreasoning.In J.R. HobbsandR. C. Moore,editors,FormalTheoriesof theCommonsenseWorld, pages251–268.Ablex PublishingCorp.,1985.

[2] T. Berners-Lee,J. Hendler, andO. Lassila. Thesemanticweb. ScientificAmerican, 284(5):34–43,2001.

[3] E. Christensen,F. Curbera,G. Meredith,andS.Weerawarana.WebServicesDescriptionLanguage(WSDL) 1.1. http://www.w3.org/TR/2001/NOTE-wsdl-20010315, 2001.

[4] K. Decker, K. Sycara,andM. Williamson. Middle-Agentsfor theInternet.In IJCAI97, 1997.

[5] G.Denker, J.Hobbs,D. Martin,S.Narayanan,andR.Waldinger. Accessinginformationandserviceson thedaml-enabledweb. In Proc.SecondInt’l WorkshopSemanticWeb(SemWeb’2001), 2001.

[6] E-Speak. E-SpeakArchitectural SpecificationReleaseA.0. http://www.e-speak.hp.com/media/a0/architecturea0.pdf, 2001.

[7] ebXML. ebXML WebSite. http://www.ebXML.org/, 2000.

[8] T. Finin, Y. Labrou,andJ.Mayfield. KQML asanagentcommunicationlanguage.In J.Bradshaw,editor, Software Agents. MIT Press,Cambridge,1997.

[9] M. Ghallabet.al. Pddl-theplanningdomaindefinitionlanguagev. 2. TechnicalReport,reportCVCTR-98-003/DCSTR-1165,YaleCenterfor ComputationalVisionandControl,1998.

[10] J. Hendler and D. L. McGuinness. Darpa agentmarkup language. IEEE Intelligent Systems,15(6):72–73,2001.

[11] H. Levesque,R. Reiter, Y. Lesperance,F. Lin, and R. Scherl. GOLOG: A Logic programminglanguagefor dynamicdomains.Journalof Logic Programming, 31(1-3):59–84,April-June1997.

[12] D. Martin, A. Cheyer, andD. Moran. The OpenAgent Architecture: A Framework for BuildingDistributedSoftwareSystems.AppliedArtificial Intelligence, 13(1-2):92–128,1999.

[13] S.McIlraith, T. C. Son,andH. Zeng. Mobilizing thewebwith daml-enabledwebservice.In Proc.SecondInt’l WorkshopSemanticWeb(SemWeb’2001), 2001.

[14] S.McIlraith, T. C. Son,andH. Zeng.Semanticwebservice.IEEEIntelligentSystems, 16(2):46–53,2001.

[15] J.Meseguer. ConditionalRewriting Logic asaUnifiedModelof Concurrency. TheoreticalComputerScience, 96(1):73–155,1992.

[16] R. Milner. Communicatingwith Mobile Agents: The pi-Calculus. CambridgeUniversity Press,Cambridge,1999.

[17] S. Narayanan. Reasoningaboutactionsin narrative understanding.In Proc. International JointConferenceon Artifical Intelligence(IJCAI’1999), pages350–357.Morgan KaufmanPress,SanFrancisco,1999.

[18] U. Ogbuji. UsingWSDL in SOAP applications:An introductionto WSDL for SOAP programmers.http://www-106.ibm.com/developerworks/library/ws-soap/?dwzone=ws,2001.

[19] K. SycaraandM. Klusch.Brokeringandmatchmakingfor coordinationof agentsocieties:A survey.In A. e.a.Omicini, editor, Coordinationof InternetAgents. Springer, 2001.

[20] K. Sycara,M. Klusch,S. Widoff, andJ. Lu. Dynamicservicematchmakingamongagentsin openinformationenvironments. ACM SIGMODRecord (SpecialIssueon SemanticInteroperability inGlobal InformationSystems), 28(1):47–53,1999.

[21] UDDI. TheUDDI TechnicalWhitePaper.http://www.uddi.org/, 2000.

[22] D. WebberandA. Dutton. UnderstandingebXML, UDDI andXML/edi. http://www.xml.org/fea-ture articles/20001107miller.shtml,2000.

[23] H.-C. WongandK. Sycara.A Taxonomyof Middle-agentsfor theInternet.In ICMAS’2000, 2000.