Difference: STCMetadataRFC (31 vs. 32)

Space-Time Coordinate Metadata RFC

This document will act as RFC centre for the Space-Time Metadata V1.30 Proposed Recommendation.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the data model mailing list, dm@ivoa.net.g

See also historic comments on V1.21.

Comments

• (1) STC Implementations

Here is a note from Arnold describing the status of implementations. I believe the implementations are sufficient to warrant approval of the PR. - Jonathan Applications using STC

1. VOEvent The WhereWhen information of a VOEvent uses the ObsDataLocation construct from STC to indicate the spatial and temporal metadata of the event. That description is complete and unambiguous. VOEvent recognizes a limited collection of standard coordinate systems. See: http://ivoa.net/Documents/latest/VOEvent.html

2. JHU Footprint Service The footprint service developed at JHU and used for SDSS and HLA deploys STC regions and coordinate positions for describing footprints and search regions. It represents a complete implementation of STC regions and provides a complete set of operative functions. See: http://voservices.net/footprint Coordinate transformation are not supported, although it would not be difficult to add.

3. Registry The Coverage component of the Registry's resource description is expressed through STC metadata. These descriptions are complete and unambiguous. An issue arising from the concatenation of documents, as performed by registry services, appears to be headed for imminent resolution; otherwise there is an acceptable work-around. It should be stressed that this is not a specific STC issue, but the general problem of handling unambiguous associations between elements when concatenating documents. See: http://ivoa.net/Documents/latest/RM.html

4. David Berry's prototype David Berry implemented a prototype coordinate transformation service for STC version 1.20. Although this service is not operative for the present version, it demonstrates that the coordinate system metadata in STC pass the test of allowing coordinate transformations to be executed unambiguously. See: http://www.starlink.ac.uk/~dsb/ast/ast.html#stc_demo

5. Examples Ten validated sample documents show that the schema meets its requirements of being able to represent the coordinate metadata for a wide range of applications.

See also my STC web page http://hea-www.harvard.edu/~arots/nvometa/STC/ - Arnold Rots

• (2) How does STC fit in IVOA?

I have every confidence that STC can represent complex and rigorous points and regions. But I want to do less rigorous things in a simple way. STC forces the specification of sky position to include observer position, which is not usual in astronomy. STC conflates wavelength and sky position, also not usual. STC does not allow the use of the vernacular "J2000 coordinate frame", also not usual. I worry that the complex syntax and divergence from usual astronomical practice will make STC a niche standard only.

There are already several ways within the IVOA framework for specifying positions and regions. The cone search uses a simple string such as POS=180,20 SR=1 to represent a disk region on the sky, and the registry has used expressions like polygon(FK5, 53.29, -27.97, 53.29, -27.7, ....) and Skynode uses Region('CIRCLE J2000 182.5 -0.89 8'). Is there an intention in the IVOA to deprecate these simple notations in favour of the more complex STC system?

Finally, I note that my cursory search of the registry records (30 minutes) found very few records that have a spatial extent of greater complexity than "AllSky". I found no records with an STC representation of coverage. Can the registry really be considered an interoperable implementation of STC?

-- RoyWilliams - 30 Apr 2007

In reply to Roy's first paragraph, it is important to emphasize the difference between interfaces and metadata. Interfaces may state explicit defaults or restrictions in: (a) how users enter information or make requests and (b) how information is presented to the users. Metadata that accompany and describe data that are being exchanged, on the other hand, should be complete and unambiguous (in the style of STC). This means that there is a requirement that we are able to perform unambiguous mapping between the two.

-- ArnoldRots - 09 May 2007

Referencing mechanisms withing STC

There is a potential problem with STC's use of xml ID and IDREF types for identifying and referring to coordinate systems within the xml instance, when individual instances are concatenated, as might happen within a registry for instance.

This issue was discussed at length in the registry mailing list with the thread starting http://www.ivoa.net/forum/registry/0612/1764.htm and section 6.2.1 of the standard where the conclusion of discussion is effectively deferred by saying that that the naming conventions for the IDs will have to be agreed.

