1. Semantic Markup for Semantic Web Tools:
A DAML-S description of an RDF-Store
Debbie Richards and Marta Sabou
Presenter: Adrian Mocan

2. Contents Introduction Languages for (semantic) service description
Sesame
Specifying service semantic
The Role and Use of Domain Knowledge
Linking between parts of the description
IO Specifications
Conclusions

3. Introduction
WWW – turning in source of information and services usable by software agents
Easy integration and discovery of WS
DAML-S
DAML+OIL ontology for describing WS in a machine interpretable way
Partial use - Process ontology or Profile ontology
Some experiments – describing services by merging agents technology with DAML-S
Mathematical services – MSDL
Sesame – a typical SW Tool described by using the entire DAML-S ontology and WSDL

4. DAML-S Divided in three sub-ontologies Profile Process Grounding
What a service does, how the service works, how the service is implemented
Profile
Contact information of providers
Specifies characteristics of the service and functionality description – “IOPE”
Process
Working of the service in term of the internal processes (process model and dataflow)
Together with Profile -> Conceptual Level Description
Grounding
Operational level details
Links Conceptual Level Description with WSDL

5. WSDL Standard for describing web-accessible services
XML-based, machine processable language
Meaning (semantics) of the interface elements is only human interpretable
Abstract description level
Types, messages, operations, portTypes
Binding description part
Elements of the abstract interface are bound to concrete network protocols and message formats

6. Sesame RDF(S) repository and query engine
Part of an application or accessed via a web interface
Six different functionalities:
listRepositories
addData
clearRepository
removeStatements
extractRDF
performRQLQuery or perform RDQLQuery

7. Sesame – Modelling Requirements
Used by agents which will reason with the provided semantic data
Technical information for operational level integration must be captured (-> DAML-S)
Semantics of the offered functionality
A service can be specified by describing its parameters
A service meaning depends on its relation to other services – composition, algebraic properties
Ex:
Deleted statement is idempotent
Queering for a statement -> statement back as result
Delete statement + Queering for a statement -> null
Remove statement + add statement -> null operation

8. Specifying service semantic
Each Sesame functionality is a simple web service
Sesame is a complex service
Traditional Service Modelling
Adopted Modelling
One single service instance
Functionalities  processes
One profile instance for each functionality
Each functionality as a service

9. The Role and Use of Domain Knowledge
The Domain Ontology
A conceptual difference between tools and their functionalities
has functionality property – specifies the kind of functionalities a tool offers
Contains a set of terms needed to describe Sesame (Repository, User, Password)
Reasons for using domain concepts in DAML-S description:
Expressing the meaning of the offered functionality at the profile level
Describing “IOPE” both at the Process and Profile level
Enriching WSDL descriptions with domain Knowledge

10. Use of Domain Knowledge in Profiles

11. Profile to Process Bridge
Profile has_process Process
Profile IOPE ↔ Process IOPE
IOPE are treated as parameters of the Profile
IO parameters of the Process
PE simple properties of the Process

12. DAML-S and WSDL Mapping
ServiceGrounding builds the bridge between the ProcessModel and WSDL
Rules:
Each DAML-S AtomicProcess corresponds to a WSDL operation
Each input (output) of a DAML-S AtomicProcess is mapped to a corresponding message-part in the input (output) message of the WSDL
The type of each WSDL message part can be specified in terms of a DAML-S parameter (XMLS data type or DAML+OIL concept)

13. Conditional Inputs DAML-S does not support conditionals inputs
Solution: extend the Process ontology to support conditional inputs
ConditionalInput class bundles a Condition and an input
Inputs depending on external factors
Inputs conditioned by other inputs
Mandatory inputs -> the condition is always true
Optional inputs -> modelled as unconditional inputs

14. Complex Data Types
Complex data types have to be specified both at syntactic and semantic level
XSD is used to specify complex data types
Syntactic information easy to parse
Information has no semantics
DAML+OIL replace XSD definitions with semantic definitions
Difficult to represent complex syntax only with DAML+OIL
Useless for user that not understand DAML+OIL
Not all parts of a complex data type are interested semantically
Extend XSD types rather than replace them
XSD to specify the syntax of the output
Augment the type components with reference to corresponding DAML+OIL concepts
xsd:annotation

15. Conclusions
The goal of this paper was to asses the expressivity of DAML-S for certain service characteristics
DAML-S offers a useful set of terms for describing semantic web tools – but some extensions are needed
The given properties of Sesame triggered many of these extensions
Sesame combines a set of self contained services which can be used in any combination