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

[Martin Hill]

How can I resist?!

But seriously, you *can* in principle serialise anything to a table. 
It's not easy however to deserialise back from table to a non-trivial 
data structure.

It's easier to de/serialise to/from related tables (eg a relational 
database) using references between the tables as the 
association/aggregation links.  From your comments below I gather that 
VOTable 1.1 *could* do similar things using PARAM/FIELD/TABLEDATA.

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 that 
can marshall/unmarshall (read: de/serialise) a VOTable to an object 
model.  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.

Let's not reinvent the wheel...

 > 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

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


-- 
Martin Hill
www.mchill.net
07901 55 24 66