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

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 • 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. Traditional Service Modelling Adopted Modelling Specifying service semantic • Each Sesame functionality is a simple web service • Sesame is a complex service • 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_processProcess • 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