Hi John,
Yes, there is a URL of the form:
http://vocab.ndg.nerc.ac.uk/list/GGS1/current/
that returns all the flags (currently only three as we have yet to fully populate the vocabulary).
Note the term 'current' in the URL. This specifies that the current version should be served. However, if you want to be absolutely sure the external definitions and the internal reference match, then you can explicitly specify the version number.
Compare and contrast two version of the GEBCO flag list using:
http://vocab.ndg.nerc.ac.uk/list/GGS1/1/
and
http://vocab.ndg.nerc.ac.uk/list/GGS1/2/
Cheers, Roy.
-----Original Message-----
From: John Caron [mailto:caron at unidata.ucar.edu]
Sent: 27 October 2009 13:17
To: Lowry, Roy K
Cc: martin.juckes at stfc.ac.uk; cf-metadata at cgd.ucar.edu; Weatherall, Pauline
Subject: Re: [CF-metadata] Dealing with large numbers of flag values innetcdf cf
Lowry, Roy K wrote:
> Hello Martin,
>
> There is another possible solution to your problem, which we are looking at for dealing with a data source flag to be used with the GEBCO bathymetric grid. This is to put a URI base into an attribute that when concatenated with a flag values gives the flag definition from a vocabulary server. For example, having a flag_definition attribute like:
>
> URI_base='http://vocab.ndg.nerc.ac.uk/term/GGS1/current/'
>
> For a flag value of 1, the resulting URL is:
>
> http://vocab.ndg.nerc.ac.uk/term/GGS1/current/1
>
> which is a live NERC Vocabulary Server URL returning the flag definition attributes in a SKOS document.
>
> I appreciate that this moves away from fully self-contained CF files and that a standardised syntax for the URI base encoding is required, but I think this provides a scalable solution to the flag definition problem.
>
> Cheers, Roy.
Hi Roy:
If I was an application trying to use this feature, i would like to be able to download all the possible values for this flag enumeration with one call to your server. Is that possible?
I guess the other concern with external tables is ensuring that the writer and the reader really have the same table. Is there some way to ensure that?
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Tue Oct 27 2009 - 07:59:02 GMT