Beyond simple features: Do complex feature types need complex service descriptions?' B.N. Lawrence (1,2), D. Lowe (1,2), S. Pascoe (1,2) and A. Woolf (1). (1) Centre for Environmental Data Archival, Rutherford Appleton Laboratory, STFC; (2) NCAS British Atmospheric Data Centre'

Outline Motivation NDG Portal Link Types Standards Experience Futures

Scientific Data and the Web Scientific Data Complex feature types. Complex workflow. Reuse wanted, but within the “science” community and between science communities? Web 2.0 etc RESTful Scalable Reusable. SIMPLE!

State of the Art in the Grid World Create a new service using the Introduce integrated development environment, defining operations and resource properties, folding in required functionality (e.g., security, notification), and selecting types from both base types and predefined libraries. (Using gRAVI we can also encapsulate executables.) Publish this service into registries (GT4 index services). Discover available services. Compose services into workflows, e.g., via the use of Taverna, which thanks to recent work by Wei Tan and Ravi Madduri (and much help from the Taverna team) can now invoke GT4 services. Deploy and publish the workflow in turn … (Ian Foster: But: GLOBUS JAVA (Python?) Not an “interoperable stack” (which is not to say that it is in any way less impressive) …. HARD … What if I want to use ENVIRONMENT-A LANGUAGE-B REGISTRY-C And still use catalogues, workflow Orchestration (or even build a hardwired client that does the first of these?) … in an interoperable manner? OGC and the WEB of course! STILL HARD

Portals and Services Deployment issue: Services deployed remotely Portal aggregates data descriptions ( EBRIM model of data+service descriptions+associations not yet deployable but even if it were, much of what follows would apply for auto generated associations) Portal Client needs “shopping cart” functionality before handing over to service client Service client may or may not be colocated with portal/catalogue!

Catalogues (type 1) Metadata! Not directly useful to client software! (Great for humans)

Catalogues (type 2) Note: 1)Link- type icons 2)Metadata and data links.

How do we decide to show what services work? How do we pass the right information to those services? HARDWIRED!

Links and Link Descriptions NASA GCMD DIF: how does a catalogue client USE these links? Needs to parse them (I.e. understand the semantics of the link type). ISO19115: even less utility for USING the links. ATOM Syndication: Semantics of link meaning, but relies on a mime type for the link-type. Not much use for services.

Sadly, not much better: what we have in MOLES (today), allows us to to do more than the syntax (mimetype) and add the featureType.

ISO Services “An implementation of a service may be associated with a specific dataset or it may be a service that can be used to operate on multiple, unspecified datasets. The first case is referred to as a tightly-coupled service. The second case is referred to as a loosely-coupled service.”

Discovery Portal Data Provider 1 Data Provider 2 Client DIF OAI-PMH

Service Description: Option 1 Portal Data Provider 1 Data Provider 2 Client Capabilities WMS GetCapabilities

Service Description: Option 2 Portal Data Provider 1 Data Provider 2 Client WMC HTTP GET

Visualise Portal Data Provider 1 Data Provider 2 Client Image WMS GetMap

Portal Visualisation From Web Map Context OpenLayers WMS Client

Layer Model differences WMC Layer + queryable [required] + hidden [required] WMS_Capabilities Layer + queryable [default=0] WMC LayerList 1..* Similar differences exist in

WMS Service description flaws 1 Capabilities document per service leads to bloat as service expands Web Map Context not designed as a service description –captures (and enforces) more information than necessary –layer model differs from WMS Capabilities

OGC WXS - tight coupling Dataset 1 WMS Dataset 1 WCS Dataset 2 WMS Dataset 2 WCS Dataset 1 WCS Dataset 2 WCS Resource centric Loosely coupled

Loose coupling: CSML features with plotting service

Futures Better Link Descriptions RESTful (i.e OGC services should be recast!) Packaged up for multiple granules and services per catalogue entry! OAI-ORE? Machine readable service descriptions OWL-S?