Day 2

1 RI Issues

1.1 Recap

1.1.1 OAI

HTTP Get: standard OAI

SOAP

1.1.2 Successes

Harvesting worked well

Searching less

Problem discovery

1.1.3 Failures

Search interface

ADQL 0.7.4 vs XPath

Discovering new registries

Communication for status updates

1.2 Issues

1.2.1 OAI

Ray: ADS looking to harvest abstract info from registries

1.2.1.1 methods/verbs

6 std methods: must respond to all of them:

• ListSets: category names & descriptions
  • eg ivo_managed
    
    records published by that registry
• ListRecords (from, until, set)
  • must specify ivo_managed if only want managed recs
  • default is ALL
• Identifier: describes registry
  • returns registry record

Discover capabilities of interface

Identifier

Resolve: ivo_managed is only way to get only managed records: default for ListRecords is all

1.2.2 resumption tokens

options

• return all
• token or paging: requires state
• cut off: NO
• add From and To parameters to search interface

resolve: add From and To for search parameters; returned in last record: From, NumberReturned, More (Y/N)

1.2.3 getResource

method:

resolve: RI includes getResource

resolve: will only take single identifier

1.2.4 ownedAuthority

recap: have got managedAuthority

resolve: drop idea of ownedAuthority

1.2.5 interfaces

resolve: schema will support multiple interface endpoints

1.2.6 full or not

axes:

• publishing and/or searchable
• full or not

publishing/searchable: whether it has the interface

full/not: Full metadata in schema

1.2.7 standard support interfaces

Note that we have to implement what GWS decides is the standard for all interfaces: but only for iVOA compliant services

eg Availbility

resolve: subtype of Service: IVOAService must contain StandardInterface endpoint

1.2.8 query language

moved by Paul: prob tying us to ADQL spec version & restriction on WHERE clause & use restricted xpath to spec col names (ele/ele/ele + attribs)

advantage with using ADQL parsers (s -> x)

long argument about adql vs xquery

resolve: will support both: adql version is mandatory; xquery is optional

resolve: if less than full resource wanted, use xquery option

resolve: can return only identifiers on adql query

1.2.9 multi-versioning

2 curation

eg fields used in wrong way: fixed by better documentation

2.1 syntactic

validates with schema

2.2 semantic

validly completed records

2.3 resolution

schemaLocation must be used in namespace

if you use xsi-type, must use prefix

2.3.1 sia schema

will add fields for ra,dec which guaranteed to return records

2.4 reg types

2.4.1 full vs selective

2.4.2 handling extensions

can registry handle extensions that are unknown?

3 other issues

3.1 compliance services

can we get some built for different xsiTypes

suggest to TechLead that groups should provide testing service as well as reference implementations

3.2 hierarchical structure

METS schema

can describe hierarchy of resources

3.2.1 mirrors

4 RofR

presentation & demo by Ray

4.1 implements publishing interface

4.2 checks for compliance

without registering if desired

4.3 enter

4.3.1 baseURL

4.3.1.1 call Identify method

4.3.2 ivoa identifier

4.4 click

access registry record

displays whether conformant

4.5 register

4.5.1 1: mail

4.5.2 2: register with key

4.6 discussion

mirroring not critical

subdomain of ivoa managed by some organisation (ESO, NCSA, ...)

define set for getting data

4.7 issues

need set name

resolve: will implement registry of registries: one only to be hosted by some facility

resolve: will add ivo_rofr set name to RI

action: Roy to decide if RofR needs standard or Note

5 validationLevel

5.1 registry modifiable data

only proposing validationLevel

5.2 0..4

0: nothing to say

1: compliant with schema

2: service functionally & syntactically compliant

3: record inspected & okay with registry owner: checked for semantically compliant

4: exemplary: mandatory that record has valid dataQuality item

5.3 issues

5.3.1 include in VOResource

not under publisher control

diff standards for diff registries

how to manage -> common practices

5.3.2 diff levels at each registry

5.3.3 quality of review based on discipline

5.3.4 how does resource get to top level for all registries

5.3.5 registries inconsistent

applications will not be able to rely on getting same data from each registry, if queried on validationLevel

feature, not a bug

5.3.6 KB proposal

reviewers for resources

will have the right experience for each type of resource

will get consistency across all resources

stops registry putting all their own resources at 4

5.3.6.1 issues

coordinated by ivoa: easier for project to decide level than ivoa

5.4 resolution

each resource will have repeating group containing:

• validationLevel
• validatingOrganisation

6 presentations

6.1 ESA

Aurelien Stebe, Christophe Arviset

6.1.1 June 2005

6.1.2 design

adql -> xslt -> xpathQL -> regex -> sql

6.1.3 tech

java,jsp/html/css + xsd, xsl + sybase/sql & xform (UI)

altova xmlspy & mapforce

tomcat & chiba

java libs:

• chiba (form engine)
• jconn, altova (db-xml interface)
• axis, xerxes, xalan

6.1.4 interfaces

can support multiple versions of adql

metadata formats: ivo_vor, esa_vor, oai_dc

methods: XPathQLSearch & GetResource

6.2 JVO

Yuji Shirasaki

6.2.1 publishing reg

use nvo software

modified to use v0.10

6.2.2 searchable

internal only

types: OpenSkyNode, SimpleImageAccess, Registry

Native XML DB: Karearea SEC

harvests from nvo,astrogrid, jvo

interface:

• standard
• getResources
• getResources (Identifier)
• getResourcesByTableName

6.2.3 resources

87 registered resources

6.2.4 usage

user access via JVO portal

data service resolver for JVO skynode portal

6.2.5 problems

invalid xml in nvo

non-std resource type

6.2.6 status

not yet adql search