From Tony.Linde at leicester.ac.uk  Thu Dec  1 07:22:33 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Thu, 1 Dec 2005 15:22:33 -0000
Subject: VOConcepts paper (fwd)
In-Reply-To: <Pine.LNX.4.63.0511302303200.3333@localhost.localdomain>
Message-ID: <002a01c5f68b$0d452710$0b01a8c0@marindi>

I don't think Roy's email made it to this list so I'm appending the
'vocabulary' which prompted Doug's comments. I agree it makes more sense to
have the discussion here or in the semantics list so I'll add my comments
here.

Just wanted to ask what this list is to be used for. As Doug says, it looks
much like UCDs. Where does the semantics come in?

(Pardon my ignorance - this is the first time I've seen any of this work.)

Cheers,
Tony. 

> -----Original Message-----
> From: owner-ucd at eso.org [mailto:owner-ucd at eso.org] On Behalf 
> Of Doug Tody
> Sent: 01 December 2005 06:05
> To: ucd at ivoa.net
> Subject: Re: VOConcepts paper (fwd)
> 
> [This discussion probably should be on the ucd or semantics 
> list rather than voevent, which is an application.]
> 
> 
> ---------- Forwarded message ----------
> Date: Wed, 30 Nov 2005 22:58:14 -0700 (MST)
> From: Doug Tody <dtody at nrao.edu>
> To: Roy Williams <roy at cacr.caltech.edu>
> Cc: IVOA List VOEvent <voevent at ivoa.net>
> Subject: Re: VOConcepts paper
> 
> 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.
> 
> 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.  - Doug
> 
> 
> 
> On Wed, 30 Nov 2005, Roy Williams wrote:
> 
> > Please find attached a white paper from Andrea Preite-Martinez, the 
> > chairman of the IVOA Semantics working group, which is a 
> first attempt 
> > to build a standard vocabulary for astronomical phenomena 
> and for astronomical objects.
> > I would like to have a brief discussion of this at the 
> VOEvent meeting 
> > next week, and/or receive comments by email from those who cannot 
> > attend the meeting. Rick Hessman has already worked on 
> exactly this topic.
> > 
> > I would like to compile a "group response feedback" on this 
> paper for 
> > Andrea and the Semantics WG.
> > 
> > Roy Williams
> > 
> > California Institute of Technology
> > 626 395 3670
> > 
> >
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VO-standard-vocabulary_3.pdf
Type: application/pdf
Size: 98495 bytes
Desc: not available
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd/attachments/20051201/69eacdb2/attachment.pdf>

From roy at cacr.caltech.edu  Thu Dec  1 07:45:45 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Thu, 1 Dec 2005 07:45:45 -0800
Subject: VOConcepts paper (fwd)
In-Reply-To: <002a01c5f68b$0d452710$0b01a8c0@marindi>
References: <002a01c5f68b$0d452710$0b01a8c0@marindi>
Message-ID: <7466b1db8ed315ec531880172d59660d@cacr.caltech.edu>

> Just wanted to ask what this list is to be used for.

For labeling VOEvents. So that a machine can decide if the 
interpretation of an event has changed as a result of followup or 
further analysis. That is why it was sent to the VOEvent mailing list.

> As Doug says, it looks much like UCDs.

These are syntactically like UCD, but they are not "content 
descriptors", but rather object and process descriptors.

> Where does the semantics come in?

Because the discussion is about the meanings of words. See definition 
below.

Roy
------------

 From wikipedia:
"In the main, semantics (from the Greek semantikos, or "significant 
meaning," derived from sema, sign) is the study of meaning, in some 
sense of that term....  Semantics is distinguished from ontology (study 
of existence) in being about the use of a word more than the nature of 
the entity referenced by the word."

California Institute of Technology
626 395 3670



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1087 bytes
Desc: not available
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd/attachments/20051201/6bea1e67/attachment.bin>

From seaman at noao.edu  Thu Dec  1 09:04:34 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 10:04:34 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
Message-ID: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>

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


From seaman at noao.edu  Thu Dec  1 09:04:34 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 10:04:34 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
Message-ID: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>

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


From seaman at noao.edu  Thu Dec  1 09:04:34 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 10:04:34 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
Message-ID: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>

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


From andrea.preitemartinez at rm.iasf.cnr.it  Thu Dec  1 09:55:57 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Thu, 01 Dec 2005 18:55:57 +0100
Subject: VOConcepts ...
Message-ID: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>

Tony, Doug,

with the VOEvent meeting approaching, I sent a draft document to the 
chairman of the VOEvent WG concerning "concepts and objects" and the 
way they could semantically and syntactically be represented in 
VOEvents.

The document is still in the form of a "personal note" in the sense 
that it should be considered as a personal contribution to the upcoming 
meeting (after an exchange of mail on "processes" with Rick Hessman).

I'm working to transform this "personal draft" into a IVOA-Note to be 
distributed and discussed within the WG. Meanwile, I took the first 
comments from Rick and Doug already into account ... and put the 
document in the present form in the UCD page

http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD

Latest documents:
The IVOA Standard Vocabulary Version 0.4 (20051201)

Cheers,

Andrea

==============================================================================
Andrea Preite Martinez                  andrea.preitemartinez at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma                              CDS :+33.3.90242473
==============================================================================



From dtody at nrao.edu  Thu Dec  1 09:58:59 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 10:58:59 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
Message-ID: <Pine.LNX.4.63.0512011029230.21971@oak>

Some more details on the simple use case I mentioned.

Suppose we have a catalog of spectra, containing spectra from
many types of objects, including stellar spectra.  If the
information is available we would like to characterize the type
of stellar spectra as precisely as we can, as the UCD proposal
makes possible.  Hence we have "stars;class.carbon", "stars.pulsar",
"stars.variable;class.variation.flare", and so forth.  Each object is
classified with such a object-type UCD, or possibly several such UCDs.

When it comes time to query the spectral catalog we may want to refine
the query to the level of an individual UCD, but more generally we will
want to query for a class of objects.  Hence we issue a query with a
parameter such as "targetclass=star".

We don't want to query for a list of UCDs, because there might be hundreds
of different types of object in the overall class "star".  This would be
too awkward a query mechanism, plus it would require too much knowledge
on the part of the client.

Hence, to support query by targetclass, the service needs to support
mapping of common object class names or acronyms (star, galaxy, AGN, QSO,
etc.) to fully-qualified names (UCD-type names).

To do this in a reliable fashion we need to standardize the common names
or acronyms, and define standard mappings to the fully-qualified names.
We don't want to build this vocabulary (which will evolve constantly) into
each service implementation, so it needs to be possible to download these
mappings via the network, and cache the translation table in the service.
They need to be in a standard form which the service code can deal with,
probably something based on XML.  The mechanism should be simple enough
to support arbitrary implementations without requiring using some complex
inference framework.

I think this is more or less the problem we need to solve.   In general we
want to specify object types as precisely as we can at the level of the
object metadata, but the query mechanism needs to be powerful enough to
deal with broader classes of objects.  I doubt if it matters much whether
we are dealing with events or datasets.     - Doug


From dtody at nrao.edu  Thu Dec  1 09:58:59 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 10:58:59 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
Message-ID: <Pine.LNX.4.63.0512011029230.21971@oak>

Some more details on the simple use case I mentioned.

Suppose we have a catalog of spectra, containing spectra from
many types of objects, including stellar spectra.  If the
information is available we would like to characterize the type
of stellar spectra as precisely as we can, as the UCD proposal
makes possible.  Hence we have "stars;class.carbon", "stars.pulsar",
"stars.variable;class.variation.flare", and so forth.  Each object is
classified with such a object-type UCD, or possibly several such UCDs.

When it comes time to query the spectral catalog we may want to refine
the query to the level of an individual UCD, but more generally we will
want to query for a class of objects.  Hence we issue a query with a
parameter such as "targetclass=star".

We don't want to query for a list of UCDs, because there might be hundreds
of different types of object in the overall class "star".  This would be
too awkward a query mechanism, plus it would require too much knowledge
on the part of the client.

Hence, to support query by targetclass, the service needs to support
mapping of common object class names or acronyms (star, galaxy, AGN, QSO,
etc.) to fully-qualified names (UCD-type names).

To do this in a reliable fashion we need to standardize the common names
or acronyms, and define standard mappings to the fully-qualified names.
We don't want to build this vocabulary (which will evolve constantly) into
each service implementation, so it needs to be possible to download these
mappings via the network, and cache the translation table in the service.
They need to be in a standard form which the service code can deal with,
probably something based on XML.  The mechanism should be simple enough
to support arbitrary implementations without requiring using some complex
inference framework.

I think this is more or less the problem we need to solve.   In general we
want to specify object types as precisely as we can at the level of the
object metadata, but the query mechanism needs to be powerful enough to
deal with broader classes of objects.  I doubt if it matters much whether
we are dealing with events or datasets.     - Doug


From eca at mssl.ucl.ac.uk  Thu Dec  1 10:05:11 2005
From: eca at mssl.ucl.ac.uk (Elizabeth Auden)
Date: Thu, 1 Dec 2005 18:05:11 +0000 (GMT)
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>

> We don't want to build this vocabulary (which will evolve constantly) into
> each service implementation, so it needs to be possible to download these
> mappings via the network, and cache the translation table in the service.
> They need to be in a standard form which the service code can deal with,
> probably something based on XML.

Perhaps OWL or RDF triples?

--
Elizabeth Auden, MSSL
Holmbury St. Mary, Dorking RH5 6NT
Tel: +44 (0)1483 204 276
eSDO Technical Lead, AstroGrid Developer


From eca at mssl.ucl.ac.uk  Thu Dec  1 10:05:11 2005
From: eca at mssl.ucl.ac.uk (Elizabeth Auden)
Date: Thu, 1 Dec 2005 18:05:11 +0000 (GMT)
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>

> We don't want to build this vocabulary (which will evolve constantly) into
> each service implementation, so it needs to be possible to download these
> mappings via the network, and cache the translation table in the service.
> They need to be in a standard form which the service code can deal with,
> probably something based on XML.

Perhaps OWL or RDF triples?

--
Elizabeth Auden, MSSL
Holmbury St. Mary, Dorking RH5 6NT
Tel: +44 (0)1483 204 276
eSDO Technical Lead, AstroGrid Developer


From Tony.Linde at leicester.ac.uk  Thu Dec  1 10:15:52 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Thu, 1 Dec 2005 18:15:52 -0000
Subject: VOConcepts ...
In-Reply-To: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>
Message-ID: <004501c5f6a3$43a42460$0b01a8c0@marindi>

Hi Andrea, I have no problems with where the document appeared. But, I would
tend to agree with Doug and Rob that simple names that have meaning within a
context where the context is specified by a versioned namespace is a better
approach. Trying for an astronomy-wide vocabulary which some central party
approves is unlikely to succeed in the long-term.

But I already know that the voevent group will reject any idea with the word
'namespace' in it so I don't hold out much hope! :)

Cheers,
Tony. 

> -----Original Message-----
> From: owner-ucd at eso.org [mailto:owner-ucd at eso.org] On Behalf 
> Of Andrea Preite Martinez
> Sent: 01 December 2005 17:56
> To: ucd at ivoa.net
> Subject: VOConcepts ...
> 
> Tony, Doug,
> 
> with the VOEvent meeting approaching, I sent a draft document 
> to the chairman of the VOEvent WG concerning "concepts and 
> objects" and the way they could semantically and 
> syntactically be represented in VOEvents.
> 
> The document is still in the form of a "personal note" in the 
> sense that it should be considered as a personal contribution 
> to the upcoming meeting (after an exchange of mail on 
> "processes" with Rick Hessman).
> 
> I'm working to transform this "personal draft" into a 
> IVOA-Note to be distributed and discussed within the WG. 
> Meanwile, I took the first comments from Rick and Doug 
> already into account ... and put the document in the present 
> form in the UCD page
> 
> http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD
> 
> Latest documents:
> The IVOA Standard Vocabulary Version 0.4 (20051201)
> 
> Cheers,
> 
> Andrea
> 
> ==============================================================
> ================
> Andrea Preite Martinez                  
> andrea.preitemartinez at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma                              CDS :+33.3.90242473
> ==============================================================
> ================
> 
> 
> 


From dtody at nrao.edu  Thu Dec  1 10:22:33 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 11:22:33 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
 <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
Message-ID: <Pine.LNX.4.63.0512011110030.21971@oak>

I suspect we are headed towards something like that.  Probably what is 
needed is to define the information in some simple, stable,
technology-independent fashion which we (IVOA) control, then auto-generate
the namespaces and mappings in several popular forms such as OWL, RDF,
etc., for use at runtime by implementations.  Perhaps also in HTML, for
human viewing of the terminology and dictionaries.  It should be possible
to use the information without having to adopt some complex inference
framework, but we don't want to prevent people from doing so either.   Doug


On Thu, 1 Dec 2005, Elizabeth Auden wrote:
>> We don't want to build this vocabulary (which will evolve constantly) into
>> each service implementation, so it needs to be possible to download these
>> mappings via the network, and cache the translation table in the service.
>> They need to be in a standard form which the service code can deal with,
>> probably something based on XML.
>
> Perhaps OWL or RDF triples?
>
> --
> Elizabeth Auden, MSSL
> Holmbury St. Mary, Dorking RH5 6NT
> Tel: +44 (0)1483 204 276
> eSDO Technical Lead, AstroGrid Developer
>


From dtody at nrao.edu  Thu Dec  1 10:22:33 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 11:22:33 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
 <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
Message-ID: <Pine.LNX.4.63.0512011110030.21971@oak>

I suspect we are headed towards something like that.  Probably what is 
needed is to define the information in some simple, stable,
technology-independent fashion which we (IVOA) control, then auto-generate
the namespaces and mappings in several popular forms such as OWL, RDF,
etc., for use at runtime by implementations.  Perhaps also in HTML, for
human viewing of the terminology and dictionaries.  It should be possible
to use the information without having to adopt some complex inference
framework, but we don't want to prevent people from doing so either.   Doug


On Thu, 1 Dec 2005, Elizabeth Auden wrote:
>> We don't want to build this vocabulary (which will evolve constantly) into
>> each service implementation, so it needs to be possible to download these
>> mappings via the network, and cache the translation table in the service.
>> They need to be in a standard form which the service code can deal with,
>> probably something based on XML.
>
> Perhaps OWL or RDF triples?
>
> --
> Elizabeth Auden, MSSL
> Holmbury St. Mary, Dorking RH5 6NT
> Tel: +44 (0)1483 204 276
> eSDO Technical Lead, AstroGrid Developer
>


From seaman at noao.edu  Thu Dec  1 11:30:21 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 12:30:21 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain> <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>

Another example is the characterization of filters for direct  
imaging.  For instance, the NOAO Mosaic camera team maintains a list  
of filters that includes both a long identifier - unique but hard to  
remember - as well as a short identifier, such as "R".  Each short  
identifier may correspond to several long identifiers, that is, to  
several individual filters.

If UCDs were used to create and track such lists, one could attempt  
to achieve the same many-to-one mapping by relying on the  
hierarchical nature of UCDs:   
filter.R.this_is_a_specific_wideband_R_filter.  This has problems on  
both ends.  First, there will often be a redundant prefix like  
"filter." and second, who is to say that it is the "R-ness" of the  
filter that we wish to capture in a short nickname?  Perhaps we  
rather need to capture the "wideband-ness" of the filter.  The  
problem with relying on a hierarchy in a single namespace is  
precisely that only one hierarchy exists per namespace.  On the other  
hand, multiple mappings are trivial with multiple namespaces.

The essential nature of a viable solution will be some mechanism for  
multiple authorities to maintain multiple non-local lists that permit  
such niceties as versioning.  In the absence of such a mechanism,  
separate projects will field separate, non-interoperable solutions.

The trouble with anecdotal examples is that they are too easy to  
gather.  The difficulty with this mechanism (whether realized as UCD  
namespaces or as RDF or as brute-force lists of aliases) will not be  
encountered when distinguishing between "stars" and "galaxies", but  
in the more obscure questions of art as referred to by George.

Rob
seaman at noao.edu


From seaman at noao.edu  Thu Dec  1 11:30:21 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 12:30:21 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain> <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>

Another example is the characterization of filters for direct  
imaging.  For instance, the NOAO Mosaic camera team maintains a list  
of filters that includes both a long identifier - unique but hard to  
remember - as well as a short identifier, such as "R".  Each short  
identifier may correspond to several long identifiers, that is, to  
several individual filters.

If UCDs were used to create and track such lists, one could attempt  
to achieve the same many-to-one mapping by relying on the  
hierarchical nature of UCDs:   
filter.R.this_is_a_specific_wideband_R_filter.  This has problems on  
both ends.  First, there will often be a redundant prefix like  
"filter." and second, who is to say that it is the "R-ness" of the  
filter that we wish to capture in a short nickname?  Perhaps we  
rather need to capture the "wideband-ness" of the filter.  The  
problem with relying on a hierarchy in a single namespace is  
precisely that only one hierarchy exists per namespace.  On the other  
hand, multiple mappings are trivial with multiple namespaces.

The essential nature of a viable solution will be some mechanism for  
multiple authorities to maintain multiple non-local lists that permit  
such niceties as versioning.  In the absence of such a mechanism,  
separate projects will field separate, non-interoperable solutions.

The trouble with anecdotal examples is that they are too easy to  
gather.  The difficulty with this mechanism (whether realized as UCD  
namespaces or as RDF or as brute-force lists of aliases) will not be  
encountered when distinguishing between "stars" and "galaxies", but  
in the more obscure questions of art as referred to by George.

Rob
seaman at noao.edu


From dtody at nrao.edu  Thu Dec  1 12:37:16 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 13:37:16 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
 <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>
Message-ID: <Pine.LNX.4.63.0512011315170.21971@oak>

Right!  This is the classical problem of explicit hierarchy versus flat
or mostly-flat namespaces which are associated in a more general fashion
(e.g., hierarchical versus relational structures).  Unless you are
trying to model a single complex entity it is almost always better
to use the relational approach where simple, well-defined entites are
associated.  This allows more complex relationships to be described,
permits multiple views of the same data, and in some cases can permit
inference.  The namespace/mapping approach is a good one for vocabularies.
For structured data one does much the same thing, but the namespace in
this case is a component data model.  - Doug



On Thu, 1 Dec 2005, Rob Seaman wrote:
> If UCDs were used to create and track such lists, one could attempt to 
> achieve the same many-to-one mapping by relying on the hierarchical nature of 
> UCDs:  filter.R.this_is_a_specific_wideband_R_filter.  This has problems on 
> both ends.  First, there will often be a redundant prefix like "filter." and 
> second, who is to say that it is the "R-ness" of the filter that we wish to 
> capture in a short nickname?  Perhaps we rather need to capture the 
> "wideband-ness" of the filter.  The problem with relying on a hierarchy in a 
> single namespace is precisely that only one hierarchy exists per namespace. 
> On the other hand, multiple mappings are trivial with multiple namespaces.


From Tony.Linde at leicester.ac.uk  Thu Dec  1 12:58:31 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Thu, 1 Dec 2005 20:58:31 -0000
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011315170.21971@oak>
Message-ID: <004f01c5f6b9$fca52070$0b01a8c0@marindi>

My own view is that the single hierarchical approach is fine for a well
controlled and well defined area: we can define the account systems for a
company using a relational or set of hierarchical structures because it is a
relatively closed problem with one authority who can decide how things will
be represented. For a wide range of groups tackling different problems and
who do not closely interact or are not under a single authority then you
have to accept that each group will define structures that suit their own
field; in this case you need to be able to namespace those structures and
then, when you need to, define how those namespaces are related.

This is now coming up in the semantic web field - there were quite a few
papers at ISWC2005 dealing with ontology interoperability and how systems
can work with multiple overlapping ontologies.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-ucd at eso.org [mailto:owner-ucd at eso.org] On Behalf 
> Of Doug Tody
> Sent: 01 December 2005 20:37
> To: Rob Seaman
> Cc: ucd at ivoa.net
> Subject: Re: VOConcepts paper
> 
> Right!  This is the classical problem of explicit hierarchy 
> versus flat or mostly-flat namespaces which are associated in 
> a more general fashion (e.g., hierarchical versus relational 
> structures).  Unless you are trying to model a single complex 
> entity it is almost always better to use the relational 
> approach where simple, well-defined entites are associated.  
> This allows more complex relationships to be described, 
> permits multiple views of the same data, and in some cases 
> can permit inference.  The namespace/mapping approach is a 
> good one for vocabularies.
> For structured data one does much the same thing, but the 
> namespace in this case is a component data model.  - Doug
> 
> 
> 
> On Thu, 1 Dec 2005, Rob Seaman wrote:
> > If UCDs were used to create and track such lists, one could 
> attempt to 
> > achieve the same many-to-one mapping by relying on the hierarchical 
> > nature of
> > UCDs:  filter.R.this_is_a_specific_wideband_R_filter.  This has 
> > problems on both ends.  First, there will often be a 
> redundant prefix 
> > like "filter." and second, who is to say that it is the "R-ness" of 
> > the filter that we wish to capture in a short nickname?  Perhaps we 
> > rather need to capture the "wideband-ness" of the filter.  
> The problem 
> > with relying on a hierarchy in a single namespace is 
> precisely that only one hierarchy exists per namespace.
> > On the other hand, multiple mappings are trivial with 
> multiple namespaces.
> 


From abdixul at qon.lao.net  Thu Dec  1 13:55:13 2005
From: abdixul at qon.lao.net (Marisol)
Date: Thu, 01 Dec 2005 23:55:13 +0200
Subject: ineffective Get an inexpensive price on your next style. belittle
Message-ID: <6C0F4AD9.AD5C76B@qon.lao.net>

You know how you've always desired an expensive timepiece but didn't have
enough dough? I think I may have stumbled on a solution.
You are very important to me so I want to tell you about this excellent
deal!

You no longer need tons of currency to purchase the fashion you desire!
I don't want you to torture yourself any longer, you ought to have an
highly delicate piece!
This dealer has been operating for over 19 years and can count on hundreds
of happy regulars.

amfv  http://rewxlwvp.halcyonglisten.com

I know this fashion accessory will make everyday at work nicer and I can't
wait to see it!

'And when are you going to hear at full, true, and particular account of
the life and adventures of Oliver Twist?' asked Grimwig of Mr. Brownlow, at
the conclusion of the meal; looking sideways at Oliver, as he resumed his
subject. 


fbwait  fbmunmap  eruliaf HZ04 envm  esoterik
`I think they are great nonsense, and I'll thank you not to be silly, and
spoil my fun. Laurie's a nice boy, and I like him, and I won't have any
sentimental stuff about compliments and such rubbish. We'll all be good to
him, because he hasn't got any mother, and he may come over and see us,
mayn't he, Marmee?' 
`Yes, Jo, your little RING is very welcome, and I hope Meg will remember
that children should be children as long as they can.' 


From genova at cluster.u-strasbg.fr  Thu Dec  1 22:21:00 2005
From: genova at cluster.u-strasbg.fr (Francoise Genova)
Date: Fri, 2 Dec 2005 07:21:00 +0100 (MET)
Subject: Object types
Message-ID: <200512020621.jB26L0927788@astro.u-strasbg.fr>

The list of object types in SIMBAD can be found at 
http://simbad.u-strasbg.fr/guide/chF.htx
an example is given below

It is maintained, i.e. we include new object types from the scanning
of published papers, but it remains fairly stable. 

We have made choices on the 'granularity' of the list, and more 
details or additional branches could be included in some of the branches.
The example I show is for instance not complete for the X-ray objects I
think.

Of course there are problems with a strictly hierarchical representation
of the object types. For the moment we have pragmatic short-cuts 
and there are on-going tests on building ontologies.

Andrea has used the list to build a more formal representation of
object types (with some updates/additions I suppose). It would
be interesting to check this list for the object types required by
VOEvent -  are there many additions/changes required?

Object types are a relatively simple case and it is certainly 
worth trying to create a single list for the sake of interoperability. 
I have the impression that it is possible.

Cheers
Francoise

 12.13.02.0:	  SB            SB*     Spectroscopic binary
 12.13.11.0:      CataclyV*     CV*     Cataclysmic Variable Star
 12.13.11.2:        DQHer       DQ*     Cataclysmic Var. DQ Her type
 12.13.11.3:        AMHer       AM*     Cataclysmic Var. AM Her type
 12.13.11.5:        Nova-like   NL*     Nova-like Star
 12.13.11.6:        Nova        No*     Nova
 12.13.11.7:        DwarfNova   DN*     Dwarf Nova
 12.13.12.0:      XB            XB*     X-ray Binary
 12.13.12.2:        LMXB        LXB     Low Mass X-ray Binary
 12.13.12.3:        HMXB        HXB     High Mass X-ray Binary






From dtody at nrao.edu  Fri Dec  2 08:03:37 2005
From: dtody at nrao.edu (Doug Tody)
Date: Fri, 2 Dec 2005 09:03:37 -0700 (MST)
Subject: Object types
In-Reply-To: <200512020621.jB26L0927788@astro.u-strasbg.fr>
References: <200512020621.jB26L0927788@astro.u-strasbg.fr>
Message-ID: <Pine.LNX.4.63.0512020858170.3333@localhost.localdomain>

Francoise - this looks great.  My main concern is the use of the
characters '*' and '?' in the "condensed" names.  While I understand the
short names are intended for things like table columns, they could be
used for input as well.  These are common characters in pattern matching
templates, and whenever we search based on text patterns, we might want
to use a template of some sort.   - Doug


On Fri, 2 Dec 2005, Francoise Genova wrote:

> The list of object types in SIMBAD can be found at
> http://simbad.u-strasbg.fr/guide/chF.htx
> an example is given below
>
> It is maintained, i.e. we include new object types from the scanning
> of published papers, but it remains fairly stable.
>
> We have made choices on the 'granularity' of the list, and more
> details or additional branches could be included in some of the branches.
> The example I show is for instance not complete for the X-ray objects I
> think.
>
> Of course there are problems with a strictly hierarchical representation
> of the object types. For the moment we have pragmatic short-cuts
> and there are on-going tests on building ontologies.
>
> Andrea has used the list to build a more formal representation of
> object types (with some updates/additions I suppose). It would
> be interesting to check this list for the object types required by
> VOEvent -  are there many additions/changes required?
>
> Object types are a relatively simple case and it is certainly
> worth trying to create a single list for the sake of interoperability.
> I have the impression that it is possible.
>
> Cheers
> Francoise
>
> 12.13.02.0:	  SB            SB*     Spectroscopic binary
> 12.13.11.0:      CataclyV*     CV*     Cataclysmic Variable Star
> 12.13.11.2:        DQHer       DQ*     Cataclysmic Var. DQ Her type
> 12.13.11.3:        AMHer       AM*     Cataclysmic Var. AM Her type
> 12.13.11.5:        Nova-like   NL*     Nova-like Star
> 12.13.11.6:        Nova        No*     Nova
> 12.13.11.7:        DwarfNova   DN*     Dwarf Nova
> 12.13.12.0:      XB            XB*     X-ray Binary
> 12.13.12.2:        LMXB        LXB     Low Mass X-ray Binary
> 12.13.12.3:        HMXB        HXB     High Mass X-ray Binary
>
>
>
>
>


From genova at cluster.u-strasbg.fr  Sun Dec  4 01:16:59 2005
From: genova at cluster.u-strasbg.fr (Francoise Genova)
Date: Sun, 4 Dec 2005 10:16:59 +0100 (MET)
Subject: Object types
Message-ID: <200512040916.jB49GxL18153@astro.u-strasbg.fr>

Hi Doug,

I just sent the SIMBAD list as is for information.
Andrea already told me about the potential problem with '*' and
'?' - we had to build three-letter names for SIMBAD
but this constraint does not apply for a more general usage
and one can very well define more suitable 'short names'. 

I cannot access Andrea's
document from here but I think that he has added a column
containing 'short names' in the present version of
his  preliminary document following your remark that 
they are needed.

Cheers
Francoise


From pdidelon at cea.fr  Mon Dec  5 08:26:18 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Mon, 05 Dec 2005 17:26:18 +0100
Subject: VOConcepts ...
In-Reply-To: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>
References: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>
Message-ID: <43946A2A.5090800@cea.fr>

Hi,

Andrea Preite Martinez wrote:

> Tony, Doug,
> 
> with the VOEvent meeting approaching, I sent a draft document to the 
> chairman of the VOEvent WG concerning "concepts and objects" and the way 
> they could semantically and syntactically be represented in VOEvents.
> 
> The document is still in the form of a "personal note" in the sense that 
> it should be considered as a personal contribution to the upcoming 
> meeting (after an exchange of mail on "processes" with Rick Hessman).
> 
> I'm working to transform this "personal draft" into a IVOA-Note to be 
> distributed and discussed within the WG. Meanwile, I took the first 
> comments from Rick and Doug already into account ... and put the 
> document in the present form in the UCD page
for further comments?
> 
> http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD
> 
> Latest documents:
> The IVOA Standard Vocabulary Version 0.4 (20051201)
I am very disturbed by the fact that the same "thing"/"concept" can be represented
in two way :

Extinction or absorption	phys.absorption
Acceleration			phys.acceleration
OR
Generic absorption of wave or particle	process.absorption
Acceleration (particles, ..)		process.acceleration

what is the distinction between them?

Is there any plan to construct a list for the category "photometric filter"
which cyclically reappear in UCD discussion? ;-)
> 
> Cheers,
> 
> Andrea
> 
> ============================================================================== 
> 
> Andrea Preite Martinez                  
> andrea.preitemartinez at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma                              CDS :+33.3.90242473
> ============================================================================== 
> 
> 
> 
best regards,
-- 
Pierre	DIDELON



