W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2004

Re: Use case: tiger map/census data: have it your way

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 24 Mar 2004 12:31:44 +0200
Message-Id: <72369803-7D7E-11D8-858C-000A95EAFCEA@nokia.com>
Cc: Dan Connolly <connolly@w3.org>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: "ext Eric Prud'hommeaux" <eric@w3.org>


On Mar 23, 2004, at 05:21, ext Eric Prud'hommeaux wrote:

> value-constrained query approach:
>   same as above, only limit the scope to those cities within a 50 mile
>   *square* of Cambridge. (Assuming 42.3, -71.1 for Cambridge, MA and
>   one mile corresponds to .01 degrees in both latitude and longitude):
> QL requirements: conjunction+numeric comparison
>     ?city gis:latitude ?lat
>     ?city gis:longitude ?long
>     ?lat <= 42.8
>     ?lat >= 41.8
>     ?long <= 70.6
>     ?long >= 71.6
>   collect (?city ?lat ?long)
> You still have to write a program to do the same math, but you get to
> greatly reduce the query result set that the program must walk through.

This was the approach I also proposed, and the one that I think
makes most sense at this point in time.

Adding support for mathematical functions is something that we likely
will want to do during a second pass -- and which I expect can be
done as a fully backwards-compatible extension to whatever we come
up with in the first version, but I think that doing it now is
taking a bigger bite than we have time to chew...

(there's also the issue of adoption due to implementational burden)

I.e. I think we should consider math (or other add-on) functions one of
those "out of scope but nearby" issues, for which we can address in the
documentation using examples such as above which illustrate how such 
things
can be done on the client side in conjunction with a 
slightly-less-powerful
DAWG query.

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com
Received on Wednesday, 24 March 2004 05:40:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:18 GMT