Discovering Data Collections

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Wed Aug 12 13:03:54 CEST 2015


Pat,

On Tue, Aug 11, 2015 at 09:24:43AM -0700, Patrick Dowler wrote:
> 
> 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...

Right, though I'm not quite sure if I like the symlink metaphor.

> 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

No, the basic VOResource capability --
http://docs.g-vo.org/schemadoc/schemas/VOResource-v1_0_xsd/elements/capability.html
-- only has description, validationLevel, and interface.

I had hoped I'd get by with this, but apparently that's not enough,
so it seems we'll have to have an new capability.

> 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...

Agreed.

> 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)?

I'd be reluctant with that.  relationships are still useful for all
kinds of "soft" information (e.g., with tutorials, they let you find
"texts dealing with Aladin" or "texts using service X").  Interfaces
like WIRR finally expose them, so I guess their hour might yet come.

I'd just like to avoid basing anything "hard" on  them

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

No.  Since the main standardId of TAP is defined in the TAP standard,
so should the auxiliary standardId.

The way the DAL extensions are defined now (SimpleDALRegExt), their
aux capabilities would have to be defined there.  I'm not sure if
that's what we should do; I'd prefer if that could happen in the
respective DAL standards in the future (as in TAP, they'd then define
their main and aux capability ids).

Talking about which (and this is mainly for Pat): Maybe we could
still squeeze in something like

  Auxiliary capabilities as proposed by Demleitner (2015) have a
  standardId of 

  ivo://ivoa.net/std/SIA#query-aux-2.0

on p. 19 of SIAv2?  Or, if you're (justifiably) queasy pushing
something like this in this late in the SIAv2 process and this early in
the discoverdependent process -- maybe we could at least have the
term in the SIAv2 registry record?

Cheers,

          Markus



More information about the registry mailing list