Doug says:
> The use-case identified in Madrid, which prompted the need for
> standard
> object type names was searching by object type in SSA. We want to be
> able to do things like query for spectra where targetclass=QSO. I was
> expecting to see a simple list of names like "star", "galaxy", "PN",
> "QSO", "AGN", "GRB", etc., which is what I think users would like to
> search for, but what we have instead are more UCD-like names such as
> "process.variation.burst;em.gamma" which I guess indicates a GRB.
The notion of project specific glossaries has come up before on the UCD forums, e.g., http://www.ivoa.net/forum/ucd/0506/0217.htm. There is a need for standardization in both simple names and in highly precise nomenclature. The hierarchical nature of UCDs is intended to address this. Does it?
> I can see where it could be useful to specify more precisely what type
> of object we have as the UCD approach suggested permits, but it would
> also be useful to standardize the actual, simple acronyms commonly
> used
> by astronomers. Perhaps what we need are two lists, one for precise
> characterisation of physical object types, another defining the
> common,
> standard acronym associated with such object types. This could be
> done
> by merely defining a standard list of acronyms for object types, and
> assigning one to each of the object type UCDs, where appropriate.
Two lists are only the start. The key to the success of UCDs now, and of ontologies later, will be the ease with which distinct, purpose specific, namespaces are supported. As Doug points out, some of those namespaces will contain acronyms/aliases/synonyms of others (a feature, not a bug), but this is not the only reason to instantiate multiple namespaces. A list of acronyms (nicknames might be another way to put it) represents a namespace that maps as a subset of another. One might also seek to partition a "master" list of UCDs (if such were possible) into non-overlapping disjoint sets. But the most interesting cases will be namespaces that overlap only partially for various historical or topic related reasons.
Andrea's work on incorporating Rick's VOConcept list(s) into the standard IVOA UCD namespace is very welcome. But no matter how completely and precisely defined the list is now, it is inevitable that new nomenclature will evolve as the science evolves. The proposed mechanism for nominating and adopting new UCDs provides a medium to long latency solution for widely purposed names - that are also restricted in other ways, such as being deemed unique when adopted. But not all useful names are destined for wide adoption and not all projects can wait a minimum of several weeks before using them.
Or invert the question. The VO will inevitably come into contact with prior astronomical art in different areas. For instance, the IAU, through bodies such as CBAT, has previously implemented glossaries for characterizing astronomical objects and processes. A successful strategy for the "virtualization" of such projects would be to adopt pre-existing nomenclature into project specific namespaces. (This may be the only successful strategy - the VO is not going to supplant the IAU.) It is precisely such baseline namespaces that will support the later evolution of a consensus understanding of the richly overlapping concepts. After all, isn't this precisely the way that UCDs were harvested from the literature?
A related but orthogonal issue is versioning of namespaces (see, e.g., http://www.ivoa.net/forum/ucd/0510/0246.htm). Imagine a document (a VOEvent packet, for instance) that has been issued against a particular namespace at a particular time. The semantics of that document depend on the choice of UCDs (or other identifiers) that was made from the list as it existed previously. If the list of names is allowed to evolve without versioning, subsequent interpretation of the document will change. A document must be interpreted against the context of its creation to be understood properly. A historical document discussing a "supernova" may be talking about the same thing as current literature discussing "SN Ia". More to the point, a "spiral nebula" may later be completely reinterpreted as a "spiral galaxy".
So, yes - SSA requires a broad list of simple names for categories of objects, and VOEvent requires a detailed list of precise categories of processes as well as of objects, but both of these are distinct from the original purpose of UCDs to tag tabular columns - and all future examples of these different types of lists need to be versioned.
Static semantics are boring semantics.
Rob
seaman-at-noao.edu
Received on 2005-12-01Z17:24:41