200 likes | 433 Views
Describing OGC WMS and WFS with the OWL-S Web Service Ontology. Dr Kristin Stock Allworlds Geothinking , UK Centre for Geospatial Science, University of Nottingham, UK EDINA, UK. Introduction. COMPASS Project ( http://compass.edina.ac.uk/ )
E N D
Describing OGC WMS and WFS with the OWL-S Web Service Ontology Dr Kristin Stock AllworldsGeothinking, UK Centre for Geospatial Science, University of Nottingham, UK EDINA, UK
Introduction • COMPASS Project (http://compass.edina.ac.uk/) • OGC Standards focus on syntactic descriptions of web services. • Some recent work incorporates object semantics. • Nothing so far done on semantics of functionality. • We tried to fill this gap with OWL-S.
Why do this? • Web service ontologies are intended to assist with: • Discovery • Dynamic execution • Chaining • Automating the publish-find-bind model.
OWL-S • One of the dominant web service ontologies (cf WSMO). • The basic model: • Profile – advertises what the service does; • Process Model – describes the process that it executes; • Grounding – describes how it can be executed. • Inputs, Outputs, Preconditions, Results
ServiceProfile Inputs, Outputs, Preconditions and Results presents (what it does) Domain Ontology (Feature Types) ServiceGrounding Service supports (how to access it) describedBy (how it works) ServiceModel Inputs, Outputs, Preconditions and Results
GetCapabilities • Content of GetCapabilities mapped to OWL-S. • This process could be automated for WFS and WMS. • Augment with semantic links.
The OWL-S OGC Ontology (1) • Created an OWL-S OGC Ontology to describe the specifications. • Each implementation of a WFS or WMS imports the OWL-S OGC Ontology and creates instances.
The OWL-S OGC Ontology (2) • For WFS and WMS, the OWL-S OGC Ontology is quite comprehensive, because specs are specific – wouldn’t be so for WPS.
OWL-S OGC Ontology: What’s in it? • Classes for: • WFS and WMS specialised service; • The processes that a WMS or WFS may offer and inputs and outputs; • An OGCHttp Grounding and operations; • Connections between processes and the operations that implement them.
The Grounding • OWL-S has a WSDL grounding. • We didn’t use it because it’s XML, not OWL – doesn’t fit our architecture. • Could have applied the WSDL – RDF mapping but time limited. • Created a new grounding.
Children of Process:AtomicProcess (for each WFS and WMS operation) OGCHttpGrounding groundsAtomicProcess hasOGCHttpOperation OGCHttpOperation has<OperationName>Input has<OperationName>Output hasOGCHttpConstraint hasOGCHttpParameter OGCHttpConstraint OGCHttpParameter groundsAbstractParameter Process:Parameter hasDomain hasQueryModel hasDomain Domain QueryModel hasComponent Meaning DataType CheckBox isA RadioButton PossibleValues DefaultValue InputBox OptionList DomainMetadata ValuesUnit
How exactly does this describe the semantics? • IOPR describe semantics of functionality; • Process describes steps/branches/loops etc. (not implemented) • IOPR can be connected to concepts in a domain ontology; • OWL-S OGC ontology includes hasTopic to link service, feature type or layer.
Dynamic service execution • Grounding includes binding between operation parameters and ‘query model’. • This is information that can be used to dynamically generate form to ask user for input. • e.g. Which feature type they would like to query in WFS, layer in WMS.
What’s in the ontology for each web service? • Details from GetCapabilities, including: • Which operations are implemented; • Actual grounding (URLs) and query model; • etc. • Semantic hasTopic links; • You don’t have to repeat IOPR.
What did we find? • It’s very cumbersome. • Full implementation of OWL-S includes IOPR more than once (different purposes); • Difficulties with cardinality constraints.
How did we modify OWL-S? • Did not describe IOPR multiple times, but once with references, same for parameters. • New grounding. • Did not define IOPR in each instance ontology, just referenced.
It’s a limited implementation • Didn’t fully describe preconditions and results. • Didn’t fully model the complexity of some parameters. • Process model limited.
Conclusions • Full OWL-S implementation impractical. • OGC specifications make it easier to use OWL-S. • OWL-S can be used to support discovery and execution. • Didn’t test orchestration.
Questions or Comments? or contact me: kristin.stock@nottingham.ac.uk