"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"

Vocabulary Services

Contents

Related pages



Vocabulary services are, as we all know, a critical part of a distributed information framework.

Registries are too. Taking the ISO 11179 metadata registry "meta-model", we can implement using ebXML, or at least the ebXML Registry Information Model (ebRIM), and link vocabularies to the services, or specifically the metadata artefacts that allow services to be discovered and used.

Ergo, we have a need to implement some subset of vocabularies as ClassificationSchemes within our registry infrastructure.

"Point of truth" issues

Making these vocabularies available through a separate vocabulary server is possibly sensible, but we must maintain a coherent "point of truth" for managing these vocabularies. Thus, we need to automatically import vocabularies into the registry from vocabulary services, or vice versa, or both (for different vocabularies!).

given that many vocabularioes will be created through the process of registration of objects (lists of organisations, sensor types etc) we know that for at least some vocabularies, the registry is the natural point of truth.

for others, it would appear that:

* there may be ontological richness beyond what a classification scheme supports * we may want to prune the classification scheme to support searching against only those things classified - e.g. we may have one or two resources for specific species, and not want to import the entire linnaen classification scheme! * there will be established processes, tools and business logic around maintenance.

Implementation Options

Short term (MOTIIVE project)

So it appears we need to do some work for MOTIIVE project (since this will instantiate FeatureType Registers and exploit vocabularies from BODC's vocabulary services, and more in the long term:

  1. have both components enabled to import/export from each other
  2. Have a common vocabulary service interface, and make both components conform
  3. make clients capable of adapting to multiple vocabulary interfaces

Longer term needs

In the longer term we will have even more potential sources, particularly when addressing cross-domain problems. IMHO this makes option 1 less attractive. Option 3 would need to be supported by a common meta-model and registration of mapping/binding solutions so that a client could find out how to invoke and interpret the responses from an arbitrary vocabulary source.

Exploring this problem is a work item for a project I'm involved in here (Water Resources Observation Network) that has some emerging linkages with the UN, and will probably start with a similar testbed framework as MOTIIVE. BODC's vocabulary service will be one input into the analysis, as will work being done in the W3C and OGC SensorWeb stuff.

Interesting times ahead!

 
Topic revision: r2 - 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).