Re: T0 : extensions to em, obs, spect, instr - FINAL COMMENT?

From: Frederic V. \ <Hessman-at-Astro.physik.Uni-Goettingen.DE>
Date: Thu, 2 Jun 2005 14:41:23 +0200

On 1 Jun 2005, at 8:03 pm, Rob Seaman wrote:

> On Jun 1, 2005, at 10:25 AM, Sebastien Derriere wrote:
>
>> <src>
>> <param ucd="meta.id" value="NGC12345" />
>> <param ucd="src.class" value="Galaxy" />
>> <param ucd="src.morph.type" value="Sc" />
>> </src>
>
> This is similar to how I was envisioning VOEvent usage. Rick should
> speak up (on whatever mailing list :-) if he sees this much
> differently. That said, I question whether these specific UCDs will
> survive our discussions.

This is fine for VOTable, where "value" is really rather diffuse scientifically ("the thing in the table row and column with some scientific meaning given by the ucd") and where the main purpose is to recreate the non-astronomical thing "table" into an astronomical unit which can be processed. You really don't care if you have

        <param ucd="src.class" value="Galaxy"/> or

        <param ucd="src.class" value="galaxy"/> or

        <param ucd="src.class" value="island universe"/>

As soon as you get away from tables, things become more complex, since the "value" can - and SHOULD - take on
more meaning. In VOEvent, the point is NOT to have a string which someone used to randomly label an object (the VOTable equivalent task), but to tell stupid computers that the object is something in particular. With

        <param ucd="src.class" value="Galaxy"/>

there's no way to know if the class is "galaxies in general" or even "The Milky Way" unless the VO has an official dictionary saying that the "value" of "src.class" for galaxies in general should be "Galaxy" (a poor choice if you ask me, but...). Thus, I personally find the present model good for random information (non-classification tasks) but extremely bad for particular information (classification tasks).

If the only way to express "spiral galaxy" is to use "src.class" = "Galaxy" and "src.morph" = "SC", then someone (i.e. a programmer) with have to deal with the fact that "src.morph" - a concept used for zillions of other astronomical objects not related to galaxies - may or may not be applicable to the object in question. That forces her/him to use an ontology :-( While I applaud those willing to tackle such, it'll be a long while until we have one which can be used in real applications. And all of this work simply because we don't have "src.galaxies.spiral" (note I've dropped "class" to reduce the number of hierarchies).

> We think we have a pretty good idea now what a "spiral galaxy" is. It
> wasn't so very long ago that we hadn't the slightest idea of its true
> nature. As long as astronomy is a living subject, there will be names
> with fluid meanings.

True enough, but the point is we DO know what a "spiral galaxy" is right now, we already know of billions of them, and survey projects need NOW to be able to tell us that they've found one.

Let's worry about the concepts we haven't developed when they appear.

On 2 Jun 2005, at 10:48 am, Miguel Cerviņo wrote:

> In this case I am not sure it it would be required an UDC of It would
> more useful a line with
> <PARAM ucd="gal.sp" dataype="char" value="Elliptical">
>
> Any casee I aggre that there is a problem in how the "value" is
> spelling (Elliptical, E0,....) that would difficult any direct search,
> I think that it is a un-soluble problem: Each astronomer/VO developer
> etc has their own
> preferences (that is great, by the way).... and any machine program
> will have the preferences of its "owner"
> etc...

NO!!! The VO apps of the future will "know" how to express the concept of "elliptical galaxy" in a common fashion (otherwise they're too
stupid to be able to talk to each other about them) but the human user see's what the human equivalent is supposed to be in terms s/he WANTS to see (e.g. in english, in french, or for a 3rd grade student in Malaysia,...). The ONLY question now is how difficult we want to make the life of VO programmers - nothing else! An astronomer who refuses to accept that somewhere buried in the VO software architecture there's a "src.galaxies.elliptical" or a "src.class"="Galaxy" + "src.morph"="elliptical" instead of the string "elliptische Galaxie" simply won't (and shouldn't) use the VO.

Miguel's comment does raise a totally different issue which may explain why there's no confluence of ideas: do we want a VO architecture which is simply a more elegant means of letting a human user deal with complex sets of VO data and VO apps - in which case "Elliptical" will be fine to describe the galaxy since a human in there to interpret what it means - or do we want to use things like UCD's to permit computers to deal with this information without ANY human involved IN PRINCIPLE (e.g. automatic classification of zillions of LSST sources triggering robotic observations). My feeling is that the work on VOTable and UCD has been based largely on the former and I know that the work on VOEvent is largely based on the latter. Yes, this is oversimplified, but it would help to explain why we don't seem to be talking about the same thing......

Don't get me wrong - I think UCD's in their present form are great - but if this list is just about last-minute refining of the present list using the present limited set of officially allowed concepts, then please remove me so you won't have to be bothered by my rantings anymore. I'm sure you'll do a great job and we'll certainly use UCDs all over the place, but I'm then personally interested in something else and would then try to find a IVOA group doing the next - and unfortunately officially defined as different - task of teaching computers a minimal set of concepts needed to do automatic processing of VO information NOW without the use of ontologies (we just barely got our GRB colleagues to accept XML - wait until I tell them they're going to have to use OWL!).   Seems
a shame, but then the IVOA has historically been a pretty heterogeneous bunch and so yet another group doing some of the same work using a totally different approach won't be noticed. Computers are fast, databases can be linked, cross-references can be made, translators and parsers can be written, generations of students need to be given work, .... :-)

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
------------------------------------------------------------------------ 
-------------------------

MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------
Received on 2005-06-02Z14:39:18