content, format, ctype, or xtype ?

[Rob Seaman]

I agree with Roy - Good job Norman!

On May 12, 2009, at 7:16 AM, Markus Demleitner wrote:

> I'd be still much happier if there could be a separation of
> concerns like my understanding so far:
>
> (a) ucd: What's in the column?
> (b) unit: What's the unit of the values?
> (c) utype: What's the role of this column in a defined data model?
>
> plus, I'd wish,
>
> (d) content, ctype, representation, whatever: What representation  
> for a
>    value has been chosen?

- My immediate visceral reaction to all this metadata is that there  
are numerous use cases in which practicing astronomers are encouraged  
to manipulate their own data holdings into VO compliant formats. We  
are likely all skeptical that they will bother with even a fraction of  
this.

- The more left-brain response is that perhaps we aren't normalizing  
the data structures properly.  Shouldn't some of this complexity be  
built into the pertaining data model(s), for instance?

- Or are we sidestepping a responsibility to choose appropriate  
defaults?  Units can be forced into narrow options, e.g., RA can be  
required to be either the decimal degrees or sexagesimal hours that  
correspond to 99.9% of the use cases.  (And bizarre "12 34 56" triple  
columns would be recognized as being intrinsically non-compliant with  
remediation left to the responsible parties.)

- Or isn't it more appropriate to burden the programmers with the  
requirement to recognize a narrow range of formats?  After all,  
reasonable code will have to validate the inputs anyway - we can't  
just rely on somebody's metadata to be utterly truthful.  Does a  
string parse as a number - then it is floating point.  Does it parse  
as ISO-8601?

- And it seems like we have yet to even clarify what (a) means.  What  
does "What's in the column?" mean, precisely?  Does anybody have the  
URL to Tom McGlynn's screed on UCDs?

Rob