Hello UCD Fan's and Pro's,
the ongoing discussion seems very promising to me, and the experts certainly have a goog understanding of that's going on. Nevertheless I would like to make comments on three recurrent subjects. My point of view is perhaps obvious and trivial, but as UCD, and more generaly ontology, try to make implicit assumption became explicit, I felt free to post the following.
The points are related to the UCD handling,
the way of adding UCD,
and UCD usage at different levels.
I was very happy to read the following in Sebastien's doc.
"The hierchical tree is not fundamental -
it's merely a way of classification". What is actually very
important for me is the knowledge base represented by
the UCDs, which certainly describe very well, even if not
exhaustively the columns of astronomical catalogs.
The ways, different people want to look at this metadata
pond/container will certainly be differents.
But actually the UCD structure and even the name structure itself
does not promote or facilitate others point of view on this
fabulous metadata bank.
But as stressed also in sebastien's doc, "it is clear that
the definition of right roots does not exist, and is influenced
by the user's own needs".
It means that a static absolute and final UCD structuration
is not realistic, and so "different structures corresponding to
different views" of UCD must coexist.
It is one more argument in addition to a parametrized and atomic
definition of Descriptors.
2) Adding UCD.
As Patricio said, "the problem is not to add more UCDs", everbody
would agree on that, but it is certainly _how_ to perform
the metadata bank update, when _really_ needed.
A very strict and tedious approvment by an "expert group",
as proposed in sebastien's doc, is certainly not appropriate
for a lot of cases, where quick even instantaneous
response is needed.
Once more, migrating to parametrized atomic Descr (PAD?),
will perhaps facilitate their dynamic handling.
To clarify my point of view, perhaps a little bit too broad
and common, let's take an example.
Try to imagine a Web service which can create data on the flight and must be able to assign UCDs to these _dynamic_ data. A very simple example would be a data bank of SED or photometric data covering a very wide spectral range, and which can delivered a flux, mag, color or anyelse sensible combined data at whatever wavelength required by the user. This service don't want to register one predifine UCD for any data conmbination but needs only to parametrize the UCD and perhaps, in the most complex case re-organize the basic predifined atoms.
Then the atoms definitions and the combination rules allowed must be approved by an "expert group", but the parameter s and the combinations used can be freely adapted by each data provider, portal or anyelse service or tool.
3) UCD usage at different level
As already mention by sebastien and anita, any UCD
used as column description in one dataset can be used
as header or global metadata in another dataset,
and some times an association between these two uses
must be performed.
To my feeling the answer already exist in the VOTable
structure. UCDs exist in two class, FIELD and PARAM.
And it is obvious that they are specialization of a more
general class which could be called vardescr (variables descriptors).
In the particular case of PARAM instances, the values are
attached to the description, while for the FIELD
the data link is more loosely. Adressing this more general
class would certainly facilitate the association between
global/header metadata and column description.
The main problem is that UCD are historically concerned
with column descriptors and so cover very well this field
of interest but it is not obvious how exhaustive are the
existing UCD to cover the needs of global metadata
used in headers (Fits) or definitions (VOTable).
I hope that these comments are not out of scope, and that the expression of my feelings are not unpleasant to anybody.
Sincerely yours,
Pierre Didelon
Received on 2003-03-20Z15:25:43