SIA-2.0: query params for string values

[Ger van Diepen]

I'm not that familiar with the DAL specifications, but I assume an
operator like = or < has to be supplied. Why not also support operator
~= meaning about equal. It can be used for floating point values (e.g.
relatively to 1e-5), but also for this string case (substring,
case-insensitive). 
It is used in TaQL. 

Ger

>>> Jose Enrique Ruiz <jer at iaa.es> 6/30/2014 6:36 PM >>>

Hi DAL 



for the params: collection, facility_name, instrument_name and
target_name, I would just provide the vision of a potential DAL-user.
This is that in the case I didn't know the *exact values* of these
textual fields (they are not physical numeric values, but curation
metadata and I guess not so easy to infer out of the blue) or several
archives provide slightly different values for these fields, the ideal
response would be provide products satisfying "substring match" and
"non-case sensitivity", as it is the case for registry queries by
keyword in i.e. Topcat. 



This does not mean that I'm voting for substring match and
non-case-sensitive, maybe all this may be solved client side, I am just
saying that for a DAL-user the perception of these params may be not so
different from those used when performing a query in the registry by
keywords. I think a TAP-user may have a different perception, more
oriented towards "equals match" and "case-sensitivity", and if this
discussion remained only in the scope of ObsCore/TAP use cases I will
strongly support equals and non-case sensitive.  


 

FWIW, DALI clearly states in 3.1.1 "Parameter values are case sensitive
unless a concrete DAL service specification explicitly states that the
values of a specific parameter are to be treated as case-insensitive",
though I do not see anything related to equals/contains issues (we are
very used to queries with numeric values :), maybe we could find some
light from Registry-queries use cases. As I see it, in the ideal world
all these params would be issued from central resolution services
(similar to resolution of target names, filter names, etc.) integrated
both in the client side as well as in the server side (the curator
mapping these values to unique keys provided by these services..) 



Hope it helps.. 





Cheers 


---
 
Jose Enrique Ruiz
Instituto Astrofisica Andalucía - CSIC
Glorieta de la Astronomía s/n
18009 Granada, Spain
Tel: +34 958 230 618 ( tel:%2B34%20958%20230%20618 ) 







2014-06-30 15:57 GMT+02:00 Marco Molinaro <molinaro at oats.inaf.it>:



Hi Markus, 

hi DAL-ers,



2014-06-30 10:18 GMT+02:00 Markus Demleitner
<msdemlei at ari.uni-heidelberg.de>: 





Dear DAL,


On Thu, Jun 26, 2014 at 09:12:33PM +0200, Marco Molinaro wrote:
> 2014-06-26 9:25 GMT+02:00 Markus Demleitner
<msdemlei at ari.uni-heidelberg.de>

> > More precisely, I believe we shouldn't say anything about case
> > folding in the protocol. That's because unfortunately, we're
already
> > knee-deep in case-insensitivity hell: IVORNs were defined as being
> > c-i (which of course leads to no end of interoperability woes
because
> > few services actually treat them accordingly). So, if there were a
> > PUBDID parameter (which could be useful in certain datalink
> > scenarios), backend matching would have to be case insensitive.
But
> > that's a (regrettable) property of IVORNs, not the protocol.
> >
>
> Here I thing I'm missing one point (or more, don't know): what means
we
> shouldn't say anything about case sensitivity? To me this reads like
using
> case sensitive values, otherwise both client and server will never
know how
> to robustly submit or respond to a request.
> Delete the "I think" here above: What am I missing?


What I'm saying is: the protocol should say (if anything):
"Parameters are compared for equality".

The trouble hidden in there is that we've already shot ourselves in
the foot by defining equality for some relevant types in, as far as I
am concerned, unexpected ways. IVORNs, for instance, are
case-insensitive, so when you compare them for equality, you need to
do some case-folding, whether you're talking SIAv2 or OAI-PMH: It's a
property of the type, not of the protocol.

 



Ok, so equality and case-sensitivity are bound together but IVORNS
(e.g.) are a special case that complicate the interface behavior. 

Can we start thinking of using [case-sensitive] request parameters that
are compared for equality and explicitly state which are the already
existing special cases where this fails to be exactly true? 

If I remember correctly RegTAP already says something similar due to
identifiers and other stuff. 

I know that it'll complicate recommendation editing and curation but,
once all protocols have interfaces that work on the same guidelines
it'll be maybe easier to revert the "case-insensitivity hell" without
clashing on existing implementations. 

I don't know if this proposal can make sense. 



BTW, we hadn't too many contributions to this SIA-2.0 string valued
query params discussion. 



Marco 
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140701/169a0aaf/attachment-0001.html>