hello
An experience report on using DAMLS Marta Sabou Dept. of Artificial Intelligence Vrije Universiteit Amsterdam, The Netherlands marta@cs.vu.nl Debbie Richards Div. of I.C.S. Macquarie University Sydney, Australia richards@ics.mq.edu.au Sander van Splunter Dept. of Artificial Intelligence Vrije Universiteit Amsterdam, The Netherlands sander@cs.vu.nl ABSTRACT Though DAML-S is growing into a de facto standard for semantic web-service markup, we have only found few complete service descriptions and even less papers discussing technical issues about the markup process. We addressed this lack by (1) reporting on our experiences in describing a set of services, (2) concluding several limitations of the latest DAML-S version (v0.7) and (3) making our work accessible to the research community1. 1. INTRODUCTION DAML-S is an initiative of the Semantic Web community to facilitate automatic discovery, invocation, composition, interoperation and monitoring of web-services (WSs) through their semantic description[4]. DAML-S is a DAML+OIL ontology conceptually divided into three sub-ontologies for specifying what a service does? (Profile2), how the service works? (Process3) and how the service is implemented? (Grounding4). We decided to apply the latest release (v0.7) to one of our WS projects. Our preliminary literature study yielded four types of usage scenarios. First, within the DAML-S coalition two complete, fictitious examples (on the DAML-S site) and two concrete applications[ 7] are provided. Second, several projects use only certain parts of the DAML-S ontology, eg. matchmaking research tends to focus on the Profile ontology [3, 8]. Third, we found work which extends parts of DAML-S: [2] enriches the Process ontology, [9] extends the Profile ontology with bio-informatics related properties, [6] extends the specification of conditions. Finally, some papers mention use of complete DAML-S as is, but the purpose of the papers was to describe other research work. Common to all the above referenced papers is that none of them describe the process of writing the DAML-S markup. We were also concerned that very little of the DAML-S markup we found pointed to actual services. We sought to fill this gap by providing a set of complete, real web service descriptions and sharing our modelling experiences. For space, this paper only presents the two simplest services we marked up and discusses a set of emerging, noteworthy issues. A brief description of DAML-S, WSDL and our application scenario (section 2) is followed by our practical experiences in describing increasingly complex services (3), a discussion of emerging global observations (4) and our conclusions (5). 1http://www.cs.vu.nl/˜marta/services/ 2http://www.daml.org/services/daml-s/0.7/Profile.daml 3http://www.daml.org/services/daml-s/0.7/Process.daml 4http://www.daml.org/services/daml-s/0.7/Grounding.daml Copyright is held by the author/owner(s). WWW2003, May 20–24, 2003, Budapest, Hungary. ISBN 9633113555. 2. TECHNOLOGY AND CASE STUDY 2.1 DAMLS The information about a DAML-S Service instance is distributed in three main entities. We will explain these entities and introduce the schematic service representations we use through this paper. A service presents a ServiceProfile which describes the capabilities of the service for discovery purposes. The Profile ontology contains the vocabulary to describe the ServiceProfile. Its central concept, Profile, is a subclass of ServiceProfile and contains the contact information of providers, an extensible set of service characteristics and a functionality description by specifying the inputs, outputs, preconditions and effects of the service (IOPE’s). It also points to the described Process. In this paper, for each Profile instance we depict the process it describes (hasProc) and its functional characteristics (IOPE’s) together with their type. In the example below, the Bib2Rdf service presents the Pr1 Profile, which describes Process P1, has a BibFile input and an RdfFile output. Service Bib2Rdf: *Profile:Pr1 (hasProc P1)(I(BibFile), O(RdfFile)) *ProcessModel: AtomicProcess:P1 (I(BibFile),O(RdfFile)) *WSDLGrounding: WsdlAtomicProcessGrounding: Gr1 (P1->op1) *WSDL: Service(PortType:Translator ( op1 (IMsg(url), OMsg(stream)))) A ServiceModel describes the internal workings of the service and it is further specialized as a ProcessModel in the Process ontology. A ProcessModel has a single Process which can be atomic, simple or composite (composed from atomic processes through various control constructs). Each Process has a set of IOPE’s. In our notation, for each service we represent its ProcessModel with its Process. For each Process we depict its type, the involved control constructs, the IOPE’s and their types. Bib2Rdf has a single AtomicProcess P1, with a BibFile input and an RdfFile output. A ServiceGrounding links the abstract description of the service to actual implementation details, such as message exchange formats and network protocols so that automatic invocation of the service is possible. Currently support is offered for grounding DAMLS to WSDL service descriptions. The Grounding ontology specializes the ServiceGrounding as WSDLGrounding which contains a set of WsdlAtomicProcessGrounding elements, each grounding one of the atomic processes specified in the ProcessModel. We depict each atomic process grounding by showing the link between the atomic process and the corresponding WSDL element. Bib2Rdf has a single atomic process grounding where Process P1 is grounded to op1, which is a WSDL operation. See the next subsection. 2.2 WSDL WSDL is an industry standard for describing web-accessible services. As an XML-based language, it is machine processable, being a structured and standardized way to describe web-interfaces of services. However the intended meaning (semantics) of the interface elements is only accessible to human readers. In WSDL a service is seen as a collection of network endpoints which operate on messages. A WSDL document has two major parts. First, it specifies an abstract interface of the service. Complex data types are defined and used to construct messages. A message has a name and a set of parts of certain type. Messages represent either an input parameter set or the output of some abstract operations, which are conceptually grouped together into a Port- Type. Second, an implementation part binds the abstract interface to concrete network protocols and message formats (SOAP, HTTP). A service is a collection of ports of various PortTypes. We depict the WSDL representation by presenting the main Port- Types and the operations which are contained by each port. For each operation we show the input and the output messages, and for each message we enumerate its parts. It follows that Bib2Rdf has a single port (of type Translator) with one operation (op1), where the input and output messages have a single part. 2.3 Case Study the Semantic University The goal of the SW@VU5 project is to use Semantic Web technology within the Vrije Universiteit Amsterdam. The first case study was to share the bibliographic data of the involved researchers through semantic portals. While building the infrastructure for this experiment, a set of web-accessible software components were created. The task of creating the portal simply became shipping data from one service to another. First, each available BibTex file is converted to RDF(S) using the Bib2Rdf service then saved in a web-accessible RDF(S) repository and query engine, Sesame6. When merging our data, syntactically different resources pointed to the same person. We used daml:sameIndividualAs to encode this redundancy and extended Sesame’s reasoning capabilities to interpret this new tag. To provide automated support for the task of finding the resources referring to the same person we developed the SIA(SameIndividualAs) service. Using machine learning techniques on the RDF(S) source, SIA extracts the resources which might refer to the same person. It returns tuples of similar resources. Therefore the second step is to extract all the data from Sesame, send it to SIA, obtain the redundancy file and save it back to Sesame. Finally, portal creator software creates the portals of publications by querying Sesame. By augmenting our web-services with a semantic description we allow automatic execution of a set of services in a pre-defined way. However, we envision more “intelligent” service composition that will be able to adapt according to changes in the requirements. For example, the portal creation task could be performed by different sets of services. Or, if RDF(S) source is provided there is no need for translation. Also, a single data source would not require any redundancy checking. We aim to support such adaptive service composition. 3. MODELLING EXPERIENCES We used DAML-S to describe services with an increasing level of complexity. We present our experiences related to the Bib2Rdf and SIA services. We describe the main issues/pitfalls we encountered. In retrospect, some of what we learned was available in the 5http://www.cs.vu.nl/˜mcaklein/SW@VU/ 6http://sesame.aidministrator.nl documentation, but the counterintuitiveness of some aspects of the language meant we had to learn them for ourselves. Therefore, to provide the basis for discussion of some of the features we found difficult in DAML-S, we do not only convey our final solutions but describe the major design decisions we took during modelling. 3.1 Modelling a simple service Bib2Rdf Bib2Rdf7 is a simple service: it transforms a BibTex file into a RDF(S) representation. The service takes as input the URL of a BibTex file and returns the RDF(S) encoding of this data. Using domain knowledge for service description. It is important to realize that the Profile makes use of already speci- fied domain knowledge (ontology). If multiple services are described using the same ontology, matchmaking and integration will be based on this ontology. We have modelled a set of terms from our application domain in the ProfileTaxonomy8 ontology and used them in our service descriptions.