"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Discussion: Service Architecture Task Group

Also see Service Architecture Main pageSort

Go to Static GeoSciML Registry

Please confine discussions, arguments, flames, etc. to these pages. I will attempt to summarize occasionally any conclusions reached here on the main SA page. If anyone else feels moved to create a summary, please feel free.

-- BruceJohnson - 14 Mar 2007

Discussion Topics:

Service Standards

It seems to me that for the next attempt to build a testbed, we need to agree to some standards for both the services themselves and the data that's being served. Of course, I have some suggestions to get the ball rolling:

  • All GeoSciML services must return GeoSciML, where requested (particularly WFS services).
  • All GeoSciML services must be publicly accessible from a published URL.
  • All GeoSciML services must have a human-readable, descriptive 'title' in the configuration file. A small subgroup (BruceJohnson, Tomas Lindberg, and MarcusSen) is currently working on a proposal. We'll include it here shortly.
  • For each data layer type (geology, lithology, age, etc.) we need to agree on the feature type being served and a GeoSciML profile the data must fit.
  • We need to agree to standard requests that will be serviced and standard responses to those requests.
  • We need to agree on a set of projections that each service agrees to support

  • WMS services:
    • Maps should be built without outlines around mapped areas or around colored polygons (they look terrible at small scales)
    • Maps should be confined to the borders of the mapped area (don't overlap into an adjacent country, county, quad, etc. and don't color adjacent water)
    • We should agree on which level of the WMS standard we are going to support (1.0.0, 1.1.0, or 1.1.1)
    • WMS services should be able to provide images large enough to be displayed full screen on a reasonable sized monitor (several services are currently limiting their image size such that they fail in a client with a full-screen window on a 1200x1600 monitor)

OK, you get the idea. What else do we need?

-- BruceJohnson - 14 Mar 2007

  • We agreed on 1.1.1 because the latest version, 1.3.0 (the version ISO supports) does not include Legends and SLD.

-- EricBoisvert - 15 Mar 2007

GeoSciML Service Registry

Anyone have any ideas on where to start?

ebRIM (electronic business Registry Information Model) : http://www.opengeospatial.org/pressroom/pressreleases/655

There is a OGC profile : http://www.opengeospatial.org/standards/requests/29

-- EricBoisvert - 15 Mar 2007

I believe the WRON project (Water Resources Online Network?) here will be in need of a physical implementation of a registry service, and their timeframe is shorter than ours As with everything in this space Simon is involved and can probably elaborate more but, I'll see what else I can find out and post here. -- DalePercival - 15 Mar 2007

Conformance Testing

Anyone have any ideas on where to start?

An online validation service from one of the participants that can check an instance document against a schema? I have to develop something similar on a much smaller and much less complex scale for another project. On the surface this would appear to solve the problem of which version of a validator or a particular piece of software each of us were using. -- DalePercival - 15 Mar 2007

This is one aspect of the conformance. There are a bit more involved when implementing services. I can bet a belgian beer there is some ISO / OGC documentation on this.

In the mean time, I found this : http://www.opengeospatial.org/search/node/CITE .. maybe not exactly what are looking for because it's a lot about how people and organisations can ask the OGC certification. Maybe there are a couple of pointers in there..

-- EricBoisvert - 16 Mar 2007

OGC Web Service Standards Interpretation, Usability and Profiles

  • Which versions of standards to use
  • How to interpret parts of the standards which are unclear (to us)
  • Which subsets (profiles) of the standards to use when there are several possibilities
  • Are the standard interfaces fit for our purposes; working around deficiencies and suggesting future changes.

See WFSUsabilityIssues for some discussion of some aspects of the WFS interface which don't really support the types of queries we want to do.

for general discussion on service profiling mechanisms see https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/ServiceProfiles

-- MarcusSen - 09 Jul 2007

Conformance tests what are ServiceArchitectureTG task group deliverables

A ServiceDeploymentTG has not yet been set up but there has been some email discussion of the role of setting up conformance tests by the ServiceArchitectureTG task group and the administration of them by ServiceDeploymentTG and others. I've pasted in some email comments by SteveRichard below which provide some discussion points for defining the ServiceArchitectureTG task group's role (-- MarcusSen 26 Jul 2007)

I think we need some clearer definition of what kind of conformance tests we're talking about, and exactly what the Service Architecture TG needs to provide.

Basic schema validation for instance documents against GeoSciML.xsd is probably the simplest and most fundamental conformance test. There needs to be some sort of online service to which someone can send an instance file to and get a 'valid' or 'invalid' response, ideally with some sort of indication of what failed if the validation fails. Who builds and maintains this?

Any practical interchange operation (e.g. OneGeology) using GeoSciML is going to have to have some sort of associated profile/best practices document to guide data providers on how to make decisions where alternate encoding approaches would work, and help data consumers to know how to use the responses they get. Some items that need guidance would be: what elements to include in line vs by ref, how to interpret codespace attributes, are unique identifiers included and how, what sort of ISO19115 profile is being used, are there required elements or cardinality restrictions different from (but consistent with) the normative schema, what vocabularies are expected or required.

Anyone publishing data from their in house information system will be limited to putting the information they have in their GeoSciML documents, and will probably find they have information that doesn't fit nicely in the existing scheme.

Conclusion--conformance tests have to be defined at a service-definition level. Each service will probably need to have some sort of profile/best practices documentation, some 'normative' data sets (GeoSciML docs...), and operations that allow someone implementing the service to determine that their implementation properly executes the required service requests.

Questions-- does 'Service Architecture' consist of specifying what is required of a GeoSciML service-- e.g. some collection required requests, a transaction protocol, the existence of conformance test documents and operations, the existence of the 'profile/best' practice doc, etc. Or is the service architecture task group expected to actually define services (with all of the above elements) in sufficient detail that they can be implemented and used by the community?

Seems like if the Service Architecture group is going to define services at a developer level, these should be the services required for Test Bed 3--the two jobs go hand in hand. Test Bed implementers are then the guinea pigs implementing the services defined by SA TG.


Persistent Identifiers in GeoSciML Services

A proposal to test the use HTTP URIs as persistnt identifiers for features and classifiers is documented here: PersistentIdentifiersInGeoSciMLServices.
Topic revision: r13 - 15 Oct 2010, UnknownUser

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).