(r10) ResourceMetadataRFC < IVOA

IVOA Web>IvoaResReg>IVOARegWp03>ResourceMetadataRFC (revision 10) (raw view)~~EditAttach~~
---++ Resource Metadata RFC

This document will act as *RFC* centre for the [[http://www.ivoa.net/Documents/PR/ResMetadata/PR-RM-20040126.html][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 TWiki.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 at the bottom of the document and link to it from the comment.

Discussion about any of the comments or responses should be conducted on the registry mailing list, registry@ivoa.net.

---++ Comments

   * First sample comment : by TonyLinde : [[#RfcResp01][response]]
   * "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?  [[#RfcResp02][response]]
   * Array-valued elements : by GuyRixon : I see many cases where scalar metadata are required that might be better served by arrays. Source and <nop>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, <nop>CentralWavelength, <nop>MinimumWavelength and <nop>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.  [[#RfcResp03][response]]
   * 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.
   * Service.HTTPResults : by GuyRixon : Can we rename this one?  It's not specific to HTTP and the name is confusing.  <nop>Service.ResultsMIMEtype?
   * (from EdShaya on mailing list): Constraint should be called something more specific like <i><nop>PlanarConstraint</i>.  The description is unclear here.
      * 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.
   * Relationship: by EdShaya: Because the <nop>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.
   * 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.
   * IVOA Identifiers: by RobertPower: The <nop>PublisherID and <nop>RelationshipID are resource IDs and as such are IVOA Identifiers? Maybe spell this out as done in Sectin 3.1 for Identifier.
   * Being Pedantic: by RobertPower: In Section 3.3 the definition of <nop>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.
   * 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 <nop>ConeSearch within IVOA):
      * Service.<nop>InterfaceURL http://archive.stsci.edu/sdss/catalog.html
      * Service.<nop>BaseURL http://archive.stsci.edu/sdss
      * Service.<nop>StandardURL http://www.ivoa.net/Documents/REC/ConeSearch.html


---
---++ Responses

#RfcResp01
   * Response to first sample comment: wibble wibble
      * subsidiary point

#RfcResp02
   * "Independent" metadata : by 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.)

#RfcResp03
   * Array-valued elements : by 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).
Topic revision: r10 - 2004-02-05 - RayPlante
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema