VOConcepts paper

[Rob Seaman]

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