VOResource Schema v1.0

1
THE INTERNATIONAL VIRTUAL OBSERVATORY ALLIANCE
VOResource Schema v1.0 Release 6

1. General Changes since Kyoto
2. Revised Service Model

Ray Plante NCSA
2
Roadmap for VOResource Schemas

• Aiming to upgrade registries to RI v1.0 this
  summer
• Dependencies
• RI v1.0 gt VOResource v1.0, ADQL v? gt RM v1.1,
  Identifiers v1.0
• VOResource v1.0 Core Metadata Model
• Move to PR status ASAP
• Components
• Core metadata from RM v1.1
• New Service model
• VORegistry v1.0 for supporting RI
• To be incorporated into RI v1.0 (ASAP)
• VODataService v1.0, SIA v1.0, ConeSearch v1.0,
  SkyNode v1.0
• Over the next six months
• Coordinate with next revisions of DAL services
• Focus on issues of fine vs. coarse grain
  registries
• VOStandard v1.0 (new)
• 1 year

3
VOResource v1.0 Specification

• Overview
• Builds on Resource Metadata v1.0
• Adopts names and definitions
• Basic Data Model
• Overall Model (mapping RM to Schema)
• Including new Service Model
• Conventions for XML definitions
• How to extend the schema
• Detailed XML definitions
• Complete, explicit semantic definition of EVERY
  element name
• Reference manual approach

4
VOResource Miscellaneous Changes

• Require full timestamp on created, updated
• Date handling n previous release
• All dates must be UTC ltdategt, created, updated
• Allowed either xsdate or xsdateTime via a
  xsunion
• 2006-05-15 or 2006-05-15091500Z
• code generator note wsdl2java returns Calendar
  type
• Required Z suffix to denote UTC
• Disallow future times
• Proposed change
• created, updated xsdateTime
• Drop forcing Z suffix on timestamps
• Just assume UTC

5
VOResource Miscellaneous Changes

• Relationships
• Was
• Now
• Alt
• Why
• allows new relationship names to be defined in an
  extension schema without requiring an update to
  the VOResource core schema
• Use xsitype to select the desired set of
  relationship types to draw from

ltrelationshipgt ltrelationshipTypegtservice-forlt/
relationshipTypegt ltrelatedResource
ivo-id"ivo//adil.ncsa/adil"gt NCSA
Astronomy Digital Image Library
lt/relatedResourcegt lt/relationshipgt
ltrelationship xsitype"vrCoreRelationship"gt
ltrelatedResource ivo-id"ivo//adil.ncsa/adil"gt
NCSA Astronomy Digital Image Library
lt/relatedResourcegt ltrelationshipTypegt
service-for lt/relationshipTypegt lt/relationshipgt
ltrelationshipgt ltrelatedResource
ivo-id"ivo//adil.ncsa/adil"gt NCSA
Astronomy Digital Image Library
lt/relatedResourcegt ltrelationshipType
xsitype"vrCoreRelationship"gt service-for
lt/relationshipTypegt lt/relationshipgt
6
VOResource Miscellaneous Changes

• Move WebService Interface sub-type to core schema
• Definition A Web Service that is describable by
  a WSDL document
• Allows description of a generic WS without an
  extension schema
• ltinterface xsitype"vrWebService"gt
• ltaccessURLgt
• http//nvo.ncsa.uiuc.edu8081/validate/ConeSe
  archValidater
• lt/accessURLgt
• lt!- OPTIONAL only needed if ?wsdl doesn't
  work for this service --gt
• ltwsdlURLgt
• http//nvo.ncsa.uiuc.edu/VO/services/ConeSear
  chValidater.wsdl
• lt/wsdlURLgt
• lt/interfacegt
• accessURL is the service endpoint

7
VOResource Miscellaneous Changes

• elementFormDefaultunqualified
• qualified means
• locally-defined elements must indicate
  elements namespace
• xmlnshttp//www.ivoa.net/xml/VOResource/v1.0
• Or via namespace prefix ltvrtitlegt
• Gets messy when combining terms from different
  schemas
• XPaths must include prefixes
• vrcapability/siamaxRecords
• unqualified no xmlns, prefixes
• Types that appear in xsitype still need prefix
• Authors dont have to worry about which elements
  are part of which schema -- less error prone!
