From Alberto.Micol at eso.org Fri Sep 16 10:31:47 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Fri, 16 Sep 2005 19:31:47 +0200 Subject: UCD RFC Message-ID: <48f333f751645d4a43928bca5cbb1134@eso.org> Sorry, I'm not sure about the process. I added the following to the http://www.ivoa.net/twiki/bin/viewauth/IVOA/UCDwordsRFC page but maybe that should have been discussed first on the mailing list... ? Anyway, here what I added there: ---------------------------------- AlbertoMicol - 16 Sep 2005: 3. Suppress em.wl.central Rationale: em.wl.central exists, em.energy.central and em.freq.central don't. Wouldn't be better to remove it and use instead em.wl;stat.mean? 4. em.wl.effective Similar, but not completely identical, to em.wl.central. Maybe effective and central should be added to (e.g.) stat? ----------------------------------- It's just a little point indeed. The idea being that symmetry is always useful, while em.wl and em.energy (or em.freq) aren't. A nice weekend to everybody, Alberto From pdidelon at cea.fr Mon Sep 19 04:47:55 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Mon, 19 Sep 2005 13:47:55 +0200 Subject: UCD1+ incompletness Message-ID: <432EA56B.9070204@cea.fr> Hi, some UCD1+ seems incomplete, even compared to UCD1. it concerns phys.polarization and pos.bodyrc as mentionned on Unified Content Descriptor Controlled Vocabulary RFC page (http://www.ivoa.net/twiki/bin/viewauth/IVOA/UCDwordsRFC) bur perhaps also, pos.precess, pos.eop, pos.eop.nutation. -- Pierre From pfo at star.le.ac.uk Tue Sep 20 09:45:51 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 20 Sep 2005 17:45:51 +0100 (BST) Subject: Comments to the UCD RFC Message-ID: Hi, Some comments about the official list of UCD words: * file http://vizier.u-strasbg.fr/UCD/ucd1-ucd1p.txt has one typo in SPECT_EQ-WIDTH spect.line.eqwidth It should be spect.line.eqWidth. * The following deprecated terms still appear in the list: phot.fluxDens still in the list phot.fluxDens.sb still in the list phys.massYield still in the list * The definition of arith.ratio can be used with quantities with different UCDs, eg, axis ratio: semi-major and semi-minor axes have different UCDs. Although the new UCD phys.size;arith.ratio doesn't make it clear that we're dealing with an axis ratio, we could be comparing planet sizes... worrisome * em.line... drop molecular, so far only atomic lines are mentioned, unless molecular lines are to be added to the list. S | instr.pixel | Pixel S | instr.plate | Photographic plate could be better off as Q * pos.resolution... despite that most astronomical resolution is angular, there are other resolutions in distance, eg, solar and planetary phenomenae, and quite possibly a resolution in the distance scale. Simplifying too much could be dangerous in the long run. Furthermore, the angular resolution seems to me a quantity more related to the instrument than an intrinsic property of the object position in space. * seems to me that instr.seeing should become part of the obs.atmos family... hold on, * S | obs.field | Region covered by the observation Does the explanation encompass field of view? The equivalences with UCD1 doesn't seem to show that. * I agree with Pierre that the section on polarization has been oversimplified * phys.gravity: gravity is more than surface gravity, as it could be measured around any * objcted at any distance from the surphace, and the ones doing gravitational waves experiments may find this too limiting. * Are numbers permitted in atoms? This: phys.mass.light may look much better as phys.mass2ligth or phys.massToLight, light is not a property of mass. * People still quote "major axis" and "minor axis"... how do we fit this with phys.size.smajAxis and phys.size.sminAxis ? * temperature: people modelling interiors might want a few more flavours of temperature. * Q | pos.earth.altitude | Altitude, height above the Earth's surface Do we really mean Earth's surface, as in an airborne apparatus or above sea level (to quote how high an observatory is?) * time.x.start, and time.x.end . exposure is fine, observation is fine, what about a phenomenon? eg, a solar flare? What about start and end of a phenomenon at different levels of intensity/importance? * in the area of photometry and color indices, how would I assign a UCD, and later on recognize without having to sort through a ton of meta-data a color index formed with two HST filters? Or Gunn filters? Just to name two of the commonly used systems today and left out of the list. If it's felt that there are too many UCDs in the phot field, at least leave the root of the different photometric systems to avoid sorting irrelevant data when one is digging a registry for Cousins V-I!! Cheers, Patricio P.S. the comments above also appear in the wiki page --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From pdidelon at cea.fr Fri Sep 23 01:59:14 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Fri, 23 Sep 2005 10:59:14 +0200 Subject: [Fwd: UCD1+ incompletness] Message-ID: <4333C3E2.7060302@cea.fr> Hi, this morning I tried to add some comments on Unified Content Descriptor Controlled Vocabulary RFC page (http://www.ivoa.net/twiki/bin/viewauth/IVOA/UCDwordsRFC) I would have add here that pos.precess, pos.eop, pos.eop.nutation really need extensions like phys.polarization and pos.bodyrc. It seems to me that pos.satellite is not very usefull now that pos.bodyrc is available. Moreover its equivalent in UCD1, POS_PLANETARY has very strange usages (see http://cdsweb.u-strasbg.fr/UCD/cgi-bin/ucd_stats?leaf=POS_PLANETARY&query=Submit) like, among others, positions of spots on close binary system [in J/A+A/426/1001, Catalog of contact binary stars (Csizmadia+, 2004) (http://cdsweb.u-strasbg.fr/cgi-bin/VizieR) (http://cdsweb.u-strasbg.fr/cgi-bin/VizieR-3?-source=34261001&-out=*POS_PLANETARY&-meta.ucd=u)] Some reflexions about coordinates has to be performed, at least from my point of view. For example, why do we need pos.geocentric and pos.earth etc... but it is perhaps more reasonable to postpone this kind of discussion for a next version of the UCD list. -- Pierre From andrea.preitemartinez at rm.iasf.cnr.it Wed Sep 28 08:05:02 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Wed, 28 Sep 2005 17:05:02 +0200 Subject: Call for contributions Message-ID: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> (This message is sent to the UCD and UCD-sci lists: I?m sorry, some of you will receive it twice!) Dear All, The InterOp meeting is approaching, and there is still ample room for contribution in the Agenda of the UCD session. For the moment I envisage to shortly describe the current status of UCDs and open a discussion on future perspectives. Between the present situation and the future development of ontology, I think there is the need for an intermediate step. Up to now, with the "first generation" UCDs, we tackled the problem of describing mainly "quantities" appearing in table data, with the addition of various flavours of qualifiers and modifiers. On the other hand there is an increasing need to describe other concepts within a semantic scheme unique and agreed upon by the whole community. Elements of data models or object types and phenomena of "events" are typical examples of what we might want to integrate in a "second generation" UCDs. We should keep in mind that we need to go any way through this intermediate step in order to build the ontology. By the way, this is the reason why we asked in Kyoto to add "semantics" to the name of the working group. I think it is time to discuss how to build the second generation of UCDs. Some of you already proposed ucd-words of this kind during the recent discussion on the ucd vocabulary. Next UCD session is the right place to restart the discussion. If you want to contribute, send me a title and the time required in order to update the agenda of the session. Andrea ============================================================================== Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma CDS :+33.3.90242473 ============================================================================== From seaman at noao.edu Wed Sep 28 09:42:04 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 28 Sep 2005 09:42:04 -0700 Subject: Call for contributions In-Reply-To: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> Message-ID: On Sep 28, 2005, at 8:05 AM, Andrea Preite Martinez wrote: > Elements of data models or object types and phenomena of "events" > are typical examples of what we might want to integrate in a > "second generation" UCDs. Yes, indeed. I think we can all reach agreement on such things. > On the other hand there is an increasing need to describe other > concepts within a semantic scheme unique and agreed upon by the > whole community. No, not at all. A single, unique UCD namespace will never satisfy all requirements and all users. The current UCD effort has produced a worthy product. The way to protect the investment in the current UCDs, as well as to support the development of new classes of UCDs, is to recognize just that - that "VOConcepts" and other future DM specific UCDs represent separate classes of UCDs - separate namespaces. UCDs are not XML, but the concept of a purpose specific namespace is larger than either. We cannot possibly afford to wait for agreement from the whole community for every single UCD that is proposed. The solution is to recognize that UCDs live in multiple lists managed by multiple authorities, i.e., they live in namespaces (whether or not we call them that). And bear in mind that as the VO matures, the community in question will become the larger astronomy and physics (and geoscience and planetary science and exobiology and...) community, not just the current cozy coffee klatch. Terminology will inevitably collide. We should allow for that now, rather than address each name collision as some ad hoc shoehorning of concepts into nomenclature that fits badly or not at all. > We should keep in mind that we need to go any way through this > intermediate step in order to build the ontology. Yes and no. Yes this is the correct path to follow. No, I am skeptical that a single universe-girdling ontology will emerge at the end of the day. If the VO semantic efforts fail, it will be due to over-reaching and over-generalization. We need to define a process for building separate, project and purpose specific, ontologies (plural). Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at astro.umd.edu Wed Sep 28 10:33:43 2005 From: thomas at astro.umd.edu (Brian Thomas) Date: Wed, 28 Sep 2005 13:33:43 -0400 Subject: Call for contributions In-Reply-To: References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> Message-ID: <200509281333.43341.thomas@astro.umd.edu> On Wednesday 28 September 2005 12:42 pm, Rob Seaman wrote: > Yes and no.? Yes this is the correct path to follow.? No, I am skeptical that a single > universe-girdling ontology will emerge at the end of the day.? If the VO semantic > efforts fail, it will be due to over-reaching and over-generalization.? We need to > define a process for building separate, project and purpose specific, ontologies (plural). > I largely agree with this approach. There is no reason that user-ontologies cannot pick and choose whom they wish to inherit from. The downside is that some data that are semantically described in an ontology that the user does not use will not be discoverable. =b.t. -- -------------------------------------- | | Dr. Brian Thomas | | Dept of Astronomy | University of Maryland-College Park | | Phone: (301) 405-2312 | Fax: (301) 314-9067 | -------------------------------------- From roy at cacr.caltech.edu Wed Sep 28 11:10:19 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 28 Sep 2005 11:10:19 -0700 Subject: Call for contributions In-Reply-To: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> Message-ID: <7c91e618ae1dd30e11790017baf3f7d1@cacr.caltech.edu> Andrea Thank you for your effort to restart the injection of ontology and other knowledge engineering into the VO. I see various ways to extend the UCD concept. For example by extending scope, so that a UCD is not just a "semantic type" of a parameter or table column, but we could make new UCDs for describing service input parameters, types of astronomical object, transitions that can happen to those objects, etc etc. I think namespaces are critical. There are other projects that are possible: building an ontology, thesaurus, glossary, et etc. But the same malaise seems to strike all the semantics efforts together: there is a great intellectual effort in representing knowledge, but little emphasis on a fundamental question: WHAT ARE HOPING TO ACHIEVE? What is needed is not grand plans for the far future, but rather a small application or demo -- it can be very limited in scope -- so that Jo Astronomer is interested, impressed, and perhaps surprised when she sees it. What is NOT needed -- in my opinion -- is a complicated and formal descriptive apparatus that has no immediate objective or application. Something that might fit this bill is the Textpresso system (http://www.textpresso.org/). It is made by biologists here at Caltech, and sets out to be a better literature search than Google, at least in its restricted domain. Textpresso builds a knowledge base from automated processing of scientific literature, that can answer quite specific queries about its subfield, in this case genetics of a small worm called C. Elegans. For example "In what cells is the gene eat-4 expressed". The astronomy version might be able to tackle such queries as finding "polarized radio observations of Sharpless 171", and be much better at it than Google. Roy California Institute of Technology 626 395 3670 From eca at mssl.ucl.ac.uk Wed Sep 28 11:21:06 2005 From: eca at mssl.ucl.ac.uk (Elizabeth Auden) Date: Wed, 28 Sep 2005 19:21:06 +0100 (BST) Subject: Call for contributions In-Reply-To: <7c91e618ae1dd30e11790017baf3f7d1@cacr.caltech.edu> References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> <7c91e618ae1dd30e11790017baf3f7d1@cacr.caltech.edu> Message-ID: Hi Roy, > efforts together: there is a great intellectual effort in representing > knowledge, but little emphasis on a fundamental question: WHAT ARE HOPING TO > ACHIEVE? What is needed is not grand plans for the far future, but rather a > small application or demo -- it can be very limited in scope -- so that Jo > Astronomer is interested, impressed, and perhaps surprised when she sees it. There's an ontology workshop at Strasbourg at the end of October - I'm giving a talk (and hopefully a demo, but so far I just have a logo) about a small ontology based application that will use an ontology based on VOEvent to correlate solar events in different catalogues. I'll let you know when I get past the logo stage. :) cheers, Elizabeth -- Elizabeth Auden, MSSL Holmbury St. Mary, Dorking RH5 6NT Tel: +44 (0)1483 204 276 eSDO Technical Lead, AstroGrid Developer From Alberto.Micol at eso.org Thu Sep 29 06:24:51 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Thu, 29 Sep 2005 15:24:51 +0200 Subject: Instrument related UCDs Message-ID: Dear UCDers, I'm pretty aware that this email comes far too late, and I apologise for that. Still, for the next round, I think that some of the UCD descriptions should be improved to avoid confusion. But please keep reading, and imagine a naive user which might or might not have deep knowledge on how an instrument works; still s/he is given the task to assign ucds to different quantities. Here we go: E instr.background: Is it the signal induced by e.g. the electronics of the detector, or, another example, by the heat of the detector? Note: it is not to be confused with the readout noise (instr.det.noise). If the answer is yes, then... Q instr.skyLevel: ...Is it different than instr.background? If it is a "sky" level, why does it belong to instr? Also, why is it not marked with the syntax code "E"? Q instr.det.psf: Is this the FWHM of the PSF, or the PSF itself? Maybe a better description to clarify... And why is it associated to instr.det? Usually the PSF is the product of the convolution of various components starting from the seeing; is this just only the component induced by the instrument optics (including the telescope itself), or is it really meant to be the component coming from the fact that the detector is sampled into pixels? I would think that the ucd for PSF FWHM is: phys.size;phys.resolution;instr (but phys.resolution does not exist). instr.precision: Is it the sampling precision, or e.g. the astrometric accuracy? instr.det.qe, instr.sensitivity: At first sight one might think that those two ucds are equivalent! I would recommend to change the description of instr.sensitivity to actually explicit the fact that the sensitivity includes BOTH the detector QE AND the transmission of the optics (at least that is my guess!). Q instr.tel: Is it suppose to be the name of the telescope? Or is it just only an adjective (in which case Q should be changed to S)? Q instr.tel.focalLength exists; what about instr.tel.diameter? Let me end this with TRANSMISSION: Regarding transmission I would like to see explicited in the text that phys.transm is actually the covolution of various things, eg.: phys.transm = instr.sensitivity * instr.filter.transm (where I assume that instr.sensitivity = instr.det.qe * instr.optics.transm and notice that I invented the last one, which does not exist) I think we have to make very clear such distinctions, otherwise people will use e.g. instr.sensitivity, while they mean phys.transm, or viceversa! Alberto From Alberto.Micol at eso.org Fri Sep 16 10:31:47 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Fri, 16 Sep 2005 19:31:47 +0200 Subject: UCD RFC Message-ID: <48f333f751645d4a43928bca5cbb1134@eso.org> Sorry, I'm not sure about the process. I added the following to the http://www.ivoa.net/twiki/bin/viewauth/IVOA/UCDwordsRFC page but maybe that should have been discussed first on the mailing list... ? Anyway, here what I added there: ---------------------------------- AlbertoMicol - 16 Sep 2005: 3. Suppress em.wl.central Rationale: em.wl.central exists, em.energy.central and em.freq.central don't. Wouldn't be better to remove it and use instead em.wl;stat.mean? 4. em.wl.effective Similar, but not completely identical, to em.wl.central. Maybe effective and central should be added to (e.g.) stat? ----------------------------------- It's just a little point indeed. The idea being that symmetry is always useful, while em.wl and em.energy (or em.freq) aren't. A nice weekend to everybody, Alberto From pdidelon at cea.fr Mon Sep 19 04:47:55 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Mon, 19 Sep 2005 13:47:55 +0200 Subject: UCD1+ incompletness Message-ID: <432EA56B.9070204@cea.fr> Hi, some UCD1+ seems incomplete, even compared to UCD1. it concerns phys.polarization and pos.bodyrc as mentionned on Unified Content Descriptor Controlled Vocabulary RFC page (http://www.ivoa.net/twiki/bin/viewauth/IVOA/UCDwordsRFC) bur perhaps also, pos.precess, pos.eop, pos.eop.nutation. -- Pierre From pfo at star.le.ac.uk Tue Sep 20 09:45:51 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 20 Sep 2005 17:45:51 +0100 (BST) Subject: Comments to the UCD RFC Message-ID: Hi, Some comments about the official list of UCD words: * file http://vizier.u-strasbg.fr/UCD/ucd1-ucd1p.txt has one typo in SPECT_EQ-WIDTH spect.line.eqwidth It should be spect.line.eqWidth. * The following deprecated terms still appear in the list: phot.fluxDens still in the list phot.fluxDens.sb still in the list phys.massYield still in the list * The definition of arith.ratio can be used with quantities with different UCDs, eg, axis ratio: semi-major and semi-minor axes have different UCDs. Although the new UCD phys.size;arith.ratio doesn't make it clear that we're dealing with an axis ratio, we could be comparing planet sizes... worrisome * em.line... drop molecular, so far only atomic lines are mentioned, unless molecular lines are to be added to the list. S | instr.pixel | Pixel S | instr.plate | Photographic plate could be better off as Q * pos.resolution... despite that most astronomical resolution is angular, there are other resolutions in distance, eg, solar and planetary phenomenae, and quite possibly a resolution in the distance scale. Simplifying too much could be dangerous in the long run. Furthermore, the angular resolution seems to me a quantity more related to the instrument than an intrinsic property of the object position in space. * seems to me that instr.seeing should become part of the obs.atmos family... hold on, * S | obs.field | Region covered by the observation Does the explanation encompass field of view? The equivalences with UCD1 doesn't seem to show that. * I agree with Pierre that the section on polarization has been oversimplified * phys.gravity: gravity is more than surface gravity, as it could be measured around any * objcted at any distance from the surphace, and the ones doing gravitational waves experiments may find this too limiting. * Are numbers permitted in atoms? This: phys.mass.light may look much better as phys.mass2ligth or phys.massToLight, light is not a property of mass. * People still quote "major axis" and "minor axis"... how do we fit this with phys.size.smajAxis and phys.size.sminAxis ? * temperature: people modelling interiors might want a few more flavours of temperature. * Q | pos.earth.altitude | Altitude, height above the Earth's surface Do we really mean Earth's surface, as in an airborne apparatus or above sea level (to quote how high an observatory is?) * time.x.start, and time.x.end . exposure is fine, observation is fine, what about a phenomenon? eg, a solar flare? What about start and end of a phenomenon at different levels of intensity/importance? * in the area of photometry and color indices, how would I assign a UCD, and later on recognize without having to sort through a ton of meta-data a color index formed with two HST filters? Or Gunn filters? Just to name two of the commonly used systems today and left out of the list. If it's felt that there are too many UCDs in the phot field, at least leave the root of the different photometric systems to avoid sorting irrelevant data when one is digging a registry for Cousins V-I!! Cheers, Patricio P.S. the comments above also appear in the wiki page --- Patricio F. Ortiz pfo at star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UK From pdidelon at cea.fr Fri Sep 23 01:59:14 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Fri, 23 Sep 2005 10:59:14 +0200 Subject: [Fwd: UCD1+ incompletness] Message-ID: <4333C3E2.7060302@cea.fr> Hi, this morning I tried to add some comments on Unified Content Descriptor Controlled Vocabulary RFC page (http://www.ivoa.net/twiki/bin/viewauth/IVOA/UCDwordsRFC) I would have add here that pos.precess, pos.eop, pos.eop.nutation really need extensions like phys.polarization and pos.bodyrc. It seems to me that pos.satellite is not very usefull now that pos.bodyrc is available. Moreover its equivalent in UCD1, POS_PLANETARY has very strange usages (see http://cdsweb.u-strasbg.fr/UCD/cgi-bin/ucd_stats?leaf=POS_PLANETARY&query=Submit) like, among others, positions of spots on close binary system [in J/A+A/426/1001, Catalog of contact binary stars (Csizmadia+, 2004) (http://cdsweb.u-strasbg.fr/cgi-bin/VizieR) (http://cdsweb.u-strasbg.fr/cgi-bin/VizieR-3?-source=34261001&-out=*POS_PLANETARY&-meta.ucd=u)] Some reflexions about coordinates has to be performed, at least from my point of view. For example, why do we need pos.geocentric and pos.earth etc... but it is perhaps more reasonable to postpone this kind of discussion for a next version of the UCD list. -- Pierre From andrea.preitemartinez at rm.iasf.cnr.it Wed Sep 28 08:05:02 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Wed, 28 Sep 2005 17:05:02 +0200 Subject: Call for contributions Message-ID: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> (This message is sent to the UCD and UCD-sci lists: I?m sorry, some of you will receive it twice!) Dear All, The InterOp meeting is approaching, and there is still ample room for contribution in the Agenda of the UCD session. For the moment I envisage to shortly describe the current status of UCDs and open a discussion on future perspectives. Between the present situation and the future development of ontology, I think there is the need for an intermediate step. Up to now, with the "first generation" UCDs, we tackled the problem of describing mainly "quantities" appearing in table data, with the addition of various flavours of qualifiers and modifiers. On the other hand there is an increasing need to describe other concepts within a semantic scheme unique and agreed upon by the whole community. Elements of data models or object types and phenomena of "events" are typical examples of what we might want to integrate in a "second generation" UCDs. We should keep in mind that we need to go any way through this intermediate step in order to build the ontology. By the way, this is the reason why we asked in Kyoto to add "semantics" to the name of the working group. I think it is time to discuss how to build the second generation of UCDs. Some of you already proposed ucd-words of this kind during the recent discussion on the ucd vocabulary. Next UCD session is the right place to restart the discussion. If you want to contribute, send me a title and the time required in order to update the agenda of the session. Andrea ============================================================================== Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma CDS :+33.3.90242473 ============================================================================== From seaman at noao.edu Wed Sep 28 09:42:04 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 28 Sep 2005 09:42:04 -0700 Subject: Call for contributions In-Reply-To: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> Message-ID: On Sep 28, 2005, at 8:05 AM, Andrea Preite Martinez wrote: > Elements of data models or object types and phenomena of "events" > are typical examples of what we might want to integrate in a > "second generation" UCDs. Yes, indeed. I think we can all reach agreement on such things. > On the other hand there is an increasing need to describe other > concepts within a semantic scheme unique and agreed upon by the > whole community. No, not at all. A single, unique UCD namespace will never satisfy all requirements and all users. The current UCD effort has produced a worthy product. The way to protect the investment in the current UCDs, as well as to support the development of new classes of UCDs, is to recognize just that - that "VOConcepts" and other future DM specific UCDs represent separate classes of UCDs - separate namespaces. UCDs are not XML, but the concept of a purpose specific namespace is larger than either. We cannot possibly afford to wait for agreement from the whole community for every single UCD that is proposed. The solution is to recognize that UCDs live in multiple lists managed by multiple authorities, i.e., they live in namespaces (whether or not we call them that). And bear in mind that as the VO matures, the community in question will become the larger astronomy and physics (and geoscience and planetary science and exobiology and...) community, not just the current cozy coffee klatch. Terminology will inevitably collide. We should allow for that now, rather than address each name collision as some ad hoc shoehorning of concepts into nomenclature that fits badly or not at all. > We should keep in mind that we need to go any way through this > intermediate step in order to build the ontology. Yes and no. Yes this is the correct path to follow. No, I am skeptical that a single universe-girdling ontology will emerge at the end of the day. If the VO semantic efforts fail, it will be due to over-reaching and over-generalization. We need to define a process for building separate, project and purpose specific, ontologies (plural). Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at astro.umd.edu Wed Sep 28 10:33:43 2005 From: thomas at astro.umd.edu (Brian Thomas) Date: Wed, 28 Sep 2005 13:33:43 -0400 Subject: Call for contributions In-Reply-To: References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> Message-ID: <200509281333.43341.thomas@astro.umd.edu> On Wednesday 28 September 2005 12:42 pm, Rob Seaman wrote: > Yes and no.? Yes this is the correct path to follow.? No, I am skeptical that a single > universe-girdling ontology will emerge at the end of the day.? If the VO semantic > efforts fail, it will be due to over-reaching and over-generalization.? We need to > define a process for building separate, project and purpose specific, ontologies (plural). > I largely agree with this approach. There is no reason that user-ontologies cannot pick and choose whom they wish to inherit from. The downside is that some data that are semantically described in an ontology that the user does not use will not be discoverable. =b.t. -- -------------------------------------- | | Dr. Brian Thomas | | Dept of Astronomy | University of Maryland-College Park | | Phone: (301) 405-2312 | Fax: (301) 314-9067 | -------------------------------------- From roy at cacr.caltech.edu Wed Sep 28 11:10:19 2005 From: roy at cacr.caltech.edu (Roy Williams) Date: Wed, 28 Sep 2005 11:10:19 -0700 Subject: Call for contributions In-Reply-To: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> Message-ID: <7c91e618ae1dd30e11790017baf3f7d1@cacr.caltech.edu> Andrea Thank you for your effort to restart the injection of ontology and other knowledge engineering into the VO. I see various ways to extend the UCD concept. For example by extending scope, so that a UCD is not just a "semantic type" of a parameter or table column, but we could make new UCDs for describing service input parameters, types of astronomical object, transitions that can happen to those objects, etc etc. I think namespaces are critical. There are other projects that are possible: building an ontology, thesaurus, glossary, et etc. But the same malaise seems to strike all the semantics efforts together: there is a great intellectual effort in representing knowledge, but little emphasis on a fundamental question: WHAT ARE HOPING TO ACHIEVE? What is needed is not grand plans for the far future, but rather a small application or demo -- it can be very limited in scope -- so that Jo Astronomer is interested, impressed, and perhaps surprised when she sees it. What is NOT needed -- in my opinion -- is a complicated and formal descriptive apparatus that has no immediate objective or application. Something that might fit this bill is the Textpresso system (http://www.textpresso.org/). It is made by biologists here at Caltech, and sets out to be a better literature search than Google, at least in its restricted domain. Textpresso builds a knowledge base from automated processing of scientific literature, that can answer quite specific queries about its subfield, in this case genetics of a small worm called C. Elegans. For example "In what cells is the gene eat-4 expressed". The astronomy version might be able to tackle such queries as finding "polarized radio observations of Sharpless 171", and be much better at it than Google. Roy California Institute of Technology 626 395 3670 From eca at mssl.ucl.ac.uk Wed Sep 28 11:21:06 2005 From: eca at mssl.ucl.ac.uk (Elizabeth Auden) Date: Wed, 28 Sep 2005 19:21:06 +0100 (BST) Subject: Call for contributions In-Reply-To: <7c91e618ae1dd30e11790017baf3f7d1@cacr.caltech.edu> References: <20050928170502.cr5855mfvtwk004o@webmail.sic.rm.cnr.it> <7c91e618ae1dd30e11790017baf3f7d1@cacr.caltech.edu> Message-ID: Hi Roy, > efforts together: there is a great intellectual effort in representing > knowledge, but little emphasis on a fundamental question: WHAT ARE HOPING TO > ACHIEVE? What is needed is not grand plans for the far future, but rather a > small application or demo -- it can be very limited in scope -- so that Jo > Astronomer is interested, impressed, and perhaps surprised when she sees it. There's an ontology workshop at Strasbourg at the end of October - I'm giving a talk (and hopefully a demo, but so far I just have a logo) about a small ontology based application that will use an ontology based on VOEvent to correlate solar events in different catalogues. I'll let you know when I get past the logo stage. :) cheers, Elizabeth -- Elizabeth Auden, MSSL Holmbury St. Mary, Dorking RH5 6NT Tel: +44 (0)1483 204 276 eSDO Technical Lead, AstroGrid Developer From Alberto.Micol at eso.org Thu Sep 29 06:24:51 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Thu, 29 Sep 2005 15:24:51 +0200 Subject: Instrument related UCDs Message-ID: Dear UCDers, I'm pretty aware that this email comes far too late, and I apologise for that. Still, for the next round, I think that some of the UCD descriptions should be improved to avoid confusion. But please keep reading, and imagine a naive user which might or might not have deep knowledge on how an instrument works; still s/he is given the task to assign ucds to different quantities. Here we go: E instr.background: Is it the signal induced by e.g. the electronics of the detector, or, another example, by the heat of the detector? Note: it is not to be confused with the readout noise (instr.det.noise). If the answer is yes, then... Q instr.skyLevel: ...Is it different than instr.background? If it is a "sky" level, why does it belong to instr? Also, why is it not marked with the syntax code "E"? Q instr.det.psf: Is this the FWHM of the PSF, or the PSF itself? Maybe a better description to clarify... And why is it associated to instr.det? Usually the PSF is the product of the convolution of various components starting from the seeing; is this just only the component induced by the instrument optics (including the telescope itself), or is it really meant to be the component coming from the fact that the detector is sampled into pixels? I would think that the ucd for PSF FWHM is: phys.size;phys.resolution;instr (but phys.resolution does not exist). instr.precision: Is it the sampling precision, or e.g. the astrometric accuracy? instr.det.qe, instr.sensitivity: At first sight one might think that those two ucds are equivalent! I would recommend to change the description of instr.sensitivity to actually explicit the fact that the sensitivity includes BOTH the detector QE AND the transmission of the optics (at least that is my guess!). Q instr.tel: Is it suppose to be the name of the telescope? Or is it just only an adjective (in which case Q should be changed to S)? Q instr.tel.focalLength exists; what about instr.tel.diameter? Let me end this with TRANSMISSION: Regarding transmission I would like to see explicited in the text that phys.transm is actually the covolution of various things, eg.: phys.transm = instr.sensitivity * instr.filter.transm (where I assume that instr.sensitivity = instr.det.qe * instr.optics.transm and notice that I invented the last one, which does not exist) I think we have to make very clear such distinctions, otherwise people will use e.g. instr.sensitivity, while they mean phys.transm, or viceversa! Alberto