I believe that for a schema that is primarily intended to be used as an imported component of other schemas it is fundamentally wrong to impose document-wide constraints that are inherited (ID and IDREF) as it restricts how STC can be used within instance documents of the inheriting schema whilst at the same time trying to make sure that the resulting documents XML valid. In fact the just about the only possible result of the retaining ID and IDREF is that there will be many more xml fragments in the world that all are trying to describe the same physical coordinate system, but each with a unique identfier - this cannot be a good thing, and is basically equivalent to Roy's complaint above that STC is verbose to describe the common venacular.

Something based purely on the xlink mechanism could be more flexible (because the xml parser does not validate these references) and ultimately simpler because the mnajority of STC instance documents will use standard coordinate systems. There is really no need to have the two level identifier system that currently is defined in STC where an <AstroCoords> uses an IDREF to the ID of an <AstroCoordSystem> which can then use an xlink:href to a standard definition- it can all be done with just a direct xlink:href at the <AstroCoords> level.

This xlink only mechanism would positively encourage the reuse of the standard URIs for coordinate systems and the publishing of new co-ordinate system definitions, and observatory locations at well known URIs, promoting reuse and reducing verbosity.

For the smaller set of cases where a novel coordinate system does need to be defined within the STC document, then there is already a convention to refer to an coordinate system defined only locally within the document using the # 'fragment' notation of URIs.

-- PaulHarrison - 04 May 2007

As was pointed out in that discussion, the proposed solution does not really solve the problem and, more importantly, this is an IVOA-wide issue, not just an STC quirk. The problem is simply that any unambiguous association mechanism in XML documents runs afoul of the no-ambiguity requirement when those documents are included in a larger document by a concatenating service (such as the Registry). We do need a mechanism that allows unambiguous association in XML documents and the ID/IDREF pairs are intended for that purpose and fit the bill precisely. The onus is on the concatenating services to ensure that unique associations remain unique. On the other hand, the criticism that this presents a significant burden on those services, since it requires checking all relevant schemata, is justified. What is needed is a convention that enables document readers to identify ID and IDREF attributes without having to resort to the schema. Two candidate conventions have been discussed:

1. By signifying it in the attribute's name:
- Attributes of type ID will be identified by having their names start with "ID_".
- Attributes of type IDREF will be identified by having their names start with "IDREF_".
This option has the virtue of being simple.
coord_system_id="MyCoordSystem"
would become:
IDREF_coord_system="MyCoordSystem"

2. By identifying specific attributes to be of a certain type through a specific attribute (minOccur=0, maxOccur="unbounded"):
- The attribute ID_type (string) will contain the name of an attribute that is of type ID.
- The attribute IDREF_type (string) will contain the name of an attribute that is of type IDREF.
This option has the advantage that it is backward compatible, can be retrofitted, and makes it easier to fix documents; it's also easily extensible.
coord_system_id="MyCoordSystem"
would become:
coord_system_id="MyCoordSystem", IDREF_type="coord_system_id"

-- ArnoldRots - 09 May 2007

This issue was discussed today and the conclusion was that STC can go forward as currently defined. A more comprehensive solution involving a generally applicable convention will be worked out for a future version.

-- ArnoldRots - 18 May 2007

Data model element names

Thank you for pointing this out; I have corrected this in my copy of the document; AstroCoordSystem is the correct name.

-- ArnoldRots - 15 May 2007

URIs and URLs of standard libraries

In Appendix C, the definition of standard libraries of CoordSys and ObservatoryLocations are given along with suggested URIs for the examples. I think that there is a mismatch between the content of the examples and the URIs assigned. The URIs are given from the ivo: scheme for IVOA resource identifiers, which have the registry as the only locator, however the XML content shown would not be legal for the registry.

The XML content shown could however be served (possibly more naturally/easily for the Observatory) by a http server as say http://www.noao.edu/kpno/STCObservatoryLocation.xml for instance. So I would recommend

1. altering the coordinate system content to be registry legal.
2. altering the observatory location example URI to be a http: URL.

-- PaulHarrison - 15 May 2007

I may be mistaken, but I believe the registry only provides direction to the authority Id in the identifier which in this case is STClib; from there on that resource takes over. It does mean, of course, that STClib must be registered as a resource. In that sense it is no different than the dataset identifiers that exist under ADS's authority. As to the observatory locations, I would much rather see them all gathered in a single library, identified by a proper IVOA dentifier.

