+ All Categories
Home > Documents > Architectures for Data Access Services Practical considerations for design of discoverable, reusable...

Architectures for Data Access Services Practical considerations for design of discoverable, reusable...

Date post: 30-Mar-2015
Category:
Upload: breana-halley
View: 213 times
Download: 1 times
Share this document with a friend
Popular Tags:
21
Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.
Transcript
Page 1: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

Architectures for Data Access Services

Practical considerations for design of discoverable, reusable interoperable data sources.

Page 2: 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”

Page 3: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 4: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 5: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 6: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 7: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 8: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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.

Page 9: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 10: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 11: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 12: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

AUKEGGS workshop, Edinburgh Sept 2005

Views into data

Related Feature Types

Stations

Time-series

Station id

Page 13: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

AUKEGGS workshop, Edinburgh Sept 2005

Demo

Run from laptop

SEEGrid demonstrator online

Page 14: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 15: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 16: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 17: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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

Page 18: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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.

Page 19: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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»

Page 20: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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»

Page 21: Architectures for Data Access Services Practical considerations for design of discoverable, reusable interoperable data sources.

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..*


Recommended