Ticket #389 (new issue)

Opened 13 years ago

Last modified 11 years ago

[DS][M] Exposing vars to user via CSML and CDML - name plus cell_methods plus coordinate?

Reported by: astephen Owned by: domlowe
Priority: required Milestone: NDG3
Component: COWS Version:
Keywords: DataExtractor Cc:

Description (last modified by spascoe) (diff)

The DX (and other) GUI needs to provide enough information about a variable so that the user can identify what it is. The name is not enough because:

  • you can have different cell_methods (CF-talk) on a variable (such as mean and std deviation)

But, even cell_methods might not be definitive. We need to consider what/how this stuff gets to users.

Change History

comment:1 Changed 13 years ago by astephen

  • Status changed from new to assigned

comment:2 Changed 13 years ago by selatham

  • Cc rkl added
  • Summary changed from [DS] Exposing vars to user via CSML and CSML - name plus cell_methods plus coordinate? to [DS][M] Exposing vars to user via CSML and CSML - name plus cell_methods plus coordinate?

Isn't this a vocabulary/ontology matter. Practically we are currently doing things with NetCDF and CF and CF standard names (would be nice). But isn't the issue much wider? I would ask for Roy's comments on 'Parameter Usage Vocabularies'. I think the BODC's new vocab/ontology should contain all neccessary semantic elements.

comment:3 Changed 13 years ago by rkl

This touches on an issue that I have raised, thought about, but have yet to address. Basically, as it stands alone the CF Standard Name is a 'discovery vocabulary', not a 'usage vocabulary' because in some cases there are other bits needed to fully describe the data value such as 'cell methods'. What is needed is a robust mechanism to serve CF standard names plus ancilliary information as a 'CF Usage Vocabulary'. What is needed is an ontology relating each 'Standard Name' to its cell methods and any other CF fields describing what the number is. This is not currently on my radar because I don't know enough about the details of CF (though I might have to learn in the next 2 months), but maybe falls into Alison Pamments's domain. Such an ontology could then be mapped to the BODC Usage Vocabulary semantic model giving us parameter interoperability (a twinkle in the eye rather than something planned in reality) and a really neat solution to Ag's problem (short_names for direct display with long, complete descriptions available for hover-text).

There is another issue in this area. What happens when an essential bit of the parameter description is part of the data rather than metadata (e.g. radiation wavelength for spectral data)? I have nothing to offer on this one!

The ontology I will build initially is concerned with discovery terms and only discovery terms.

comment:4 Changed 13 years ago by astephen

  • Summary changed from [DS][M] Exposing vars to user via CSML and CSML - name plus cell_methods plus coordinate? to [DS][M] Exposing vars to user via CSML and CDML - name plus cell_methods plus coordinate?

All comments appreciated. As ever I'm slightly more concerned with what goes out the door first. We already have a live Data Extractor showing Hadley Centre model output where we cannot fully disambiguate variable names unless we use:

  • variable name (be it short, long, standard etc)
  • cell_methods (i.e. averaging etc over what axes)
  • axis name(s)

And of course this is relatively useless unless you say what the axis is in more detail which could involve:

  • what is axis type? (time, lat, etc).
  • what is axis interval? (i.e. monthly means, daily means etc).

comment:5 Changed 12 years ago by selatham

  • Status changed from assigned to new
  • Owner changed from astephen to spascoe
  • Milestone changed from BETA to PROD Step2

Is this an issue in the WMS, WCS?

comment:6 Changed 11 years ago by lawrence

  • Keywords CSML removed
  • Component changed from T03_DataExtractor to ndg2

Moved to obsolete ndg2 components as part of ndg2 cleanup

comment:7 Changed 11 years ago by spascoe

  • Priority changed from desirable to required
  • Status changed from new to assigned
  • Component changed from ndg2 to COWS
  • Description modified (diff)
  • Milestone changed from NDG2 Cleanup to NDG3

This issue is well illustrated by the current HiGEM EDP service. The variable names are completely unrecognisable. It would be a big win to have at least a partial solution to this for NDG3.

Priority elevated.

comment:8 Changed 11 years ago by spascoe

  • Owner changed from spascoe to domlowe
  • Status changed from assigned to new
  • Description modified (diff)
  • Cc rkl removed

This was duplicated in #986 where Dom said the following:

The parameter names/titles exposed by some model datasets for WMS/WCS are meaningless (fairly obscure, and non-cf compliant). Modify CSML Scanner to allow for modification of these attributes in CSML documents.

Reassigning to Dom but we will discuss the best solution.

Note: See TracTickets for help on using tickets.