-- ArnoldRots - 15 May 2007

The starting point is that the standard library components are imported into instance documents with xlink:href. My reading of xlink is that this is a single dereferencing, so if there were an XML parser that could understand how to dereference the ivo: URI scheme, the best that it could do would be to fetch the registry record itself. According to the URI conventions you could use the fragment (#) notation to convey that you wanted only a portion of the referenced record. With this in mind there is a way in the V1.0 registry schema to register STCResourceProfiles - see http://www.ivoa.net/internal/IVOA/RegUpgradeToV10/stc.xml for an example. The uri of the FK5 system in this case is ivo://STClib/CoordSys#UTC-FK5-TOPO. The rest of the coordinate systems listed in your Table 6 could also be placed into the same registry record.

I might be have missed something, but I do not think that there is a field in a registry resource that you could fill to point to the actual STC instance (presumaby at a http accessible location) without at least abusing the spirit of the intended use of the registry metadata items. So I do not think that the double dereferencing that you are assuming can happen is not representable, as well as undesireable, and unnesessary with the currently published V1.0 registry schema.

There is nothing to stop the observatory locations being published in the registry in the same fashion as the coordinate systems above, however, the direct http: URL method seems to me that it might be a useful option for registryless publishing of such STC coordinate system/location fragments, which might provide a lower barrier to people actually doing so.

-- PaulHarrison - 15 May 2007

I believe I understand what Paul is getting at with regard to defining stardard systems. Start by noting:

1. The use of an IVOA identifier (a URI that starts with ivo:) requires that there is an associated record in an IVOA registry (ref: IVOA Identifiers Recommendation).
2. The record must be of type Resource from the VOResource schema or a legal extension (ref: Registry Interfaces WD).

Thus, since your example does not satisfy 2., it is not sufficient for the legal use of the IVOA identifier.

In addition to the example instance document that Paul points to (stc.xml), Please have a look at the VODataService schema (http://www.ivoa.net/xml/VODataService/v1.0): find the definition of the StandardSTC type, an extension of the Resource type. As Paul points out, the intended mechanism for resolving an ivo:-based xlink via the registry is a complete solution based on existing services (though, as a discussion with Arnold revealed, it needs to be better documented). Thus I would suggest that Appendix C.1. is not needed.

-- RayPlante - 18 May 2007

We have discussed this issue and the resolution is simply that Registry has put the standard coordinate systems library in place. The only thing that needs to be changed in the document are the examples in Appendix C.

-- ArnoldRots - 18 May 2007

Various comments on the document

• Section numbering: a six-level depth, that's really huge ! And many intermediate levels are most likely not required e.g. there is 4.2.1, followed by 4.2.1.1.1, at least one level could be dropped there. Not fundamental, but makes the overall structure hard to read.
• 4.2.1.1.2.1 Scalar reference frame: strange to find a proposal for a "logarithmic projection" there: why only for 1D data ? And why not other functions ? For 2D or higher dimension, only linear (by a transformation matrix) or spherical projections are proposed.
• 4.2.2.1.2 "vextor"
• 4.4.1.1.2 there are already many acronyms, why is it necessary to add unofficial ones (IAT)?
• 4.4.1.2.2 the special Units "deg deg m" should really be removed, this is not a unit. A physical unit can only qualify a number; for a vector, the units classically qualifies the number along one axis. The recommendation should be to assign units to the individual components.
• 4.4.1.2.2 (cont.) Why wait to add CYLINDRICAL ? And some names can have any dimensionality (cartesian), but other (SPHERICAL) can only accept a unique dimensionality (3). Listing the names, acceptable values of coord_naxes would be useful (isn't POLAR with naxes=3 identical to SPHERICAL ?)
• 4.5 there is no recursion there -- it's just a composition law (the result of an operation on regions is a region). In mathematical terms it's an endomorphism.
• 4.5 (cont.) the fill_factor is really difficult to define when the region refers to a set of point sources (a large number of points has still a measure of its area equal to zero, hence would be assigned a fill_factor=0)
• Appendix C: given the highly probable extensive usage of the STClib described in Appendix C, at least a reference to this Appendix in section 4.4 would help a reader trying to understand an STC serialization
• Appendix C: as far as I know, the Hipparcos catalog (which defines the ICRS system) uses the barycentric origin and a terrestrial time. This fundamental association (TT-ICRS-BARY) does not appear in the list?
• utypes: how to refer to the STC schema via utypes could be mentioned e.g. by a reference to a note (which has to be written...)

-- FrancoisOchsenbein - 21 May 2007

Response:

1. Yes,six-level deep is unfortunate, but unavoidable. You are right about 4.2.1.1.1 and it will be corrected; thank you for pointing it out.
2. This is tricky; I don't assume you are advocating a log-log spatial x-y scaling. the only application I can imagine is one where one of the spatial coordinates (e.g., radius, of latitude) gets scaled differently. The schema can always be extended, so we will leave this for later when the need arises.
3. Thank ou - will be corrected.
4. IAT is actually in use in astronomical data; that's why it is included.
5. "deg deg m" may well be removed in a future version, but let's await the devel;opment of standard units.
6. CYLINDRICAL could be added without effort. SPHERICAL may be 2-D or 3-D. POLAR in 3-D counts zenith distance opposite to SPHERICAL's latitude, so it is not the same.
7. This may be sloppy terminology; I will remove the sentence.
8. You are not calculating the fill factor correctly here. In the context of, say, a catalog, the fill factor refers to the fraction of the region that is covered by the catalog (which, one would hope, would be 100%), not the fraction that is actually covered by the sources.
9. I will add a reference; thank you.
10. Are you sure they are not using TDB?
11. I will add a comment on utypes.

-- ArnoldRots - 11 Jun 2007

Set of comments from ReubenWright

1. Final bullet point on page 8 - "a Pixel Coordinate System is needed for pixilated data". Simple typo where "pixilated" should be "pixelated". This is repeated in 6.1.4 Observational Metadata and 7.2.4 Observational Data.
2. 4 Design - "The detailed implementation requirements that follow from this design are presented in Section 6.2.1.". I think that all of section 6.2 is relevant here.
3. 4.2.2.1.1 CoordName (and others in this section). The element in the XML schema is called "Name", and it would be helpful to make this explicit.
4. 4.2.3.1 ScalarInterval and 4.4.3.1 TimeInterval - "[ScalarInterval/TimeInterval] has Boolean attributes LoLimInclude and HiLimInclude". These are actually called lo_include and hi_include.
5. 4.3.3 Pixel Coordinate Area - "The Pixel Coordinate Area has the same properties are the generic Coordinate Area". Simple typo, "are" should be "as".
6. 4.4.2.2.2 CoordName. It would be good to state explicitly whether this uses same mechanism as the following subsection (list of elements), or XSD list type.
7. 4.5.2.4 Difference. Would be better to be define this explicitly (ie what is calculated, and which argument is which). Perhaps something like "the portion of the first region that is not in the second region". Also, is a note needed about contained boundaries?
8. 6.1.1.1 Coordinate System - "with respect to an other,". Simple typo - should be "another".
9. 6.1.1.1 Coordinate System - "origin, c.q., translation". I am not familiar with c.q. (Casu Quo?), does the context make this clear enough for expected audience?
10. 6.1.2.1 Astronomical Coordinate System "also space velocity of this reference position needs to be provided". Rather than "needs" could we use one of MUST or SHOULD?
11. 6.1.2.2 Astronomical Coordinates - "The Time Instant (Section 4.4.2.1.1) in a Time Coordinate (Section 4.4.2.1) MUST contain: Absolute time value, in JD, MJD, or ISO-8601, as specified in Section 4.4.2.1.1.1". Perhaps add "with appropriate Unit specification".
12. 6.1.2.2 Astronomical Coordinates - "A Redshift Coordinate (Section 4.4.2.4) MUST be 1-dimensional and MUST have a Spatial Position Unit and a Time Unit if it is expressed as a Doppler velocity". I think the logic here could be more clear if split into two sentences. eg. "A Redshift Coordinate (Section 4.4.2.4) MUST be 1-dimensional and MUST have a Spatial Position Unit. If it is expressed as a Doppler velocity it MUST also have a Time Unit." - if this is what is meant.
13. 6.1.2.3 Astronomical Coordinate Area - "An Astronomical Coordinate Area object MAY contain: - Any number of Coordinate Intervals for each Coordinate Frame - Coordinate Intervals for the following Coordinate Frames: - Generic (Section 6.1.1.3) - Time". I don't understand what the first bullet point "Any number of Coordinate Intervals for each Coordinate Frame" is adding to the list.
14. 6.1.3.3 Pixel Coordinate Area - "A lower and upper limit value of appropriate dimensionality". According to 4.3.3 Pixel Coordinate Area, it has the same properties as the generic Coordinate Area (see Section 4.2.3). As such is only one of lower and upper limit required, and the other optional?
15. 6.2.1 Referencing Mechanism - "there is no obligation for the client to go and substitute an element that is referenced through Xlink (though it should always be permissible). We will provide some standard libraries (e.g., of common coordinate systems and observatory locations; see Appendix C) with a standard naming convention; a client that is familiar with such libraries may use its inside knowledge instead.". Is it permissible for a client to ignore an XLink and treat the element value as UNKNOWN? I think this is implied but perhaps should be explicit to avoid any confusion.
16. 6.2.2 Versioning "The STC schema will be versioned using three numbers: i.jk". This has the consequence of limiting to at most 10 minor versions between major versions; is this intended? A second separator (eg i.j-k or i.j.k) would add in more flexibility. See also my point below about namespace and schema versioning.
17. UML diagrams. Section 7.2 emphasises that we can have dual values in many situations, implying a range rather than a single value. I don't think this is reflected in the UML diagrams which label these relationships (eg CoordValue -> Coordinate) as 0..1 -> 1. Should they be changed to 0..2?
18. Appendix B.9 Using a FITS File. This doesn't have a Mapping element, but 7.2.4 Observational Data, suggests that it should, saying "there is a third Coordinate metadata element in the case of pixilated data. A Mapping element will define the transformation between the Observation Location and the Pixel Space."
19. XSD Schema - "targetNamespace="http://www.ivoa.net/xml/STC/stc-v1.30.xsd" ". Using the namespace URI as a pointer to the schema is generally not advised. There are a number of reasons to do with future evolution of the namespace, and multiple schemas sharing a namespace. Perhaps the simplest reason however is that it will confuse XML developers working with the standard. I would suggest using http://www.ivoa.net/xml/STC/ This does also raise the issue of versioning for the namespaces, and schemas, and instance documents. Given the comment that "All versions with identical major and minor version numbers SHALL be downward compatible. Users are encouraged to reference the STC version only by these numbers..." (6.2.2) it may make sense for the namespace to be http://www.ivoa.net/xml/STC/1.3/. However this would introduce issues with having to update any XPaths to use the new namespace any time a new version was released. An alternative is to use a version attribute on the root element of the instance documents (STCResourceProfile, ObsDataLocation etc) to identify the version. We could have each version of the schema enforce that each instance match that version by including eg. <xs:attribute name="version" use="required" fixed="1.3" /> for version 1.3, or we can provide this attribute but not mandate that it be used, which adds flexibility.
20. XSD Schema - "<xs:annotation> <xs:documentation>Region is the base type for everything</xs:documentation> </xs:annotation>". This isn't within any element below schema, and seems too general an annotation to belong there - I assume it used to be within the schema elt of a region.xsd schema. Perhaps it is best moved within Region element, or removed altogether.

-- ReubenWright - 29 May 2007

Response
Thank you for your careful reading; here are the individual responses:

1. Thank you - pixilated does have a rather different meaning.
2. Actually, it is Section 6.1.
3. Will be fixed.
4. Will be fixed.
5. Will be fixed.
6. Will be fixed.
7. Will be clarified; boundaries are a hornet's nest.
8. Will be fixed.
9. Yes, casu quo; I would hope and trust this is understood.
10. Will be fixed, although it is somewhat debatable since the sentence is a note on the requirement.
11. No, these do not need units; the errors, etc., do, though.
12. No, both are only needed for Doppler velocities, neither for redshifts.
13. Although the three bullets are not entirely orthogonal, they play different roles. The first bullet says that areas may be made up of multiple intervals; the second says how they are implemented for different frames; and the third provides specifics.
14. No, pixel areas do require upper AND lower limits.
15. It would be permissable, but definitely not recommended; since UNKNOWN requires the client to assume a default, which might easily conflict with what is in the referenced element.
16. This is an IVOA-wide issue; I am following the official guidelines here.
17. I know; but see the caveat on p. 42.
18. This will be reworded, replacing the Mapping Element by the Transformation Element (on p. 80).
19. Like item 16, this is a matter of IVOA-wide conventions.
20. Will be fixed.

-- ArnoldRots - 11 Jun 2007

Here are some additional comments that were offered (well) after the close of the RFC period (by RayPlante).

Comments from the Working Group Chairs and Interest Group Chairs

Chairs should add their comments under their name.

Mark Allen and Mark Taylor (Applications WG)

The STC formalism allows precise description of a wide variety of coordinate information of the kind which is needed in the VO, and we congratulate the author for attention to detail in this work.

We note however that real use of STC in applications will require significant amount of effort to develop libraries and functions for coordinate transformations, and to ease it's implementation and use within tools. The standard looks sufficiently complicated that it appears as though it will be very hard to take a general STC description and do something useful with it. Questions like "tell me the name of the reference frame" may be straight forward by searching for the relevant XML attribute. But performing coordinate transformations, calculating distances, answering questions about coverage etc, where different coordinate systems are involved will be difficult.

It seems unlikely that applications could attain full STC compliance. The flexibility of having a 'CustomFrame' is one aspect of this, but just considering the list of 'Standard Reference Frames' (Table 3), it would require significant effort to write a library which could perform general transformations between all coordinate systems specified by STC. The document does acknowledge that 'there are a few common coordinate systems that will serve the bulk of our data and we will make an effort to make their use as simple as possible'. We highlight the need for these ideas to be expanded and clearly explained 'somewhere' to guide implementation of STC for the common subset of coordinate systems. It is important that these common cases do not require too much overhead imposed by the flexibility of the STC structure. It is difficult to assess this from the document.

The reference implementations provide some example usage, but are somewhat weak in terms of coordinate transformations. The comment concerning the reference implementation of the JHU Footprint Service, "Coordinate transformation are not supported, although it would not be difficult to add" seems to be overstated, as transformations for example between systems with reference frames of URANUS_G_III and SUPER_GALACTIC may be quite challenging.

We approve the current STC because it provides the precise description of coordinates. From an applications point of view there is still much work to required for general libraries which can parse a general STC description and perform astronomically non-trivial operations on it.

Minor comments:

Section 5. meat ? 'Such a Projection or Mapping metadata object is very much like the meat in the FITS WCS'

Sec 6.1.2.3: I think the bullet point nesting has lost a negative indent near "All non-Generic Coordinate Areas MUST...". But I could be wrong.

Appendix A says: "The subsequent pages show the design of the Coordinates and Coordinate Area classes, though these represent the design of versions 1.2 and 1.3, and are therefore slightly outdated at this time; in particular, the Pixel Space is missing." It would be better if these were updated for an IVOA REC.

B.4A ucd="whoknows" is not a good thing to see in an IVOA document.

Christophe Arviset (TCG vice Chair)

Nonetheless, the document contains the description of the metadata which is fine, but it also covers some other areas which I don't believe belong to STC metadata but more to other IVOA standards, in particular:

- 4.5.2 operations (probably more linked to ADQL specs)

- 7.2.2 query constraints (probably more linked to ADQL specs)

- 7.2.3 catalog entry (probably more linked to other DM)

- 7.2.4 observational data(probably more linked to other DM)

I believe these sections (and their corresponding examples if any) should be removed or at least a clear reference to the other IVOA standards should be mentioned.

The document describes all possible STC metadata but does not indicate how to "convert" one coordinate / coordinate system to an other. So if 2 services implement STC, but using different coordinate / coordinate system, how do these 2 services be interoperable ?

Matthew Graham (Grid & Web Services WG)

I approve this document with the following comments:

(!) It is not clear to me what the precise scope of STC is. Is it just for representing astronomical coordinates or is for any coordinate system - is it, in fact, the Coordinate data model? Can I legitimately report my data set in some multidimensional phase space in STC? Can STC be used for theoretical simulations to represent Eulerian or Lagrangian systems and should it be?

(2) I would have liked at one least reference library supporting region handling and coordinate transformations that I can install on my laptop and use as one of the implementations.

(3) It is no clear to me that STC can handle complex coordinate transformations: e.g. defining a coordinate system using cosmological comoving coordinates from the known Ra, Dec, redshift system. How would I specify the cosmological model I am using and the functional form of the metric?

Bob Hanisch (Data Curation & Preservation IG)

I approve this document. This is perhaps the most complicated of the VO standards, and only through more extensive use will we be able to ascertain properly how it needs to evolve further. We should move forward and deal with those revisions through the standard process.

Gerard Lemson (Theory IG)

My main comments are with the structure of the presented model. I find it worrisome that the only result one can see as a standard that allows applications to be built against it etc is the XML schema. It seems to me that we can not consider the UML diagrams as normative as they are way less detailed then the schema, even though the latter is supposed to be only one serialisation of the model. It is unclear how the various UML diagrams have to be interpreted. The colored onese are surely closer to an understandable model than the white ones (which can be removed) and do indeed allow one to understand the structure of the model better than reading the XML schema does. I refer further to my TCG comment in the spectrum datamodel for more comments on the use of UML in the DM working group.

One problem I have with the schema is that it is very monolithic. It would be nice if the schema could be modularised in separate namespaces, with their interdependency organised as a DAG, so that when wanting to use only part of the model, say region, one needs not import all the stuff one is not interested in.

This has several advantages. As a natural first step in validating an XML document one should check it against the corresponding schema. If the schema is a smaller module it is now not necessray to import the whole schema to do so. Similarly, code generators, which form the simplest way to create an XML parser, do not need to create 400+ different classes corresponding to all the different complex and simple types and root elements if one needs only a (small) subset of the whole model.

Another aspect I can not ignore to mention (as I did so before) is the design choices Arnold made in the XML schema. His use of ref="" in element definitions instead of name=""+type="", has as a consequence that way more root elements have to be introduced than would be necessary if a straighforward mapping from his UML diagrams would imply. As an example, only because of this design choices do we now have root elements named Region and Region2, as well as Union and Union2 etc. For they are to be referenced at by the two components in a union or an intersection etc. I counted that there are about 300+ root elements, to the 100+ complex types.

Another potential problem with this choice is that a strict XML validation will allow STC documents that consist of a single element . This may be ok in certain contexts (?), but not in others. Any other schema that imports the current, non-modular STC schema will automatically validate such a document as well. This makes schema based validation hard and requireas extra work on the side of potential users of the STC model.

This same discussion has been held in the registry and votable working groups, and in both it was decided to stay away form this design for the reasons as mentioned above. It might be nice if an attempt could be made to have the STC schema conform to these same design choices.

Anita Richards in agreement with Mireille Louys (Data Models WG)

I am very happy to approve STC as we need to carry on using the model and also refering instrument/data handling tool developers to its definitions. I have some comments which could be attended to in a future version. In some places it may be that I have overlooked or misunderstood what is already in the document, if so I apologise but maybe that indicates a need for clarification in those places. In general it's quite verbose. This can make it difficult for people who are slow reading English (although it is beautifully written!). A summary of the meat of Sections 1-3 in a couple of paras might help.

1) Specifying the handedness of axes

Although RA and Dec and some other coordinate systems have an unambiguous 'handedness', this is not always the case. For example, if I need to use the positions of telescopes in a synthesis array, these may be given in array-centred coordinates in xyz metres offset from a reference position, but some arrays use left-handed and some arrays use right-handed coordinates. Bitter experience has shown that expecting users or publishers to adjust to a common conventions does not work, you have to be able to specify the convention.

I think that GEO_D as in Table 3 p.20 covers this, or if not Generic 6.1.1 - in any case, I am not sure how to specify handedness.

(The reference position should of course be in a well-defined conventional system).

2) In FK4, you need to be able to specify the epoch as well as the equinox for full accuracy and I don't see how to do that.

3) In the long term, generic coordinates should be allowed to be more than 3 dimensional, e.g. sometimes cosmologists want 4 interchangable space-time axes, or even more dimensions.

