>>>>> - It seems to me that VOThing is unlikely to be embraced as a name.
>>>>> Suggestions? Perhaps this facility should exist underneath VOEvent
>>>>> itself in some fashion. Other VO projects needing access would
>>>>> then
>>>>> simply reference us in return.
>>>>
>>>> Remember: I purposefully used this terrible name to emphasize the
>>>> need
>>>> for a VO-wide solution. How about "VOConcept"?
>>>>
>>>> It seems that the UCD community will also have to address the
>>>> usefuless
>>>> of the present UCD usage: one requires a separate parser to
>>>> disentagle
>>>> what "em.X-ray;phot.count;obs.image" is supposed to mean, whereas
>>>> parsing something like
>>>>
>>>> <group><ucd>em.X-ray</ucd><ucd>phot.count</ucd><ucd>obs.image</
>>>> ucd><group>
>>>>
>>>> would fall out of the normal processing of the XML document with no
>>>> real additional effort.
>>>
>>> Possibly, but that makes UCDs tied to a particular representation
>>> (XML),
>>> which I don't believe should be the way to go. If UCDs are to be used
>>> widely, they should remain as independent of the "way to write them"
>>> as possible. Some people (include me) would like to use UCDs in a non
>>> XML context, and build our own tools. Furthermore, which usages do
>>> you
>>> have in mind where a piece of software would be required to
>>> "understand"
>>> the meaning of a UCD? (other than just compare with other UCDs,
>>> either
>>> completely or partially)
>> >> I don't see any problem: in produing the UCDType (not to be confused >> with VOTable's "ucdType", which just says what a ucd should look like >> lexographically), I simply took the official list and put it in a >> schema enumeration so that it could be checked syntactically. This >> certainly doesn't preclude someone else using the list for totally >> different purposes. > > Perhaps, I can see it from your point of view. That means that anyone > getting an XML document adopting that convention and wanting to use > "total" UCDs needs to append these elements into a new element which > will look like the original.
I'm not sure what you mean by "total" - "original"? UCD information
which
gets passed via its XML representation can be turned into any format you
want: e.g.
<group><ucd>em.opt.R</ucd><ucd>phot.flux</ucd>...</group>
is the same as
<PARAM ucd="em.opt.R;phot.flux" .../>
in a VOTable, and we hope the human at the end only sees
"R-band optical flux of 1.234e-4 W/m^2"
(or something similarly intelligent) and neither of the above computer representations!
> Non-XML representations will remain as originally proposed, right?
My point is that UCDs will have a life of their own as an official
representation
of astronomical quantities and concepts - to be used for whatever
purposes
people find them useful for - but that their use as a means of
communication
between computers and between people and computers will be much simpler
if there is an official XML representation. The current model of
simple string
concatenation is a cumbersome one for computers given that everything
else
is cast in XML. Thus, the creation of an official UCD standard list
should be
accompanied (not replaced!) by an attempt to make the list XML-enabled.
My suggestion of using concatenated <ucd> elements instead of
concatenated
UCD content is just one obivous way to achieve this functionality.
>> The whole point of UCD's was, at least as I understood it, that one >> could use an official label for a concept which a computer could then >> process. The UCD tags aren't for people - they're for computers. By >> making the UCD list available within a schema, we can make the list >> simpler for computers to process. > > In an ideal world, yes, UCDs should be for computers, but in a few > cases > the information for a given column is so "cryptic" that a human would > get > more information from the UCD than from an explanation/column-name > combination. Besides, I can think of cases in which users are faced > with > a choice between a number of "things" (to use that term :-) :-) in > which > the UCD will play an important role to understand what they are dealing > with. Searches launched by users will not always return "precise > answers", (eg, a registry query) so one of the discriminating elements > may > well be the UCD.
Absolutely - the UCD can be the syntactical glue by which the human
users
are finally able to communicate with the external VO world. All the
more
reasons to invest (1) in a more useful parallel version of the UCD list
(XML)
and (2) in extensions to the now still VOTable-ish UCD list (a la but
not
necessarily exactly like VOThing).
Rick
Dr. Frederic V. Hessman Hessman-at-Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ -------------------------
http://monet.uni-goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2005-05-06Z15:05:42