• Simpler XPaths
• Capability/maxRecords

8
VODataServices Miscellaneous Changes

• Change Resource class name
• SkyService -gt DataService, ObsDataService, or ??
• Metadata added beyond core
• Facility, Instrument, Coverage
• Change Resource class name
• TabularSkyService -gt CatalogService
• Metadata added beyond SkyService Table

9
VODataServices Miscellaneous Changes

• STC integration
• Contents
• stcSTCResourceProfile, footprint, waveband
• Issues
• STC uses elementFormDefaultqualified
• Must use namespace prefix on STC element
• Regsitry can not index it in same way as other
  registry data
• Complex model with many alternate markup
• Searching will require special tranformation
• Will require help for authors on creating STC
  descripitons.

10
New Service Modelhttp//www.ivoa.net/twiki/bin/vi
ew/IVOA/RegDMServices

• Goals
• Indicate standard version Multiple version
  support
• Support multiple endpoints covering different
  parts of a single, logical service
• Allow descriptions of additional, non-standard
  interfaces
• Clarify the association between service
  capability metadata and interface that supports
  the capability

11
New Service Modelhttp//www.ivoa.net/twiki/bin/vi
ew/IVOA/RegDMServices
12
New Service Modelhttp//www.ivoa.net/twiki/bin/vi
ew/IVOA/RegDMServices

• Bring together various related service
  capabilities together into one logical Resource
  record Service with capabilities
• Structure
• Service has one or more ltcapabilitygt elements
• Capability type specialized for standard services
• ltcapability xsitypecsConeSearch gt
• Interface has one or more ltinterfacegt elements
• Indicates which version is supported
• List alternate interfaces
• Finding ConeSearch services
• v0.10 _at_xsitype like ConeSearch
• v1.0 capability/_at_xsitype like ConeSearch
• Add ltvalidationLevelgt as child of ltcapabilitygt
• Allows different capabilities to be evaluated
  independently
• This validationLevel focuses capability metadata
  and compliance with service standard (e.g.
  ConeSearch)
• Top level validationLevel remains, focuses on
  core metadata description

13
New Service Modelhttp//www.ivoa.net/twiki/bin/vi
ew/IVOA/RegDMServices
ltcapability xsitype"snSkyNode"
standardID"ivo//ivoa.net/std/SkyNode"gt
ltvalidationLevel validatedBy"ivo//nvo.ncsa/regis
try"gt2lt/validationLevelgt lt!-- version 1.0 of
the standard SkyNode interface --gt ltinterface
xsitype"vrWebService" role"std"
version"1.0"gt ltaccessURLgt
http//archive.org/service/skynode lt/accessURLgt
lt/interfacegt lt!-- version 1.1 of the standard
SkyNode interface --gt ltinterface
xsitype"vrWebService" role"std"
version"1.1"gt ltaccessURLgt
http//archive.org/service/skynode1.1
lt/accessURLgt lt/interfacegt lt!-- a
interactive alternative interface, assesible via
a browser --gt ltinterface xsitype"vrWebBrows
er"gt ltaccessURLgt http//archive.org/skynode.h
tml lt/accessURLgt lt/interfacegt
... lt/capabilitygt
14
New Service Modelhttp//www.ivoa.net/twiki/bin/vi
ew/IVOA/RegDMServices

• Alternate way to identify support for standard
  standardID""
• Useful when standard does not require specialized
  capability metadata.
• Lower cost to registries, applications for adding
  support
• Use of IVOA Identifier implies registration of
  standard in a registry
• Propose to register IVOA standards in the IVOA
  Registry of Registries
• Local standards could be registered anywhere
• VOStandard schema for describing standards
• standardID can lead users to specification
  documents
• standardID -gt service standard record -gt
  ltreferenceURLgt
• Can include other information useful to workflow
  GUI-builders
• Interface all content data is optional except
  ltaccessURLgt
• Previously, an SIA interface description included
  redundant metadata
• ParamHTTP interface output MIME type, input
  parameters (including required ones)
• Good for supporting workflow automatic GUI
  builders
• In practice, SIA-aware applications ignore all
  info but accessURL
• Now service standard entry can contain
  description of default interface an SIA
• Implementation record may list support for
  optional or non-standard parameters