> > Term and Data can be:  point, line, area, volume
> Oversimplifying because point, line, area, and volume don't cover: (a) curve
> and (b) surface.

A curve is a line that isn't straight.  You can't specify it by two
points, obviously, but it's still a line. You'd probably want to specify
an equation that generates the line if it was in a term.
A surface is a non straight area, and the same applies.

So you might want to make an assertion like:

1,3 is within x=(cos(y)+1)/2

[I expect that it's not, but you see the point]
[No I don't think that anyone would actually /do/ this but it doesn't
break my dimensional model, just complicates the way that you specify
terms, which is why we need Mike's relation modifiers]

> Overcomplicating because it appears that the geo folks may only want a crude
> normalized rectangle (east bounding longitute, west bounding longitude, north
> bounding latitude, and south bounding latitude).  See:

I can't comment on what they want, but if the model is generic rather than
geo-centric it'll work for other non point searches.  I agree that the geo
community are the ones that our initial focus is on, but there's plenty of
other application areas that could use them.  My background is history and
medieval lit, so my examples typically come from there, but here's another
one using a non straight line:  Did the travels of Arthur and Gawain
intersect?  (arthurPath within/partial gawainPath)

That said, the issue is with how to model these things, not the protocol.
All SRW needs (AFAICT) is within, encloses, and /partial.  Then we need
profilers to develop canonical lists of term describing relation

On the other hand, if they just want a bounding box then we can easily
provide some simple relation modifiers for things like that.


      ,'/:.          Rob Sanderson ([log in to unmask])
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: 7777
____/:::::::::::::.              WWW: