[tdwg-tapir] Interpretation of TAPIR filters

[Renato De Giovanni]

Hi Roger,

> Does this mean that if I have a filter that specifies long, lat and  
> altitude and a provider who has no notion of altitude
> 
> 1) requests that include the long, lat and alt parameters will return  
> matches for records with those longs and lats (the alt COP will have  
> been dropped from the equals block)

No. If a request contains the parameters long, lat and alt, it will 
only get records from providers that have mapped all three underlying 
concepts. If a provider didn't map alt, you'll get no results back 
because the alt condition will evaluate to false.

> 2)  requests that include just long and lat parameters will match  
> nothing because the alt COP will evaluate to false.

No. Requests containing only long and lat will return records from 
all providers that mapped the two underlying concepts, even if they  
didn't map alt (in this case the alt condition will be dropped).

> To get a result from a provider one has to define a parameter for a  
> concept they don't map! If this is correct isn't it counter  
> intuitive?  Perhaps I have interpreted it wrongly. (long lat is  
> probably a bad example)

Well, that proposal still makes sense to me, unless I'm missing 
something. The only thing, still using your example, is that if no 
parameters are passed, all conditions will be dropped, which means 
there will be no filter and you'll get all records back (truncated by 
the maximum element repetitions, of course). But I don't think this 
is a problem.

> A related issue to this is sorting. It is not clear what the orderBy  
> operator does because there are no data types in TAPIR concepts.  

Concept data types are specified by the respective conceptual schema. 
The data types for ABCD or DarwinCore concepts, for example, are all 
well-defined by their XML Schemas. But if the conceptual schema is 
just a simple list in a CNS configuration file, with no other 
external definitions, then I agree it may be an issue. Perhaps we 
should recommend more explicitly that concepts will be better defined 
in a format which includes data types? (could even be just a simple 
list of global elements in an XML Schema).

> Should the wrapper order results by the conceptual XML schema data  
> type (if there is one) or the output model data type? 

It should order results by the data type defined in the conceptual 
schema.

> I can't see solutions for this because I can't see how a wrapper
> would implement alternative sorting mechanisms from the ones 
> it knows i.e. the types of its columns. Perhaps the capabilities
> should indicate the data type the concepts are treated as e.g.
> 
> <mappedConcept id="http://example.net/redlist/DataSourceCode"   
> alias="DataProviderCode"  as="xsd:string" />
> 
> Meaning "We have mapped this concepts and we treat it like a string".

I like the idea, even if it will just repeat an information that can 
be found in the conceptual schemas. Not sure what the others think 
about this. But I would make this new attribute optional, for 
backwards compatibility and also considering possible class concepts 
in the future.

> This problem grows when we think of data types that may be serialized  
> in different ways (date is the only one I can think of). If I want all  
> the records before a certain date how do I pass the date? 

In this case you should pass a value compatible with the 
corresponding data type. If the data type somehow accepts values in 
different formats (for instance '2002-09-24Z' or '2002-09-24+06:00') 
then the provider should be able understand all these formats when 
processing the query.

Best Regards,
--
Renato