DAL 1 and 2 notes (Thanks to Arnold and Mireille, Markus and Doug) Doug argued that we need both a single simple Spectrum model and a model that connects multiple spectrum segments by building associations between individual simple spectra. Inga and Jonathan argued that such associations also cover the case of Echelle spectra. Doug argued that an Echelle is such an association and can be modeled in this fashion, but that most people doing data analysis aren't interested in the details of specific instruments and would often prefer to treat it as equivalent to a single high resolution 1D spectrum (or a set of smaller 1D spectra). Associations can be either physical, by including spectra in the same container with common metadata (as with SED), or logical, by associating individual datasets via metadata in the SSA query response. Others pointed out that 'SED' doesn't always imply 'low spectral resolution'. For an SED, we add metadata to cover the entire SED, plus the individual metadata for the segments. During JCM's talk, we mentioned more about spectral data associations. Brian asked when Quantity would enter. Ray reminded us to ensure consistency in curation metadata between Registry and DM. He mentioned that more than one thing is mandatory in Registry curation. Discussion about polarization: pointed out that model can do polarization as y axis using the relevant UCD. Ray asked about having multiple VOTABLE PARAM with the same utypes; this was addressed later in the Bonnarel talk. Doug said that 'parameterization' had to be safeguarded, meaning that each field in a data model must have a simple, unique utype token so that a data model can be "flattened" into a set of parameters to permit flexibility of representation. When you have two instances of a data model class in the schema, they will thus share the same UTYPEs, and some mechanism other than UTYPE is required to be able to distinguish between the two instances. Alberto was worried about the load on the data provider. He doesn't want to provide data in a different format from what's in the archive. JCM pointed out that for the data to be useful, someone has to transform it from the provider format to some standard format. Alberto wants a generic mechanism which describes the provider format in a machine-readable way, presumably so that some code can read it automatically with an uber-data-model that can read any format. He volunteered to investigate such a mechanism, while JCM and Arnold expressed skepticism that it would be feasible to read all different existing formats with a single code. Doug also expressed skepticism, stating that a generic convertor might be possible for simple cases but was probably intractable for general data model conversions and format transformations, and that mediation of data into a standard model required detailed knowledge available only to the data provider and was best done by the data provider. Do we incorporate STC in Char? Do we incorporate STC and Char in Spectrum (v0.97)? Brian: STC and Char are headed for train wreck, but Quantity is the way out. Jonathan: middle way with a simple version of STC included in Spectrum. Is this like STC-lite which was tried and rejected for VOEvent? Jonathan: No. Doug: A middle course using parts of STC and much of Char is required as we need to make the SSA query response and the Spectrum model more consistent with each other, as well as improve consistency with Char and STC. (Break) In the Bonnarel talk about utypes, several issues were raised. What are the public (resuable) objects of a data model? Not necessarily same as the XML public classes, since technical XML issues force some internal objects to be public. UML template classes: we have a CharacterizationAxis class which is generic. We have several instantiations in one document with different axis UCDs (space, time, etc). These effectively define on-the-fly subclasses. Francois proposed an XPATH like string syntax to refer to such subclasses along the lines of "CharacterizationAxis[@ucd=pos]". However, Doug and JCM proposed using GROUP structures for reflecting the DM structure in VOTABLE, and Francois agreed to this. We noted that an XPATH like syntax might be relevant for an external, e.g. http based, query system. We need to describe the use cases in more detail, distinguishing between identifiers within a document and external strings referencing the documents. In the meantime, for common axes like Spatial, Doug said that we should subclass them so that no separate UCD reference is needed to identify them uniquely: so that CharacterizationAxis is subclassed to SpatialAxis, for example. FB said that there is a need to define new tags in Votable to describe some elements (I didn't understand his point..) Doug's discussion of SSA: the version negotiation was controversial. Bob argued that it shouldn't be in both registry and SSA. Doug argued that DAL protocols be able to work independently of the registry and that real time version verification is desirable even if redundant with the static mechanism implemented by the registry, while Bob argued that any VO data access should be mediated by the registry. Another discussion was that of mandatory support for query parameters (esp. POS) and mandatory inclusion of certain output fields (again POS). For theory data, POS may not be relevant. Such theory servers may ignore POS queries and return blank fields for the POS column in the return votable. FO confirmed that a blank field entry is the appropriate way of recording a null value in a VOTABLE cell. We agreed that the SSA doc should have an example use case for theory data (and maybe for solar data?). The SSA has an object class parameter, and an object name parameter used for objects with no fixed celestial position (e.g. Mars). We noted that the Semantics group should sort out what the allowed values are here. VOEvent has a similar problem, and we agreed that a similar approach should be found which both DAL and VOEvent can adopt. Dolensky talk delayed to next session. - Jonathan