Fwd: SODA gripes (1): The Big One

Patrick Dowler pdowler.cadc at gmail.com
Fri Jan 15 17:48:54 CET 2016


I would like to add (remind) that the evolution plan includes a {metadata}
capability that we nominally said would be part of SIA-2.1 but since it is
another capability it could be defined there or in a new spec or in another
spec (eg SODA-1.1). The {metadata} capability is intended to allow clients
to get the necessary metadata for a single dataset (ID=...) so they can
figure out how to call the SODA service and take advantage of all the
features offered.

Now, that general usage pattern (make a remote call to get metadata) is
nice an clean but it isn't necessarily optimal if you want to process many
things the same way. I can understand Markus' idea to define domain
metadata inline in a SODA service descriptor but it looks a lot like an
optimisation to me. I' not saying it isn't useful/necessary to optimise,
but I do not think we should try to do that without having tackled the
general problem.

This also makes me now think that {metadata} is much more closely related
to SODA than it is to SIA and it's a good thing we thought about detailed
metadata but didn't do anything in SIA-2.0 when we didn't need it. So it is
good to advertise intentions but not do anything concrete with them until
we actually need them :-)



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160115/73b31835/attachment.html>


More information about the dal mailing list