From andrea.preitemartinez at iasf-roma.inaf.it Mon Jul 17 02:01:14 2006 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Mon, 17 Jul 2006 11:01:14 +0200 Subject: RFMs (Requests for modification) on the List of UCD-words Message-ID: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> RFMs (Requests for modification) on the List of UCD-words ========================================================= Dear all, You can find at http://www.ivoa.net/twiki/bin/view/IVOA/UCDwordsRFM a list of proposed requests (RFMs) to modify/add the present standard list of ucd-words: The UCD1+ controlled vocabulary, Vers. 1.11 - IVOA Recommendation 31 December 2005 ( http://www.ivoa.net/Documents/latest/UCDlist.html ). The RFMs were collected over the past few month, from suggestions coming from various members of the IVOA community. The list has been presented at the UCD-session in Victoria (see the presentation of the original list at http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD ), and corrected taking into account the discussions during the meeting within the WG and with the Theory IG. Other suggestions have been added to describe attributes used by some Data Models. The list is open for discussion in accordance with the approved standard procedure: Maintenance of the list of UCD words, Version 1.20 - IVOA Recommendation 28 May 2006 (http://www.ivoa.net/Documents/latest/UCDlistMaintenance.html ). Due to web security problems, for the moment we discourage the usage of the web-based form for submitting RFMs. So we can consider the present list of RFMs as a collective effort of the community, not requiring a private personal answer (see par. 2.2 and 2.3 of the maintenance document). For the time being, all the RFMs and all the corresponding answers will be grouped together in a public document. Other RFMs could be proposed during the discussion phase, so that we can consider this document as a temporary repository of all proposed RFMs. Due to the holiday period, I propose to leave the discussion (and the possibility to include other RFMs in the present list) open till August 15. Then I will propose to the WG a revised version of the UCD1+ controlled vocabulary. Cheers, Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4651 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242473 I-00133 Roma Cell.1 :+39.320.43.15.383 Cell.2 :+39. =================================================================================== From ndelmott at eso.org Mon Jul 17 05:34:11 2006 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Mon, 17 Jul 2006 14:34:11 +0200 Subject: observation proposal and name of the observer In-Reply-To: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: <44BB83C3.3010702@eso.org> Dear Andreas, all, Thanks a lot for the new list of proposed requests. I'd like to comment on the following two points: - What is the difference between 'title of an observation proposal' and 'name of an observation proposal'? So far I would not have expected any difference but with the introduction of the new UCD word obs.proposal, it seems it is possible to construct both meta.title;obs.proposal and meta.id;obs.proposal Maybe someone could provide an example, in case there is a difference of meaning between those two UCDs? I just cannot see the difference... (given that the proposal code is already defined by meta.code;obs.proposal). By the way, what about the 'abstract of the observation proposal'? meta.abstract;obs.proposal? - Name of the observer: so far it has been obs.observer but if we introduce meta.id.PI, meta.id.Coi for human beings, why not meta.id.Observer;obs? Thanks, Cheers, Nausicaa Andrea Preite Martinez said the following on 07/17/2006 11:01 AM: > RFMs (Requests for modification) on the List of UCD-words > ========================================================= > > > Dear all, > > You can find at http://www.ivoa.net/twiki/bin/view/IVOA/UCDwordsRFM a > list of proposed requests (RFMs) to modify/add the present standard list > of ucd-words: The UCD1+ controlled vocabulary, Vers. 1.11 - IVOA > Recommendation 31 December 2005 ( > http://www.ivoa.net/Documents/latest/UCDlist.html ). > > The RFMs were collected over the past few month, from suggestions coming > from various members of the IVOA community. > > The list has been presented at the UCD-session in Victoria (see the > presentation of the original list at > http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD ), and corrected > taking into account the discussions during the meeting within the WG and > with the Theory IG. Other suggestions have been added to describe > attributes used by some Data Models. > > The list is open for discussion in accordance with the approved standard > procedure: Maintenance of the list of UCD words, Version 1.20 - IVOA > Recommendation 28 May 2006 > (http://www.ivoa.net/Documents/latest/UCDlistMaintenance.html ). > > Due to web security problems, for the moment we discourage the usage of > the web-based form for submitting RFMs. So we can consider the present > list of RFMs as a collective effort of the community, not requiring a > private personal answer (see par. 2.2 and 2.3 of the maintenance > document). For the time being, all the RFMs and all the corresponding > answers will be grouped together in a public document. Other RFMs could > be proposed during the discussion phase, so that we can consider this > document as a temporary repository of all proposed RFMs. > > Due to the holiday period, I propose to leave the discussion (and the > possibility to include other RFMs in the present list) open till August 15. > > Then I will propose to the WG a revised version of the UCD1+ controlled > vocabulary. > > Cheers, > > Andrea > > =================================================================================== > > Andrea Preite Martinez > andrea.preitemartinez at iasf-roma.inaf.it > IASF Tel.IASF:+39.06.4993.4651 > Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242473 > I-00133 Roma Cell.1 :+39.320.43.15.383 > Cell.2 :+39. > =================================================================================== > > > -- Dr Nausicaa Delmotte @..@ ndelmott at eso.org ESO Archive Service Developer (----) Tel: +49 (0)89 3200 6418 Karl-Schwarzschild-Str. 2 ( >__< ) Fax: +49 (0)89 3200 6677 D-85748 Garching bei Muenchen ^^ ~~ ^^ http://www.eso.org/~ndelmott/ From seaman at noao.edu Mon Jul 17 08:35:16 2006 From: seaman at noao.edu (Rob Seaman) Date: Mon, 17 Jul 2006 08:35:16 -0700 Subject: RFMs (Requests for modification) on the List of UCD-words In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: Hi Andrea, > proposed requests (RFMs) to modify/add the present standard list of > ucd-words Should we be gratified or distressed at the large number of proposed changes? :-) I understand from the maintenance agreement, that the end result here will be a new list with an incremented version number. I don't see any discussion for supporting older versions indefinitely in service of content previously created. Comments? > Other suggestions have been added to describe attributes used by > some Data Models. Does this represent a change in the original coherent genesis of the UCDs as astronomical column headings? What does "some" Data Models mean? Do UCDs now have a mandate to support all IVOA (or even astronomical) DMs? From the RFMs: >> A complete proposed revision of the time branch can be found in a >> TN at the end of this document. I support drawing a clearer distinction between duration and epoch. What is the benefit, however, to keep both notions under the same "time" hierarchy? Why not, for example, simply "duration.event" and "epoch.event"? I'm also concerned that this list is growing too rapidly. Timelike modifiers will often appear in combination with other UCDs - they are more like adjectives and adverbs than nouns and verbs. As with other fundamental concepts, time descriptors should remain elegantly simple and sparse. >> Other ?computational? and ?cosmological? words were discussed in >> Victoria, also with the Theory IG. We need an input from them in >> order to revise/complete the list I have the same response to these terms as I do to VOEvent's - don't these really represent a different namespace? In particular, shouldn't the Theory group be maintaining this list if they are its primary target? Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From hessman at Astro.physik.Uni-Goettingen.DE Thu Jul 20 04:59:55 2006 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Thu, 20 Jul 2006 13:59:55 +0200 Subject: RFMs (Requests for modification) on the List of UCD-words In-Reply-To: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: <1EF62D83-43EB-4974-920D-56F4F625D0D8@astro.physik.uni-goettingen.de> Just a few points: - DM/DE: Why phys.matter.dark and phys.DarkEnergy rather than phys.DarkMatter and phys.energy.dark? - capitalization: I'm confused again about the question of capitalizations: e.g. why phys.DarkEnergy but phys.cosmology.hubble rather than phys.darkEnergy and phys.cosmology.Hubble (or phys.cosmology.hubbleConstant)? Yes, this is a can of worms (e.g. em.uv instead of em.UV), but there should at least be some system (e.g. if you normally write things capitalized, then capitalize, e.g. UV instead of uv, Hubble instead of hubble). - add: obs.calib.flat.sky obs.calib.flat.dome obs.calib.flat.internal phys.particle.neutrino (there are neutrino telescopes) - flux density: Solution (c) using composite UCD's will be cumbersome: phot.flux.perDecade is then phot.flux;em.decade? - length: I'm also confused again about why we have stat.probability (11 letters) and time.duration (8) but comp.sim, and time.expo rather than stat.prob, time.dur, comp.simulation (10 letters) and time.exposure (8). Remind me why we sometimes need to save a few bytes of memory by using occational abbreviations (independent of the length) and can't simply spell things out .... ;-) Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.preitemartinez at iasf-roma.inaf.it Tue Jul 25 02:26:34 2006 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Tue, 25 Jul 2006 11:26:34 +0200 Subject: observation proposal and name of the observer In-Reply-To: <44BB83C3.3010702@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> Message-ID: <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> Quoting Nausicaa Delmotte : > - What is the difference between 'title of an observation proposal' > and 'name of an observation proposal'? > > So far I would not have expected any difference but with the introduction > of the new UCD word obs.proposal, it seems it is possible to construct both > meta.title;obs.proposal > and > meta.id;obs.proposal > > Maybe someone could provide an example, in case there is a difference > of meaning > between those two UCDs? I just cannot see the difference... (given > that the proposal > code is already defined by meta.code;obs.proposal). > Don't forget catalogues! According to the Catalogue DM, a catalogue can have: - a name (in the description text)/a title (in the XML schema) - an identifier - a shortName My point of view: - The title of XYZ is a string describing the content of XYZ, as in a scientific paper (actually this is the origin of the ucd); - the name/identifier is a string uniquely identifying XYZ, as for humans (e.g.: Andrea Preite Martinez is my name/identifier); - a short name for me could be APM (and my "code" could be my social security number!). I don't see the difference between name and identifier. Another point is that a "possible" ucd is not necessarily a "good" ucd!! > By the way, what about the 'abstract of the observation proposal'? > meta.abstract;obs.proposal? > Good, why not? > - Name of the observer: so far it has been obs.observer > but if we introduce meta.id.PI, meta.id.Coi for human beings, > why not meta.id.Observer;obs? > The ucd-word obs.observer was introduced to describe the observer/discoverer of a source, then extended to PIs. By the way, not always the PI is also the Observer, so why not have both! Cheers, Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4651 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242473 I-00133 Roma Cell.1 :+39.320.43.15.383 Cell.2 :+39. =================================================================================== From Alberto.Micol at eso.org Tue Jul 25 04:51:19 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 25 Jul 2006 13:51:19 +0200 Subject: observation proposal and name of the observer In-Reply-To: <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> Message-ID: <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> On Jul 25, 2006, at 11:26, Andrea Preite Martinez wrote: > Quoting Nausicaa Delmotte : > > >> - What is the difference between 'title of an observation proposal' >> and 'name of an observation proposal'? >> >> So far I would not have expected any difference but with the >> introduction >> of the new UCD word obs.proposal, it seems it is possible to >> construct both >> meta.title;obs.proposal >> and >> meta.id;obs.proposal I would personally use: meta.title;obs.proposal for the title of a proposal meta.id;obs.proposal for the proposal id I do not understand what "name of an observational proposal" actually means. Where did you get this one from Nausicaa? >> Maybe someone could provide an example, in case there is a >> difference >> of meaning >> between those two UCDs? I just cannot see the difference... (given >> that the proposal >> code is already defined by meta.code;obs.proposal). >> > Don't forget catalogues! According to the Catalogue DM, a catalogue > can have: > > - a name (in the description text)/a title (in the XML schema) > - an identifier > - a shortName > Yes, in the case of catalogues there is a third quantity to consider, the shortname, which does not exist for proposals. What should we be using here? catalog title -> meta.title;meta.table catalog id -> meta.id;meta.table catalog shortname -> ??? One could think of using meta.id;meta.table also for the shortname given that shortname is an alias of the catalog id (which happens to be just more human-readable). But I am against that for the reasons given below... > My point of view: > - The title of XYZ is a string describing the content of XYZ, as in > a scientific paper (actually this is the origin of the ucd); > - the name/identifier is a string uniquely identifying XYZ, as for > humans (e.g.: Andrea Preite Martinez is my name/identifier); To me names and identifiers are quite different. The name might not be unique, while an identifier better be. In the human case, the name is not unique, but the name with the birth certificate makes that person unique. What is unique is the identifier assigned to such human when registering to whatever service, e.g. the social security number. An identifiers will differ for the same human within different services. Alike, a catalogue which is colloquially called Veron 2006, will have different IDs in different services. I think a meta.nickname could be useful here. Aside note: I would drop meta.dataset in favour of meta.id;obs > - a short name for me could be APM (and my "code" could be my > social security number!). > I don't see the difference between name and identifier. meta.code is described as: "Code or flag" Given that meta.id to me is the identifier, I am pushed to think that Code is not an identifier. Hence I always interpret meta.code as a flag. As such, as a UCD user, I am not going to assign the ucd meta.code to a social security number. I guess that after this email, I will be invited not to assign ucds any longer... ;-) But the truth is that the UCD assignment is a highly subjective matter. > Another point is that a "possible" ucd is not necessarily a "good" > ucd!! And how can a user tell wether her choice resulted into a "good" ucd? Alberto From seaman at noao.edu Tue Jul 25 07:26:33 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 07:26:33 -0700 Subject: observation proposal and name of the observer In-Reply-To: <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> Message-ID: <4CC29EE4-F187-41B3-BC3E-99D24FC29211@noao.edu> On Jul 25, 2006, at 4:51 AM, Alberto Micol wrote: > I would personally use: > > meta.title;obs.proposal for the title of a proposal > meta.id;obs.proposal for the proposal id > > I do not understand what "name of an observational proposal" > actually means. Me neither. The most obvious distinction between the title of a proposal and its ID is that the title is assigned by the proposing astronomer(s) and the ID is assigned by the observatory acting as an agent for the resources the astronomers are proposing to use. > Yes, in the case of catalogues there is a third quantity to consider, > the shortname, which does not exist for proposals. A name, including a shortname, applies to a resource - whoever assigns the name. A catalog, instrument, telescope, filter, etc., is a resource. A proposal is not. A proposal can ultimately result in the production of a resource, such as the catalogs or images published by a survey project. These may themselves have a shortname - a nickname - that might colloquially also be applied to the project or even the proposal. For example, Nick Suntzeff is the P.I. for a proposal entitled: "The w Project: Measuring the Equation of State of the Universe". NOAO assigned the ID "2002B-0007" (see http://www.noao.edu/perl/abstract? 2002B-0007). This has resulted in a survey - and the fruits of that survey - also known as "ESSENCE" (http://www.ctio.noao.edu/essence). One might then choose to refer to the "ESSENCE proposal abstract" (a casually assigned name), for instance, even though the acronym came about after the original project was proposed. > To me names and identifiers are quite different. > The name might not be unique, while an identifier better be. Agree with this, but this distinction is only the result of who assigns the token. A name can be assigned by any party involved in some resource transaction. An identifier may only be assigned by the holder of the resource. Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndelmott at eso.org Tue Jul 25 07:56:21 2006 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Tue, 25 Jul 2006 16:56:21 +0200 Subject: observation proposal and name of the observer In-Reply-To: <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> Message-ID: <44C63115.8020101@eso.org> Alberto Micol said the following on 07/25/2006 01:51 PM: > I do not understand what "name of an observational proposal" actually > means. > Where did you get this one from Nausicaa? From the list of examples at http://www.ivoa.net/twiki/bin/view/IVOA/UCDwordsRFM meta.id;obs.proposal | name of the proposal meta.code;obs.proposal | proposal code etc. > I am not going to assign the ucd meta.code to a social security number I agree that meta.code should be reserved for flags and codes but not IDs. Though for ESO proposals, the difference between code and ID is getting fuzzy since the ID is itself composed of codes, e.g. 074.D-0761 [0-2]PP.[A-Z]-NNNN [0-2] is the type of program (normal, large...) [A-Z] is the category of the proposal (cosmology, stars, galaxies...) But the whole is greater than the sum of the parts, so the proposal ID should correspond to meta.id;obs.proposal and not meta.code;obs.proposal. >> Another point is that a "possible" ucd is not necessarily a "good" ucd!! > > And how can a user tell wether her choice resulted into a "good" ucd? I would say that the more examples we give in the reference UCD document, the easiest it is for a user to be convinced that the correct UCD was assigned. Nausicaa From Alberto.Micol at eso.org Tue Jul 25 08:18:06 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 25 Jul 2006 17:18:06 +0200 Subject: observation proposal and name of the observer In-Reply-To: <4CC29EE4-F187-41B3-BC3E-99D24FC29211@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <4CC29EE4-F187-41B3-BC3E-99D24FC29211@noao.edu> Message-ID: <20B7754A-5A0F-4ADC-92B0-B3EAC704378C@eso.org> On Jul 25, 2006, at 16:26, Rob Seaman wrote: > On Jul 25, 2006, at 4:51 AM, Alberto Micol wrote: > >> I would personally use: >> >> meta.title;obs.proposal for the title of a proposal >> meta.id;obs.proposal for the proposal id >> >> I do not understand what "name of an observational proposal" >> actually means. > > Me neither. > > The most obvious distinction between the title of a proposal and > its ID is that the title is assigned by the proposing astronomer(s) > and the ID is assigned by the observatory acting as an agent for > the resources the astronomers are proposing to use. > >> Yes, in the case of catalogues there is a third quantity to consider, >> the shortname, which does not exist for proposals. > > A name, including a shortname, applies to a resource - whoever > assigns the name. A catalog, instrument, telescope, filter, etc., > is a resource. A proposal is not. A proposal can ultimately > result in the production of a resource, such as the catalogs or > images published by a survey project. These may themselves have a > shortname - a nickname - that might colloquially also be applied to > the project or even the proposal. > > For example, Nick Suntzeff is the P.I. for a proposal entitled: > "The w Project: Measuring the Equation of State of the Universe". > NOAO assigned the ID "2002B-0007" (see http://www.noao.edu/perl/ > abstract?2002B-0007). This has resulted in a survey - and the > fruits of that survey - also known as "ESSENCE" (http:// > www.ctio.noao.edu/essence). One might then choose to refer to the > "ESSENCE proposal abstract" (a casually assigned name), for > instance, even though the acronym came about after the original > project was proposed. Also in the HST case short names are used (e.g. UDF, HDF, etc), and one could say "the UDF proposal" actually referring to a list of proposals that composed the entire project. (I do not actually remember now whether UDF was developed through various proposals and not only one, but the important thing is that it CAN happen). Just to say that a nickname is a loose concept, which does not necessarily map one to one with the described entity (the proposal in this case). Hence I think it would be better to have a meta.nickname ucd... >> To me names and identifiers are quite different. >> The name might not be unique, while an identifier better be. > > Agree with this, but this distinction is only the result of who > assigns the token. A name can be assigned by any party involved in > some resource transaction. An identifier may only be assigned by > the holder of the resource. Fully agreed. > Rob Seaman > NOAO Alberto -- Alberto Micol ESA/DSCI/RSSD/SNM From seaman at noao.edu Tue Jul 25 08:36:19 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 08:36:19 -0700 Subject: observation proposal and name of the observer In-Reply-To: <44C63115.8020101@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> Message-ID: <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> On Jul 25, 2006, at 7:56 AM, Nausicaa Delmotte wrote: > I would say that the more examples we give in the reference UCD > document, > the easiest it is for a user to be convinced that the correct UCD > was assigned. If the logic behind UCDs may only be correctly grasped by example, UCDs might just as well be opaque tokens assigned randomly. It seems to me that the whole point of the exercise is to illuminate (at least partially) the intrinsic structure that underlies astronomical nomenclature. Given a categorized value, what are the rules for constructing quantities contingent on that value? Given a complex UCD expression, how does one parse it without consulting documentation such as a master list? Users need to understand other people's UCDs - they may also need to assign their own. UCD fluency won't be established through better documentation (not that this hurts), but rather must be built into the linguistic structure of the "language". Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alberto.Micol at eso.org Tue Jul 25 08:56:11 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 25 Jul 2006 17:56:11 +0200 Subject: observation proposal and name of the observer In-Reply-To: <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 17:36, Rob Seaman wrote: > On Jul 25, 2006, at 7:56 AM, Nausicaa Delmotte wrote: > >> I would say that the more examples we give in the reference UCD >> document, >> the easiest it is for a user to be convinced that the correct UCD >> was assigned. > > If the logic behind UCDs may only be correctly grasped by example, > UCDs might just as well be opaque tokens assigned randomly. It > seems to me that the whole point of the exercise is to illuminate > (at least partially) the intrinsic structure that underlies > astronomical nomenclature. Given a categorized value, what are the > rules for constructing quantities contingent on that value? Given > a complex UCD expression, how does one parse it without consulting > documentation such as a master list? > > Users need to understand other people's UCDs - they may also need > to assign their own. UCD fluency won't be established through > better documentation (not that this hurts), but rather must be > built into the linguistic structure of the "language". I do agree, but ... how to make it happen? I mean, a pragmatic service provider would want to read (and real fast) the existing ucd documentation and start using ucds asap. Kids learn the linguistic structure during their kindergarden phase, using the trial and error method. How can we succeed, that is make such service provider happy, and at the same time reach desired "UCD fluency" without asking the service providers to go through the kindergarden phase? I do agree with Nausicaa, we need more examples, and probably more comprehensive UCD descriptions (not just only the couple of words currently listed for each ucd); not too much, but just enough to not have anyone repeating the same errors again and again, and to avoid confusion (e.g. meta.code while one really means meta.id, meta.id while one really means meta.code, ;-) etc.) Al From roy at cacr.caltech.edu Tue Jul 25 09:07:41 2006 From: roy at cacr.caltech.edu (Roy Williams) Date: Tue, 25 Jul 2006 09:07:41 -0700 Subject: RFMs (Requests for modification) on the List of UCD-words In-Reply-To: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: <65879593-BCAA-414E-BEA7-ACE2A9304141@cacr.caltech.edu> Andrea et al I like the new UCDs, I do not have any problem with approving the new words and the changes. But perhaps I can make a pest of myself by suggesting a couple more. I see we already have P | meta.ref | Reference, or origin P | meta.ref.url | URL, web address, service endpoint and I would like to suggest also for completeness P | meta.ref.uri | URI, universal resource identifier P | meta.ref.ivorn | IVORN, Int. Virtual Obs. Resource Name ivo:// Hope this is not too late. Indeed I have use cases for these if you would like to see that. Roy On Jul 17, 2006, at 2:01 AM, Andrea Preite Martinez wrote: > RFMs (Requests for modification) on the List of UCD-words > ========================================================= > > > Dear all, > > You can find at http://www.ivoa.net/twiki/bin/view/IVOA/ > UCDwordsRFM a list of proposed requests (RFMs) to modify/add the > present standard list of ucd-words: The UCD1+ controlled > vocabulary, Vers. 1.11 - IVOA Recommendation 31 December 2005 > ( http://www.ivoa.net/Documents/latest/UCDlist.html ). California Institute of Technology 626 395 3670 From seaman at noao.edu Tue Jul 25 09:20:53 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 09:20:53 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 8:56 AM, Alberto Micol wrote: > we need more examples, and probably > more comprehensive UCD descriptions (not just only the couple > of words currently listed for each ucd); not too much, but just enough > to not have anyone repeating the same errors again and again, > and to avoid confusion (e.g. meta.code while one really means meta.id, > meta.id while one really means meta.code, ;-) etc.) Well, you might start there. I still have no clue what the distinction is supposed to be between meta.code and meta.id. As a cautionary tale, I highly recommend "The Meaning of Everything" by Simon Winchester. This is the story of the Oxford English Dictionary - the prototypical project that was supposed to take five years, but took fifty - or was it 75 years? - to complete. (Only to start all over again.) UCDs are ultimately derived from the experience of the OED - both are structured word lists, compiled by reference to a body of literature. Rob From roy at cacr.caltech.edu Tue Jul 25 09:48:11 2006 From: roy at cacr.caltech.edu (Roy Williams) Date: Tue, 25 Jul 2006 09:48:11 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 9:20 AM, Rob Seaman wrote: > I still have no clue what the distinction is supposed to be between > meta.code and meta.id. My understanding: -- A code is also called an enumeration or a labeling or a classification. It is tied to a namespace. In the Hubble namespace, galaxies have codes Sa, Sb, SBa, E0 etc etc -- An ID is unique identifier for something that is strongly linked to a namespace. Within the Messier namespace, there are identifiers M31, M51, M87. -- A name is anything that identifies something, need not be unique. Thus a single galaxy can have several names, eq M87 and NGC4486 are different names for the same thing. -- A Title is a multi-word version of a name: "Center of Virgo cluster" would be a title for M87. California Institute of Technology 626 395 3670 From seaman at noao.edu Tue Jul 25 10:43:43 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 10:43:43 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: <674900CA-4073-41C9-AD02-BD494AF95D3C@noao.edu> Roy wrote: > -- A code is also called an enumeration or a labeling or a > classification. It is tied to a namespace. In the Hubble namespace, > galaxies have codes Sa, Sb, SBa, E0 etc etc > > -- An ID is unique identifier for something that is strongly linked > to a namespace. Within the Messier namespace, there are identifiers > M31, M51, M87. Ok. How about, rather, meta.classID and meta.nameID? It seems to me that the "IDness" of something is the part that will suggest to most users that this is something from a controlled namespace, whereas a class is a type of something and a name denotes a specific something, either of which might require a controlled ID. > -- A name is anything that identifies something, need not be > unique. Thus a single galaxy can have several names, eq M87 and > NGC4486 are different names for the same thing. > > -- A Title is a multi-word version of a name: "Center of Virgo > cluster" would be a title for M87. But surely a name can be multi-word and a title, e.g., "Macbeth" need not. And nicknames can indeed be "short names", such as "B" instead of "Johnson B", but can also be longer, such as "The Scottish Play". The general question of names is an issue of alias management. An ID is only unique in the sense of being guaranteed not to apply to more than one item. On the other hand, a single item may have multiple IDs - multiple aliases. Rob From Alberto.Micol at eso.org Wed Jul 26 03:02:58 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 26 Jul 2006 12:02:58 +0200 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 18:48, Roy Williams wrote: > > My understanding: > -- A code is also called an enumeration or a labeling or a > classification. It is tied to a namespace. In the Hubble namespace, > galaxies have codes Sa, Sb, SBa, E0 etc etc > -- An ID is unique identifier for something that is strongly linked > to a namespace. Within the Messier namespace, there are identifiers > M31, M51, M87. > > -- A name is anything that identifies something, need not be > unique. Thus a single galaxy can have several names, eq M87 and > NGC4486 are different names for the same thing. > > -- A Title is a multi-word version of a name: "Center of Virgo > cluster" would be a title for M87. > > I think that the above sentences put together by Roy are a perfect example of how to write ucd descriptions. I would not agree though on the Hubble classification because the right ucd is in that case meta.code.class, and not just meta.code P | meta.code | code is also called an enumeration or a labeling | of a flag. An example is the PixFlags in the SIAP1.0 | standard, which is a flag whose meaning is well | understood within that protocol. P | meta.code.class | Classification, tide to a namespace. | In the Hubble namespace, galaxies have codes | Sa, Sb, SBa, E0 etc P | meta.id | An ID is unique identifier for something that | is strongly linked to a namespace. Within the | Messier namespace, there are identifiers M31, M51, M87 P | meta.title | A Title is a multi-word version of a name: | "Center of Virgo cluster" would be a title for M87 P | meta.name | *** currently to be found under meta.id, *** | *** but probably it deserves its own ucd? *** It would be nice to extend the descriptions of all other ucds in a similar way, wouldn't it? Alberto From seaman at noao.edu Wed Jul 26 07:42:54 2006 From: seaman at noao.edu (Rob Seaman) Date: Wed, 26 Jul 2006 07:42:54 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> On Jul 26, 2006, at 3:02 AM, Alberto Micol wrote: > I think that the above sentences put together by Roy > are a perfect example of how to write ucd descriptions. Roy certainly has a good knack for simplifying a description. But that doesn't excuse IVOA from a responsibility to simplify the things actually being described. Design elegance is a goal, not just a serendipitous occurrence. > I would not agree though on the Hubble classification because the > right ucd is in that case meta.code.class, and not just meta.code Every message in this discussion seems to bring additional nuances of usage. One suspects the latest is still not a complete list - either in the sense of capturing all ID-like meta UCD constructs that have been proposed - or in the sense of providing orthonormal basis vectors suitable for describing pertinent metadata. > P | meta.code | code is also called an > enumeration or a labeling > | of a flag. An example is > the PixFlags in the SIAP1.0 > | standard, which is a flag > whose meaning is well > | understood within that > protocol. > > P | meta.code.class | Classification, tide to a > namespace. > | In the Hubble namespace, > galaxies have codes > | Sa, Sb, SBa, E0 etc Users are not going to understand these distinctions. You will see as many instances of meta.class.code as you do of meta.code.class. You may see more meta.class instances than anything else. Users are going to have a hard enough time understanding why they need the "meta" at all - ain't all UCDs about metadata? If "code" is synonymous with "enum", why not use "enum"? The word "code" is horrifically overloaded for other purposes. Also, isn't an enumeration a modifier of the base UCD? A classification certainly could be open-ended - that is, not a code at all. How about: meta.class;enum Which opens up the possibility of constructs like: meta.id;enum Which might be used to limit the allowed values to a specific list of observing proposals, for instance - say, to those belonging to a particular investigator or pertaining to a particular telescope. > P | meta.id | An ID is unique identifier > for something that > | is strongly linked to a > namespace. Within the > | Messier namespace, there > are identifiers M31, M51, M87 If a namelike UCD ID requires only two levels, why should a classlike UCD ID require three? > P | meta.title | A Title is a multi-word > version of a name: > | "Center of Virgo cluster" > would be a title for M87 Again - multi-word is not the essence of the issue. That the title is assigned by the investigators, not by the observatory, likely is. > P | meta.name | *** currently to be found > under meta.id, *** > | *** but probably it > deserves its own ucd? *** So UCDs that don't actually exist are to be described, too? To the extent that this particular pseudo-meta-notional-concept exists, you are most closely describing a shortname here, and the title is an instance of a long name - or simply a "name". In fact, all of these concepts could be said to be subclassed from "name". > It would be nice to extend the descriptions of all other ucds > in a similar way, wouldn't it? Such descriptions certainly won't hurt, but the things being described should first be as carefully specified as anything in IVOA. From the discussion it seems obvious that no user can ever be trusted with either the generation or interpretation of a UCD. It also suggests that a UCD validator would be immediately seized upon by a grateful IVOA developer community. The question of versioning UCDs takes on new importance, too, since subtleties like those above will lead to perennial pressure to revise the roster of UCDs, not only to add new descriptors to open up new vistas of domain space, but also to clarify previous blessed descriptors. The meaning of a UCD construct seems unsettlingly unstable. Rob From ndelmott at eso.org Thu Jul 27 03:29:03 2006 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Thu, 27 Jul 2006 12:29:03 +0200 Subject: classification and code In-Reply-To: <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> Message-ID: <44C8956F.9050101@eso.org> Rob Seaman said the following on 07/26/2006 04:42 PM: >> P | meta.code | code is also called an >> enumeration or a labeling >> | of a flag. An example is the >> PixFlags in the SIAP1.0 >> | standard, which is a flag >> whose meaning is well >> | understood within that protocol. >> >> P | meta.code.class | Classification, tide to a >> namespace. >> | In the Hubble namespace, >> galaxies have codes >> | Sa, Sb, SBa, E0 etc > > Users are not going to understand these distinctions. You will see as > many instances of meta.class.code as you do of meta.code.class. You may > see more meta.class instances than anything else. It is true that there is some ambiguity regarding meta.code and meta.code.class According to the dictionary, a code is a coding system used for transmitting messages requiring brevity or secrecy and a classification is a group of people or things arranged by class or category Thus a classification code is a code representing a category within a classification system. Suppose a user wants to classify a list of observations according to the following categories: 'SCIENCE', 'CALIB', 'ACQUISITON', 'TEST', etc. Those categories are words, not codes. So a new UCD like meta.class is needed. Though one could argue that words are part of the language system and language is a code for human thought ;-) If you assign shortcuts to the categories ('S' for 'SCIENCE', 'C' for 'CALIB' etc), the correct UCD is meta.class.code since the UCD recommendation says that the order of the atoms induces a hierarchy. Now the question is: are there codes that are not part of a classification system? If no, I would drop meta.code and all columns previously assigned meta.code.class should be re-assigned meta.class.code. > If "code" is synonymous with "enum", why not use "enum"? The word > "code" is horrifically overloaded for other purposes. Strictly speaking, I don't think a code is an enumeration. An enumeration is a detailed account, in which each thing is specially noticed. However, 'code' and 'enumeration' are sometimes used for the same thing. It is something like a language shortcut. It is not necessarily bad to mention such words in the definition of a UCD since people are used to deal with both of them, it could even make things easier for the user but only AS LONG AS EXAMPLES ARE GIVEN since some other people might start wondering about the true meaning of words in the definition. In that case, they will have to look at the examples and that will solve the ambiguity. That is why we need to provide examples. Learning by example allows to grasp the basics more easily. > Also, isn't an > enumeration a modifier of the base UCD? A classification certainly > could be open-ended - that is, not a code at all. How about: > > meta.class;enum I would say an enumeration is a list of things (codes or not) that belong to a common category within a classification system... > Which opens up the possibility of constructs like: > > meta.id;enum > > Which might be used to limit the allowed values to a specific list of > observing proposals, for instance - say, to those belonging to a > particular investigator or pertaining to a particular telescope. ... so here I would assign meta.id;meta.class or better meta.id;meta.class.part? Cheers Nausicaa From seaman at noao.edu Thu Jul 27 09:22:34 2006 From: seaman at noao.edu (Rob Seaman) Date: Thu, 27 Jul 2006 09:22:34 -0700 Subject: classification and code In-Reply-To: <44C8956F.9050101@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> <44C8956F.9050101@eso.org> Message-ID: <66680684-D374-4A7F-8B7B-EFBCAAB805E6@noao.edu> Hi Nausicaa, I said: >> Users are not going to understand these distinctions. and you said a bunch of stuff ending with: > ... so here I would assign meta.id;meta.class or better > meta.id;meta.class.part? This was in regard to some specific question of usage that is neither here nor there at the moment. What is both here and there is that you - an expert for some question of IVOA usage - are now arguing with yourself about the correct answer. I'll say it again - users are not going to understand how to use UCDs. This may or may not be acceptable - it depends on whether our users will ever need to either parse other people's UCDs or create their own. More generally, the question isn't whether UCDs make *any* sense - there appears to be a defensible logic behind every individual distinction that is raised. The question is whether the same logic lies behind all choices - and further, whether the logic is stable over time. I recommend: 1) UCD versioning be explicit 2) a UCD verification web service be assigned high priority (that is, beyond checking syntax and atoms) > a code is a coding system used for transmitting messages requiring > brevity or secrecy But "code" also means a way of representing a message in a new medium, e.g., ASCII. Code can be error detecting or correcting. A code can be a statute, that is, a rule. I see the "brevity or secrecy" definition at dictionary.com, but there many other entries: genetic code, a patient whose heart has stopped :-(, source code. In the latter case, we learn that the word "code" is used specifically to distinguish instructions from data ("often used in opposition to 'data'") - and yet, here we are applying it to (meta)data. I'm getting a code in my node. It isn't that I don't understand the logic behind the choice - it's that many other choices are just as logical. Why make *this* choice? And second, why specifically meta.code.class and *not* meta.class.code or meta.class;meta.code or any of the many other variations? Given the basic rules of UCDs and a list of atoms, a motivated undergraduate should be able to recreate the master list to a couple of sigma - heck, an awk script should be able to do it. But what is one to do with a rule like: "after the primary word, subsequent words are arranged by decreasing importance"? Importance to whom and for what purpose? The rule for atoms is even more ethereal: "the order of these atoms induces a hierarchy". We also have: "the only possible validation of the selected vocabulary is to check its ability to describe properly a wide range of real data". Check how? Define "properly". How about a Monte Carlo test of a canonical ensemble of alternate vocabularies? :-) Perhaps I simply don't understand the rules yet. I doubt I'm alone. I think there is reason to worry if the official list of UCDs can only be justified a posteriori. If nobody else feels the same way, by all means continue with the adoption of the new batch. In addition to versioning and a verification tool, I would then reiterate my support for retaining the ability to namespace UCDs. > If you assign shortcuts to the categories ('S' for 'SCIENCE', 'C' > for 'CALIB' etc), > the correct UCD is meta.class.code since the UCD recommendation > says that the order > of the atoms induces a hierarchy. Ok. So *both* meta.code.class and meta.class.code are to be supported? And is our software supposed to be able to understand these razor thin distinctions and do something usefully different? > Now the question is: are there codes that are not part of a > classification system? > If no, I would drop meta.code and all columns previously assigned > meta.code.class > should be re-assigned meta.class.code. Again - versioning. If our databases aren't to be held hostage to the vagaries of future drifts in UCD usage, they need to be able to refer to a specific, permanently stable, list of UCDs that was in effect when the columns were assigned. I suspect I'm not the only archivist to feel a chill at the sight of the word "re-assign" :-) > Strictly speaking, I don't think a code is an enumeration. > An enumeration is a detailed account, in which each thing is > specially noticed. > However, 'code' and 'enumeration' are sometimes used for the same > thing. > It is something like a language shortcut. Ok - I'm all for precision of expression. We have: - a code is a coding system used for transmitting messages requiring brevity or secrecy - a classification is a group of people or things arranged by class or category - an enumeration is a detailed account, in which each thing is specially noticed And we have the rule that "the order of the atoms induces a hierarchy", so each of: meta.code.class.enum, meta.code.enum.class, meta.class.code.enum, meta.class.enum.code, meta.enum.class.code, and meta.enum.code.class are distinctly different in the obvious way :-) > they will have to look at the examples and that will solve the > ambiguity. > That is why we need to provide examples. > Learning by example allows to grasp the basics more easily. I haven't heard anybody argue against providing examples, but the assertions of solving ambiguities and grasping basics should be challenged by providing IVOA beta testers with such examples and requesting they a) describe the meaning of the examples, and b) use the knowledge gained to create new UCDs representing various concepts. I suggest this worthy goal continue: "The UCD working group has tried to resist the temptation to allow the UCD syntax to be overly expressive." Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jul 27 10:05:09 2006 From: Hessman at Astro.physik.Uni-Goettingen.DE (Hessman Frederic) Date: Thu, 27 Jul 2006 19:05:09 +0200 Subject: classification and code In-Reply-To: <66680684-D374-4A7F-8B7B-EFBCAAB805E6@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> <44C8956F.9050101@eso.org> <66680684-D374-4A7F-8B7B-EFBCAAB805E6@noao.edu> Message-ID: <588E1AA5-556C-45ED-A04C-81A6FF94D77E@Astro.physik.Uni-Goettingen.DE> Rob Seaman said... > I'll say it again - users are not going to understand how to use > UCDs. This may or may not be acceptable - it depends on whether > our users will ever need to either parse other people's UCDs or > create their own. > > More generally, the question isn't whether UCDs make *any* sense - > there appears to be a defensible logic behind every individual > distinction that is raised. The question is whether the same logic > lies behind all choices - and further, whether the logic is stable > over time. > It isn't that I don't understand the logic behind the choice - it's > that many other choices are just as logical. Why make *this* choice? I think there is reason to worry if the official list of UCDs can only be justified a posteriori. If nobody else feels the same way, by all means continue with the adoption of the new batch. In addition to versioning and a verification tool, I would then reiterate my support for retaining the ability to namespace UCDs. > Ok. So *both* meta.code.class and meta.class.code are to be > supported? And is our software supposed to be able to understand > these razor thin distinctions and do something usefully different? > Hear, hear! Yes, the list grew in a historical process somewhat organically, and yes we're all very glad that those who worked in the initial development who had other things on their minds than the long- term evolution, but THIS is the time - not later - to put the UCDs on a firm symantic foundation and to clearly define how to create words and how to clearly avoid naming a concept for which no one can find a meaning. Thus, I concur that we need a very explicit and robust set of guidelines, e.g. > I recommend: 0) UCD constructions DO NOT constitute a formal ontology and are intended to be clearly understood, chosen, and interpreted within the context they are used. Thus, long _generic_ hierarchies should be avoided (e.g. meta.code.class.enum). > 1) UCD versioning be explicit > 2) a UCD verification web service be assigned high priority (that > is, beyond checking syntax and atoms) 3) UCD words can be contracted if the uncontracted form is cumbersome or if the contracted form constitutes a commonly recognized abbreviation, but uncontracted forms are to be preferred and length is per se no constraint. 4) UCD words should not be contracted if the meaning of the contraction is not clearly understood outside of it's immediate context ... Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.preitemartinez at iasf-roma.inaf.it Mon Jul 17 02:01:14 2006 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Mon, 17 Jul 2006 11:01:14 +0200 Subject: RFMs (Requests for modification) on the List of UCD-words Message-ID: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> RFMs (Requests for modification) on the List of UCD-words ========================================================= Dear all, You can find at http://www.ivoa.net/twiki/bin/view/IVOA/UCDwordsRFM a list of proposed requests (RFMs) to modify/add the present standard list of ucd-words: The UCD1+ controlled vocabulary, Vers. 1.11 - IVOA Recommendation 31 December 2005 ( http://www.ivoa.net/Documents/latest/UCDlist.html ). The RFMs were collected over the past few month, from suggestions coming from various members of the IVOA community. The list has been presented at the UCD-session in Victoria (see the presentation of the original list at http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD ), and corrected taking into account the discussions during the meeting within the WG and with the Theory IG. Other suggestions have been added to describe attributes used by some Data Models. The list is open for discussion in accordance with the approved standard procedure: Maintenance of the list of UCD words, Version 1.20 - IVOA Recommendation 28 May 2006 (http://www.ivoa.net/Documents/latest/UCDlistMaintenance.html ). Due to web security problems, for the moment we discourage the usage of the web-based form for submitting RFMs. So we can consider the present list of RFMs as a collective effort of the community, not requiring a private personal answer (see par. 2.2 and 2.3 of the maintenance document). For the time being, all the RFMs and all the corresponding answers will be grouped together in a public document. Other RFMs could be proposed during the discussion phase, so that we can consider this document as a temporary repository of all proposed RFMs. Due to the holiday period, I propose to leave the discussion (and the possibility to include other RFMs in the present list) open till August 15. Then I will propose to the WG a revised version of the UCD1+ controlled vocabulary. Cheers, Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4651 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242473 I-00133 Roma Cell.1 :+39.320.43.15.383 Cell.2 :+39. =================================================================================== From ndelmott at eso.org Mon Jul 17 05:34:11 2006 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Mon, 17 Jul 2006 14:34:11 +0200 Subject: observation proposal and name of the observer In-Reply-To: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: <44BB83C3.3010702@eso.org> Dear Andreas, all, Thanks a lot for the new list of proposed requests. I'd like to comment on the following two points: - What is the difference between 'title of an observation proposal' and 'name of an observation proposal'? So far I would not have expected any difference but with the introduction of the new UCD word obs.proposal, it seems it is possible to construct both meta.title;obs.proposal and meta.id;obs.proposal Maybe someone could provide an example, in case there is a difference of meaning between those two UCDs? I just cannot see the difference... (given that the proposal code is already defined by meta.code;obs.proposal). By the way, what about the 'abstract of the observation proposal'? meta.abstract;obs.proposal? - Name of the observer: so far it has been obs.observer but if we introduce meta.id.PI, meta.id.Coi for human beings, why not meta.id.Observer;obs? Thanks, Cheers, Nausicaa Andrea Preite Martinez said the following on 07/17/2006 11:01 AM: > RFMs (Requests for modification) on the List of UCD-words > ========================================================= > > > Dear all, > > You can find at http://www.ivoa.net/twiki/bin/view/IVOA/UCDwordsRFM a > list of proposed requests (RFMs) to modify/add the present standard list > of ucd-words: The UCD1+ controlled vocabulary, Vers. 1.11 - IVOA > Recommendation 31 December 2005 ( > http://www.ivoa.net/Documents/latest/UCDlist.html ). > > The RFMs were collected over the past few month, from suggestions coming > from various members of the IVOA community. > > The list has been presented at the UCD-session in Victoria (see the > presentation of the original list at > http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006UCD ), and corrected > taking into account the discussions during the meeting within the WG and > with the Theory IG. Other suggestions have been added to describe > attributes used by some Data Models. > > The list is open for discussion in accordance with the approved standard > procedure: Maintenance of the list of UCD words, Version 1.20 - IVOA > Recommendation 28 May 2006 > (http://www.ivoa.net/Documents/latest/UCDlistMaintenance.html ). > > Due to web security problems, for the moment we discourage the usage of > the web-based form for submitting RFMs. So we can consider the present > list of RFMs as a collective effort of the community, not requiring a > private personal answer (see par. 2.2 and 2.3 of the maintenance > document). For the time being, all the RFMs and all the corresponding > answers will be grouped together in a public document. Other RFMs could > be proposed during the discussion phase, so that we can consider this > document as a temporary repository of all proposed RFMs. > > Due to the holiday period, I propose to leave the discussion (and the > possibility to include other RFMs in the present list) open till August 15. > > Then I will propose to the WG a revised version of the UCD1+ controlled > vocabulary. > > Cheers, > > Andrea > > =================================================================================== > > Andrea Preite Martinez > andrea.preitemartinez at iasf-roma.inaf.it > IASF Tel.IASF:+39.06.4993.4651 > Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242473 > I-00133 Roma Cell.1 :+39.320.43.15.383 > Cell.2 :+39. > =================================================================================== > > > -- Dr Nausicaa Delmotte @..@ ndelmott at eso.org ESO Archive Service Developer (----) Tel: +49 (0)89 3200 6418 Karl-Schwarzschild-Str. 2 ( >__< ) Fax: +49 (0)89 3200 6677 D-85748 Garching bei Muenchen ^^ ~~ ^^ http://www.eso.org/~ndelmott/ From seaman at noao.edu Mon Jul 17 08:35:16 2006 From: seaman at noao.edu (Rob Seaman) Date: Mon, 17 Jul 2006 08:35:16 -0700 Subject: RFMs (Requests for modification) on the List of UCD-words In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: Hi Andrea, > proposed requests (RFMs) to modify/add the present standard list of > ucd-words Should we be gratified or distressed at the large number of proposed changes? :-) I understand from the maintenance agreement, that the end result here will be a new list with an incremented version number. I don't see any discussion for supporting older versions indefinitely in service of content previously created. Comments? > Other suggestions have been added to describe attributes used by > some Data Models. Does this represent a change in the original coherent genesis of the UCDs as astronomical column headings? What does "some" Data Models mean? Do UCDs now have a mandate to support all IVOA (or even astronomical) DMs? From the RFMs: >> A complete proposed revision of the time branch can be found in a >> TN at the end of this document. I support drawing a clearer distinction between duration and epoch. What is the benefit, however, to keep both notions under the same "time" hierarchy? Why not, for example, simply "duration.event" and "epoch.event"? I'm also concerned that this list is growing too rapidly. Timelike modifiers will often appear in combination with other UCDs - they are more like adjectives and adverbs than nouns and verbs. As with other fundamental concepts, time descriptors should remain elegantly simple and sparse. >> Other ?computational? and ?cosmological? words were discussed in >> Victoria, also with the Theory IG. We need an input from them in >> order to revise/complete the list I have the same response to these terms as I do to VOEvent's - don't these really represent a different namespace? In particular, shouldn't the Theory group be maintaining this list if they are its primary target? Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From hessman at Astro.physik.Uni-Goettingen.DE Thu Jul 20 04:59:55 2006 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Thu, 20 Jul 2006 13:59:55 +0200 Subject: RFMs (Requests for modification) on the List of UCD-words In-Reply-To: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: <1EF62D83-43EB-4974-920D-56F4F625D0D8@astro.physik.uni-goettingen.de> Just a few points: - DM/DE: Why phys.matter.dark and phys.DarkEnergy rather than phys.DarkMatter and phys.energy.dark? - capitalization: I'm confused again about the question of capitalizations: e.g. why phys.DarkEnergy but phys.cosmology.hubble rather than phys.darkEnergy and phys.cosmology.Hubble (or phys.cosmology.hubbleConstant)? Yes, this is a can of worms (e.g. em.uv instead of em.UV), but there should at least be some system (e.g. if you normally write things capitalized, then capitalize, e.g. UV instead of uv, Hubble instead of hubble). - add: obs.calib.flat.sky obs.calib.flat.dome obs.calib.flat.internal phys.particle.neutrino (there are neutrino telescopes) - flux density: Solution (c) using composite UCD's will be cumbersome: phot.flux.perDecade is then phot.flux;em.decade? - length: I'm also confused again about why we have stat.probability (11 letters) and time.duration (8) but comp.sim, and time.expo rather than stat.prob, time.dur, comp.simulation (10 letters) and time.exposure (8). Remind me why we sometimes need to save a few bytes of memory by using occational abbreviations (independent of the length) and can't simply spell things out .... ;-) Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.preitemartinez at iasf-roma.inaf.it Tue Jul 25 02:26:34 2006 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Tue, 25 Jul 2006 11:26:34 +0200 Subject: observation proposal and name of the observer In-Reply-To: <44BB83C3.3010702@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> Message-ID: <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> Quoting Nausicaa Delmotte : > - What is the difference between 'title of an observation proposal' > and 'name of an observation proposal'? > > So far I would not have expected any difference but with the introduction > of the new UCD word obs.proposal, it seems it is possible to construct both > meta.title;obs.proposal > and > meta.id;obs.proposal > > Maybe someone could provide an example, in case there is a difference > of meaning > between those two UCDs? I just cannot see the difference... (given > that the proposal > code is already defined by meta.code;obs.proposal). > Don't forget catalogues! According to the Catalogue DM, a catalogue can have: - a name (in the description text)/a title (in the XML schema) - an identifier - a shortName My point of view: - The title of XYZ is a string describing the content of XYZ, as in a scientific paper (actually this is the origin of the ucd); - the name/identifier is a string uniquely identifying XYZ, as for humans (e.g.: Andrea Preite Martinez is my name/identifier); - a short name for me could be APM (and my "code" could be my social security number!). I don't see the difference between name and identifier. Another point is that a "possible" ucd is not necessarily a "good" ucd!! > By the way, what about the 'abstract of the observation proposal'? > meta.abstract;obs.proposal? > Good, why not? > - Name of the observer: so far it has been obs.observer > but if we introduce meta.id.PI, meta.id.Coi for human beings, > why not meta.id.Observer;obs? > The ucd-word obs.observer was introduced to describe the observer/discoverer of a source, then extended to PIs. By the way, not always the PI is also the Observer, so why not have both! Cheers, Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4651 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242473 I-00133 Roma Cell.1 :+39.320.43.15.383 Cell.2 :+39. =================================================================================== From Alberto.Micol at eso.org Tue Jul 25 04:51:19 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 25 Jul 2006 13:51:19 +0200 Subject: observation proposal and name of the observer In-Reply-To: <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> Message-ID: <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> On Jul 25, 2006, at 11:26, Andrea Preite Martinez wrote: > Quoting Nausicaa Delmotte : > > >> - What is the difference between 'title of an observation proposal' >> and 'name of an observation proposal'? >> >> So far I would not have expected any difference but with the >> introduction >> of the new UCD word obs.proposal, it seems it is possible to >> construct both >> meta.title;obs.proposal >> and >> meta.id;obs.proposal I would personally use: meta.title;obs.proposal for the title of a proposal meta.id;obs.proposal for the proposal id I do not understand what "name of an observational proposal" actually means. Where did you get this one from Nausicaa? >> Maybe someone could provide an example, in case there is a >> difference >> of meaning >> between those two UCDs? I just cannot see the difference... (given >> that the proposal >> code is already defined by meta.code;obs.proposal). >> > Don't forget catalogues! According to the Catalogue DM, a catalogue > can have: > > - a name (in the description text)/a title (in the XML schema) > - an identifier > - a shortName > Yes, in the case of catalogues there is a third quantity to consider, the shortname, which does not exist for proposals. What should we be using here? catalog title -> meta.title;meta.table catalog id -> meta.id;meta.table catalog shortname -> ??? One could think of using meta.id;meta.table also for the shortname given that shortname is an alias of the catalog id (which happens to be just more human-readable). But I am against that for the reasons given below... > My point of view: > - The title of XYZ is a string describing the content of XYZ, as in > a scientific paper (actually this is the origin of the ucd); > - the name/identifier is a string uniquely identifying XYZ, as for > humans (e.g.: Andrea Preite Martinez is my name/identifier); To me names and identifiers are quite different. The name might not be unique, while an identifier better be. In the human case, the name is not unique, but the name with the birth certificate makes that person unique. What is unique is the identifier assigned to such human when registering to whatever service, e.g. the social security number. An identifiers will differ for the same human within different services. Alike, a catalogue which is colloquially called Veron 2006, will have different IDs in different services. I think a meta.nickname could be useful here. Aside note: I would drop meta.dataset in favour of meta.id;obs > - a short name for me could be APM (and my "code" could be my > social security number!). > I don't see the difference between name and identifier. meta.code is described as: "Code or flag" Given that meta.id to me is the identifier, I am pushed to think that Code is not an identifier. Hence I always interpret meta.code as a flag. As such, as a UCD user, I am not going to assign the ucd meta.code to a social security number. I guess that after this email, I will be invited not to assign ucds any longer... ;-) But the truth is that the UCD assignment is a highly subjective matter. > Another point is that a "possible" ucd is not necessarily a "good" > ucd!! And how can a user tell wether her choice resulted into a "good" ucd? Alberto From seaman at noao.edu Tue Jul 25 07:26:33 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 07:26:33 -0700 Subject: observation proposal and name of the observer In-Reply-To: <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> Message-ID: <4CC29EE4-F187-41B3-BC3E-99D24FC29211@noao.edu> On Jul 25, 2006, at 4:51 AM, Alberto Micol wrote: > I would personally use: > > meta.title;obs.proposal for the title of a proposal > meta.id;obs.proposal for the proposal id > > I do not understand what "name of an observational proposal" > actually means. Me neither. The most obvious distinction between the title of a proposal and its ID is that the title is assigned by the proposing astronomer(s) and the ID is assigned by the observatory acting as an agent for the resources the astronomers are proposing to use. > Yes, in the case of catalogues there is a third quantity to consider, > the shortname, which does not exist for proposals. A name, including a shortname, applies to a resource - whoever assigns the name. A catalog, instrument, telescope, filter, etc., is a resource. A proposal is not. A proposal can ultimately result in the production of a resource, such as the catalogs or images published by a survey project. These may themselves have a shortname - a nickname - that might colloquially also be applied to the project or even the proposal. For example, Nick Suntzeff is the P.I. for a proposal entitled: "The w Project: Measuring the Equation of State of the Universe". NOAO assigned the ID "2002B-0007" (see http://www.noao.edu/perl/abstract? 2002B-0007). This has resulted in a survey - and the fruits of that survey - also known as "ESSENCE" (http://www.ctio.noao.edu/essence). One might then choose to refer to the "ESSENCE proposal abstract" (a casually assigned name), for instance, even though the acronym came about after the original project was proposed. > To me names and identifiers are quite different. > The name might not be unique, while an identifier better be. Agree with this, but this distinction is only the result of who assigns the token. A name can be assigned by any party involved in some resource transaction. An identifier may only be assigned by the holder of the resource. Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndelmott at eso.org Tue Jul 25 07:56:21 2006 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Tue, 25 Jul 2006 16:56:21 +0200 Subject: observation proposal and name of the observer In-Reply-To: <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> Message-ID: <44C63115.8020101@eso.org> Alberto Micol said the following on 07/25/2006 01:51 PM: > I do not understand what "name of an observational proposal" actually > means. > Where did you get this one from Nausicaa? From the list of examples at http://www.ivoa.net/twiki/bin/view/IVOA/UCDwordsRFM meta.id;obs.proposal | name of the proposal meta.code;obs.proposal | proposal code etc. > I am not going to assign the ucd meta.code to a social security number I agree that meta.code should be reserved for flags and codes but not IDs. Though for ESO proposals, the difference between code and ID is getting fuzzy since the ID is itself composed of codes, e.g. 074.D-0761 [0-2]PP.[A-Z]-NNNN [0-2] is the type of program (normal, large...) [A-Z] is the category of the proposal (cosmology, stars, galaxies...) But the whole is greater than the sum of the parts, so the proposal ID should correspond to meta.id;obs.proposal and not meta.code;obs.proposal. >> Another point is that a "possible" ucd is not necessarily a "good" ucd!! > > And how can a user tell wether her choice resulted into a "good" ucd? I would say that the more examples we give in the reference UCD document, the easiest it is for a user to be convinced that the correct UCD was assigned. Nausicaa From Alberto.Micol at eso.org Tue Jul 25 08:18:06 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 25 Jul 2006 17:18:06 +0200 Subject: observation proposal and name of the observer In-Reply-To: <4CC29EE4-F187-41B3-BC3E-99D24FC29211@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <4CC29EE4-F187-41B3-BC3E-99D24FC29211@noao.edu> Message-ID: <20B7754A-5A0F-4ADC-92B0-B3EAC704378C@eso.org> On Jul 25, 2006, at 16:26, Rob Seaman wrote: > On Jul 25, 2006, at 4:51 AM, Alberto Micol wrote: > >> I would personally use: >> >> meta.title;obs.proposal for the title of a proposal >> meta.id;obs.proposal for the proposal id >> >> I do not understand what "name of an observational proposal" >> actually means. > > Me neither. > > The most obvious distinction between the title of a proposal and > its ID is that the title is assigned by the proposing astronomer(s) > and the ID is assigned by the observatory acting as an agent for > the resources the astronomers are proposing to use. > >> Yes, in the case of catalogues there is a third quantity to consider, >> the shortname, which does not exist for proposals. > > A name, including a shortname, applies to a resource - whoever > assigns the name. A catalog, instrument, telescope, filter, etc., > is a resource. A proposal is not. A proposal can ultimately > result in the production of a resource, such as the catalogs or > images published by a survey project. These may themselves have a > shortname - a nickname - that might colloquially also be applied to > the project or even the proposal. > > For example, Nick Suntzeff is the P.I. for a proposal entitled: > "The w Project: Measuring the Equation of State of the Universe". > NOAO assigned the ID "2002B-0007" (see http://www.noao.edu/perl/ > abstract?2002B-0007). This has resulted in a survey - and the > fruits of that survey - also known as "ESSENCE" (http:// > www.ctio.noao.edu/essence). One might then choose to refer to the > "ESSENCE proposal abstract" (a casually assigned name), for > instance, even though the acronym came about after the original > project was proposed. Also in the HST case short names are used (e.g. UDF, HDF, etc), and one could say "the UDF proposal" actually referring to a list of proposals that composed the entire project. (I do not actually remember now whether UDF was developed through various proposals and not only one, but the important thing is that it CAN happen). Just to say that a nickname is a loose concept, which does not necessarily map one to one with the described entity (the proposal in this case). Hence I think it would be better to have a meta.nickname ucd... >> To me names and identifiers are quite different. >> The name might not be unique, while an identifier better be. > > Agree with this, but this distinction is only the result of who > assigns the token. A name can be assigned by any party involved in > some resource transaction. An identifier may only be assigned by > the holder of the resource. Fully agreed. > Rob Seaman > NOAO Alberto -- Alberto Micol ESA/DSCI/RSSD/SNM From seaman at noao.edu Tue Jul 25 08:36:19 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 08:36:19 -0700 Subject: observation proposal and name of the observer In-Reply-To: <44C63115.8020101@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> Message-ID: <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> On Jul 25, 2006, at 7:56 AM, Nausicaa Delmotte wrote: > I would say that the more examples we give in the reference UCD > document, > the easiest it is for a user to be convinced that the correct UCD > was assigned. If the logic behind UCDs may only be correctly grasped by example, UCDs might just as well be opaque tokens assigned randomly. It seems to me that the whole point of the exercise is to illuminate (at least partially) the intrinsic structure that underlies astronomical nomenclature. Given a categorized value, what are the rules for constructing quantities contingent on that value? Given a complex UCD expression, how does one parse it without consulting documentation such as a master list? Users need to understand other people's UCDs - they may also need to assign their own. UCD fluency won't be established through better documentation (not that this hurts), but rather must be built into the linguistic structure of the "language". Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alberto.Micol at eso.org Tue Jul 25 08:56:11 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 25 Jul 2006 17:56:11 +0200 Subject: observation proposal and name of the observer In-Reply-To: <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 17:36, Rob Seaman wrote: > On Jul 25, 2006, at 7:56 AM, Nausicaa Delmotte wrote: > >> I would say that the more examples we give in the reference UCD >> document, >> the easiest it is for a user to be convinced that the correct UCD >> was assigned. > > If the logic behind UCDs may only be correctly grasped by example, > UCDs might just as well be opaque tokens assigned randomly. It > seems to me that the whole point of the exercise is to illuminate > (at least partially) the intrinsic structure that underlies > astronomical nomenclature. Given a categorized value, what are the > rules for constructing quantities contingent on that value? Given > a complex UCD expression, how does one parse it without consulting > documentation such as a master list? > > Users need to understand other people's UCDs - they may also need > to assign their own. UCD fluency won't be established through > better documentation (not that this hurts), but rather must be > built into the linguistic structure of the "language". I do agree, but ... how to make it happen? I mean, a pragmatic service provider would want to read (and real fast) the existing ucd documentation and start using ucds asap. Kids learn the linguistic structure during their kindergarden phase, using the trial and error method. How can we succeed, that is make such service provider happy, and at the same time reach desired "UCD fluency" without asking the service providers to go through the kindergarden phase? I do agree with Nausicaa, we need more examples, and probably more comprehensive UCD descriptions (not just only the couple of words currently listed for each ucd); not too much, but just enough to not have anyone repeating the same errors again and again, and to avoid confusion (e.g. meta.code while one really means meta.id, meta.id while one really means meta.code, ;-) etc.) Al From roy at cacr.caltech.edu Tue Jul 25 09:07:41 2006 From: roy at cacr.caltech.edu (Roy Williams) Date: Tue, 25 Jul 2006 09:07:41 -0700 Subject: RFMs (Requests for modification) on the List of UCD-words In-Reply-To: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> Message-ID: <65879593-BCAA-414E-BEA7-ACE2A9304141@cacr.caltech.edu> Andrea et al I like the new UCDs, I do not have any problem with approving the new words and the changes. But perhaps I can make a pest of myself by suggesting a couple more. I see we already have P | meta.ref | Reference, or origin P | meta.ref.url | URL, web address, service endpoint and I would like to suggest also for completeness P | meta.ref.uri | URI, universal resource identifier P | meta.ref.ivorn | IVORN, Int. Virtual Obs. Resource Name ivo:// Hope this is not too late. Indeed I have use cases for these if you would like to see that. Roy On Jul 17, 2006, at 2:01 AM, Andrea Preite Martinez wrote: > RFMs (Requests for modification) on the List of UCD-words > ========================================================= > > > Dear all, > > You can find at http://www.ivoa.net/twiki/bin/view/IVOA/ > UCDwordsRFM a list of proposed requests (RFMs) to modify/add the > present standard list of ucd-words: The UCD1+ controlled > vocabulary, Vers. 1.11 - IVOA Recommendation 31 December 2005 > ( http://www.ivoa.net/Documents/latest/UCDlist.html ). California Institute of Technology 626 395 3670 From seaman at noao.edu Tue Jul 25 09:20:53 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 09:20:53 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 8:56 AM, Alberto Micol wrote: > we need more examples, and probably > more comprehensive UCD descriptions (not just only the couple > of words currently listed for each ucd); not too much, but just enough > to not have anyone repeating the same errors again and again, > and to avoid confusion (e.g. meta.code while one really means meta.id, > meta.id while one really means meta.code, ;-) etc.) Well, you might start there. I still have no clue what the distinction is supposed to be between meta.code and meta.id. As a cautionary tale, I highly recommend "The Meaning of Everything" by Simon Winchester. This is the story of the Oxford English Dictionary - the prototypical project that was supposed to take five years, but took fifty - or was it 75 years? - to complete. (Only to start all over again.) UCDs are ultimately derived from the experience of the OED - both are structured word lists, compiled by reference to a body of literature. Rob From roy at cacr.caltech.edu Tue Jul 25 09:48:11 2006 From: roy at cacr.caltech.edu (Roy Williams) Date: Tue, 25 Jul 2006 09:48:11 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 9:20 AM, Rob Seaman wrote: > I still have no clue what the distinction is supposed to be between > meta.code and meta.id. My understanding: -- A code is also called an enumeration or a labeling or a classification. It is tied to a namespace. In the Hubble namespace, galaxies have codes Sa, Sb, SBa, E0 etc etc -- An ID is unique identifier for something that is strongly linked to a namespace. Within the Messier namespace, there are identifiers M31, M51, M87. -- A name is anything that identifies something, need not be unique. Thus a single galaxy can have several names, eq M87 and NGC4486 are different names for the same thing. -- A Title is a multi-word version of a name: "Center of Virgo cluster" would be a title for M87. California Institute of Technology 626 395 3670 From seaman at noao.edu Tue Jul 25 10:43:43 2006 From: seaman at noao.edu (Rob Seaman) Date: Tue, 25 Jul 2006 10:43:43 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: <674900CA-4073-41C9-AD02-BD494AF95D3C@noao.edu> Roy wrote: > -- A code is also called an enumeration or a labeling or a > classification. It is tied to a namespace. In the Hubble namespace, > galaxies have codes Sa, Sb, SBa, E0 etc etc > > -- An ID is unique identifier for something that is strongly linked > to a namespace. Within the Messier namespace, there are identifiers > M31, M51, M87. Ok. How about, rather, meta.classID and meta.nameID? It seems to me that the "IDness" of something is the part that will suggest to most users that this is something from a controlled namespace, whereas a class is a type of something and a name denotes a specific something, either of which might require a controlled ID. > -- A name is anything that identifies something, need not be > unique. Thus a single galaxy can have several names, eq M87 and > NGC4486 are different names for the same thing. > > -- A Title is a multi-word version of a name: "Center of Virgo > cluster" would be a title for M87. But surely a name can be multi-word and a title, e.g., "Macbeth" need not. And nicknames can indeed be "short names", such as "B" instead of "Johnson B", but can also be longer, such as "The Scottish Play". The general question of names is an issue of alias management. An ID is only unique in the sense of being guaranteed not to apply to more than one item. On the other hand, a single item may have multiple IDs - multiple aliases. Rob From Alberto.Micol at eso.org Wed Jul 26 03:02:58 2006 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 26 Jul 2006 12:02:58 +0200 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: On Jul 25, 2006, at 18:48, Roy Williams wrote: > > My understanding: > -- A code is also called an enumeration or a labeling or a > classification. It is tied to a namespace. In the Hubble namespace, > galaxies have codes Sa, Sb, SBa, E0 etc etc > -- An ID is unique identifier for something that is strongly linked > to a namespace. Within the Messier namespace, there are identifiers > M31, M51, M87. > > -- A name is anything that identifies something, need not be > unique. Thus a single galaxy can have several names, eq M87 and > NGC4486 are different names for the same thing. > > -- A Title is a multi-word version of a name: "Center of Virgo > cluster" would be a title for M87. > > I think that the above sentences put together by Roy are a perfect example of how to write ucd descriptions. I would not agree though on the Hubble classification because the right ucd is in that case meta.code.class, and not just meta.code P | meta.code | code is also called an enumeration or a labeling | of a flag. An example is the PixFlags in the SIAP1.0 | standard, which is a flag whose meaning is well | understood within that protocol. P | meta.code.class | Classification, tide to a namespace. | In the Hubble namespace, galaxies have codes | Sa, Sb, SBa, E0 etc P | meta.id | An ID is unique identifier for something that | is strongly linked to a namespace. Within the | Messier namespace, there are identifiers M31, M51, M87 P | meta.title | A Title is a multi-word version of a name: | "Center of Virgo cluster" would be a title for M87 P | meta.name | *** currently to be found under meta.id, *** | *** but probably it deserves its own ucd? *** It would be nice to extend the descriptions of all other ucds in a similar way, wouldn't it? Alberto From seaman at noao.edu Wed Jul 26 07:42:54 2006 From: seaman at noao.edu (Rob Seaman) Date: Wed, 26 Jul 2006 07:42:54 -0700 Subject: observation proposal and name of the observer In-Reply-To: References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> Message-ID: <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> On Jul 26, 2006, at 3:02 AM, Alberto Micol wrote: > I think that the above sentences put together by Roy > are a perfect example of how to write ucd descriptions. Roy certainly has a good knack for simplifying a description. But that doesn't excuse IVOA from a responsibility to simplify the things actually being described. Design elegance is a goal, not just a serendipitous occurrence. > I would not agree though on the Hubble classification because the > right ucd is in that case meta.code.class, and not just meta.code Every message in this discussion seems to bring additional nuances of usage. One suspects the latest is still not a complete list - either in the sense of capturing all ID-like meta UCD constructs that have been proposed - or in the sense of providing orthonormal basis vectors suitable for describing pertinent metadata. > P | meta.code | code is also called an > enumeration or a labeling > | of a flag. An example is > the PixFlags in the SIAP1.0 > | standard, which is a flag > whose meaning is well > | understood within that > protocol. > > P | meta.code.class | Classification, tide to a > namespace. > | In the Hubble namespace, > galaxies have codes > | Sa, Sb, SBa, E0 etc Users are not going to understand these distinctions. You will see as many instances of meta.class.code as you do of meta.code.class. You may see more meta.class instances than anything else. Users are going to have a hard enough time understanding why they need the "meta" at all - ain't all UCDs about metadata? If "code" is synonymous with "enum", why not use "enum"? The word "code" is horrifically overloaded for other purposes. Also, isn't an enumeration a modifier of the base UCD? A classification certainly could be open-ended - that is, not a code at all. How about: meta.class;enum Which opens up the possibility of constructs like: meta.id;enum Which might be used to limit the allowed values to a specific list of observing proposals, for instance - say, to those belonging to a particular investigator or pertaining to a particular telescope. > P | meta.id | An ID is unique identifier > for something that > | is strongly linked to a > namespace. Within the > | Messier namespace, there > are identifiers M31, M51, M87 If a namelike UCD ID requires only two levels, why should a classlike UCD ID require three? > P | meta.title | A Title is a multi-word > version of a name: > | "Center of Virgo cluster" > would be a title for M87 Again - multi-word is not the essence of the issue. That the title is assigned by the investigators, not by the observatory, likely is. > P | meta.name | *** currently to be found > under meta.id, *** > | *** but probably it > deserves its own ucd? *** So UCDs that don't actually exist are to be described, too? To the extent that this particular pseudo-meta-notional-concept exists, you are most closely describing a shortname here, and the title is an instance of a long name - or simply a "name". In fact, all of these concepts could be said to be subclassed from "name". > It would be nice to extend the descriptions of all other ucds > in a similar way, wouldn't it? Such descriptions certainly won't hurt, but the things being described should first be as carefully specified as anything in IVOA. From the discussion it seems obvious that no user can ever be trusted with either the generation or interpretation of a UCD. It also suggests that a UCD validator would be immediately seized upon by a grateful IVOA developer community. The question of versioning UCDs takes on new importance, too, since subtleties like those above will lead to perennial pressure to revise the roster of UCDs, not only to add new descriptors to open up new vistas of domain space, but also to clarify previous blessed descriptors. The meaning of a UCD construct seems unsettlingly unstable. Rob From ndelmott at eso.org Thu Jul 27 03:29:03 2006 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Thu, 27 Jul 2006 12:29:03 +0200 Subject: classification and code In-Reply-To: <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> Message-ID: <44C8956F.9050101@eso.org> Rob Seaman said the following on 07/26/2006 04:42 PM: >> P | meta.code | code is also called an >> enumeration or a labeling >> | of a flag. An example is the >> PixFlags in the SIAP1.0 >> | standard, which is a flag >> whose meaning is well >> | understood within that protocol. >> >> P | meta.code.class | Classification, tide to a >> namespace. >> | In the Hubble namespace, >> galaxies have codes >> | Sa, Sb, SBa, E0 etc > > Users are not going to understand these distinctions. You will see as > many instances of meta.class.code as you do of meta.code.class. You may > see more meta.class instances than anything else. It is true that there is some ambiguity regarding meta.code and meta.code.class According to the dictionary, a code is a coding system used for transmitting messages requiring brevity or secrecy and a classification is a group of people or things arranged by class or category Thus a classification code is a code representing a category within a classification system. Suppose a user wants to classify a list of observations according to the following categories: 'SCIENCE', 'CALIB', 'ACQUISITON', 'TEST', etc. Those categories are words, not codes. So a new UCD like meta.class is needed. Though one could argue that words are part of the language system and language is a code for human thought ;-) If you assign shortcuts to the categories ('S' for 'SCIENCE', 'C' for 'CALIB' etc), the correct UCD is meta.class.code since the UCD recommendation says that the order of the atoms induces a hierarchy. Now the question is: are there codes that are not part of a classification system? If no, I would drop meta.code and all columns previously assigned meta.code.class should be re-assigned meta.class.code. > If "code" is synonymous with "enum", why not use "enum"? The word > "code" is horrifically overloaded for other purposes. Strictly speaking, I don't think a code is an enumeration. An enumeration is a detailed account, in which each thing is specially noticed. However, 'code' and 'enumeration' are sometimes used for the same thing. It is something like a language shortcut. It is not necessarily bad to mention such words in the definition of a UCD since people are used to deal with both of them, it could even make things easier for the user but only AS LONG AS EXAMPLES ARE GIVEN since some other people might start wondering about the true meaning of words in the definition. In that case, they will have to look at the examples and that will solve the ambiguity. That is why we need to provide examples. Learning by example allows to grasp the basics more easily. > Also, isn't an > enumeration a modifier of the base UCD? A classification certainly > could be open-ended - that is, not a code at all. How about: > > meta.class;enum I would say an enumeration is a list of things (codes or not) that belong to a common category within a classification system... > Which opens up the possibility of constructs like: > > meta.id;enum > > Which might be used to limit the allowed values to a specific list of > observing proposals, for instance - say, to those belonging to a > particular investigator or pertaining to a particular telescope. ... so here I would assign meta.id;meta.class or better meta.id;meta.class.part? Cheers Nausicaa From seaman at noao.edu Thu Jul 27 09:22:34 2006 From: seaman at noao.edu (Rob Seaman) Date: Thu, 27 Jul 2006 09:22:34 -0700 Subject: classification and code In-Reply-To: <44C8956F.9050101@eso.org> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> <44C8956F.9050101@eso.org> Message-ID: <66680684-D374-4A7F-8B7B-EFBCAAB805E6@noao.edu> Hi Nausicaa, I said: >> Users are not going to understand these distinctions. and you said a bunch of stuff ending with: > ... so here I would assign meta.id;meta.class or better > meta.id;meta.class.part? This was in regard to some specific question of usage that is neither here nor there at the moment. What is both here and there is that you - an expert for some question of IVOA usage - are now arguing with yourself about the correct answer. I'll say it again - users are not going to understand how to use UCDs. This may or may not be acceptable - it depends on whether our users will ever need to either parse other people's UCDs or create their own. More generally, the question isn't whether UCDs make *any* sense - there appears to be a defensible logic behind every individual distinction that is raised. The question is whether the same logic lies behind all choices - and further, whether the logic is stable over time. I recommend: 1) UCD versioning be explicit 2) a UCD verification web service be assigned high priority (that is, beyond checking syntax and atoms) > a code is a coding system used for transmitting messages requiring > brevity or secrecy But "code" also means a way of representing a message in a new medium, e.g., ASCII. Code can be error detecting or correcting. A code can be a statute, that is, a rule. I see the "brevity or secrecy" definition at dictionary.com, but there many other entries: genetic code, a patient whose heart has stopped :-(, source code. In the latter case, we learn that the word "code" is used specifically to distinguish instructions from data ("often used in opposition to 'data'") - and yet, here we are applying it to (meta)data. I'm getting a code in my node. It isn't that I don't understand the logic behind the choice - it's that many other choices are just as logical. Why make *this* choice? And second, why specifically meta.code.class and *not* meta.class.code or meta.class;meta.code or any of the many other variations? Given the basic rules of UCDs and a list of atoms, a motivated undergraduate should be able to recreate the master list to a couple of sigma - heck, an awk script should be able to do it. But what is one to do with a rule like: "after the primary word, subsequent words are arranged by decreasing importance"? Importance to whom and for what purpose? The rule for atoms is even more ethereal: "the order of these atoms induces a hierarchy". We also have: "the only possible validation of the selected vocabulary is to check its ability to describe properly a wide range of real data". Check how? Define "properly". How about a Monte Carlo test of a canonical ensemble of alternate vocabularies? :-) Perhaps I simply don't understand the rules yet. I doubt I'm alone. I think there is reason to worry if the official list of UCDs can only be justified a posteriori. If nobody else feels the same way, by all means continue with the adoption of the new batch. In addition to versioning and a verification tool, I would then reiterate my support for retaining the ability to namespace UCDs. > If you assign shortcuts to the categories ('S' for 'SCIENCE', 'C' > for 'CALIB' etc), > the correct UCD is meta.class.code since the UCD recommendation > says that the order > of the atoms induces a hierarchy. Ok. So *both* meta.code.class and meta.class.code are to be supported? And is our software supposed to be able to understand these razor thin distinctions and do something usefully different? > Now the question is: are there codes that are not part of a > classification system? > If no, I would drop meta.code and all columns previously assigned > meta.code.class > should be re-assigned meta.class.code. Again - versioning. If our databases aren't to be held hostage to the vagaries of future drifts in UCD usage, they need to be able to refer to a specific, permanently stable, list of UCDs that was in effect when the columns were assigned. I suspect I'm not the only archivist to feel a chill at the sight of the word "re-assign" :-) > Strictly speaking, I don't think a code is an enumeration. > An enumeration is a detailed account, in which each thing is > specially noticed. > However, 'code' and 'enumeration' are sometimes used for the same > thing. > It is something like a language shortcut. Ok - I'm all for precision of expression. We have: - a code is a coding system used for transmitting messages requiring brevity or secrecy - a classification is a group of people or things arranged by class or category - an enumeration is a detailed account, in which each thing is specially noticed And we have the rule that "the order of the atoms induces a hierarchy", so each of: meta.code.class.enum, meta.code.enum.class, meta.class.code.enum, meta.class.enum.code, meta.enum.class.code, and meta.enum.code.class are distinctly different in the obvious way :-) > they will have to look at the examples and that will solve the > ambiguity. > That is why we need to provide examples. > Learning by example allows to grasp the basics more easily. I haven't heard anybody argue against providing examples, but the assertions of solving ambiguities and grasping basics should be challenged by providing IVOA beta testers with such examples and requesting they a) describe the meaning of the examples, and b) use the knowledge gained to create new UCDs representing various concepts. I suggest this worthy goal continue: "The UCD working group has tried to resist the temptation to allow the UCD syntax to be overly expressive." Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jul 27 10:05:09 2006 From: Hessman at Astro.physik.Uni-Goettingen.DE (Hessman Frederic) Date: Thu, 27 Jul 2006 19:05:09 +0200 Subject: classification and code In-Reply-To: <66680684-D374-4A7F-8B7B-EFBCAAB805E6@noao.edu> References: <20060717110114.0gnivdi8v4c8ggwo@webmail.sic.rm.cnr.it> <44BB83C3.3010702@eso.org> <20060725112634.oz0z4tjnk4swk8kg@webmail.sic.rm.cnr.it> <4A0BDD99-FA55-4D89-A4EF-E7D8A4F4C44A@eso.org> <44C63115.8020101@eso.org> <601CD3E3-D975-4834-965E-6A75AF222AAB@noao.edu> <74599EA8-38A5-4A92-9410-1EE6AC72AE7C@noao.edu> <44C8956F.9050101@eso.org> <66680684-D374-4A7F-8B7B-EFBCAAB805E6@noao.edu> Message-ID: <588E1AA5-556C-45ED-A04C-81A6FF94D77E@Astro.physik.Uni-Goettingen.DE> Rob Seaman said... > I'll say it again - users are not going to understand how to use > UCDs. This may or may not be acceptable - it depends on whether > our users will ever need to either parse other people's UCDs or > create their own. > > More generally, the question isn't whether UCDs make *any* sense - > there appears to be a defensible logic behind every individual > distinction that is raised. The question is whether the same logic > lies behind all choices - and further, whether the logic is stable > over time. > It isn't that I don't understand the logic behind the choice - it's > that many other choices are just as logical. Why make *this* choice? I think there is reason to worry if the official list of UCDs can only be justified a posteriori. If nobody else feels the same way, by all means continue with the adoption of the new batch. In addition to versioning and a verification tool, I would then reiterate my support for retaining the ability to namespace UCDs. > Ok. So *both* meta.code.class and meta.class.code are to be > supported? And is our software supposed to be able to understand > these razor thin distinctions and do something usefully different? > Hear, hear! Yes, the list grew in a historical process somewhat organically, and yes we're all very glad that those who worked in the initial development who had other things on their minds than the long- term evolution, but THIS is the time - not later - to put the UCDs on a firm symantic foundation and to clearly define how to create words and how to clearly avoid naming a concept for which no one can find a meaning. Thus, I concur that we need a very explicit and robust set of guidelines, e.g. > I recommend: 0) UCD constructions DO NOT constitute a formal ontology and are intended to be clearly understood, chosen, and interpreted within the context they are used. Thus, long _generic_ hierarchies should be avoided (e.g. meta.code.class.enum). > 1) UCD versioning be explicit > 2) a UCD verification web service be assigned high priority (that > is, beyond checking syntax and atoms) 3) UCD words can be contracted if the uncontracted form is cumbersome or if the contracted form constitutes a commonly recognized abbreviation, but uncontracted forms are to be preferred and length is per se no constraint. 4) UCD words should not be contracted if the meaning of the contraction is not clearly understood outside of it's immediate context ... Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: