Describing OGC WMS and WFS with the OWL-S Web Service Ontology Dr Kristin Stock Allworlds...
-
Upload
annette-bramlett -
Category
Documents
-
view
216 -
download
0
Transcript of Describing OGC WMS and WFS with the OWL-S Web Service Ontology Dr Kristin Stock Allworlds...
Describing OGC WMS and WFS with the OWL-S Web
Service Ontology
Dr Kristin Stock
Allworlds Geothinking, UKCentre 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
ServiceServiceGrounding
ServiceProfile
ServiceModel
presents(what it does)
supports(how to access it)
describedBy(how it works)
Domain Ontology (Feature Types)
Inputs, Outputs,Preconditions and Results
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.
OGCHttpGrounding
OGCHttpOperation
OGCHttpParameter
Domain QueryModel
OGCHttpConstraint
hasOGCHttpOperation
hasOGCHttpParameter
hasOGCHttpConstraint
hasDomainhasQueryModelhasDomain
CheckBox
InputBox OptionList
RadioButton
isA
Process:Parameter
groundsAbstractParameter
Children of Process:AtomicProces
s(for each WFS and WMS operation)
groundsAtomicProcess
has<OperationName>Inputhas<OperationName>Output
Meaning
PossibleValues DefaultValu
e
DataType
DomainMetadata
ValuesUnit
hasComponent
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.