Characterisation draft

Anita Richards amsr at jb.man.ac.uk
Mon Sep 11 11:02:38 PDT 2006


Thanks Mireille and Jonathan for comments.

Jonathan: - good point, does this cover it:

A controlled vocabulary will be offered for unit and coordsystem for Space 
and Time and related axes as described in STC
but if additional axes are not yet satisfactorily covered then a 
units/coordsystem in common use should be specified.

I will comment on the Spectral model tomorrow - I like the tabulation of 
elements, though - Mireille/Francoise, is it possible to generate 
something like that and I can annotate it? (preferable ascii or latex? but 
I guess Open Office might handle a word-type tabular doc.  Or I can 
generate my own list from the schema?

Mireille:
>
> As you know , there are 2 strategies to build up the XML schema: one that 
> gathers the axes first , and then the properties along each axis, like 
> coverage; another one that groups the metadata by properties and describe 
> them in a sequence along the various axes.
> For the moment the Axisfirst strategy is more developped. But in both cases , 
> we will need to distinguish Axis on one hand and the properties (Coverage, 
> ...) on an another.
> So I would suggest to separate the requirements of Axes from the Coverage 
> ones like this:
>
> AXES ( in the schema , described by CharacterisationAxis, AxisFrame, ...)
>

Um, sorry, I am not quite clear, is this an additional explaination? I 
can't quite fill in the dots....


>> Support 'should' be given, otherwise it defaults to Bounds, if present.
> 	Here we have defined Support as beeing the area or interval where we 
> know measurements have effectively be taken. If an application follows this 
> definition, for example, computing statistics on pixel values within the 
> Spatial.Support, the result with Support defaulted to Bounds will be 
> inconsistent.

I guess I am thinking that people would not bother to give support if it 
was identical to bounds.  Defaults are always dangerous and the user 
should be aware when they have been used but sometimes they are the only 
way to provide data.

> I would prefer that Bounds should be defined if Support is given.
> May be too restrictive for Data providers???
Or too complicated - too many 'if this, then that, if not...' but I don;t 
mind saying that for now, if people get confused I think that we will ahve 
to change things.

>> If Resolution is present:
>> You 'must' give resolutionRefVal (i.e. Location)
>> You 'should' give resolutionBounds (default is resolutionRefVal)
>> 
> If the resolutionBounds is not known, I would avoid to give any value and let 
> the application interpreting the Xml description , to look for 
> resolutionRefVal which is a 'must' field. Implicit default values may be 
> badly documented and generate side effects.

Agreed, I meant to say at the beginning of my 'long mail' that all 
defaults would be applied by software agents using Char, not hard-coded 
into each instance of Char.

>> You 'should' give the ErrorRefVal (typical value i.e. Location)
>> You 'may' give the ErrorBounds for uncertainties which vary along the
>> domain of the axis
>> You 'may' give an ErrorMap (as a URI) to describe the variation of
>> errors with location.
>> 
> I thought there could be cases where the ErrorBounds is more usefull than the 
> ErrorRefval, when the Error have extreme values and the average error as 
> ErrorRefVal does not bring very much.
> So it could be that ErrorBounds is provided , and not ErrorRefVal. not 
> realistic???

True in some cases, but on the other hand I suspect that some software 
will only be able to handle a single value for the typical error (e.g. 
'give me all data with astrometry better than 10" ').  Defaulting to the 
mid point of the bounds would not work in very many cases here (e.g. if 
someone gives the noise extrema as the bounds for a radio map, the mid 
point is close to zero as noise can be -ive); better that the data 
provider gives the typical value.  Open to counter-examples, though.

I agree with all Mireille's other points.

thanks

Anita


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AstroGrid Astronomer
MERLIN/VLBI National Facility, University of Manchester, 
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. 
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).



More information about the dm mailing list