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

• • KevinBenson will present this document during the Thurs. morning session

• • 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

Monday May 24, 2004: Plenary

• Tony's introduction slides: ppt, pdf

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

Friday May 28, 2004: Plenary

• Tony's workgroup summary slides: ppt, pdf

Meeting outcomes

Resolutions

Session 1

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

Note: Decisions on referred resources were reversed in Session 3

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 decisions re Referred resources
   • Referral will be via ivo-id attribute
2. Will promote v1.1 of Identifier spec to PR status thence to REC
3. Implement owned/managed authorityID to cater for Publishing/Full registries

Actions / Timetable

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

Monday May 24, 2004: Plenary

• Tony's introduction slides: ppt, pdf

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

Friday May 28, 2004: Plenary

• Tony's workgroup summary slides: ppt, pdf

Meeting outcomes

Resolutions

Session 1

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

Note: Decisions on referred resources were reversed in Session 3

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 decisions re Referred resources
   • Referral will be via ivo-id attribute
2. Will promote v1.1 of Identifier spec to PR status thence to REC
3. Implement owned/managed authorityID to cater for Publishing/Full registries

Actions / Timetable

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. Ratified decision of previous videocon to switch from substitution group based inheritance to type-based
2. Types are defined in RM
   Documents are defined in RI
3. Logical-id will be defined via a second relationship (rather than via direct attribute)
4. Level of hierarchy will be as in RM v1.01 (except as resolved otherwise here)
5. Service types as a sub-class of Resource (rather than extending Capability)
6. Organisation type will be defined in the base VOResource definitions
7. Referred resources will be via xsi:type of RegisteredResourceType and UnregisteredResourceType
8. The element name for a referred resource identifier will be ResourceRef (instead of Identifier which was confusing)

Note: Decisions on referred resources were reversed in Session 3

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 decisions re Referred resources
   • Referral will be via ivo-id attribute
2. Will promote v1.1 of Identifier spec to PR status thence to REC
3. Implement owned/managed authorityID to cater for Publishing/Full registries

Actions / Timetable

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. Ratified decision of previous videocon to switch from substitution group based inheritance to type-based
2. Types are defined in RM
   Documents are defined in RI
3. Logical-id will be defined via a second relationship (rather than via direct attribute)
4. Level of hierarchy will be as in RM v1.01 (except as resolved otherwise here)
5. Service types as a sub-class of Resource (rather than extending Capability)
6. Organisation type will be defined in the base VOResource definitions
7. Referred resources will be via xsi:type of RegisteredResourceType and UnregisteredResourceType
8. The element name for a referred resource identifier will be ResourceRef (instead of Identifier which was confusing)

Note: Decisions on referred resources were reversed in Session 3

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 decisions re Referred resources
   • Referral will be via ivo-id attribute
2. Will promote v1.1 of Identifier spec to PR status thence to REC
3. Implement owned/managed authorityID to cater for Publishing/Full registries

Actions / Timetable

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)

Note: Decisions on referred resources were reversed in Session 3

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 decisions re Referred resources
   • Referral will be via ivo-id attribute
2. Will promote v1.1 of Identifier spec to PR status thence to REC
3. Implement owned/managed authorityID to cater for Publishing/Full registries

Actions / Timetable

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

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

• • Referral will be via ivo-id attribute

1. Will promote v1.1 of Identifier spec to PR status thence to REC
2. Implement owned/managed authorityID to cater for Publishing/Full registries

Actions / Timetable

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

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

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

Actions / Timetable

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

Actions / Timetable

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

Actions / Timetable

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. ...

Actions / Timetable

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. ...

Actions / Timetable

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. ...

Actions / Timetable

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. ...

Actions / Timetable

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)

1. Organisation type will be defined in the base VOResource definitions
2. Referred resources will be via xsi:type of RegisteredResourceType and UnregisteredResourceType
3. 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

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

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 (rahter 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)

Actions