summary of recent RI discussion

[Tony Linde]

Hi all, sorry I didn't participate in last week's discussions - I was a bit
under the weather. Many thanks to Ray for keeping the discussions on track
and producing this summary. I'll post a few responses on different topics as
I sort through the backlog!

T.

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 08 April 2005 22:21
> To: registry at ivoa.net
> Subject: summary of recent RI discussion
> 
> Hi RWGers,
> 
> I thought I would try to summarize what I think is the state 
> of the various discussion threads.  I wasn't sure until I 
> started looking back at the discussion, but we actually have 
> made some progress.  Here's my summary, segregated by topic.
> 
> 1. ownedAuthority ==> registry of registries
> 
> We ressurected the discussion of an <ownedAuthority> tag as 
> part of a mechanism for determining what registries to 
> harvest from and aggregating the harvesting at the 
> national/regional level.  The various solutions posed 
> suffered from a certain amount of complexity.  Bob Hanisch 
> suggested that the IVOA sponsor a "registry of registries": a 
> small registry containing only Registry records.  It provides 
> a central place for publishers to register their publishing 
> registries and full registries a place to find out how to 
> publish from.  
> 
> The idea of aggregating the harvesting was dropped given the 
> simplicity of this new mechanism: the number of registries to 
> harvest from might be in the low tens.  Thus, 
> <ownedAuthority> is not needed.  This idea also eliminates 
> the need for a harvester interface, which currently included a
> harvest() function and possibly a getRegistries() function.
> 
> 2. harvesting all vs. managed 
> 
> We all like the idea of being able to get all records from a 
> registry or just those that originated from that registry.  
> It was agreed to define an OAI set called "ivo_managed" to 
> harvest the latter subset.
> 
> 3. registry record curation/stamping
> 
> There was a call for moving metadata describing the registry 
> record itself out of VOResource and into a parallel block to 
> clarify the distinction.  
> Included in this block would be the verificationLevel and 
> harvestFrom tags, along with some indication of the resources 
> status/liveliness.  
> Retrieval methods, then, would get back an XML record with a 
> root element the contained the VOResource block and the 
> curation block.
> 
> While there was generally warm support for this idea, there 
> are the following misgivings:
> 
>  * There is a question about who is allowed to set/change the 
> values in 
>    the curation/stamping block.  In the NVO perspective (where the 
>    verificationLevel idea was developed), curation/stamping 
> information 
>    could be edited by any registry according to their local 
> standards.  
>    That is, they can choose what they think what records meet their 
>    quality standards.  Others were concerned that a resource 
> record was no 
>    longer identical regardless of which full registry it is retrieved 
>    from. 
>   
>  * There is a concern about metadata creep.  Having a new 
> metadata block 
>    opens the door for defining more metadata than what originally 
>    motivated the change (i.e. verificationLevel) and subsequently is 
>    really vital.  
> 
>  * This is a fairly big change in the XML that registries 
> have to support.  
>    Is the pain worth it?  
> 
> As more minor issues, we would still need to agree on exactly 
> what information to include and what the tag names should be.  
> 
> 4. ADQL/XPath ==> "RQL"
> 
> Paul Harrison posed the notion of rethinking our registry 
> query language.  His two main concerns (and correct me if I 
> have this wrong)
> are:
> 
>  * the complexity of XML; he feels we would be better served 
> by a more 
>    human readable syntax.  
> 
>  * the fact that we are tying the spec--and only partially at 
> that--to 
>    these other standards which can change and keeps us from 
> specializing 
>    to address our specific needs.  
> 
> One thing to come out of this discussion is a posting of 
> requirements for the registry language.  There is no 
> resolution at the moment, but perhaps 
> there is a clearer understanding of the issues.   
> 
> ----
> 
> Another general outcome was a general aggreement to change 
> the created and updated attributes in VOResource to support 
> the full dateTime value type.
> 
> Through our flurry of email, we've more or less obliterated 
> 3.5 of the discussion questions I posed on the twiki (that's 
> pretty good), but we've raised at least two more: 
>   1. how may resource records for the same resource differ from 
>      registry to registry?  
> 
>   2. Should we proceed with our current query language plans (though 
>      upgrade to the latest ADQL) or branch off from ADQL?  
> 
> Answering these will help point us to where we need to go on 
> the remaining issues.  I'd like to suggest we repose these 
> questions in digestable form to see if can gain a concensus.
> 
> thanks everybody!
> Ray
> 
> 
>