From naw at ast.cam.ac.uk Tue Apr 1 04:12:55 2003 From: naw at ast.cam.ac.uk (Nicholas A Walton) Date: Tue, 1 Apr 2003 13:12:55 +0100 (BST) Subject: Cambridge, UK, May 12-16, 2003, InterOperability meetings Message-ID: Dear All, ** registration now open at ** http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 please check http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 and related links for emerging details as to the upcoming InterOp meetings in Cambridge. I provide details and links to hotels on the above page. I would advise that you consider booking your accommodation as soon as possible. Yours, Nic Walton ======================================================================== Dr N. A. Walton (AstroGrid Project Scientist) Tel: +44 1223 337503 Institute of Astronomy FAX: +44 1223 337523 University of Cambridge WWW: http://www.astrogrid.org Madingley Road WWW: http://www.ast.cam.ac.uk/~naw Cambridge, CB3 0HA email: naw at ast.cam.ac.uk ======================================================================== From roy at cacr.caltech.edu Fri Apr 4 09:35:21 2003 From: roy at cacr.caltech.edu (Roy Williams) Date: Fri, 4 Apr 2003 09:35:21 -0800 Subject: Pre-meeting UCD question Message-ID: <01b101c2fad0$9168a0d0$d2add783@roxy> Dear UCD'ers In a few weeks Francoise Genova and I will be organizing a working group in Cambridge, UK to discuss the future of the UCD concept as a "common vocabulary" for the VO effort. The working group will meet May 12-14. (1) If you would like to make a short presentation to the working group in Cambridge, please send a note to Francoise and myself with a title. (2) Perhaps we can start a discussion by asking for requirements in trhe following question: ***** WHAT ARE UCD USED FOR -- now and future ***** Please try to write your opinions on this question and send to this group. Some references below. Please DO NOT suggest implementation, syntax, or other solutions -- let us try for requirements. It seems to me that once we know what we are trying to do, our time in Cambridge can be used more productively to find solutions. I hope you agree that this requirements list would be a good start. Thank You Roy Williams Ref 1: Archives of this mailing list http://www.ivoa.net/forum/ucd/ Ref 2: UCD Status and Perspectives, S. Derriere http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-status0203.pdf --- Caltech Center for Advanced Computing Research roy at cacr.caltech.edu 626 395 3670 From dbarnes at isis.ph.unimelb.edu.au Sun Apr 6 21:22:32 2003 From: dbarnes at isis.ph.unimelb.edu.au (David Barnes) Date: Mon, 7 Apr 2003 14:22:32 +1000 (EST) Subject: Pre-meeting UCD question Message-ID: <200304070422.h374MWv29499@isis.ph.unimelb.edu.au> Hi all, Roy asked: > (2) Perhaps we can start a discussion by asking for requirements in trhe > following question: > ***** WHAT ARE UCD USED FOR -- now and future ***** First up, I'm new, so please forgive (and correct) any misconceptions on my part :-) Anyway, here is my 2 cents worth. I'm not sure if I'll be able to make the meeting, but we're hoping to have someone from Aus-VO there... > Ref 2: UCD Status and Perspectives, S. Derriere > http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-status0203.pdf On the top of page 3 of this document, I am told that UCDs are not: - accurate definitions, - expressing physical dimensionality, or - tied to units. Why not? I would imagine that UCDs would be most useful if they were *all* of the above. Accurate definitions: if they are not accurate, what good are they? Why would I want to search a bunch of UCDs to find one that *might* measure what I'm looking for, rather than one that *does*? I imagine an accurate definition would be needed for this. Expressing physical dimensionality: why shouldn't they? This is a simple concept, and one that certainly could assist with at least figuring out if two apparently different UCDs can actually be compared. It's certainly not in and of its own a powerful concept, but it's perfectly possible that I might want to look for any columns which measure a length of time... On the other hand, physical dimensionality can often be derived from the units, so this is not a critical inclusion. Tied to units: again, I'm not clear on why they shouldn't be in the UCD. If we don't store units in the UCD, they have to be stored somewhere else, and then the column values are useless without *both* the UCD and this other bit of information. Overall I am in favour of having all information which describes a single measurement stored in the one place. The UCD seems like a good candidate to be that place. More generally, I felt that one way to categorize UCDs would be as: - instrumental UCDs - measurement UCDs - derived UCDs in the sense that any particular column is generally going to be either, respectively: - a setting you made on your telescope or in your theoretical software (eg. a table of frequencies corresponding to each channel of a spectrometer, or the number of particles in your simulation, ...) - a measurement you actually made (eg. the flux density at each channel of your spectrometer, the energy of each of your simulation particles) - a derived quantity, such as the line-integrated flux of your spectrum, or the total energy of your particles Then measurement UCDs would include "links" to the minimal set of instrumental UCDs needed to repeat the measurement, and derived UCDs would include "links" to the minimal set of measurement UCDs (and implicitly instrumental UCDs) to repeat the obtaining of the derived value. I think a scheme like this would enable some pretty advanced searching, such as finding catalogues (or more generally sources of data) who measured the same thing as you but in a different way. Just one idea really. Maybe I have sidetracked on to the data model, please let me know if I have. Apologies if all the above has been said and discussed in the past. Interested to hear what others think of the above. David. From dbarnes at isis.ph.unimelb.edu.au Wed Apr 9 22:29:21 2003 From: dbarnes at isis.ph.unimelb.edu.au (David Barnes) Date: Thu, 10 Apr 2003 15:29:21 +1000 (EST) Subject: Pre-meeting UCD question In-Reply-To: from "Ray Plante" at Apr 10, 2003 12:15:45 AM Message-ID: <200304100529.h3A5TLF15651@isis.ph.unimelb.edu.au> Hi, > > Accurate definitions: if they are not accurate, what good > > are they? > > The practice of UCD use to date has been mainly about relating quantities > from different catalogs which may use different column names but otherwise > refer to the same or related concepts. In other words, UCDs are a common > vocabulary that can be used to bridge different local schemas. I think, > in general, the more accurate the definitions, the more meaningful the > comparisons one can make. However, there is often a point where accuracy > begins to work against you. Rarely are two columns from different tables > exactly the same thing which can be compared directly. If your > definitions are two precise, you might not be able to recognize two things > as similar. > > I like to say that when interoperating between diverse resources, you need > to squint your eyes a bit and blur the details. How much you have to blur > is measure of how meaningful or accurate your interoperation is. > > What would be nice would be a UCD framework that allows the user to > choose (to some extent) the level of accuracy at "run-time" (rather than > having it frozen in an instance of a catalog). This might involve parsing > the UCD in some way. For example, if two frequencies are both in the > radio, that might be close enough. (Is there a requirement in here > somewhere?) I certainly agree with the general idea that for nearly any comparison you need to apply some sort of "blur" to the details. But to me this suggests that the UCDs *should* be as accurate as possible, and then they can be interpreted at the desired level of accuracy. They can be used to describe the data, *and* to interoperate. I suppose most catalogues would then have their own UCDs, but hopefully well-enough described UCDs so that comparisons can indeed be made. - David. From rplante at poplar.ncsa.uiuc.edu Wed Apr 9 22:15:45 2003 From: rplante at poplar.ncsa.uiuc.edu (Ray Plante) Date: Thu, 10 Apr 2003 00:15:45 -0500 (CDT) Subject: Pre-meeting UCD question In-Reply-To: <200304070422.h374MWv29499@isis.ph.unimelb.edu.au> Message-ID: Hi David, On Mon, 7 Apr 2003, David Barnes wrote: > Maybe I have sidetracked on to the data model, please let > me know if I have. Well, I think this simply illustrates that there is (or should be) a close relationship between data models and UCDs. > Accurate definitions: if they are not accurate, what good > are they? The practice of UCD use to date has been mainly about relating quantities from different catalogs which may use different column names but otherwise refer to the same or related concepts. In other words, UCDs are a common vocabulary that can be used to bridge different local schemas. I think, in general, the more accurate the definitions, the more meaningful the comparisons one can make. However, there is often a point where accuracy begins to work against you. Rarely are two columns from different tables exactly the same thing which can be compared directly. If your definitions are two precise, you might not be able to recognize two things as similar. I like to say that when interoperating between diverse resources, you need to squint your eyes a bit and blur the details. How much you have to blur is measure of how meaningful or accurate your interoperation is. What would be nice would be a UCD framework that allows the user to choose (to some extent) the level of accuracy at "run-time" (rather than having it frozen in an instance of a catalog). This might involve parsing the UCD in some way. For example, if two frequencies are both in the radio, that might be close enough. (Is there a requirement in here somewhere?) cheers, Ray From rplante at poplar.ncsa.uiuc.edu Wed Apr 9 21:52:30 2003 From: rplante at poplar.ncsa.uiuc.edu (Ray Plante) Date: Wed, 9 Apr 2003 23:52:30 -0500 (CDT) Subject: Pre-meeting UCD question In-Reply-To: <01b101c2fad0$9168a0d0$d2add783@roxy> Message-ID: On Fri, 4 Apr 2003, Roy Williams wrote: > (2) Perhaps we can start a discussion by asking for requirements in trhe > following question: > ***** WHAT ARE UCD USED FOR -- now and future ***** What UCDs are used for now: I feel this is well summarized in Sabastien's document (http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-status0203.pdf), section 1.4.2. The uses, I believe, all leverage off the tagging of catalog columns with UCD names, relating the column to a common concept. (Is that correct?) Requirements for the Future: Disclosure: *-ed items represent my own peculiar take on UCDs o A UCD must be able to serve as a reference to a common concept applicable across heterogenous datasets and applications. o It must be possible to use a UCD as a concept reference in a variety of contexts. In particular, it must be possible to: - tag data representing instances or values of a common concept and stored in a generic container; e.g. a VOTable column. - tag data stored in an XML document using some local schema - refer to common concepts to be used in a query, either as part of a query constraint or results request. [A single string of limited length is generally the most flexible in meeting this requirement.] o There should be an accessible document or resource that provides the definitive UCD definitions (i.e. the mapping of UCD names to the concepts they refer to). * There should be a clear, straight-forward relationship between UCDs, metadata, and data models; that is, there should be an obvious relationship between a UCD, a metadatum, and a data model component that refer to the same basic concept. Extension and Standardization: * It should be possible for a community to recommend a preferred set or sets of UCDs that can be applied across diverse resources. * It should be possible for a limited community to define new UCDs that are not covered by a currently accepted set, but understood only within a limited context. It should be possible to use them transparently alongside the currently accepted set. * There should exist a process by which new UCDs can be folded into the broadly accepted set. Compatability: * Any new UCD framework should allow the continued use of the current CDS/ESO UCDs. While they may be individually depricated as new UCDs are defined, backward-compatibility should be preserved. From francois at vizir.u-strasbg.fr Mon Apr 28 11:51:09 2003 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Mon, 28 Apr 2003 20:51:09 +0200 (MET DST) Subject: Column Groups in VOTable Message-ID: <200304281851.h3SIp9n14227@vizir.u-strasbg.fr> Dear All, The forthcoming meeting in Cambridge could be a good opportunity to discuss how "column groups" can be introduced in VOTable. Such a functionality was already expressed (maybe not explicitely); I feel that this it has also implication on UCDs, and I'm therefore posting this message to both VOTable and UCD groups. I apologize to those who will receive this message twice. -- Francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17 ================================================================================ ================================================================================ The "column groups" proposition tries to answer questions frequently themail: Undefined variable asked about column associations, typically: --> error (or standard deviation) associated to a column, e.g. a flux consists of two numbers: the measured value + the mean error --> qualities or weights associated to values --> source or origin (e.g. telescope, or bibliographical reference) of a value --> individual components e.g. x,y position of a CCD --> etc... This "column grouping" has obviously the same role as defining structures made of columns; defining structures made of structures can also be viewed as grouping groups of columns. I see essentially two ways of defining such "column groups" in VOTable: a) generalize the method currently used to describe the coordinate systems. This kind of "by reference" method defines a structure, and any can declare (via the "ref" attribute) to be a member of that structure. As an illustration of a group of columns containing a flux value and its error, the XML code could look like: 1. within the element, define a structure as e.g.: 2. within the definition, columns belonging to this structure refer to it: b) introduce a new element e.g. in the
description which would contain the fields. The same example of a flux + its associated error would be coded as: Value of the flux at 8.4GHz Error on flux value There could be a third way which would introduce new tags within each table element like e.g. and to give but it would be against the current philosophy of VOTable which defines all metadata first, and is followed by the data alone, in order to keep the efficiency and the FITS compatibility; this third method would also require frequent modifications of the schema (XMLSchema) -- generally disturbing for working applications. The defined in b) above seems to me to be a good framework for this definition. I see several advantages: => the basic tabular scheme remains -- VOTable can still be viewed as a relational database, and keeps a full compatibility with existing FITS binary tables; => groups of groups (i.e. recursive tags) enables a definition of arbitrary complex structures; => the UCDs become more accurate when defined in a group: -- adding tags within a nicely introduces a way of parametrizing a UCD -- FIELDs defined in a group can acquire the UCD of the group e.g. the error part of the flux group of fields just need the "ERROR" UCD. Using the "ref" attribute in also permits one column to be a member of several groups: for example, an error common to two fluxes measured at different frequencies can be defined as: Value of the flux at 8.4GHz Error on flux values, both at 8.4 and 7.5GHz Value of the flux at 7.5GHz ================================================================================ From francois at vizir.u-strasbg.fr Tue Apr 29 02:20:50 2003 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Tue, 29 Apr 2003 11:20:50 +0200 Subject: Column Grouping in VOTable and UCD implications Message-ID: <200304290920.h3T9KoV10291@vizir.u-strasbg.fr> Dear All, The forthcoming meeting in Cambridge could be a good opportunity to discuss how "column groups" can be introduced in VOTable. Such a functionality was already expressed (maybe not explicitely); I feel that this it has also implication on UCDs, and I'm therefore posting this message to both VOTable and UCD groups. I apologize to those who will receive this message twice. -- Francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17 ================================================================================ ================================================================================ The "column groups" proposition tries to answer questions frequently themail: Undefined variable asked about column associations, typically: --> error (or standard deviation) associated to a column, e.g. a flux consists of two numbers: the measured value + the mean error --> qualities or weights associated to values --> source or origin (e.g. telescope, or bibliographical reference) of a value --> individual components e.g. x,y position of a CCD --> etc... This "column grouping" has obviously the same role as defining structures made of columns; defining structures made of structures can also be viewed as grouping groups of columns. I see essentially two ways of defining such "column groups" in VOTable: a) generalize the method currently used to describe the coordinate systems. This kind of "by reference" method defines a structure, and any can declare (via the "ref" attribute) to be a member of that structure. As an illustration of a group of columns containing a flux value and its error, the XML code could look like: 1. within the element, define a structure as e.g.: 2. within the
11.351.12
definition, columns belonging to this structure refer to it: b) introduce a new element e.g. in the
description which would contain the fields. The same example of a flux + its associated error would be coded as: Value of the flux at 8.4GHz Error on flux value There could be a third way which would introduce new tags within each table element like e.g. and to give but it would be against the current philosophy of VOTable which defines all metadata first, and is followed by the data alone, in order to keep the efficiency and the FITS compatibility; this third method would also require frequent modifications of the schema (XMLSchema) -- generally disturbing for working applications. The defined in b) above seems to me to be a good framework for this definition. I see several advantages: => the basic tabular scheme remains -- VOTable can still be viewed as a relational database, and keeps a full compatibility with existing FITS binary tables; => groups of groups (i.e. recursive tags) enables a definition of arbitrary complex structures; => the UCDs become more accurate when defined in a group: -- adding tags within a nicely introduces a way of parametrizing a UCD -- FIELDs defined in a group can acquire the UCD of the group e.g. the error part of the flux group of fields just need the "ERROR" UCD. Using the "ref" attribute in also permits one column to be a member of several groups: for example, an error common to two fluxes measured at different frequencies can be defined as: Value of the flux at 8.4GHz Error on flux values, both at 8.4 and 7.5GHz Value of the flux at 7.5GHz ================================================================================ From derriere at newb6.u-strasbg.fr Tue Apr 29 02:12:27 2003 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Tue, 29 Apr 2003 11:12:27 +0200 Subject: ESSW03 paper accepted Message-ID: <3EAE41FB.E9DDB87E@astro.u-strasbg.fr> Hello, The paper on UCDs that was submitted to the ESSW03 Workshop (E-Services and the Semantic Web) has been accepted! This Workshop is part of the 12th WWW conference held in Budapest this year (workshop on May 20). I have placed a copy of the paper on the Wiki Website: http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France From naw at ast.cam.ac.uk Tue Apr 1 04:12:55 2003 From: naw at ast.cam.ac.uk (Nicholas A Walton) Date: Tue, 1 Apr 2003 13:12:55 +0100 (BST) Subject: Cambridge, UK, May 12-16, 2003, InterOperability meetings Message-ID: Dear All, ** registration now open at ** http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 please check http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 and related links for emerging details as to the upcoming InterOp meetings in Cambridge. I provide details and links to hotels on the above page. I would advise that you consider booking your accommodation as soon as possible. Yours, Nic Walton ======================================================================== Dr N. A. Walton (AstroGrid Project Scientist) Tel: +44 1223 337503 Institute of Astronomy FAX: +44 1223 337523 University of Cambridge WWW: http://www.astrogrid.org Madingley Road WWW: http://www.ast.cam.ac.uk/~naw Cambridge, CB3 0HA email: naw at ast.cam.ac.uk ======================================================================== From roy at cacr.caltech.edu Fri Apr 4 09:35:21 2003 From: roy at cacr.caltech.edu (Roy Williams) Date: Fri, 4 Apr 2003 09:35:21 -0800 Subject: Pre-meeting UCD question Message-ID: <01b101c2fad0$9168a0d0$d2add783@roxy> Dear UCD'ers In a few weeks Francoise Genova and I will be organizing a working group in Cambridge, UK to discuss the future of the UCD concept as a "common vocabulary" for the VO effort. The working group will meet May 12-14. (1) If you would like to make a short presentation to the working group in Cambridge, please send a note to Francoise and myself with a title. (2) Perhaps we can start a discussion by asking for requirements in trhe following question: ***** WHAT ARE UCD USED FOR -- now and future ***** Please try to write your opinions on this question and send to this group. Some references below. Please DO NOT suggest implementation, syntax, or other solutions -- let us try for requirements. It seems to me that once we know what we are trying to do, our time in Cambridge can be used more productively to find solutions. I hope you agree that this requirements list would be a good start. Thank You Roy Williams Ref 1: Archives of this mailing list http://www.ivoa.net/forum/ucd/ Ref 2: UCD Status and Perspectives, S. Derriere http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-status0203.pdf --- Caltech Center for Advanced Computing Research roy at cacr.caltech.edu 626 395 3670 From dbarnes at isis.ph.unimelb.edu.au Sun Apr 6 21:22:32 2003 From: dbarnes at isis.ph.unimelb.edu.au (David Barnes) Date: Mon, 7 Apr 2003 14:22:32 +1000 (EST) Subject: Pre-meeting UCD question Message-ID: <200304070422.h374MWv29499@isis.ph.unimelb.edu.au> Hi all, Roy asked: > (2) Perhaps we can start a discussion by asking for requirements in trhe > following question: > ***** WHAT ARE UCD USED FOR -- now and future ***** First up, I'm new, so please forgive (and correct) any misconceptions on my part :-) Anyway, here is my 2 cents worth. I'm not sure if I'll be able to make the meeting, but we're hoping to have someone from Aus-VO there... > Ref 2: UCD Status and Perspectives, S. Derriere > http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-status0203.pdf On the top of page 3 of this document, I am told that UCDs are not: - accurate definitions, - expressing physical dimensionality, or - tied to units. Why not? I would imagine that UCDs would be most useful if they were *all* of the above. Accurate definitions: if they are not accurate, what good are they? Why would I want to search a bunch of UCDs to find one that *might* measure what I'm looking for, rather than one that *does*? I imagine an accurate definition would be needed for this. Expressing physical dimensionality: why shouldn't they? This is a simple concept, and one that certainly could assist with at least figuring out if two apparently different UCDs can actually be compared. It's certainly not in and of its own a powerful concept, but it's perfectly possible that I might want to look for any columns which measure a length of time... On the other hand, physical dimensionality can often be derived from the units, so this is not a critical inclusion. Tied to units: again, I'm not clear on why they shouldn't be in the UCD. If we don't store units in the UCD, they have to be stored somewhere else, and then the column values are useless without *both* the UCD and this other bit of information. Overall I am in favour of having all information which describes a single measurement stored in the one place. The UCD seems like a good candidate to be that place. More generally, I felt that one way to categorize UCDs would be as: - instrumental UCDs - measurement UCDs - derived UCDs in the sense that any particular column is generally going to be either, respectively: - a setting you made on your telescope or in your theoretical software (eg. a table of frequencies corresponding to each channel of a spectrometer, or the number of particles in your simulation, ...) - a measurement you actually made (eg. the flux density at each channel of your spectrometer, the energy of each of your simulation particles) - a derived quantity, such as the line-integrated flux of your spectrum, or the total energy of your particles Then measurement UCDs would include "links" to the minimal set of instrumental UCDs needed to repeat the measurement, and derived UCDs would include "links" to the minimal set of measurement UCDs (and implicitly instrumental UCDs) to repeat the obtaining of the derived value. I think a scheme like this would enable some pretty advanced searching, such as finding catalogues (or more generally sources of data) who measured the same thing as you but in a different way. Just one idea really. Maybe I have sidetracked on to the data model, please let me know if I have. Apologies if all the above has been said and discussed in the past. Interested to hear what others think of the above. David. From dbarnes at isis.ph.unimelb.edu.au Wed Apr 9 22:29:21 2003 From: dbarnes at isis.ph.unimelb.edu.au (David Barnes) Date: Thu, 10 Apr 2003 15:29:21 +1000 (EST) Subject: Pre-meeting UCD question In-Reply-To: from "Ray Plante" at Apr 10, 2003 12:15:45 AM Message-ID: <200304100529.h3A5TLF15651@isis.ph.unimelb.edu.au> Hi, > > Accurate definitions: if they are not accurate, what good > > are they? > > The practice of UCD use to date has been mainly about relating quantities > from different catalogs which may use different column names but otherwise > refer to the same or related concepts. In other words, UCDs are a common > vocabulary that can be used to bridge different local schemas. I think, > in general, the more accurate the definitions, the more meaningful the > comparisons one can make. However, there is often a point where accuracy > begins to work against you. Rarely are two columns from different tables > exactly the same thing which can be compared directly. If your > definitions are two precise, you might not be able to recognize two things > as similar. > > I like to say that when interoperating between diverse resources, you need > to squint your eyes a bit and blur the details. How much you have to blur > is measure of how meaningful or accurate your interoperation is. > > What would be nice would be a UCD framework that allows the user to > choose (to some extent) the level of accuracy at "run-time" (rather than > having it frozen in an instance of a catalog). This might involve parsing > the UCD in some way. For example, if two frequencies are both in the > radio, that might be close enough. (Is there a requirement in here > somewhere?) I certainly agree with the general idea that for nearly any comparison you need to apply some sort of "blur" to the details. But to me this suggests that the UCDs *should* be as accurate as possible, and then they can be interpreted at the desired level of accuracy. They can be used to describe the data, *and* to interoperate. I suppose most catalogues would then have their own UCDs, but hopefully well-enough described UCDs so that comparisons can indeed be made. - David. From rplante at poplar.ncsa.uiuc.edu Wed Apr 9 22:15:45 2003 From: rplante at poplar.ncsa.uiuc.edu (Ray Plante) Date: Thu, 10 Apr 2003 00:15:45 -0500 (CDT) Subject: Pre-meeting UCD question In-Reply-To: <200304070422.h374MWv29499@isis.ph.unimelb.edu.au> Message-ID: Hi David, On Mon, 7 Apr 2003, David Barnes wrote: > Maybe I have sidetracked on to the data model, please let > me know if I have. Well, I think this simply illustrates that there is (or should be) a close relationship between data models and UCDs. > Accurate definitions: if they are not accurate, what good > are they? The practice of UCD use to date has been mainly about relating quantities from different catalogs which may use different column names but otherwise refer to the same or related concepts. In other words, UCDs are a common vocabulary that can be used to bridge different local schemas. I think, in general, the more accurate the definitions, the more meaningful the comparisons one can make. However, there is often a point where accuracy begins to work against you. Rarely are two columns from different tables exactly the same thing which can be compared directly. If your definitions are two precise, you might not be able to recognize two things as similar. I like to say that when interoperating between diverse resources, you need to squint your eyes a bit and blur the details. How much you have to blur is measure of how meaningful or accurate your interoperation is. What would be nice would be a UCD framework that allows the user to choose (to some extent) the level of accuracy at "run-time" (rather than having it frozen in an instance of a catalog). This might involve parsing the UCD in some way. For example, if two frequencies are both in the radio, that might be close enough. (Is there a requirement in here somewhere?) cheers, Ray From rplante at poplar.ncsa.uiuc.edu Wed Apr 9 21:52:30 2003 From: rplante at poplar.ncsa.uiuc.edu (Ray Plante) Date: Wed, 9 Apr 2003 23:52:30 -0500 (CDT) Subject: Pre-meeting UCD question In-Reply-To: <01b101c2fad0$9168a0d0$d2add783@roxy> Message-ID: On Fri, 4 Apr 2003, Roy Williams wrote: > (2) Perhaps we can start a discussion by asking for requirements in trhe > following question: > ***** WHAT ARE UCD USED FOR -- now and future ***** What UCDs are used for now: I feel this is well summarized in Sabastien's document (http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-status0203.pdf), section 1.4.2. The uses, I believe, all leverage off the tagging of catalog columns with UCD names, relating the column to a common concept. (Is that correct?) Requirements for the Future: Disclosure: *-ed items represent my own peculiar take on UCDs o A UCD must be able to serve as a reference to a common concept applicable across heterogenous datasets and applications. o It must be possible to use a UCD as a concept reference in a variety of contexts. In particular, it must be possible to: - tag data representing instances or values of a common concept and stored in a generic container; e.g. a VOTable column. - tag data stored in an XML document using some local schema - refer to common concepts to be used in a query, either as part of a query constraint or results request. [A single string of limited length is generally the most flexible in meeting this requirement.] o There should be an accessible document or resource that provides the definitive UCD definitions (i.e. the mapping of UCD names to the concepts they refer to). * There should be a clear, straight-forward relationship between UCDs, metadata, and data models; that is, there should be an obvious relationship between a UCD, a metadatum, and a data model component that refer to the same basic concept. Extension and Standardization: * It should be possible for a community to recommend a preferred set or sets of UCDs that can be applied across diverse resources. * It should be possible for a limited community to define new UCDs that are not covered by a currently accepted set, but understood only within a limited context. It should be possible to use them transparently alongside the currently accepted set. * There should exist a process by which new UCDs can be folded into the broadly accepted set. Compatability: * Any new UCD framework should allow the continued use of the current CDS/ESO UCDs. While they may be individually depricated as new UCDs are defined, backward-compatibility should be preserved. From francois at vizir.u-strasbg.fr Mon Apr 28 11:51:09 2003 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Mon, 28 Apr 2003 20:51:09 +0200 (MET DST) Subject: Column Groups in VOTable Message-ID: <200304281851.h3SIp9n14227@vizir.u-strasbg.fr> Dear All, The forthcoming meeting in Cambridge could be a good opportunity to discuss how "column groups" can be introduced in VOTable. Such a functionality was already expressed (maybe not explicitely); I feel that this it has also implication on UCDs, and I'm therefore posting this message to both VOTable and UCD groups. I apologize to those who will receive this message twice. -- Francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17 ================================================================================ ================================================================================ The "column groups" proposition tries to answer questions frequently themail: Undefined variable asked about column associations, typically: --> error (or standard deviation) associated to a column, e.g. a flux consists of two numbers: the measured value + the mean error --> qualities or weights associated to values --> source or origin (e.g. telescope, or bibliographical reference) of a value --> individual components e.g. x,y position of a CCD --> etc... This "column grouping" has obviously the same role as defining structures made of columns; defining structures made of structures can also be viewed as grouping groups of columns. I see essentially two ways of defining such "column groups" in VOTable: a) generalize the method currently used to describe the coordinate systems. This kind of "by reference" method defines a structure, and any can declare (via the "ref" attribute) to be a member of that structure. As an illustration of a group of columns containing a flux value and its error, the XML code could look like: 1. within the element, define a structure as e.g.: 2. within the
11.351.12
definition, columns belonging to this structure refer to it: b) introduce a new element e.g. in the
description which would contain the fields. The same example of a flux + its associated error would be coded as: Value of the flux at 8.4GHz Error on flux value There could be a third way which would introduce new tags within each table element like e.g. and to give but it would be against the current philosophy of VOTable which defines all metadata first, and is followed by the data alone, in order to keep the efficiency and the FITS compatibility; this third method would also require frequent modifications of the schema (XMLSchema) -- generally disturbing for working applications. The defined in b) above seems to me to be a good framework for this definition. I see several advantages: => the basic tabular scheme remains -- VOTable can still be viewed as a relational database, and keeps a full compatibility with existing FITS binary tables; => groups of groups (i.e. recursive tags) enables a definition of arbitrary complex structures; => the UCDs become more accurate when defined in a group: -- adding tags within a nicely introduces a way of parametrizing a UCD -- FIELDs defined in a group can acquire the UCD of the group e.g. the error part of the flux group of fields just need the "ERROR" UCD. Using the "ref" attribute in also permits one column to be a member of several groups: for example, an error common to two fluxes measured at different frequencies can be defined as: Value of the flux at 8.4GHz Error on flux values, both at 8.4 and 7.5GHz Value of the flux at 7.5GHz ================================================================================ From francois at vizir.u-strasbg.fr Tue Apr 29 02:20:50 2003 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Tue, 29 Apr 2003 11:20:50 +0200 Subject: Column Grouping in VOTable and UCD implications Message-ID: <200304290920.h3T9KoV10291@vizir.u-strasbg.fr> Dear All, The forthcoming meeting in Cambridge could be a good opportunity to discuss how "column groups" can be introduced in VOTable. Such a functionality was already expressed (maybe not explicitely); I feel that this it has also implication on UCDs, and I'm therefore posting this message to both VOTable and UCD groups. I apologize to those who will receive this message twice. -- Francois ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 17 ================================================================================ ================================================================================ The "column groups" proposition tries to answer questions frequently themail: Undefined variable asked about column associations, typically: --> error (or standard deviation) associated to a column, e.g. a flux consists of two numbers: the measured value + the mean error --> qualities or weights associated to values --> source or origin (e.g. telescope, or bibliographical reference) of a value --> individual components e.g. x,y position of a CCD --> etc... This "column grouping" has obviously the same role as defining structures made of columns; defining structures made of structures can also be viewed as grouping groups of columns. I see essentially two ways of defining such "column groups" in VOTable: a) generalize the method currently used to describe the coordinate systems. This kind of "by reference" method defines a structure, and any can declare (via the "ref" attribute) to be a member of that structure. As an illustration of a group of columns containing a flux value and its error, the XML code could look like: 1. within the element, define a structure as e.g.: 2. within the
11.351.12
definition, columns belonging to this structure refer to it: b) introduce a new element e.g. in the
description which would contain the fields. The same example of a flux + its associated error would be coded as: Value of the flux at 8.4GHz Error on flux value There could be a third way which would introduce new tags within each table element like e.g. and to give but it would be against the current philosophy of VOTable which defines all metadata first, and is followed by the data alone, in order to keep the efficiency and the FITS compatibility; this third method would also require frequent modifications of the schema (XMLSchema) -- generally disturbing for working applications. The defined in b) above seems to me to be a good framework for this definition. I see several advantages: => the basic tabular scheme remains -- VOTable can still be viewed as a relational database, and keeps a full compatibility with existing FITS binary tables; => groups of groups (i.e. recursive tags) enables a definition of arbitrary complex structures; => the UCDs become more accurate when defined in a group: -- adding tags within a nicely introduces a way of parametrizing a UCD -- FIELDs defined in a group can acquire the UCD of the group e.g. the error part of the flux group of fields just need the "ERROR" UCD. Using the "ref" attribute in also permits one column to be a member of several groups: for example, an error common to two fluxes measured at different frequencies can be defined as: Value of the flux at 8.4GHz Error on flux values, both at 8.4 and 7.5GHz Value of the flux at 7.5GHz ================================================================================ From derriere at newb6.u-strasbg.fr Tue Apr 29 02:12:27 2003 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Tue, 29 Apr 2003 11:12:27 +0200 Subject: ESSW03 paper accepted Message-ID: <3EAE41FB.E9DDB87E@astro.u-strasbg.fr> Hello, The paper on UCDs that was submitted to the ESSW03 Workshop (E-Services and the Semantic Web) has been accepted! This Workshop is part of the 12th WWW conference held in Budapest this year (workshop on May 20). I have placed a copy of the paper on the Wiki Website: http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD Sebastien. -- _______ / ~ /, Sebastien Derriere mailto:derriere at astro.u-strasbg.fr / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444 /______// 11, rue de l'universite Telefax +33 (0) 390 242 417 (______(/ F-67000 Strasbourg France
11.351.12