On Jul 26, 2006, at 3:02 AM, Alberto Micol wrote:
> I think that the above sentences put together by Roy
> are a perfect example of how to write ucd descriptions.
Roy certainly has a good knack for simplifying a description. But that doesn't excuse IVOA from a responsibility to simplify the things actually being described. Design elegance is a goal, not just a serendipitous occurrence.
> I would not agree though on the Hubble classification because the
> right ucd is in that case meta.code.class, and not just meta.code
Every message in this discussion seems to bring additional nuances of usage. One suspects the latest is still not a complete list - either in the sense of capturing all ID-like meta UCD constructs that have been proposed - or in the sense of providing orthonormal basis vectors suitable for describing pertinent metadata.
> P | meta.code | code is also called an
> enumeration or a labeling
> | of a flag. An example is
> the PixFlags in the SIAP1.0
> | standard, which is a flag
> whose meaning is well
> | understood within that
> protocol.
>
> P | meta.code.class | Classification, tide to a
> namespace.
> | In the Hubble namespace,
> galaxies have codes
> | Sa, Sb, SBa, E0 etc
Users are not going to understand these distinctions. You will see as many instances of meta.class.code as you do of meta.code.class. You may see more meta.class instances than anything else. Users are going to have a hard enough time understanding why they need the "meta" at all - ain't all UCDs about metadata?
If "code" is synonymous with "enum", why not use "enum"? The word "code" is horrifically overloaded for other purposes. Also, isn't an enumeration a modifier of the base UCD? A classification certainly could be open-ended - that is, not a code at all. How about:
meta.class;enum
Which opens up the possibility of constructs like:
meta.id;enum
Which might be used to limit the allowed values to a specific list of observing proposals, for instance - say, to those belonging to a particular investigator or pertaining to a particular telescope.
> P | meta.id | An ID is unique identifier
> for something that
> | is strongly linked to a
> namespace. Within the
> | Messier namespace, there
> are identifiers M31, M51, M87
If a namelike UCD ID requires only two levels, why should a classlike UCD ID require three?
> P | meta.title | A Title is a multi-word
> version of a name:
> | "Center of Virgo cluster"
> would be a title for M87
Again - multi-word is not the essence of the issue. That the title is assigned by the investigators, not by the observatory, likely is.
> P | meta.name | *** currently to be found
> under meta.id, ***
> | *** but probably it
> deserves its own ucd? ***
So UCDs that don't actually exist are to be described, too? To the extent that this particular pseudo-meta-notional-concept exists, you are most closely describing a shortname here, and the title is an instance of a long name - or simply a "name". In fact, all of these concepts could be said to be subclassed from "name".
> It would be nice to extend the descriptions of all other ucds
> in a similar way, wouldn't it?
Such descriptions certainly won't hurt, but the things being described should first be as carefully specified as anything in IVOA. From the discussion it seems obvious that no user can ever be trusted with either the generation or interpretation of a UCD. It also suggests that a UCD validator would be immediately seized upon by a grateful IVOA developer community. The question of versioning UCDs takes on new importance, too, since subtleties like those above will lead to perennial pressure to revise the roster of UCDs, not only to add new descriptors to open up new vistas of domain space, but also to clarify previous blessed descriptors. The meaning of a UCD construct seems unsettlingly unstable.
Rob Received on 2006-07-26Z16:43:14