4) 4.4.2.2.4 error in RA always in units of arc angle... is this essential? My experience e.g. with people who publish data to Astroscope, is that people won;t convert. Hence it would be more foolproof to insist that units are given or at least allow them, so that if the errors are in time-like seconds there is no confusion.

5) 6.1.3.1 Is there some place to specify the units for Scaling?

AnitaRichards for Mireille

Keith Noddle (Data Access Layer WG)

A formidable body of work! I recommend approval; some details need attaention (how could it be otherwise?) but no show stoppers.

Francois Ochsenbein (VOTable WG)

Pedro Osuna (VOQL WG)

Ray Plante (Resource Registry WG)

I recommend the approval of this document to Recommendation status; however, I would strongly encourage the following changes:

1. Clarifying statements are made about the as-yet non-existent documents listed in Section 1. In particular, the answers to the following questions should be made clear:
   1. Are any of these documents a constituent of the standard being approved or is this document complete in and of itself?
      Preceding the list is the statement that STC-X "is an integral part of this standard." What does this mean?
   2. What kind of documents will those on STC-X and STC-S be? Standards that go through the process, or simply IVOA Notes?
   3. Which document will standardizes the STC-X schema: this one or the forthcoming STC-X document?
   4. What is the purpose of the STC document on Arnold's web site? This document is described as "full documentation" for STC (where as the STC-X document just "documents STC-X"). Is it authoritative? Or just helpful? Either way, if it is important enough to reference as a related document, it probably should be published as an IVOA Note, rather than on a private web site.
