Data Model utype

[Markus Demleitner]

Hi all,

On Fri, Apr 16, 2010 at 12:38:39PM +0200, Mireille Louys wrote:
> You're right , better to have short Utypes so I would suggest :
>
> DataModel.Name instead of DataModelReference.Name for instance
Great -- I'll have that in the STC note coming up, then.

> I agree we do not parse Utypes , so 'stc:' in 'stc:AstroCoords' is not a  
> name space , but it gives the context  of the utype  .
> We could have it as
>
> DataModel.Prefix 
>
> if you prefer.
Hm -- I don't quite understand this.  What would the value of that
utype be?  Transmitting

stc:Datamodel.Prefix -> stc

doesn't help, does it?

> My take is that each datamodel should provide  a recommended versionned  
> Utype list , published in the IVOA
> so this prefix could work as a pointer to the utypelist document , in the 
> same way as the name space 'stc' points to the STC xml schema in an  
> instance XML document.
> in other words ,
>
> DataModel.Prefix can be mapped to DataModel.Uri DataModel.Uri could point 
> to the published Utypelist
Again -- I'm not quite sure I understand.  Why do you want to define
DataModel.Prefix?  By the requirement that utypes should not require
parsing, the prefix for stc utypes must *always* be stc and nothing
else.  The utypes

stc:AstroCoordSystem.href

and 

dm0:AstroCoordSystem.href

must have *no* relationship whatsoever unless we give up the "don't
have to parse" requirement.  To illustrate what I'm worried about,
I'd tend to believe I could have something like

dm0:Prefix -> stc  (?)
dm0:URI -> http://www.ivoa.net/xml/STC/stc-v1.30.xsd
dm0:AstroCoordSystem.href -> TT-ICRS

and have that equivalent to 

stc:Prefix -> stc  (?)
stc:URI -> http://www.ivoa.net/xml/STC/stc-v1.30.xsd
stc:AstroCoordSystem.href -> TT-ICRS

-- and that, I think, would be a grave mistake since users couldn't just
use string matching to figure out the values for roles in data
models.


> which allow then for an application to check the utypes properly
Let me try and describe what I think is "good enough" for that
purpose again:

(1) Each utype set (e.g., a group containing STC, but also maybe a
text file containing utype-value mappings) SHOULD define the data
model it is written against.  It does so in a utype-value pair
with utype <data model id>:DataModel.URI.

(2) If given, DataModel.URI SHOULD be a URL that, when asked for
HTML, should return human-readable documentation on the DM

(3) If not DataModel.URI is not given, the receiving application is
free to assume any data model.

This allows applications that care *very* strongly to check what DM
*version* they are supposed to understand.  The (at least) 80% of the
programs that just need some way to figure out "this is the error to
that coordinate, and it's in GALACTIC" can ignore this, and they are
even free to dump STC info into VOTables or somewhere else without
having to worry about URIs.

Admittedly, this means that we're not free to change the meaning of 
stc:AstroCoords.Position2D.Value2.C1, and we're not allowed to "fix"
the utype list and suddenly say "it's stc:coo.pos.c1 now".  But I
strongly believe that kind of stability is a definite *must* if we
ever want astronomers to take advantage of this kind of shallow
semantics.

If and when we get a fixed STC machinery, there's always stc2: (that
could even live happily togehter with stc:).

Cheers,

           Markus