InterOpMay2004 Registry

Preliminary Reading

• Resource Metadata Specification v1.01
  • this was recently elevated to full Recommendation. BobHanisch will review changes made just prior to this elevation during the Wed. morning session.

• IVOA Identifiers V1.1
  • See Appendix B for a summary of minor changes over v1.0.
  • RayPlante will request that v1.1 be elevated to a PR during the Wed. morning session

• VOResource v0.9 XML Schema and its extension schemas
  • links to schema documentation can be found on this twiki page
  • no changes this calendar year
  • RayPlante will present a set of recommended changes for a version v0.10 during the Wed. morning session; revised schemas and examples will be posted soon.

• Lessons Learned Using VOResource v0.9
  • This document describes in part the changes to be recommended for VOResource v0.10

• Proposed VOResource V0.10 XML Schema and Extensions
  • Includes links to seven example instance documents
  • RayPlante will present this proposal during the Wed. morning session

• Registry Interface Specification (draft)
  • KevinBenson will present this document during the Thurs. morning session

• Registry Harvesting
  • an alternative section 4 for the RI Specification above
  • this document is a proposal for an OAI-based standard for Harvesting
  • RayPlante will present this proposal during the Wed. morning session

Timetable

Wednesday May 26, 2004: Morning session
RM & Schema updates

Thursday May 27, 2004: Morning session
Registry Interface

Thursday May 27, 2004: Afternoon session
Identifiers, Curation & Signoffs

Meeting outcomes

Resolutions

Session 1

1. Types are defined in RM
   Documents are defined in RI
2. Logical-id will be defined via a second relationship (rather than via direct attribute)
3. Level of hierarchy will be as in RM v1.01 (except as resolved otherwise here)
4. Service types as a sub-class of Resource (rather than extending Capability)
5. Organisation type will be defined in the base VOResource definitions
6. Referred resources will be via xsi:type of RegisteredResourceType and UnregisteredResourceType
7. The element name for a referred resource identifier will be ResourceRef (instead of Identifier which was confusing)

Session 2

1. An IVOA Registry must support OAI-PMH protocol for harvesting via HTTP GET, returning at least oai_dc and ivo_vor metadata formats using standard data criteria
2. The metadata describing a registry will include a flag indicating whether it is a full or publising registry.
3. The standard IVOA Registry Harvesting specification will be web service-based and will conform to the full OAI-PMH specification: details will be worked out on the mailing list
4. An IVOA Registry must support the Keyword Search as specified in the RI document
5. An IVOA Registry must support a Full Query (interface tbd) using the WHERE clause of the ADQL schema with fields specified using non-namespaced XPath directives (simple, ie no [...] options), and returning full resource entries

Session 3

1. Reversed Session 1 decision re Referred resources
   • Referral will be via ivo-id attribute
2. Will promote v1.1 of Identifier spec to PR status thence to REC

Actions / Timetable