Error column in VOResource -> metadata standardization

[Pierre Didelon]

Hi Tony,

on the god path? at least some mutual  understanding reached!

Tony Linde wrote:

> Hi Pierre,
> 
> I agree in principle to the levelled approach (after ten seconds thought :)
> ).
> 
> What we must have is some XMLSchema based metadata representation that is
> common across all VObs components. This ensures the use of standard tools
> and mechanisms including the ability to state a block standard and then
> refer to it via a namespace. 
> 
> And namespaces is probably the way to get to your levelled approach: the top
> level are the standard IVOA namespaced metadata blocks; the next level will
> use parts of these standards and perhaps add certain extensions; the third
> level will be whole new blocks perhaps.
> 
> How all this might work I don't know - the discussion and trials need to
> happen now - but we've got to dump the present way of representing metadata
> in VOTable because it is a dead-end (with a 100m cliff beyond!).
For level 1 (as I discribed it) Registry group has to predefine it needs
and appropriate data structure.
But for level 2 (generic data structure) I don't see any technical
obstacle/impediment to use VOTable as metadata reservoir.
may be waiting quantity... or the miracle! ;-)
> 
> Cheers,
> Tony. 
> 
> 
>>-----Original Message-----
>>From: Pierre Didelon [mailto:pdidelon at cea.fr] 
>>Sent: 19 May 2004 12:59
>>To: Tony Linde
>>Cc: 'Doug Tody'; registry at ivoa.net
>>Subject: Re: Error column in VOResource -> metadata standardization
>>
>>
>>
>>Tony Linde wrote:
>>
>>
>>>I completely agree, Doug. We should standardize on what we 
>>
>>can agree 
>>
>>>as a common standard - via the DM effort.
>>
>>Which will be materialised in a precise data structure in a 
>>specify format (XML specific or whatever else) with precise 
>>specificaly define ("semantic"?) content.
>>
>>>But any extensions should follow some
>>>standard extension mechanism
>>
>>Why not, in this case, using a generic data structure (FITS 
>>header, VOTable header, or whatever else at group 
>>convenance), to allow generic look up tool, visualisation and 
>>search, and all possible generic behaviors/handling allowed 
>>by this structure.
>>
>>
>>>so that, as you say, they can at least be seen  by users or included 
>>>and passed on by applications.
>>
>>generic structure would certainly allow this.
>>
>>So you can handle information/metadata like a three level cake;
>>- the first one having precisely defined structure AND 
>>content (semantic?) which covers the 'most' common and 
>>important part, fully searcheable and directly operationnal 
>>for processing and analysis
>>- the second one having a defined structure but a free 
>>content, less searchable or harvestable, but nevertheless 
>>searchable...
>>You can always imagining and code a search looking for a 
>>certain value of a Fits keyword list.
>>- and even a third one with a free stucture and content; i.e. 
>>proprietary format in the sens of data producer specific 
>>format, this one non-searcheable and perhaps even not 
>>vizualisable, but which can be propagate to user, and if he 
>>knows how to handle it, it could be usefull for some of them.
>>
>>You can even imagine a standard process to promote some 
>>information from level 2 to level 1; create a new piece of 
>>info (structure and content) at level 1 and process (in a 
>>generic way?) level 2 structure to feed newly created level 1 
>>piece of info.
>>
>>Is this silly, already in the reflexion domain or completly 
>>out of subject?
>>I must admit that I din't follow the discussions on this list 
>>very accuratly, only keeping an eye on it, so forgive me any 
>>non-appropriate intervening.
>>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
--------------------------------------------------------------------------