Architectures for Data Access Services
Practical considerations for design of discoverable, reusable interoperable data sources.
AUKEGGS workshop, Edinburgh Sept 2005
Overview
Problem characterisation
An end-user’s perspective on “binding”
Component view of infrastructure
Discovery
Semantic mapping
“Minimal Unified Architecture”
AUKEGGS workshop, Edinburgh Sept 2005
Problem Characterisation
Starting from a (fairly) well understood position: Service Oriented Architectures
The “Publish-Find-Bind” model
Registry
ServiceClient
publishfind
bind
AUKEGGS workshop, Edinburgh Sept 2005
Problem Characterisation
“Binding” is actually a complex problem
Service protocols tell you what parameters are necessary
Data types tell you possible structure of queries
Content “domain” required to actually make meaningful queries
Standards (OGC, WSDL, WSRF) help
But fall short on describing content
AUKEGGS workshop, Edinburgh Sept 2005
Semantics of services
Are services “self-describing”?
Of course not! (c.f. Gödel’s incompleteness theorem)
But they can form nodes in a pragmatic epistemology
Self-consistent overlapping models of reality
Each model has utility
Ergo, services are usefully described by the framework in which they are found
AUKEGGS workshop, Edinburgh Sept 2005
ISO/OGC service framework
Just Web Services
Within a defined abstract framework
More useful than arbitrary “self-describing” services
Its not just REST versus RPC…
Its about external semantic framework
OGC gives us spatio-temporal semantics
Need to add our own frameworks to make content meaningful
AUKEGGS workshop, Edinburgh Sept 2005
Problem characterisation
During discovery, content is the primary search consideration.
Data types have structural and content domain aspects
Structural specification controls portrayal organisation (e.g. rows in a table, graphic geometry type)
Esp. navigation (how to find more info)
Content often needs translation
AUKEGGS workshop, Edinburgh Sept 2005
Problem characterisation
Content domain (vocabulary) and Feature Types are missing
Governance and technical implementation missing
But the glue we need!
Architecturally treat them as if they will be there one day
Any component can be brought “in-house” in the interim.
AUKEGGS workshop, Edinburgh Sept 2005
End User Perspective
Find a monitoring site representative of geography-of-interest
Request data for phenomenon of interest
Use it:
1. Portray it usefully
2. Record it
3. Reference it
AUKEGGS workshop, Edinburgh Sept 2005
Case Study
Water Quality Monitoring
Spatial Aspects:
Spatial distribution
Explicit relationships ( “end-of-valley” site monitors upstream phenomenon
Time
Phenomenon being measured
AUKEGGS workshop, Edinburgh Sept 2005
Implications
Client software has to chain queries against different FeatureTypes
Queries may need additional information
Eg. User specify which analyte
Presentation may contain navigation elements
Navigating through the Feature Type relationships
AUKEGGS workshop, Edinburgh Sept 2005
Views into data
Related Feature Types
Stations
Time-series
Station id
AUKEGGS workshop, Edinburgh Sept 2005
Demo
Run from laptop
SEEGrid demonstrator online
AUKEGGS workshop, Edinburgh Sept 2005
Application Architecture
Application Framework
Browser
Stylesheets
Bindings
Context
Layout
GIS data
Mapserver
WMS
WMS
Proxy
Internet
GetCapabilities
GetMapFeatureInfo
GMLresponse
Invoke{layout + context + area + application specific parameters (e.g. indicator)}
Oracle
Geoserver
Query constraints
Schemamapping
Time-series data
WFSquery
Query Map
AUKEGGS workshop, Edinburgh Sept 2005
Implicit architectural challenges
“Geography-of-interest” is a very complex concept:
Named entity (of a given type)
Location of entities where related features meet certain conditions
“all stations where turbidity recorded at > 1200 units”.
Topological relationships
Stations upstream of X
Spatial relationships
Nearest hospitals to Edinburgh
AUKEGGS workshop, Edinburgh Sept 2005
Component view
Gazetteers
Feature Type relationships
Explicit
Implicit in certain constrained Query Models
Grouping of different spatial, topological data sources
“Map Context” and other persistent bindings
AUKEGGS workshop, Edinburgh Sept 2005
“Query Models”
Identify mandatory terms
Constrain all critical axes so that the result set is predictably organised (e.g. time series of results for an analyte the same monitoring station => therefore graphable.
Bind “domain” to queryable properties
E.g. Collection date is Time, normalised to DD/MM/YYYY
Species observation service uses taxonomy from service X
AUKEGGS workshop, Edinburgh Sept 2005
Metadata types
cd CataloguedResourceTypes
CataloguedResource
+ type: ControlledVocab
«XMLDocument»OperationalMetadata
«NotDiscoverable»Harv estableServ ice
Discov eryMetadataBinaryObject
May be totally ingested into searchable slots, this may simply be a special case of XML document, or we could use native capabil ity.
Record that controls where other records and services can be harvested from
«NotDiscoverable»Harv estingRules
Tells how to handle XML document types on loading
«XMLDocument»Bindings
See RunTime bindings diagram
DataContributorDetails
«Discoverable»Organisation
«Discoverable»Activ ity
Each DC has a harvest location where additional harvest control records can be located.
AUKEGGS workshop, Edinburgh Sept 2005
Information Architecturepd Packages
«Catalogued Resource»Marine Profile Metadata
«CataloguedResource»Serv icesMetadata
Data Serv ices
«FeatureMetadata»DataQuality
ISO:19115
«CataloguedResource»PortrayalRules
Vocabularies
«CataloguedResource»DataAccessQueryModels
FeatureTypes
SWE:SamplingRegime
relationships between observations and operations that can be undertaken is a function of the Sampling Regime.
GML:Observ ationsAndMeasurements
Topic
«Catalogued Resource»Finder Queries
Finders bind othervocabularies using other metadata slots to a particular Topic
Bind vocabularies to attributes ofspecific data types, allowing a service to be meaningfully queried
«CataloguedResource»DataAcessServ ice
DataAccessServices are harvested from Service Capabilities and reflect actual data access points
«realize»
«realize»
«realize»
AUKEGGS workshop, Edinburgh Sept 2005
Systems Viewcd System Overv iew
Marine Catalogue WRS
Marine Catalogue DB
Harv ester
Classification Uitlity
Oceans Portal
QueryModels
Portrayal Resources
Vocab
Other Application
Data Access Serv ice
Taxonomy Serv ice
«artifact»
Operational Metadata
«realize»
«realize»
AUKEGGS workshop, Edinburgh Sept 2005
Service Typescd Serv ice Coherence
WFS
WMS
Database
WCS
«config»
Selection and portrayal
«config»
Object/relational mapping
FeatureType
GetFeature
GetMap
GetFeatureInfo
Feature
DescribeFeatureType
Cov erage
StyledLayerDescriptor
Filter
Domain
GetCoverage
«config»
Axis mapping
«realize»
«realize»
0..*