Error column in VOResource->DM-Quantity <=> VOTable-PARAM

[Pierre Didelon]

Martin Hill wrote:

> How can I resist?!
> 
Don't! ;-)
> 
> But I question *why* we would even try.  As a 'hobby' exercise it might 
> be interesting to do in your spare time, but it's a waste of VO effort.
> 
> The 'existing standard' is an illusion: there are no existing tools 

I think that there is a small mis understanding here.
I spoke of tools in the sens of endusers tools like VOPlot, TopCat,
Specview... and it seems (to me) that you are thinking of programming
tools useful for software ingeneers (like us).


> that can marshall/unmarshall (read: de/serialise) a VOTable to an object 
> model.  

Isn't/can't STIL of starlink/uk a tentative of this kind of tool?

>So we would have to build a new standard onto VOTable to 
> represent object models, new tools, etc, whereas there are several 
> existing tools (eg castor) that will do this already straight to XML.

Can't castor with an xsd file handle properly VOTable?
At least the metadata (header) part of it?
> 
> Let's not reinvent the wheel...
OK! Once needed things will be defined, let's see if VOTable can't be used.
> 
>  > not surprising as VOTable is conceived as a generic container (even if
>  > tailored
>  > for table data), so generic description has corresponding structure in
>  > VOTable,
> 
> Hmmm well, really VOTable is a table container, and attempts are being 
> made to retailor it as a generic container.  The former is fine(ish), 
> the latter is going to require a large set of shears, special tooling 
> and a lot of patches... >:->
> 
> MC
> 
> (relatively light thunder, minor sparks :-D

Thanks,
Sincerely yours,
Pierre
> 
> Pierre Didelon wrote:
> 
>> Hi Roy,
>>
>> Roy Williams wrote:
>>
>> Snip
>>
>>>
>>> (2) Pragmatism
>>>
>>> Now we get a whiff of the UCD3 and ontology questions that we 
>>> discussed last
>>> year. Who will create and build all this fancy metadata, who will 
>>> write the
>>> software that reads it, and who are the clients that want to use it.
>>>
>>> So maybe I come round to agree with you. The most common "relationship"
>>> between table columns is one of univariate error estimate. So lets 
>>> just get
>>> that right and forget the rest. But if that is the philosophy, we should
>>> forget quite a bit of other VO-related "modelling" activities, right? 
>>> Maybe
>>> all this stuff about "Quantity" and "Observation" is just the PARAM 
>>> element
>>> in VOTable?
>>
>>
>>
>> Some part of VOTable are the equivalent of DM concept...
>> not surprising as VOTable is conceived as a generic container (even if 
>> tailored
>> for table data), so generic description has corresponding structure in 
>> VOTable,
>> but it is not only PARAM.
>> Let me try to explain my (personnal) point of view, hopping that I am 
>> not introducing
>> too much "noise" in discussion.
>>
>> For Observation François Bonnarel shows that possible "views" of the 
>> data model
>> can be serialised in VOTable format, but the full functionality of 
>> VOTable
>> is needed to represent it, and it gives only a partial excerpt of the DM.
>>
>> Concerning Quantity it is eveident that PARAM tag in VOTable can be 
>> seen as
>> a possible serialisation of basicQuantity (atomic quantity with one 
>> value),
>> with one PARAM in a VOTable even VOTable can be used as one possible 
>> serialisation of it,
>> I am not arguing that it must be the realisation of it ( ;-) martin ).
>> Admitting that, FIELD tag and corresponding column in TABLEDATA can be 
>> seen as vectors,
>> GROUP allow to associate them, TABLE can be used to serialised matrices,
>> and RESOURCE/VOTable as generic serialisation for N-Cubes.
>> It is a perhaps a too generic serialisation which do not force semantic
>> to be included always in the same way, but at least it gives a way of 
>> serialisation
>> which would works with an already existing VO standard...
>> For me VOTable is a _possible_ serialisation of quantity, but I feel
>> like an heretic saying that, beeing quite sure that DM people would 
>> not agree.
>> Moreover it has to be assed by DM group first, once they define what 
>> are the necessary
>> informations needed, so that all quantity informations can be 
>> serialised in
>> PARAM/VOTable format.
>> It has nevertehless the advantage to be an already existing standard,
>> with available tools in increasing number.
>>
>> pending lightning and thunderbolt... :-)
>>
>> Regards,
>> Pierre
> 
> 
> 

-- 
Pierre 
--------------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
--------------------------------------------------------------------------