IVOA, Trieste 19-May-2008, Minutes of DM Session 1: UTYPEs/UFIs, UNITs kindly provided by Alberto Micol DT: Doug Tody BF: Pepi Fabbiano AR: Anita Richards FC: Fabien Chéreau AW: Andreas Wicenec MA: Mark Allen JS: Jesus Salgado PO: Pedro Osuna AL: Andy Lawrence FG: Françoise Genova FO: François Ochsenbein ML: Mireille Louys IC: Igor Chilingarian FO's presentation on UTYPEs/STC from a VOTable perspective ========================================================================== Q&A session: ------------ Bob Hanisch: Main criticism I heard about was about the asymetry of the approach: a VOTable using STC cannot be translated back to a full STC document. Is that true? FO: Yes, it is true. If not all elements are provided (e.g. only Right Ascension is needed for a particular application), then there is no way to map it back. There will be an IVOA Note explaining how to reference STC elements from VOTable documents, published asap on our web site. FC: the problem of Unicity for Utypes in a generated table: for instance in a catalog a source may be described by diff columns , with possibly the same Utype : making the difference between these columns is required. Doug Tody: uniqueness of utypes normally resolved via groups, but does not need to be unique! FO: Is non-unicity of utype/ucds a real problem? Select * from ivoa_table from yYour_Table where "phot:sdss.mag.r" - "phot:sdss.mag.i" between 1.5 and 2.5 what's the problem? r(1") r(3" r(5") and i(1") i(3") i(5") -> phot:sdss.mag.i ??? ambiguous Three answers: 1: it's an error 2: ambiguous designation, there are 3 columns corresponding to "phot:sdss.mag.r" 3: The server makes a choice (defines its default columns for that utype) 1-> is not satisfactory (and propagate the error back to the user) 2-> a choice can be made by the calling application 3-> data server decides: e.g. r(3") [because e.g. best resolution] or because its' the most accurate magnitude or the server decides to use the min or max or avg value, or just the left most column The knowledge is generally at the server side. The returned metadata must though specify what was the decision taken by the server. Laurent Michel (SAADA): for a precise data collection the mapping of existing metadata can be defined interactively and stored in a configuration file. Utypes & UCDs can be used in SAADA. DT: if the user wants to bypass the model it will use the column itself. Otherwise, a complete model must be available. FC: if the VOTable is a local file there is no way to go back to a server to decide what the best column is... what to do then? FO: Choice must be done at the beginning. FO: data model incomplete: e.g. missing an aperture photometry data model and it is not possible to have infinite number of data models. PO: from VOQL perspective we need unique identifiers. After Cambridge (2007)a note was sent to DM wg to specify the reason for unique identifier. E.g.: Char:axis.spatial.fk5.ra PO will forward such note once again to the DM WG. VOQL needs unique identfiers to be able to work! FO: Not sure why... PO: We can discuss it again after having read the note. FB: using combinations of UTYPEs and UCDs to solve the problem or using more GROUPs in serialisation. FC: we cannot invent a model for everything, infinite amount of models? FO: No, if you have a utype it means that there is a model, if there is no model then you do not use a utype, but something else. FB: In the SSA and spectra the whole chain (utypes, ucds) shows how the system works. FC: implemented a SSA parser but he had to invent new utypes. ML: issue of mapping (some datasets are not fully mappable to a dm, but are still queriable), ML: question open now: if we are looking for the best syntax for utypes there will always be a counter example... I want to see how many cases are covered or not by the current UTYPEs so to see if UFIs are necessary (where and when). Identify use cases for UFIs. DG: don't confuse utypes and ufis. DG then explained the difference between utypes and ufis (you do not parse utypes you use equals for utypes, while ufis need parsing) AR: not sure how to describe ucd,utype, ufi to a euro-dca audience, huge burden. GL: queries to dm-based services: star.mass galaxy.mass (two different utypes for the same column called "mass"). Is that possible? FO: don't add complexity, split the table in two tables one for stars the other for galaxies. IC: joining from two different DMs, the result is a single field, how to show the mapping from the two originating DMs to the end user? FO: not a simple problem, we should start with simple solutions first. ========================================================================== Anita Richard: Units ==================== Anita presented the status of the work on UNITs. Little interest showed, only one person providing use cases at the last moment. In summary: SD prepared a ESAC/CDS/? units compilation Arnold provided STC units dimensional analysis by ESAC archived fits headers cluttered by wrong units (e.g. ISO using Watts instead of Watt) conversion tools (flux unit converstions, coordinate conversions... if we could centralise all examples, and tools... Q&A session: ------------ DT: fits wcs units? AR: nobody looked into it, Paddy Leahy: wcs fits identical to the ogip units PF: Arnold wants to build stc-based libraries, (someone just hired). you should talk to Arnold to see what developements are planned. FC: Any effort to define best practice? AR: no, some units are already in existence... difficult enough to get to agree on any standard, better not to push for any one in particular. AW: reference frame of meter, second, etc.? definition of a second changes with time. AR: IAU covers that. FC: referencing a kind of units "version" important. AL: important on the user point of view: if all conversions are done automatically that is a real win, let's do it in the simplest possible manner. MA: photometric units, where to go? AR: units group could provide definitions of physical units ML: there is an effort for a photometry DM, led by Jonathan McDowell (who could not come to this meeting). AL: magnitudes, xray counts, are dynamic they change with time (latest calibration); that should be a secondary step. AR: What do we actually need? (question to the audience) JS: not compare the strings, but define a data model for it. JS suggests a package for the IVOA at large. AL: we need a list of standardized strings. FG: a table has been made to show that we are not far from what AL said. Conversion tools are needed. A proposal for a list of standard units is a starting point to be used when we talk to the DCA people. AR: twiki page available for everyone to hack! [ see http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/UnitsDesc ] ========================================================================== Norman Gray : How to use URI and RDF for the Utype syntax cha:SpatialAxis.accuracy.SysError.ErrorRefval Let's not invent a new syntax otherwise new parsers, validation, error recovery, libraries are going to be needed... Resource Description Framework (RDF) is an existing debugged well-defined, library supported, syntax and query language. It's a framework for describing resources... sounds good. RDF focuses on properties. It's very expressive. SPARQL query language exists. Note available at: http://www.ivoa.net/Documents/latest/utype-uri.html Also, with the same framework other things are possible: e.g. describing relations between resources (e.g. fits header extensions). Q&A session: ------------ FC: Can that RDF shown be translated to XML? NG: Yes, there are many formats, no problem. ML: Looks interesting, we need to see how to use it with various use cases. ==========================================================================