130 likes | 258 Views
WSDL Mapping to RDF/Semantic Web. July, 2004 London, England F2F. The requirement. 4.11 Mapping to the Semantic Web R070 The WG specification(s) MUST allow providing a mapping from the description language to [RDF]. (From the Charter. Last revised 11 April, 2002.) Must allow ? Ok, done.
E N D
WSDL Mapping to RDF/Semantic Web July, 2004 London, England F2F
The requirement • 4.11 Mapping to the Semantic Web • R070 • The WG specification(s) MUST allow providing a mapping from the description language to [RDF]. (From the Charter. Last revised 11 April, 2002.) • Must allow? Ok, done
Semantic Web Description Languages • Expressed in KR/logic based formalisms • OWL, F-Logic, General First Order Logic, Situation Calculus, PDDL • Thus, generally aim at supporting logical theories about the services • Satisfiabily and entailment considered key • Major current contenders • Heading for convergence: • OWL-S (OWL and Sitcalc based) • WSMO (F-Logic based) • SWSL (Lots and lots and lots of things) • Others: various “straw proposals”, WSDL-S, WS-Arch ontologies • Some industry uptake and interest • E.g., Fujistu moved end user research project to R&D
Language Choices • Within W3C • RDF, RDFS, OWL Lite/DL vs. Full • With momentum • F-Logic, SWRL, FLOWS (SWRL ++) • Not all are largely compatible • Restrict to a subset of RDF/RDFS that’s roughly common • Not as useful, but much less work • Aim for a fuller ontology in OWL DL • But have a dumb down strategy
Modeling choices • Model the component model in RDF & OWL • E.g., have a class wsdl-ont:Component and wsdl-ont:Property • Then, relate Components to Properties via a predicate, i.e., “contains” • Map the component model to RDF & OWL • Components are individuals, and properties are rdf:Properties • Gets away from the container metaphor • Definiately not mapping the XML or Infoset • If anyone produces a complete mapping of the Infoset and Schema components, this comes free
Example:targetNamespace • targetNamespace • The components directly defined within a single Definitions component are said to belong to the same target namespace. The target namespace therefore groups a set of related component definitions and represents an unambiguous name for the intended semantics of the collection of components. The target namespace URI SHOULD point to a human or machine processable document that directly or indirectly defines the intended semantics of those components. • Some choices • targetNamespace URI designates the RDF/OWL document or ontology • targetNamespace URI names the Definitions individual • There must be a property targetNamespace on the Definitions (and on other things): • Exclusively, or for redundancy • May be able to infer various sorts of component equivalence
Another example: Types • Simplest: use URIs to identify all visible, legal types • Use enumeration classes to constrain the values of, e.g., the element property • Unclear what happens if operation member of more than one interface in more than one definition • Essentially no embedding • More complex: try to embed type/element/etc. definitions when possible • Please no: create mapping of XML Schema • Little hope of interestingly preserving semantics • Lack of r-transitive closure and well foundedness decisive? • Could try to add such to OWL (prior work by Calavenese et al) • Er…this is the XML Schema working group, yes?
Aligning with WS-Arch • WS-Arch mentions operations, and defines “operation” in the glossary • But no top level concept in doc or ontology • It has “Action” • And “Service task” • MEP seems right • Do we/can we want to fix or just extend the WS-Arch ontologies?
Grounding • OWL-S (among others, e.g., WSMO) ground processes in operations • Might seem backwards to some folks! • Processes are executable (or executing) thingies • Could be software, could be a robot, could be a committee • Processes generally have (worldly) effects • Often used as planning operators • Fairly significant support in manufacturing (PSL) • Beyond what WSDL says now • But pretty common way mappings are used • Providing supports would be useful and not hard
Roundtripping • Probably infeasible, if not impossible • Can’t roundtrip components to/from XML • E.g., include/import information is lost • Documentation has no component • RDF&OWL are fairly free • Tolerate missing or merged information • Can derive information implicit in the base • Including merges • Expect lots of “flat” aggregation • People will want to author and programmtically build WSDL from RDF • Not sure how far to go here with advice • Even selecting chunks of RDF to embed seems hard
Example: OWL-S PEs • OWL-S 1.1 allows specs for preconditions and effects • Conjunctions of “SWRL” atoms (RDF triples with subject and object variables) • Associated with a process • Thus, often with an operation • Used to express side constraints on engagement • E.g., ?x rdf:type ValidCreditCard & ?x hasLimit ?y & ?y > $500 • How to (generically) translate to WSDL? • Ideally want them grouped with operations • Require/encourage defining extentions with mappings? • Will include (some thing like this) as example appendix
Some references • OWL-S (1.1): http://www.daml.org/services/owl-s/1.1B/ • WS-Archt: http://www.w3.org/2004/02/wsa/ • WSMO: http://www.wsmo.org/ • SWSL: http://www.daml.org/services/swsl/ • PSL: http://www.mel.nist.gov/psl/ • WSDL-S: http://lsdis.cs.uga.edu/lib/download/WSDL-S.doc • Opt: http://cs-www.cs.yale.edu/homes/dvm/papers/opt-manual.pdf • OWL-S API: http://www.mindswap.org/2004/owl-s/api/ • Task Computing: http://tc.flacp.fujitsulabs.com/
Cont: targetNamespace • May be able to infer equivalence (perhaps only in OWL Full) <owl:DatatypeProperty rdf:id=“name”/> <owl:DatatypeProperty rdf:id=“targetNamespace”> <owl:ObjectProperty rdf:id=“qname”> <!--Snip axioms setting the range to a clas Qname which has exactly one name and targetNamespace--> <owl:Class rdf:id=“Interface”> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource=“#qname”/> <owl:cardinality rdf:datatype=“&xsd;nonNegativeInteger”>1</>