Re: BAND question

From: Anita Richards <amsr-at-jb.man.ac.uk>
Date: Thu, 18 May 2006 09:45:41 +0100 (BST)

> Hi Alberto, Doug,
>
> ... good point. In order to tackle this and another comment received in the DAL
> session this week I'd like to put another gray box with a note to section 7.4
> which deals with ordered lists and the issue of boundaries:
>
> "Interval and range list query paramaters SHOULD be ordered monotonically.
> Interval boundaries are included in the search range. A service SHOULD return
> any record inside or just overlapping the search interval. A service SHOULD err
> on the side of inclusion thereby leaving the ultimate decision to the consumer
> whether to select it for retrieval. A service MAY truncate or compute data to
> match the exact boundaries."
>
>
> One may argue for turning the SHOULDs into MUSTs but this would give service
> providers no means to exlude items from a result which would otherwise be
> deemend unreasonable for one reason or another. One could also be more specific
> depending on the type of data (atlas vs modeled), but I'm not sure being more
> verbose is useful.
>
> Cheers,
> Markus

Yes, Markus is right; this is a good example of where we need to allow flexibility at present (and not make the spec too verbose either). The only comments I would make are

  1. "...just overlapping the search interval." Leave out the word 'just'? As that implies that some kinds of overlaps are better than others, which at present is not possible to check, I think. In any case the Bounds may be slightly broader than the useful range of data (at least for some ranges) so erring on the side of inclusion is the best default.
  2. A question for future consideration (not to delay the present model): What about the situation when a user wants to select data in a workflow for immediate passing to another application, rather than human judgement and selection? In that case, you might want to select only data entirely ovelapping the desired range? Or falling entirely within it? Or some other criteria... Is this best done in a _second_ step separate from the model? I feel that is the best solution, since the exact demands may vary, so the important issue is that the model should allow enough detailed metadata to be passed with the data. Some data may fail to be selected either because it does not directly meet the specs, or because it lacks enough metadata to know whethr it does or not. That might be what some users want (e.g. for popular bright objects) but other users would be happy to get any data and decide for themselves. Markus's solution covers the latter case now and allows extension.

thanks
a

Received on 2006-05-18Z08:46:20