Re: [Plastic-devs] spectrum load message
Brought to you by:
johndavidtaylor,
thomasboch
|
From: Mark T. <m.b...@br...> - 2006-09-14 11:52:10
|
On Thu, 14 Sep 2006, Noel Winstanley wrote:
> Just trying to implement this now.
>
> The SSAP responses I see coming back from current services seem to do
> a good job of annotating their columns with UCDs. However, utypes are
> either incomplete or utterly missing.
>
> > the spectrum. The entries of this map take the form of
> > utype->value pairs, where the keys (utypes) are as defined
> > in the SSAP specification, e.g. "Access.Format" for MIME
> > type. As many or few of these entries as are known may be
> > filled in.
>
> would UCD->Value pairs be acceptable to everyone?
Probably time for me to bring up a complication I left out of my
original proposal (on the grounds that I'd see how it was going down
before I got to the nitty gritty).
As you say, SSAP as currently practiced seems to be mostly UCD-based.
I'm not sure to what extent this was ever standardised.
The real-soon-now SSAP V1.0 standard, following the real-soon-now
Spectral Data Model V1.0 standard, talks in terms of Utypes
(which is probably the Right Thing to do). No doubt our grandchildren
will invent SSAP v1.1+ to be based on VoTypes or something.
Whether that's true or not, different versions of the standard will
define more or less grossly different usages of actual utypes/UCDs.
So exactly what version of SSAP we're using determines what's the
right key-value pairs to pass in the metadata map, and what these mean.
Four possible solutions:
1. Have an additional parameter which names the identity of the
standard which defines what the keys in the map are
(e.g. "SSAP1.0" (which means they'll be utypes as per the
SSAP v1 document) or "SSAP-pre1.0" (which means they'll be
UCDs as per the existing practice) or something).
Probably these IDs ought to be URIs really.
2. Have one map for UCDs and another one for Utypes.
3. Prefix UCD keys with "ucd:" and utype keys with "utype:",
and put them all in the same map.
4. Just stick all the UCDs and all the utypes, or both, or neither,
in the same metadata map, and figure that software can probably
guess which is which when it sees them.
(1) is the most rigorous, and tackles the case of utypes whose semantics
change between different versions of the standard. (2-4) ignore that
concern. Am kind of tempted to plump for (4) following the "bit scrappy
but it'll probably do the trick" PLASTIC philosophy. Anyone else?
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|