Discovering Data Collections

[Patrick Dowler]

So is the gist of the note is that this is like a symlink with the 
ivo-id of the real service? And it is a bare vr:Capability with just 
that minimal metadata (standardID, accessURL(s), etc) and the "extended" 
record (eg *RegExt) is only in service? And there is a convention on 
standardID to make these special...

And in (b) you are making a new RegExt with even less info - just the 
ivo-id - and client must lookup the servive by ivo-id? I could see a lot 
of value in including the standardID in the AuxiliaryCapability, but 
after that adding more starts to increase cost more than value (because: 
maintaining consistency). I would think ivo-id and standardID are very 
stable while the rest could change for technical reasons...


Is it feasible to deprecate the (I assume) relatively unused 
relationships? Or just remove them in a 2.0? Could that feasibly remove 
both served-by and service-for in favour of (b)?

What would happen to RegTAP? Do aux capabilities need to be added ?



Pat


On 11/08/15 06:51 AM, Markus Demleitner wrote:
> (b) Make an AuxiliaryCapability type in a little registry extension
> that has an ivoid-valued mainService attribute.
>
> Plus: All info (i.e., accessURL  and ivoid) regarding the main
> service is in one place; its presence is enforcable by XML schema;
> semantically very precise ("look here for the service*this*  is in");
> hence, works with multiple auxiliary capabilities.
>
> Minus: Major change, we'll probably need a proper REC for our schema;
> very close in purpose to relationship; sucks a bit in RegTAP, as it
> will end up in res_details, where value isn't case-normalised, which
> IVORNs should be.
>

-- 
Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)