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-users 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 publish find 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ödels 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 Proxy Internet GetCapabilities GetMap FeatureInfo GML response Invoke {layout + context + area + application specific parameters (e.g. indicator)} Oracle Geoserver Query constraints Schema mapping Time-series data WFS query 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

AUKEGGS workshop, Edinburgh Sept 2005 Information Architecture

AUKEGGS workshop, Edinburgh Sept 2005 Systems View

AUKEGGS workshop, Edinburgh Sept 2005 Service Types