[tdwg-tapir] Interpretation of TAPIR filters

[Roger Hyam]

Hi Renato,

I think I follow you - but I'll probably believe it when I see it  
spelled out in the spec.

I think some of the sorting stuff should be in the specification.  
There are some things there that are implied but not expressed.

1) schema concepts should/must only be mapped to columns of the same  
data type in the host database or at least wrappers should act as if  
they are.

2) Values in queries (and parameters) should use the xsd serialization  
of date (and other things?). It is the wrappers responsibility to  
present the correctly to the underlying database.

3) If the concept does not have a data type the behaviour of orderby,  
greaterthan and lessthan are undefined? If we stick to XML Schema  
concept schemas then they default to string so maybe the default  
should be to act as string.

What do you think?

Roger


On 23 Nov 2007, at 05:29, Renato De Giovanni wrote:

> 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
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir