Defaults in STC

[Anita Richards]

Thanksfor that clear explanation Guy, and I agree that we should obey xml
conventions.  I will give an example to test whether using annotation is
going to work:  This is different from my original example where data are
inadequately described; this is an unavoidable situation:

1) If you have continuum data then velocity may be irrelevant and hence
you might want to omit everything related to that (e.g. velocity reference
frame) from appearing in an xml document, such as something to be filled
in by the person registering the data collection.  This is what I was
thinking of as 'not applicable'. Could some mechanism (?style sheet?) take
care of that, i.e. read the annotation? As discussed in Registry meetings,
it is a serious concern that data are not being properly described because
people find the forms too initimdating - and that includes VO people.

2) If you have a spectrum containing multiple lines  then the velocity
reference frame metadata may
all be there but you can't allocate rest frequencies and reference
velocities until you ahve identified the lines.  Here 'Unknown'
(represented as Guy suggests) shouldn't remove the other velocity
metadata.

Maybe these are trivial problems to solve, in which case don't worry about
doing it blow by blow until we have a real example, I just thought that I
would check, though.

thanks
a


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO 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).


On Mon, 11 Oct 2004, Guy Rixon wrote:

> Anita,
>
> XML distnguishes a value, an empty value (i.e. nothing between the start and
> end tags of the element) and a null (via the nil="true" attribute).  It
> doesn't distinguish "uknown" from "not applicable", nor do relational
> theory and DBMS products. We should be cautious of introducing distinctions
> not supported by the technology.
>
> AFAIK, "unknown" is supposed by the theories to be represented by a null. "Not
> applicable" would also be represented as a null in a relational schema. In a
> hierarchical schema, as in XML, it might also be represented by a variant
> schema that omits the inapplicable elements; i.e. if we have elements that are
> only sometimes valid, then we should use substitution groups to eliminate the
> invalid cases.
>
> I'm particularly keen to protect the integrity of the XML schemata. If our
> schemata are clean, then we can expect some support from third-party tools and
> our use of web services is easier. If we make all kinds of special
> arrangements, then our schemata are corrupt and may not work where we need
> them to. To this end, we should not allow authors to write "unknown" where an
> number is expected.
>
> I suggest this:
>
>  1. Any omissible elements should be marked nilable="true" in the schemata;
>     this is part of the modelling.
>
>  2. Any omitted elements in an instance of the model should be made null:
>     either a relational null or nil="true" in XML.
>
>  3. If we need to distinguish kinds of null then, in XML at least, write an
>     annotation tag with an English note.
>
>  4. If we need our programmes to distinguish different kinds of null then,
>     in XML, put an appinfo element inside the annotation element, the former
>     containing a code for the type of null.
>
> Cheers,
> Guy
>
> On Sat, 9 Oct 2004, Anita Richards wrote:
>
> >
> > Thanks Guy,
> >
> > Yes, we should conform to XML standards where applicable.  However in some
> > cases (probably not here, but e.g. in the Registry) it is useful to
> > distinguish between 'unknown' and 'not applicable' - or does XML do that,
> > too?
> >
> > cheers
> > a
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > Dr. Anita M. S. Richards, AVO 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).
> >
> >
> > On Sat, 9 Oct 2004, Guy Rixon wrote:
> >
> > > "Unknown" is, technically,  a null value.  XML has a specific way of
> > > expressing nulls: the nilable attribute in the schema and the nil (Sp?)
> > > attribute in the instances.  I suggest that we use this rather
> > > than just writing a value of "Unknown".
> > >
> > > On Thu, 7 Oct 2004, Anita Richards wrote:
> > >
> > > > > There are two kinds of uncertainties, especially for historical data.
> > > > >
> > > > > One is "I don't know exactly when this plate was taken - it was in
> > > > > 1925 or 1926".
> > > > > In principle, the observing time range, coupled with the observatory
> > > > > location, should give one a huge uncertainty in Doppler velocities, so
> > > > > no special provisions are needed.  And inaccuracies in, say, positions
> > > > > can be handled through the error elements.
> > > > >
> > > > > The other is "unknown": "I don't know whether this velocity is radio
> > > > > or optical definition, etc".
> > > > > I think the only reasonable way to handle this, if we must, is to
> > > > > allow "Unknown", "Not available", or something like it, as an allowed
> > > > > value.  It does put the bruden on the user to figure out (a) whether
> > > > > the data are still useful, and (b) if needed, what would be a
> > > > > reasonable guess for a default.
> > > > >
> > > > > So, somewhat reluctantly, I am leaning toward accepting the concept of
> > > > > "Unknown" as allowed value for a number of coordinate system elements.
> > > > > If I understand your previous message correctly, you would agree with
> > > > > that solution.  Correct?
> > > >
> > > > Thanks, yes, that is all exactly what I was trying to say, with the added
> > > > proviso that (as you mention in the original document), e.g. velocity
> > > > convention = "unknown"  would cause problems for software using the model
> > > > to deduce redshift from velocity _unless_ the application software
> > > > intrpreted "unknown" as e.g. optical convention and added the appropriate
> > > > error; knowing a redshift to a low accuracy might still be very useful.
> > > >
> > > > That would be outside the province of the STC model but is something whcih
> > > > people writing applications could take care of.  Does that sound sensible?
> > > > (i.e. caveat emptor, and your model stays pure :)
> > > >
> > > > cheers
> > > >
> > > > a
> > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > Dr. Anita M. S. Richards, AVO 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).
> > > >
> > >
> > > Guy Rixon 				        gtr at ast.cam.ac.uk
> > > Institute of Astronomy   	                Tel: +44-1223-337542
> > > Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
> > >
> >
>
> Guy Rixon 				        gtr at ast.cam.ac.uk
> Institute of Astronomy   	                Tel: +44-1223-337542
> Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
>