From Tony.Linde at leicester.ac.uk  Thu Dec  1 07:22:33 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Thu, 1 Dec 2005 15:22:33 -0000
Subject: VOConcepts paper (fwd)
In-Reply-To: <Pine.LNX.4.63.0511302303200.3333@localhost.localdomain>
Message-ID: <002a01c5f68b$0d452710$0b01a8c0@marindi>

I don't think Roy's email made it to this list so I'm appending the
'vocabulary' which prompted Doug's comments. I agree it makes more sense to
have the discussion here or in the semantics list so I'll add my comments
here.

Just wanted to ask what this list is to be used for. As Doug says, it looks
much like UCDs. Where does the semantics come in?

(Pardon my ignorance - this is the first time I've seen any of this work.)

Cheers,
Tony. 

> -----Original Message-----
> From: owner-ucd at eso.org [mailto:owner-ucd at eso.org] On Behalf 
> Of Doug Tody
> Sent: 01 December 2005 06:05
> To: ucd at ivoa.net
> Subject: Re: VOConcepts paper (fwd)
> 
> [This discussion probably should be on the ucd or semantics 
> list rather than voevent, which is an application.]
> 
> 
> ---------- Forwarded message ----------
> Date: Wed, 30 Nov 2005 22:58:14 -0700 (MST)
> From: Doug Tody <dtody at nrao.edu>
> To: Roy Williams <roy at cacr.caltech.edu>
> Cc: IVOA List VOEvent <voevent at ivoa.net>
> Subject: Re: VOConcepts paper
> 
> 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.
> 
> 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.  - Doug
> 
> 
> 
> On Wed, 30 Nov 2005, Roy Williams wrote:
> 
> > Please find attached a white paper from Andrea Preite-Martinez, the 
> > chairman of the IVOA Semantics working group, which is a 
> first attempt 
> > to build a standard vocabulary for astronomical phenomena 
> and for astronomical objects.
> > I would like to have a brief discussion of this at the 
> VOEvent meeting 
> > next week, and/or receive comments by email from those who cannot 
> > attend the meeting. Rick Hessman has already worked on 
> exactly this topic.
> > 
> > I would like to compile a "group response feedback" on this 
> paper for 
> > Andrea and the Semantics WG.
> > 
> > Roy Williams
> > 
> > California Institute of Technology
> > 626 395 3670
> > 
> >
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VO-standard-vocabulary_3.pdf
Type: application/pdf
Size: 98495 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/ucd/attachments/20051201/69eacdb2/attachment-0001.pdf>

From roy at cacr.caltech.edu  Thu Dec  1 07:45:45 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Thu, 1 Dec 2005 07:45:45 -0800
Subject: VOConcepts paper (fwd)
In-Reply-To: <002a01c5f68b$0d452710$0b01a8c0@marindi>
References: <002a01c5f68b$0d452710$0b01a8c0@marindi>
Message-ID: <7466b1db8ed315ec531880172d59660d@cacr.caltech.edu>

> Just wanted to ask what this list is to be used for.

For labeling VOEvents. So that a machine can decide if the 
interpretation of an event has changed as a result of followup or 
further analysis. That is why it was sent to the VOEvent mailing list.

> As Doug says, it looks much like UCDs.

These are syntactically like UCD, but they are not "content 
descriptors", but rather object and process descriptors.

> Where does the semantics come in?

Because the discussion is about the meanings of words. See definition 
below.

Roy
------------

 From wikipedia:
"In the main, semantics (from the Greek semantikos, or "significant 
meaning," derived from sema, sign) is the study of meaning, in some 
sense of that term....  Semantics is distinguished from ontology (study 
of existence) in being about the use of a word more than the nature of 
the entity referenced by the word."

California Institute of Technology
626 395 3670



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1087 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/ucd/attachments/20051201/6bea1e67/attachment-0001.bin>

From seaman at noao.edu  Thu Dec  1 09:04:34 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 10:04:34 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
Message-ID: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>

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


From seaman at noao.edu  Thu Dec  1 09:04:34 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 10:04:34 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
Message-ID: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>

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


From seaman at noao.edu  Thu Dec  1 09:04:34 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 10:04:34 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
Message-ID: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>

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


From andrea.preitemartinez at rm.iasf.cnr.it  Thu Dec  1 09:55:57 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Thu, 01 Dec 2005 18:55:57 +0100
Subject: VOConcepts ...
Message-ID: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>

Tony, Doug,

with the VOEvent meeting approaching, I sent a draft document to the 
chairman of the VOEvent WG concerning "concepts and objects" and the 
way they could semantically and syntactically be represented in 
VOEvents.

The document is still in the form of a "personal note" in the sense 
that it should be considered as a personal contribution to the upcoming 
meeting (after an exchange of mail on "processes" with Rick Hessman).

I'm working to transform this "personal draft" into a IVOA-Note to be 
distributed and discussed within the WG. Meanwile, I took the first 
comments from Rick and Doug already into account ... and put the 
document in the present form in the UCD page

http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD

Latest documents:
The IVOA Standard Vocabulary Version 0.4 (20051201)

Cheers,

Andrea

==============================================================================
Andrea Preite Martinez                  andrea.preitemartinez at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma                              CDS :+33.3.90242473
==============================================================================



From dtody at nrao.edu  Thu Dec  1 09:58:59 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 10:58:59 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
Message-ID: <Pine.LNX.4.63.0512011029230.21971@oak>

Some more details on the simple use case I mentioned.

Suppose we have a catalog of spectra, containing spectra from
many types of objects, including stellar spectra.  If the
information is available we would like to characterize the type
of stellar spectra as precisely as we can, as the UCD proposal
makes possible.  Hence we have "stars;class.carbon", "stars.pulsar",
"stars.variable;class.variation.flare", and so forth.  Each object is
classified with such a object-type UCD, or possibly several such UCDs.

When it comes time to query the spectral catalog we may want to refine
the query to the level of an individual UCD, but more generally we will
want to query for a class of objects.  Hence we issue a query with a
parameter such as "targetclass=star".

We don't want to query for a list of UCDs, because there might be hundreds
of different types of object in the overall class "star".  This would be
too awkward a query mechanism, plus it would require too much knowledge
on the part of the client.

Hence, to support query by targetclass, the service needs to support
mapping of common object class names or acronyms (star, galaxy, AGN, QSO,
etc.) to fully-qualified names (UCD-type names).

To do this in a reliable fashion we need to standardize the common names
or acronyms, and define standard mappings to the fully-qualified names.
We don't want to build this vocabulary (which will evolve constantly) into
each service implementation, so it needs to be possible to download these
mappings via the network, and cache the translation table in the service.
They need to be in a standard form which the service code can deal with,
probably something based on XML.  The mechanism should be simple enough
to support arbitrary implementations without requiring using some complex
inference framework.

I think this is more or less the problem we need to solve.   In general we
want to specify object types as precisely as we can at the level of the
object metadata, but the query mechanism needs to be powerful enough to
deal with broader classes of objects.  I doubt if it matters much whether
we are dealing with events or datasets.     - Doug


From dtody at nrao.edu  Thu Dec  1 09:58:59 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 10:58:59 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu>
Message-ID: <Pine.LNX.4.63.0512011029230.21971@oak>

Some more details on the simple use case I mentioned.

Suppose we have a catalog of spectra, containing spectra from
many types of objects, including stellar spectra.  If the
information is available we would like to characterize the type
of stellar spectra as precisely as we can, as the UCD proposal
makes possible.  Hence we have "stars;class.carbon", "stars.pulsar",
"stars.variable;class.variation.flare", and so forth.  Each object is
classified with such a object-type UCD, or possibly several such UCDs.

When it comes time to query the spectral catalog we may want to refine
the query to the level of an individual UCD, but more generally we will
want to query for a class of objects.  Hence we issue a query with a
parameter such as "targetclass=star".

We don't want to query for a list of UCDs, because there might be hundreds
of different types of object in the overall class "star".  This would be
too awkward a query mechanism, plus it would require too much knowledge
on the part of the client.

Hence, to support query by targetclass, the service needs to support
mapping of common object class names or acronyms (star, galaxy, AGN, QSO,
etc.) to fully-qualified names (UCD-type names).

To do this in a reliable fashion we need to standardize the common names
or acronyms, and define standard mappings to the fully-qualified names.
We don't want to build this vocabulary (which will evolve constantly) into
each service implementation, so it needs to be possible to download these
mappings via the network, and cache the translation table in the service.
They need to be in a standard form which the service code can deal with,
probably something based on XML.  The mechanism should be simple enough
to support arbitrary implementations without requiring using some complex
inference framework.

I think this is more or less the problem we need to solve.   In general we
want to specify object types as precisely as we can at the level of the
object metadata, but the query mechanism needs to be powerful enough to
deal with broader classes of objects.  I doubt if it matters much whether
we are dealing with events or datasets.     - Doug


From eca at mssl.ucl.ac.uk  Thu Dec  1 10:05:11 2005
From: eca at mssl.ucl.ac.uk (Elizabeth Auden)
Date: Thu, 1 Dec 2005 18:05:11 +0000 (GMT)
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>

> We don't want to build this vocabulary (which will evolve constantly) into
> each service implementation, so it needs to be possible to download these
> mappings via the network, and cache the translation table in the service.
> They need to be in a standard form which the service code can deal with,
> probably something based on XML.

Perhaps OWL or RDF triples?

--
Elizabeth Auden, MSSL
Holmbury St. Mary, Dorking RH5 6NT
Tel: +44 (0)1483 204 276
eSDO Technical Lead, AstroGrid Developer


From eca at mssl.ucl.ac.uk  Thu Dec  1 10:05:11 2005
From: eca at mssl.ucl.ac.uk (Elizabeth Auden)
Date: Thu, 1 Dec 2005 18:05:11 +0000 (GMT)
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>

> We don't want to build this vocabulary (which will evolve constantly) into
> each service implementation, so it needs to be possible to download these
> mappings via the network, and cache the translation table in the service.
> They need to be in a standard form which the service code can deal with,
> probably something based on XML.

Perhaps OWL or RDF triples?

--
Elizabeth Auden, MSSL
Holmbury St. Mary, Dorking RH5 6NT
Tel: +44 (0)1483 204 276
eSDO Technical Lead, AstroGrid Developer


From Tony.Linde at leicester.ac.uk  Thu Dec  1 10:15:52 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Thu, 1 Dec 2005 18:15:52 -0000
Subject: VOConcepts ...
In-Reply-To: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>
Message-ID: <004501c5f6a3$43a42460$0b01a8c0@marindi>

Hi Andrea, I have no problems with where the document appeared. But, I would
tend to agree with Doug and Rob that simple names that have meaning within a
context where the context is specified by a versioned namespace is a better
approach. Trying for an astronomy-wide vocabulary which some central party
approves is unlikely to succeed in the long-term.

But I already know that the voevent group will reject any idea with the word
'namespace' in it so I don't hold out much hope! :)

Cheers,
Tony. 

> -----Original Message-----
> From: owner-ucd at eso.org [mailto:owner-ucd at eso.org] On Behalf 
> Of Andrea Preite Martinez
> Sent: 01 December 2005 17:56
> To: ucd at ivoa.net
> Subject: VOConcepts ...
> 
> Tony, Doug,
> 
> with the VOEvent meeting approaching, I sent a draft document 
> to the chairman of the VOEvent WG concerning "concepts and 
> objects" and the way they could semantically and 
> syntactically be represented in VOEvents.
> 
> The document is still in the form of a "personal note" in the 
> sense that it should be considered as a personal contribution 
> to the upcoming meeting (after an exchange of mail on 
> "processes" with Rick Hessman).
> 
> I'm working to transform this "personal draft" into a 
> IVOA-Note to be distributed and discussed within the WG. 
> Meanwile, I took the first comments from Rick and Doug 
> already into account ... and put the document in the present 
> form in the UCD page
> 
> http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD
> 
> Latest documents:
> The IVOA Standard Vocabulary Version 0.4 (20051201)
> 
> Cheers,
> 
> Andrea
> 
> ==============================================================
> ================
> Andrea Preite Martinez                  
> andrea.preitemartinez at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma                              CDS :+33.3.90242473
> ==============================================================
> ================
> 
> 
> 


From dtody at nrao.edu  Thu Dec  1 10:22:33 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 11:22:33 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
 <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
Message-ID: <Pine.LNX.4.63.0512011110030.21971@oak>

I suspect we are headed towards something like that.  Probably what is 
needed is to define the information in some simple, stable,
technology-independent fashion which we (IVOA) control, then auto-generate
the namespaces and mappings in several popular forms such as OWL, RDF,
etc., for use at runtime by implementations.  Perhaps also in HTML, for
human viewing of the terminology and dictionaries.  It should be possible
to use the information without having to adopt some complex inference
framework, but we don't want to prevent people from doing so either.   Doug


On Thu, 1 Dec 2005, Elizabeth Auden wrote:
>> We don't want to build this vocabulary (which will evolve constantly) into
>> each service implementation, so it needs to be possible to download these
>> mappings via the network, and cache the translation table in the service.
>> They need to be in a standard form which the service code can deal with,
>> probably something based on XML.
>
> Perhaps OWL or RDF triples?
>
> --
> Elizabeth Auden, MSSL
> Holmbury St. Mary, Dorking RH5 6NT
> Tel: +44 (0)1483 204 276
> eSDO Technical Lead, AstroGrid Developer
>


From dtody at nrao.edu  Thu Dec  1 10:22:33 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 11:22:33 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
 <Pine.OSF.4.61.0512011804000.1138617@msslai.mssl.ucl.ac.uk>
Message-ID: <Pine.LNX.4.63.0512011110030.21971@oak>

I suspect we are headed towards something like that.  Probably what is 
needed is to define the information in some simple, stable,
technology-independent fashion which we (IVOA) control, then auto-generate
the namespaces and mappings in several popular forms such as OWL, RDF,
etc., for use at runtime by implementations.  Perhaps also in HTML, for
human viewing of the terminology and dictionaries.  It should be possible
to use the information without having to adopt some complex inference
framework, but we don't want to prevent people from doing so either.   Doug


On Thu, 1 Dec 2005, Elizabeth Auden wrote:
>> We don't want to build this vocabulary (which will evolve constantly) into
>> each service implementation, so it needs to be possible to download these
>> mappings via the network, and cache the translation table in the service.
>> They need to be in a standard form which the service code can deal with,
>> probably something based on XML.
>
> Perhaps OWL or RDF triples?
>
> --
> Elizabeth Auden, MSSL
> Holmbury St. Mary, Dorking RH5 6NT
> Tel: +44 (0)1483 204 276
> eSDO Technical Lead, AstroGrid Developer
>


From seaman at noao.edu  Thu Dec  1 11:30:21 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 12:30:21 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain> <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>

Another example is the characterization of filters for direct  
imaging.  For instance, the NOAO Mosaic camera team maintains a list  
of filters that includes both a long identifier - unique but hard to  
remember - as well as a short identifier, such as "R".  Each short  
identifier may correspond to several long identifiers, that is, to  
several individual filters.

If UCDs were used to create and track such lists, one could attempt  
to achieve the same many-to-one mapping by relying on the  
hierarchical nature of UCDs:   
filter.R.this_is_a_specific_wideband_R_filter.  This has problems on  
both ends.  First, there will often be a redundant prefix like  
"filter." and second, who is to say that it is the "R-ness" of the  
filter that we wish to capture in a short nickname?  Perhaps we  
rather need to capture the "wideband-ness" of the filter.  The  
problem with relying on a hierarchy in a single namespace is  
precisely that only one hierarchy exists per namespace.  On the other  
hand, multiple mappings are trivial with multiple namespaces.

The essential nature of a viable solution will be some mechanism for  
multiple authorities to maintain multiple non-local lists that permit  
such niceties as versioning.  In the absence of such a mechanism,  
separate projects will field separate, non-interoperable solutions.

The trouble with anecdotal examples is that they are too easy to  
gather.  The difficulty with this mechanism (whether realized as UCD  
namespaces or as RDF or as brute-force lists of aliases) will not be  
encountered when distinguishing between "stars" and "galaxies", but  
in the more obscure questions of art as referred to by George.

Rob
seaman at noao.edu


From seaman at noao.edu  Thu Dec  1 11:30:21 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 1 Dec 2005 12:30:21 -0700
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011029230.21971@oak>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu> <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain> <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
Message-ID: <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>

Another example is the characterization of filters for direct  
imaging.  For instance, the NOAO Mosaic camera team maintains a list  
of filters that includes both a long identifier - unique but hard to  
remember - as well as a short identifier, such as "R".  Each short  
identifier may correspond to several long identifiers, that is, to  
several individual filters.

If UCDs were used to create and track such lists, one could attempt  
to achieve the same many-to-one mapping by relying on the  
hierarchical nature of UCDs:   
filter.R.this_is_a_specific_wideband_R_filter.  This has problems on  
both ends.  First, there will often be a redundant prefix like  
"filter." and second, who is to say that it is the "R-ness" of the  
filter that we wish to capture in a short nickname?  Perhaps we  
rather need to capture the "wideband-ness" of the filter.  The  
problem with relying on a hierarchy in a single namespace is  
precisely that only one hierarchy exists per namespace.  On the other  
hand, multiple mappings are trivial with multiple namespaces.

The essential nature of a viable solution will be some mechanism for  
multiple authorities to maintain multiple non-local lists that permit  
such niceties as versioning.  In the absence of such a mechanism,  
separate projects will field separate, non-interoperable solutions.

The trouble with anecdotal examples is that they are too easy to  
gather.  The difficulty with this mechanism (whether realized as UCD  
namespaces or as RDF or as brute-force lists of aliases) will not be  
encountered when distinguishing between "stars" and "galaxies", but  
in the more obscure questions of art as referred to by George.

Rob
seaman at noao.edu


From dtody at nrao.edu  Thu Dec  1 12:37:16 2005
From: dtody at nrao.edu (Doug Tody)
Date: Thu, 1 Dec 2005 13:37:16 -0700 (MST)
Subject: VOConcepts paper
In-Reply-To: <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>
References: <7573af2b982bfbfa9a1e1527f636caf1@cacr.caltech.edu>
 <Pine.LNX.4.63.0511302237020.3333@localhost.localdomain>
 <85E8B01E-D234-4673-BA76-D35993631810@noao.edu> <Pine.LNX.4.63.0512011029230.21971@oak>
 <73396BC8-CC96-4987-9CB0-3E12145CEA78@noao.edu>
Message-ID: <Pine.LNX.4.63.0512011315170.21971@oak>

Right!  This is the classical problem of explicit hierarchy versus flat
or mostly-flat namespaces which are associated in a more general fashion
(e.g., hierarchical versus relational structures).  Unless you are
trying to model a single complex entity it is almost always better
to use the relational approach where simple, well-defined entites are
associated.  This allows more complex relationships to be described,
permits multiple views of the same data, and in some cases can permit
inference.  The namespace/mapping approach is a good one for vocabularies.
For structured data one does much the same thing, but the namespace in
this case is a component data model.  - Doug



On Thu, 1 Dec 2005, Rob Seaman wrote:
> If UCDs were used to create and track such lists, one could attempt to 
> achieve the same many-to-one mapping by relying on the hierarchical nature of 
> UCDs:  filter.R.this_is_a_specific_wideband_R_filter.  This has problems on 
> both ends.  First, there will often be a redundant prefix like "filter." and 
> second, who is to say that it is the "R-ness" of the filter that we wish to 
> capture in a short nickname?  Perhaps we rather need to capture the 
> "wideband-ness" of the filter.  The problem with relying on a hierarchy in a 
> single namespace is precisely that only one hierarchy exists per namespace. 
> On the other hand, multiple mappings are trivial with multiple namespaces.


From Tony.Linde at leicester.ac.uk  Thu Dec  1 12:58:31 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Thu, 1 Dec 2005 20:58:31 -0000
Subject: VOConcepts paper
In-Reply-To: <Pine.LNX.4.63.0512011315170.21971@oak>
Message-ID: <004f01c5f6b9$fca52070$0b01a8c0@marindi>

My own view is that the single hierarchical approach is fine for a well
controlled and well defined area: we can define the account systems for a
company using a relational or set of hierarchical structures because it is a
relatively closed problem with one authority who can decide how things will
be represented. For a wide range of groups tackling different problems and
who do not closely interact or are not under a single authority then you
have to accept that each group will define structures that suit their own
field; in this case you need to be able to namespace those structures and
then, when you need to, define how those namespaces are related.

This is now coming up in the semantic web field - there were quite a few
papers at ISWC2005 dealing with ontology interoperability and how systems
can work with multiple overlapping ontologies.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-ucd at eso.org [mailto:owner-ucd at eso.org] On Behalf 
> Of Doug Tody
> Sent: 01 December 2005 20:37
> To: Rob Seaman
> Cc: ucd at ivoa.net
> Subject: Re: VOConcepts paper
> 
> Right!  This is the classical problem of explicit hierarchy 
> versus flat or mostly-flat namespaces which are associated in 
> a more general fashion (e.g., hierarchical versus relational 
> structures).  Unless you are trying to model a single complex 
> entity it is almost always better to use the relational 
> approach where simple, well-defined entites are associated.  
> This allows more complex relationships to be described, 
> permits multiple views of the same data, and in some cases 
> can permit inference.  The namespace/mapping approach is a 
> good one for vocabularies.
> For structured data one does much the same thing, but the 
> namespace in this case is a component data model.  - Doug
> 
> 
> 
> On Thu, 1 Dec 2005, Rob Seaman wrote:
> > If UCDs were used to create and track such lists, one could 
> attempt to 
> > achieve the same many-to-one mapping by relying on the hierarchical 
> > nature of
> > UCDs:  filter.R.this_is_a_specific_wideband_R_filter.  This has 
> > problems on both ends.  First, there will often be a 
> redundant prefix 
> > like "filter." and second, who is to say that it is the "R-ness" of 
> > the filter that we wish to capture in a short nickname?  Perhaps we 
> > rather need to capture the "wideband-ness" of the filter.  
> The problem 
> > with relying on a hierarchy in a single namespace is 
> precisely that only one hierarchy exists per namespace.
> > On the other hand, multiple mappings are trivial with 
> multiple namespaces.
> 


From abdixul at qon.lao.net  Thu Dec  1 13:55:13 2005
From: abdixul at qon.lao.net (Marisol)
Date: Thu, 01 Dec 2005 23:55:13 +0200
Subject: ineffective Get an inexpensive price on your next style. belittle
Message-ID: <6C0F4AD9.AD5C76B@qon.lao.net>

You know how you've always desired an expensive timepiece but didn't have
enough dough? I think I may have stumbled on a solution.
You are very important to me so I want to tell you about this excellent
deal!

You no longer need tons of currency to purchase the fashion you desire!
I don't want you to torture yourself any longer, you ought to have an
highly delicate piece!
This dealer has been operating for over 19 years and can count on hundreds
of happy regulars.

amfv  http://rewxlwvp.halcyonglisten.com

I know this fashion accessory will make everyday at work nicer and I can't
wait to see it!

'And when are you going to hear at full, true, and particular account of
the life and adventures of Oliver Twist?' asked Grimwig of Mr. Brownlow, at
the conclusion of the meal; looking sideways at Oliver, as he resumed his
subject. 


fbwait  fbmunmap  eruliaf HZ04 envm  esoterik
`I think they are great nonsense, and I'll thank you not to be silly, and
spoil my fun. Laurie's a nice boy, and I like him, and I won't have any
sentimental stuff about compliments and such rubbish. We'll all be good to
him, because he hasn't got any mother, and he may come over and see us,
mayn't he, Marmee?' 
`Yes, Jo, your little RING is very welcome, and I hope Meg will remember
that children should be children as long as they can.' 


From genova at cluster.u-strasbg.fr  Thu Dec  1 22:21:00 2005
From: genova at cluster.u-strasbg.fr (Francoise Genova)
Date: Fri, 2 Dec 2005 07:21:00 +0100 (MET)
Subject: Object types
Message-ID: <200512020621.jB26L0927788@astro.u-strasbg.fr>

The list of object types in SIMBAD can be found at 
http://simbad.u-strasbg.fr/guide/chF.htx
an example is given below

It is maintained, i.e. we include new object types from the scanning
of published papers, but it remains fairly stable. 

We have made choices on the 'granularity' of the list, and more 
details or additional branches could be included in some of the branches.
The example I show is for instance not complete for the X-ray objects I
think.

Of course there are problems with a strictly hierarchical representation
of the object types. For the moment we have pragmatic short-cuts 
and there are on-going tests on building ontologies.

Andrea has used the list to build a more formal representation of
object types (with some updates/additions I suppose). It would
be interesting to check this list for the object types required by
VOEvent -  are there many additions/changes required?

Object types are a relatively simple case and it is certainly 
worth trying to create a single list for the sake of interoperability. 
I have the impression that it is possible.

Cheers
Francoise

 12.13.02.0:	  SB            SB*     Spectroscopic binary
 12.13.11.0:      CataclyV*     CV*     Cataclysmic Variable Star
 12.13.11.2:        DQHer       DQ*     Cataclysmic Var. DQ Her type
 12.13.11.3:        AMHer       AM*     Cataclysmic Var. AM Her type
 12.13.11.5:        Nova-like   NL*     Nova-like Star
 12.13.11.6:        Nova        No*     Nova
 12.13.11.7:        DwarfNova   DN*     Dwarf Nova
 12.13.12.0:      XB            XB*     X-ray Binary
 12.13.12.2:        LMXB        LXB     Low Mass X-ray Binary
 12.13.12.3:        HMXB        HXB     High Mass X-ray Binary






From dtody at nrao.edu  Fri Dec  2 08:03:37 2005
From: dtody at nrao.edu (Doug Tody)
Date: Fri, 2 Dec 2005 09:03:37 -0700 (MST)
Subject: Object types
In-Reply-To: <200512020621.jB26L0927788@astro.u-strasbg.fr>
References: <200512020621.jB26L0927788@astro.u-strasbg.fr>
Message-ID: <Pine.LNX.4.63.0512020858170.3333@localhost.localdomain>

Francoise - this looks great.  My main concern is the use of the
characters '*' and '?' in the "condensed" names.  While I understand the
short names are intended for things like table columns, they could be
used for input as well.  These are common characters in pattern matching
templates, and whenever we search based on text patterns, we might want
to use a template of some sort.   - Doug


On Fri, 2 Dec 2005, Francoise Genova wrote:

> The list of object types in SIMBAD can be found at
> http://simbad.u-strasbg.fr/guide/chF.htx
> an example is given below
>
> It is maintained, i.e. we include new object types from the scanning
> of published papers, but it remains fairly stable.
>
> We have made choices on the 'granularity' of the list, and more
> details or additional branches could be included in some of the branches.
> The example I show is for instance not complete for the X-ray objects I
> think.
>
> Of course there are problems with a strictly hierarchical representation
> of the object types. For the moment we have pragmatic short-cuts
> and there are on-going tests on building ontologies.
>
> Andrea has used the list to build a more formal representation of
> object types (with some updates/additions I suppose). It would
> be interesting to check this list for the object types required by
> VOEvent -  are there many additions/changes required?
>
> Object types are a relatively simple case and it is certainly
> worth trying to create a single list for the sake of interoperability.
> I have the impression that it is possible.
>
> Cheers
> Francoise
>
> 12.13.02.0:	  SB            SB*     Spectroscopic binary
> 12.13.11.0:      CataclyV*     CV*     Cataclysmic Variable Star
> 12.13.11.2:        DQHer       DQ*     Cataclysmic Var. DQ Her type
> 12.13.11.3:        AMHer       AM*     Cataclysmic Var. AM Her type
> 12.13.11.5:        Nova-like   NL*     Nova-like Star
> 12.13.11.6:        Nova        No*     Nova
> 12.13.11.7:        DwarfNova   DN*     Dwarf Nova
> 12.13.12.0:      XB            XB*     X-ray Binary
> 12.13.12.2:        LMXB        LXB     Low Mass X-ray Binary
> 12.13.12.3:        HMXB        HXB     High Mass X-ray Binary
>
>
>
>
>


From genova at cluster.u-strasbg.fr  Sun Dec  4 01:16:59 2005
From: genova at cluster.u-strasbg.fr (Francoise Genova)
Date: Sun, 4 Dec 2005 10:16:59 +0100 (MET)
Subject: Object types
Message-ID: <200512040916.jB49GxL18153@astro.u-strasbg.fr>

Hi Doug,

I just sent the SIMBAD list as is for information.
Andrea already told me about the potential problem with '*' and
'?' - we had to build three-letter names for SIMBAD
but this constraint does not apply for a more general usage
and one can very well define more suitable 'short names'. 

I cannot access Andrea's
document from here but I think that he has added a column
containing 'short names' in the present version of
his  preliminary document following your remark that 
they are needed.

Cheers
Francoise


From pdidelon at cea.fr  Mon Dec  5 08:26:18 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Mon, 05 Dec 2005 17:26:18 +0100
Subject: VOConcepts ...
In-Reply-To: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>
References: <20051201185557.v68rwj5lak08s0ks@webmail.sic.rm.cnr.it>
Message-ID: <43946A2A.5090800@cea.fr>

Hi,

Andrea Preite Martinez wrote:

> Tony, Doug,
> 
> with the VOEvent meeting approaching, I sent a draft document to the 
> chairman of the VOEvent WG concerning "concepts and objects" and the way 
> they could semantically and syntactically be represented in VOEvents.
> 
> The document is still in the form of a "personal note" in the sense that 
> it should be considered as a personal contribution to the upcoming 
> meeting (after an exchange of mail on "processes" with Rick Hessman).
> 
> I'm working to transform this "personal draft" into a IVOA-Note to be 
> distributed and discussed within the WG. Meanwile, I took the first 
> comments from Rick and Doug already into account ... and put the 
> document in the present form in the UCD page
for further comments?
> 
> http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD
> 
> Latest documents:
> The IVOA Standard Vocabulary Version 0.4 (20051201)
I am very disturbed by the fact that the same "thing"/"concept" can be represented
in two way :

Extinction or absorption	phys.absorption
Acceleration			phys.acceleration
OR
Generic absorption of wave or particle	process.absorption
Acceleration (particles, ..)		process.acceleration

what is the distinction between them?

Is there any plan to construct a list for the category "photometric filter"
which cyclically reappear in UCD discussion? ;-)
> 
> Cheers,
> 
> Andrea
> 
> ============================================================================== 
> 
> Andrea Preite Martinez                  
> andrea.preitemartinez at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma                              CDS :+33.3.90242473
> ============================================================================== 
> 
> 
> 
best regards,
-- 
Pierre	DIDELON