Difference: InterOpMay2006ResReg (20 vs. 21)

Sessions and their agenda will be posted here nearer the meeting date.

Agenda

Notes

• http://ivoa.net/twiki/bin/view/IVOA/InterOpMay2006ResReg

• http://ivoa.net/twiki/bin/view/IVOA/VOResourceV10
• http://ivoa.net/internal/IVOA/VOResourceV10/WD-VOResource-v1.html

• http://ivoa.net/twiki/bin/view/IVOA/RegDMServices

• http://ivoa.net/twiki/bin/view/IVOA/RegDMApplications

Session 1

VOResource basic changes

• Timestamp on created, updated
  • xs:dateTime instead of <date>
  • Drop 'Z': assume UTC
  • AGREED
  • also AGREED that both elements should be mandatory
• Relationships
  • Define new relationships types in extension schema
    • Use xsi:type
    • NOT AGREED
  • Will add list of keywords for rel types in doc appendix and registry systems have to code that list validation
    • AGREED
• Move webservice Interface sub-type to core schema
  • Allows desc of generic ws wo ext schema
  • accessURL is the service endpoint
  • AGREED
• elementFormDefault="unqualified"
  • All terms look like from same namespace
  • Throws element name into noname ns
  • DEFERRED
• Changes to resource class names
  • SkyService -> DataService
  • TabularSkyService -> CatalogService
  • AGREED
• STC integration
  • Contents:
    • stc:STCResourceProfile, footprint, waveband
  • Issues
    • ns is "qualified"
    • Cannot index in same way e.g. for searching
      • Services under dev't
    • Help for authors
  • AGREED
    • But need to develop tools

The issue of the usability of registry interface applications was raised: how easy it was for users (primarily data centre persons) to enter and maintain resource information. It was AGREED that the Registry sessions for the September Interop meeting in Moscow should focus on registry systems usability.

New Service Model

• Goals
  • Indicate std version
  • Support multiple endpoints
  • Desc non-std i/fs
  • Clarify assoc between service cap metadata and i/f
• Support for std via standardID
  • Registered as resource
    • Not mandated: use URI
  • Put into RofR
  • Req extension schema
  • AGREED
• Service with capabilities
  • Structure
  • Finding services
  • Add validationLevel as child of Capability
  • Extra metadata validation reqd
  • AGREED
• Interface: all content data optional except accessURL
  • Impl may list support for optional or non-std parameters
  • Interface info in std resource record

Session 2

Applications

• Extension rather than 'core'
• Goals:
  • support app-specific metadata
  • Info on stds & formats
  • Concepts of desktop app, sw lib, apps called as services
• voStandard
• Execution environment
  • Platform: generic
  • Subtype
  • Version, …
• Data formats
  • AGREED use MIMEtypes
• AGREED for Paul to produce WD for VOApplications
  • DEFERRED decision on how to replicate such info across registries to final roadmap discussion

CEA Applications

• CEA interface: how to define app asynchronously (not discussed here)
• App model
• Features
  • Multiple i/fs
  • Parameters
• a number of people were interested in developing apps which would register and be able to be discovered using this extension
• AGREED for Paul to produce WD for CEAApplication extension

Session 3

Registry Interface

• Kev gave quick run through of existing document
  • http://ivoa.net/internal/IVOA/RegistryInterface/RegistryInterface-v0.8.1.pdf

Issues:

• ADQL searching (with qualified resource schemas)
  • Unqualified ns allows no prefixes so spec needs to change
  • AGREED that Tues discussion re unqualified is ratified
• ADQL core/extended
  • Core is simple sql with REGION
    • AGREED we will implement restricted set of v1.0 of ADQL core with xpath specification of the elements
  • Extended incl multiple tables, xmatch, etc
    • Not an issue
• WSDL & RegInterface schema qualified & unqualified
  • WSDL qualified
  • But type section for messages will be unqualified
• KeywordSearch: boolean orWords
  • AGREED mandatory with default TRUE
• Xquery
  • Root element: use /RootResource
    • AGREED
    • AGREED that it is Mandatory
  • Tag in schema which says whether registry supports XQuery
    • done
• Extensions for harvesting and storing
  • AGREED mandatory that all registries MUST return full record as harvested, whether or not it can search on the extension information
• Xpath
  • Issue of e.g. selecting SIAP resources with maxRecords < 100
  • Where capability/@xsi:type="vr:SimpleImageAccess" AND capability/maxRecords<100
  • Might use keyword SimpleImageAccess or function (CAPABILITY)
  • Not an easy solution so v1.0 will not deal with this
    • Need feedback from those providing relational registries
• RofR
  • Need to create document
• Harvesting: sets
  • Allows selection of subset of collection
  • ivo_managed: only those defined in registry
    • Will mostly use this for harvesting
    • AGREED only this one in v1.0
  • Following not in v1.0 spec: registries can try these out
    • ivo_standard: only standard schemas
    • ivo_name that matches resource type
• Registering standards
  • Schema still under discussion

Session 4

Granularity

• Prelim on securityMethod

• Ray introduced topic with presentation
  • http://ivoa.net/internal/IVOA/InterOpMay2006ResReg/IVOAMay06Graininess.ppt
• Issues:
  • Metadata content: Fine-grained vs Coarse-grained
  • Types of resources in the registry
    • Larger aggregations vs images, people etc

• Data collections
  • Esp important for VizieR

• • Need to know size of catalog: coverage.objectCount is in RM

Session 5