[utypes] Parsing utypes

[Markus Demleitner]

Hi Omar,

On Wed, Feb 08, 2012 at 05:15:34PM -0500, Omar Laurino wrote:
> > from VOTables.  Applications that do not understand a data model
> > easily preserve such data and metadata.
> > """
> >
> >
> Why only VOTables? Make an experiment. Take a compliant votable spectrum
> 1.03 file (e.g. one served by ned, like:
>
> [Metadata getting lost]
>
> Do you get my points now? The current IVOA practices for Data Model
> serialization are not interoperable.

That is of course correct, and fixing this is a major purpose of the
utypes spec, and that's why I think talking about serializations is
so important.

However, I'd frankly be elated if we could in the end make sure
VOTables can keep the info.  Other formats give extra bonus points,
though.

> I don't know why you keep ignoring my replies... I showed that utypes are
> not opaque in the current recommendations :)
>
> An example (and more to come)?
> 
> photdm:PhotometryFilter.SpectralAxis.Coverage.Location.Value
> spec:Spectrum.Char.SpectralAxis.Coverage.Location.Value
> 
> They point to the same concept defined in Characterization. An application

Hm -- we're entering philosphy terrain here.  One *could* say they're
two different things, because they define different roles in
different data models (that just happen to mean the same thing in the
real world).  

So far, I've understood that utypes should support the serialization
of *one* data model, where embedding, as it were, destroys the
identity of the embedded data model.  With this interpretation,
comparing two utypes case-insensitively, does indeed figure out
whether they refer to the same concept (in a single-DM-sense) --
that's what I've taken to mean "opaque".

Whether that's a good way of doing this ultimately depends on what
people want to do.

Full disclosure: My main reason for being interested in utypes is
that since the depreciation of COOSYS we have no good way of
specifying STC metadata in VOTables.  Anything that fixes that
situation in a way people will actually take up is fine with me.
Opaque (in the sense defined above) utypes IMHO help, but of course
admitting there's structure in there opens up quite a bit of
functionality that certainly would be desirable.  

So maybe we should really toss that opaqueness requirement overboard.
What does everyone else think?  Me, I'm 60% convinced at this point.

> Or, more easily, the file itself might declare the prefix and
> associate it with the relevant concept (e.g.
> photdm:PhotometryFilter.SpectralAxis -> char:SpectralAxis), which
> is, surprise surprise, my suggestion, if you read it :)
...which of course would mean that over time lots of such
declarations would pile up in every VOTable, right?  I'm not sure if
I like that, even more since this *is*, in the end, global
information that changes rather infrequently.  Hm.

> > in the registry.  If we agree to have one, it would be easy to
> > maintain it as a StandardKeyEnumeration in the utype standard's
> > registry record.
> 
> 
> If The Things are universally defined they should be maintained somewhere.
> You can't ask a new VO service developer to read all the IVOA documentation
> just to get the list of reserved Things. Note that reading all the Data

Ah, I'll need to chime in here -- the new VO service developer just has
a list of strings (the structure of which she doesn't even need to
understand) to embed in well-defined places.  Even the application
developer doesn't need much more (she may need to parse utypes and
juggle prefixes, though, if we go along with Omar's plans).  

The only people concerened with that global list of Things would be
standards authors.  I think they can be bothered to read a few
standards before they start writing one themselves...



(I'm keeping the following list of questions to encourage others
replying to add their opinions)

> > * Generation of utypes (how do we get from some DM to utypes?)
> > * Versioning (how do clients that care figure out the DM?)
> > * Typedness (is it ok to only talk about strings in the utype REC?)
> > * Serialization of structures of utype-value pairs in VOTable
> >  (e.g., would it be cool to push GROUPs as a means for embedding?)
> > * any other serializations (e.g., do we want to recommend a means for
> >  binding together utypes and FITS header keys?)
> 
> 
> As I mentioned we *must* do it, because at the moment we can't even do a
> trivial roundtripping with a model-unaware application. I have a
> suggestion, if anybody wants to hear about it.

Me, yes.  If I may make a wish: Omar, would you just draft your plans
in the document in the volute repository?  I'm afraid I'm much easier
convinced by documents in repositories than by mails, and version
control helps a lot when following changes and suggestions.

Thanks,

        Markus