[tdwg-tapir] Interpretation of TAPIR filters

Renato De Giovanni renato at cria.org.br
Fri Nov 23 02:53:02 CET 2007


Dear all,

I came across an issue that I know it was discussed before, but I 
couldn't find anything about it in the spec and I couldn't find a 
message with a final agreement/solution.

The issue is: How should TAPIR filters be interpreted if they 
reference concepts that are not understood by providers or if they 
reference parameters that were not passed?

Query templates may often include parameterized filters with many 
conditions, such as:

<filter>
  <and>
    <equals>
      <concept id="http://rs.tdwg.org/dwc/dwcore/Genus"/>
      <parameter name="genus"/>
    </equals>
    <equals>
      <concept id="http://rs.tdwg.org/dwc/dwcore/SpecificEpithet"/>
      <parameter name="species"/>
    </equals>
    <equals>
      <concept id="http://rs.tdwg.org/dwc/dwcore/Country"/>
      <parameter name="country"/>
    </equals>
  </and>
</filter>

And it's important to be able to use the same query template even 
when not all parameters are passed, such as allowing all these calls:

http://myprovider.org/tapir?op=search&t=mytemplate&genus=x

http://myprovider.org/tapir?op=search&t=mytemplate&genus=x&species=y

http://myprovider.org/tapir?op=search&t=mytemplate&country=z

and so on...

Otherwise we would need a different template for each combination of 
parameters, which would certainly make clients very unhappy.

I've been discussing this with Markus and we're leaning towards the 
following suggestion about how to interpret filters:

1- Comparative operators (COPs) that reference unspecified parameters 
should be simply dropped from the filter.
2- COPs must evaluate to false if they reference a concept that is 
not understood by the provider, unless they also reference an 
unspecified parameter - in which case the COP must be dropped from 
the filter.
3- After dropping a COP, if it was part of a logical operator (LOP) 
then the LOP should also be dropped if there are no boolean operators 
left inside the LOP.
4- After dropping a LOP, if it was part of another LOP, then the 
parent LOP should also be dropped if there are no boolean operators 
left inside the parent LOP.

There's clearly a gap in the specification about this and we need to 
fix it, so please let me know if you have any thoughts about this. If 
there are no objections or better suggestions, then I'll probably use 
the proposal above to amend the spec.

Many thanks!
--
Renato




More information about the tdwg-tag mailing list