| ||||||||
Added: | ||||||||
> > |
| |||||||
Utypes Tiger TeamUtypes Use Cases | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | Raw use cases from Urbana-Champaign
| |||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | Reviewed Use Cases and Requirements | |||||||
Changed: | ||||||||
< < | Current Practices and Uses | |||||||
> > | Requirements: | |||||||
Changed: | ||||||||
< < | Spectrum 1.1 REC, Quality Flags: FluxAxis.Quality.n, where n is | |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | an integer. (Parsable? Anyway this is gone in Spectral 2.0) | |||||||
Changed: | ||||||||
< < | Photometry 1.0 PR, Access class: “we use the Access class defined in | |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ObsTAP and inherited from SSA” -> PhotometryFilter.transmissionCurve.Access.* | |||||||
Changed: | ||||||||
< < | Photometry 1.0 PR, Spectrum is imported using the spec namespace | |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | (notice the difference with the previous approach). | |||||||
Changed: | ||||||||
< < | Namespace (in several DMs): the namespace must be parsed out of the | |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | Utype string… but then again which is the actual Utype string? | |||||||
Changed: | ||||||||
< < | Extensibility (e.g. NED SED): FluxAxis.Published.Value: is this Utype by any chance related to the standard FluxAxis or to | |||||||
> > | Abstract Use Cases:Data Model (de)serialization | |||||||
Deleted: | ||||||||
< < | Target.Name? (How can I infer it?) | |||||||
Changed: | ||||||||
< < | Introduced as an attribute for FIELD and PARAM in VOTable 1.2:
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < |
| |||||||
Changed: | ||||||||
< < | Redefined in SSA 1.1: | |||||||
> > | VO Tools | |||||||
Deleted: | ||||||||
< < |
| |||||||
Changed: | ||||||||
< < | Utype is built with the pseudo-grammar “<component-name>”.”<field-name>” | |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
Changed: | ||||||||
< < | spec:Spectrum.Target.Name and ssa:Target.Name are the same thing. | |||||||
> > | Data Model description | |||||||
Deleted: | ||||||||
< < |
| |||||||
Changed: | ||||||||
< < | Redefined in Spectrum 1.1, also introducing Data Model inheritance:
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < | Most DMs define utypes in tables, using different conventions | |||||||
> > | Others | |||||||
Changed: | ||||||||
< < | Utypes strings can change when DMs are reused. Also, the namespace | |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | changes globally for each DM (spec:Target.Name, ssa:Target.Name) | |||||||
Changed: | ||||||||
< < | Utypes are only partially used in FITS serializations: they can be used for columns, not for parameters: in this case, an arbitrary 8 char string is | |||||||
> > | Concrete Use Cases:(Photometry Catalog, points in columns) | |||||||
Deleted: | ||||||||
< < | provided by the DM document. | |||||||
Changed: | ||||||||
< < | DMs do not define an “xmlns” link to the DM URI | |||||||
> > | Represent a Photometry Catalog with a definite number of Magnitudes expressed in columns and astronomical sources in rows. For example, an SDSS catalog with the following columns: | |||||||
Added: | ||||||||
> > | SDSSID | RA | DEC | U | G | R | I | Z
(Photometry Catalog, points in rows)A Photometry Catalog could refer to a single object observed in a number of filters, or to different objects observed in a number of filters, and the filters could be an arbitrary number. Employing an efficient relational approach would suggest to represent this as a table where each magnitude is expressed in a different row, and the other information (object name, coordinates, instrument, filter, etc) are in columns, or are factored out in the table header if they are common to all points. For instance, here is a (simple) example of an (unnormalized) catalog for different sources. Notice that this table doesn't use any controlled vocabulary for filters, target names and instruments, while VO documents should: TargetName | RA | DEC | Instrument | Filter | Magnitude | Units M51 | xx.yy | xx.yy | SDSS | u | xx | ABMAG M51 | xx.yy | xx.yy | SDSS | g | xx | ABMAG NGC1068 | xx.yy | xx.yy | GALEX | nuv | Jy(Aggregated SED)An Aggregated SED is defined as an aggregation of different segments of spectro-photometric data, where each segment can be a Photometry Catalog, a Spectrum or an entire SED itself. It should be possible to serialize an SED as a list of several tables, each table representing a segment. Complex formats like VOTable and FITS can allow the tables to be stored in the same file.STC serialization)"> (STC serialization)It has to be possible to embed STC instances in tables and attach these instances to other objects in the table. This is a generic example of Model reuse (the STC model is reused by other models)STC in a Spectrum)"> (STC in a Spectrum)This is a more specific example of model reuse. Spectral DM uses some parts of the STC DM to describe the reference frame of the observations: the frame can include several axes: time, spectral coordinate, flux, photometry filters. Some of these axes could be different instance of the same STC or STC-derived class, like the photometry filters. This has to be represented in a generic tabular format using Utypes to describe the structure of the serialized instances. Different instances of the same class must somehow be disentangled from the others.(Create compliant SSA service using a database and a non-compliant archive)Given a database and an archive containing spectra serialized in a non-compliant way (but in a supported format, like FITS), a data publisher might want to create a VO service: in principle this would require the creation of a new database (or a view on the original one) and to copy and change the headers of the non-compliant files. A more efficient solution would be to leave the archive and the database untouched and to add an additional layer on top of them: the layer would add the required metadata to the original files on the fly (see R #4). For example, the service can read the information in the database and fill a VOTable compliant header (putting together the database values with the predefined Utypes) that will wrap the original FITS file in the files response.Current Practices and UsesSpectrum 1.1 REC, Quality Flags: FluxAxis.Quality.n, where n is an integer. (Parsable? Anyway this is gone in Spectral 2.0) Photometry 1.0 PR, Access class: “we use the Access class defined in ObsTAP and inherited from SSA” -> PhotometryFilter.transmissionCurve.Access.* Photometry 1.0 PR, Spectrum is imported using the spec namespace (notice the difference with the previous approach). Namespace (in several DMs): the namespace must be parsed out of the Utype string… but then again which is the actual Utype string? Extensibility (e.g. NED SED): FluxAxis.Published.Value: is this Utype by any chance related to the standard FluxAxis or to Target.Name? (How can I infer it?) Introduced as an attribute for FIELD and PARAM in VOTable 1.2:
| |||||||
Minutes of telecon 2012-08-21Persons present: Omar, Markus, Gerard, Matthew, Patrick Points discussed (not in temporal order): | ||||||||
Changed: | ||||||||
< < | Starting with a clean slate as far as the current working draft is | |||||||
> > | Starting with a clean slate as far as the current working draft is concerned (while harvesting from the current text what's useful): None of the persons present object. | |||||||
Deleted: | ||||||||
< < | concerned (while harvesting from the current text what's useful): None of the persons present object. | |||||||
Changed: | ||||||||
< < | But: We'll have to first come up with a report that summarizes current | |||||||
> > | But: We'll have to first come up with a report that summarizes current usage of utypes (plus, when we have a better idea of where we want to go, the impact of any changes to current practice). Matthew volunteers to edit this report. Markus will help out. | |||||||
Deleted: | ||||||||
< < | usage of utypes (plus, when we have a better idea of where we want to go, the impact of any changes to current practice). Matthew volunteers to edit this report. Markus will help out. | |||||||
Changed: | ||||||||
< < | Omar will be editor of the working draft, and we assume Mireille will | |||||||
> > | Omar will be editor of the working draft, and we assume Mireille will also want to be part of the effort. | |||||||
Deleted: | ||||||||
< < | also want to be part of the effort. | |||||||
Changed: | ||||||||
< < | Omar will circulate a list of the use cases over the DM list; there's | |||||||
> > | Omar will circulate a list of the use cases over the DM list; there's already something on this page (http://wiki.ivoa.net/twiki/bin/view/IVOA/UtypesTigerTeam), but it needs smoothing and elaboration. Documents will end up in volute. | |||||||
Deleted: | ||||||||
< < | already something on this page (http://wiki.ivoa.net/twiki/bin/view/IVOA/UtypesTigerTeam), but it needs smoothing and elaboration. Documents will end up in volute. | |||||||
Changed: | ||||||||
< < | We need to make explicit what are the prime use cases driving utypes. | |||||||
> > | We need to make explicit what are the prime use cases driving utypes. Not all of the ones on the wiki may be achieveable. | |||||||
Deleted: | ||||||||
< < | Not all of the ones on the wiki may be achieveable. | |||||||
Changed: | ||||||||
< < | Attempts to define utypes: Are they "pointers into a data model | |||||||
> > | Attempts to define utypes: Are they "pointers into a data model instance", much like xpath points into a XML document? That much seems not very contentious. As far as this function is concerned, it is seen that inheritance and embedding are not very well dealt with now. | |||||||
Deleted: | ||||||||
< < | instance", much like xpath points into a XML document? That much seems not very contentious. As far as this function is concerned, it is seen that inheritance and embedding are not very well dealt with now. | |||||||
Changed: | ||||||||
< < | "I should be able to serialize and deserialize a data model instance in | |||||||
> > | "I should be able to serialize and deserialize a data model instance in any way I want" using utypes (Matthew). But we obviously need to pose additional constraints on what the target formats need to be able to to (e.g., represent key-value pairs). | |||||||
Deleted: | ||||||||
< < | any way I want" using utypes (Matthew). But we obviously need to pose additional constraints on what the target formats need to be able to to (e.g., represent key-value pairs). | |||||||
Changed: | ||||||||
< < | What formats do we actually care about? VOTable obviously, FITS | |||||||
> > | What formats do we actually care about? VOTable obviously, FITS probably (though some say people that want FITS won't care about data models), SAMP messages. JSON? No agreement. CSV doesn't have enough of a header to allow utype mapping, probably. | |||||||
Deleted: | ||||||||
< < | probably (though some say people that want FITS won't care about data models), SAMP messages. JSON? No agreement. CSV doesn't have enough of a header to allow utype mapping, probably. | |||||||
Changed: | ||||||||
< < | We've got about 8 weeks until the interop. What do we want to get done | |||||||
> > | We've got about 8 weeks until the interop. What do we want to get done by then? We want the use cases in a form so TCG/plenary/whoever can decide which absolutely have to be covered, where we as Tiger Team provide comments/suggest priorities. We also must have the overview of where utypes are already used. Telecons every two weeks. | |||||||
Deleted: | ||||||||
< < | by then? We want the use cases in a form so TCG/plenary/whoever can decide which absolutely have to be covered, where we as Tiger Team provide comments/suggest priorities. We also must have the overview of where utypes are already used. Telecons every two weeks. |