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

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 23.02.2019

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 23.02.2019

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 23.02.2019

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 23.02.2019

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 23.02.2019

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 23.02.2019

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 23.02.2019

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 23.02.2019

Use of Domain Knowledge in Profiles 23.02.2019

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 23.02.2019

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) 23.02.2019

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 23.02.2019

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 23.02.2019

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 23.02.2019