2. A clarifying statement is added indicating whether the UML representation should be considered part of the standard, or is just provided for clarification.
3. The UML Representation is regenerated, edited, annotated, or whatever to make it consistent with the text in the main sections.
   The introduction to Appendix A admits the UML diagrams are "slightly outdated at this time", and I found this a hinderance to understanding the model.

This document may not be perfect. In particular, I'm concerned that the semantics of the model have not been sufficiently spelled out. I would have prefered to have seen for every term in the model a clear, semantic definition (i.e. that says what it means). This document emphasizes structure and syntax. I'm also concerned about the lack of a reference library (that can do at least some of the things that Mark &amp Mark mention above); more information about the model is probably needed to know how to use the STC information in such a library. Nevertheless, I think STC-X is understood well enough that people are beginning to make use of it. I think the most important thing for moving things forward, is to get the standard finalized so people can start using it.

Finally, if Arnold finds himself making any last minute revisions, perhaps he could consider my additional comments that really should have been entered during the RFC period. I certainly understand, though, if its too late in the process to take some or any of them up.

Andrea Preite-Martinez (Semantics WG)

I congratulate the author for his remarkable work. I approve it for Recommendation.

Roy Williams (VOEvent WG)

It is not clear to me what, precisely, an STC instance is actually describing. It is a point in the sky, it is the orbit and/or ephemeris of a comet, it is the coverage of a survey, it is a query on a catalog. In spite of the great detail of the STC document, it does not mention relationships with other IVOA standards, does not talk of translations or equivalences, does not define where STC should and should not be used in the IVOA context. It is difficult for me to accept a recommendation that covers SO MUCH ground, but has had only ONE HAND in its creation.

However I see no practical alternative, so I enthusiastically recommend STC as an IVOA standard.

Having said this, two points that I believe should be corrected are:

(1) Some of the examples in the document have Schema Location at Harvard. These should be copied to ivoa.net and the examples changed.

(2) Use of textually meaningful ID/IDREF structures in IVOA protocols is now deprecated, and the STC examples do not show this. This line for example from Appendix C:

<AstroCoordSystem id="TT-ICRS-TOPO" xlink:type="simple" xlink:href="ivo://STClib/CoordSys#TT-ICRS-TOPO"/>

implies that a consumer of STC can detect the coordinate system by checking the coord_system_id, by splitting that into parts TT, ICRS, TOPO. But this is not true, since this token may have been changed in the registry. The correct check is on the href attribute of the xlink, and the sexample should change to imply this:

<AstroCoordSystem id="b57ccd870cf4b" xlink:type="simple" xlink:href="ivo://STClib/CoordSys#TT-ICRS-TOPO"/>

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->