Difference: ResourceMetadataRFC (19 vs. 20)

Resource Metadata RFC

This document will act as RFC centre for the Resource Metadata V1.0 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 two examples (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 registry mailing list, registry@ivoa.net.

Comments

• "Independent" metadata : by GuyRixon : In section 2, it says that resource metadata are "independent of any service". I find that phrasing confusing. Does it mean that resource metadata are uniform across all services?

RayPlante: I believe what we meant by this was that the values are not meant to be dependent on the specific way you access the data (or service). Given our experience actually deploying this schema, I have to agree the statement is confusing and could be replaced with words akin to my previous sentence. (Your suggestions are welcome.)

BobHanisch: The text actually reads "_Resource metadata_ are high-level and independent of any specific service." This was intended to mean, I believe, that at this level we are trying to describe generic metadata that apply widely to VO resources, not arcane metadata that is specific to a particular service. This interpretation is different from Ray's below, but I think this is what the text is about here. I could abide by rewriting this as "_Resource metadata_ are generic, high-level, and independent of any specific service" if that makes the point clearer.

• Array-valued elements : by GuyRixon : I see many cases where scalar metadata are required that might be better served by arrays. Source and ReferenceURL in section 3.3; coverage elements in section 3.4; uncertainties in section 4. Spectral coverage would be better served by an array of structures, each containing the Bandpass, CentralWavelength, MinimumWavelength and MaximumWavelength elements. The object density can vary wildly with position on the sky, so may need to be an array. If an array of values is too hard to handle, it would be good to have the least and greatest value of the quantities, e.g. Uncertainty.phtometric.best and Uncertainty.photometric.worst. For the Format values, I suggest allowing an array of structures, each containing media and mime-type elements.

RayPlante: Good point. We should review this metadata list in the light of our experience to indicate which ones may be array value-ed and which we must insist on singularity (e.g. Identifier).

BobHanisch: There are a number of issues here, which need to be addressed separately.

Source is a Dublin Core element and refers to a single bibliographic reference. I don't think we should change it.

ReferenceURL is "A URL..."; I think resource providers should select the most relevant URL, if there are many, and give that here.

The coverage elements in 3.4 really need to derive from the STC definitions. They stand alone here because when this was first developed STC was not very far along. I will verify that these definitions are consistent, and that a reference to STC is provided.

As for making arrays out of the data quality metadata, my fear is that is going to lead to such complicated metadata structures that no one will be able to understand them. As the document notes, "The following metadata elements are intended to capture the most basic measures of data quality, and may well require extensions as VO usage practices evolve and become more sophisticated."

As for combining the spectral coverage metadata into an array of structures, this seems to me an implementation detail of the schema.

ObjectDensity is described as "typical". At the resource level I would really hesitate to try to express more than this.

Format is already described as a list. The details of the implementation are again left to the schema.

• Bandpass names : by GuyRixon : The list of approved names need to be stored somewhere and referenced from the current document. There are too many conflicting conventions for naming bandpasses to leave this loose. C.f. unit notation used in VOTable.

BobHanisch: Agreed that this document should be consistent with, and perhaps the defining document for bandpass names. We have a bit of mix right now, with Infrared spelled out and UV abbreviated. Will resolve this.

• Service.HTTPResults : by GuyRixon : Can we rename this one? It's not specific to HTTP and the name is confusing. Service.ResultsMIMEtype?

BobHanisch: Agreed.

• (from EdShaya on mailing list): Constraint should be called something more specific like PlanarConstraint. The description is unclear here.

BobHanisch: As mentioned above, Coverage.Spatial derives from the Space-Time Coordinates metadata and must be consistent.

• • The normal vector (x,y,z) describes the orientation and position of a plane intersecting a unit sphere. It's length is the distance of the plane from the origin; and the plane is oriented perpendicular to the vector. The constraint boundary is the intersection of this arbitrary plane with the unit sphere. One could use zeta, eta to define its orientation and d to give its distance from the origin along the normal direction.
• Convex: by EdShaya : A Convex is just an intersection of Constraints. Since we already specify how to do intersections of regions there is no need for Convex. It is redundant.

BobHanisch: Agreed.

• Relationship: by EdShaya: Because the RelationshipID is separate from the Relationship it would get confusing if a resource is a mirror-of a derived-from resource. It would get even more confusing if we decide to add more relationships in this way. A simple solution is to support mirror-of.resourceID, service-for.resourceID, and derived-from.resourceID instead.

BobHanisch: To me this association of Relationship to RelationshipID is explicit, in that only one RelationshipID is given. But we could perhaps make this even clearer. And, if the RelationshipID should change, it would be preferable to update one entry in the registry rather than three.

• Entity: by RobertPower: In the discussion in Section 3.2, is an entity synonymous to a resource, or is it broader than that? There is a lot of care taken up to this point to define terms (resource, service, organisation etc), and then entity pops up.

BobHanisch: "Entity" comes directly from the Dublin Core definitions, and is explained by way of example as "a person or organization."

• IVOA Identifiers: by RobertPower: The PublisherID and RelationshipID are resource IDs and as such are IVOA Identifiers? Maybe spell this out as done in Sectin 3.1 for Identifier.

BobHanisch: Agreed.

• Being Pedantic: by RobertPower: In Section 3.3 the definition of ReferenceURL: "In general, this should be in a human-readable format", change to something like: "In general, the information should be ..." Otherwise, it could be interpreted as the URL itself should be human readable.

BobHanisch: Agreed.

• Example: by RobertPower: In the Service metadata of the example in Section 6, change the following (note the last one should maybe be http://us-vo.org/metadata/conesearch, since I couldn't find a reference to ConeSearch within IVOA):
  • Service.InterfaceURL http://archive.stsci.edu/sdss/catalog.html
  • Service.BaseURL http://archive.stsci.edu/sdss
  • Service.StandardURL http://www.ivoa.net/Documents/REC/ConeSearch.html

BobHanisch: The first suggested correction is fine. The second, to BaseURL, is not (try it out). As for "ConeSearch" vs. "conesearch" we just need to make sure things are consistent.

• Capability: PaulHarrison - why is this optional in the schema? When writing code to use the registry to hunt for services there needs to be a way of searching for a service of a particular type. The StandardID would seem to be the best fit for this. It would be good practice to force people to name and type any entries that they make.

BobHanisch: Very few of the metadata elements are required, an approach that is consistent with the Dublin Core. And since resources need not be services, it does not make sense to require service-related metadata for all resources.

TonyLinde: also, this RFC is about the RM document, not the schema (which is currently at Draft 0.9 status). The two will merge in V1.1 of the RM to be developed over the next twelve months.

• HTML problems: by AlbertoMicol: In 3.3 Astronomy journal keywords: remove the blanks in the URL pointing to edpsciences; In 3.4 the cds.astro.astroframe.html link is broken; In the Coverage.Spectral table there are pound signs instead of 'less or equal than' (while the 'greater or equal than' is ok).(both on safari(mac) and netscape7(solaris))

BobHanisch: Will try to fix these problems.

• 3.3 Type: by AlbertoMicol: There is no type for 'Image Archive' nor for 'Spectral Archive', etc. If someone is looking just for spectra, how to find only them? Can we add such types to the list? [And I would even go further suggesting sort of mime types like: image/calibrated image/raw spectrum/raw, or even image/calibratable (for a raw archive with accompaining reference files) in order to allow for more precise queries.]

• Coverage.Region Of Regard: by AlbertoMicol: the sentence 'an instrument with one degree angular resolution would have a Region Of Regard of 0.5 degree' could be misleading. If by angular resolution you mean angular resolution and not field of view than I find "one degree" a little bit to big for modern instruments, or did you mean field of view? Also, 'For an image archive the Region Of Regard corresponds to the image field of view.' In this second example R.of R. is the entire thing, while in the previous example it is half of the angular resolution. I would prefer a definition which is univocal: always the radius or always the diameter.