W3C home > Mailing lists > Public > public-lod@w3.org > June 2010

Re: URI's for Geogrid like Resource

From: Peter DeVries <pete.devries@gmail.com>
Date: Thu, 17 Jun 2010 11:05:05 -0500
Message-ID: <AANLkTikIulMBxwSfa8jP8GWnakpTJtobw8ODbr8p1YDO@mail.gmail.com>
To: Sean Gillies <sean.gillies@gmail.com>
Cc: "public-lod@w3.org" <public-lod@w3.org>
Hi Sean,

Thank your for this information. I had originally been checking for species
ranges that intersect with a particular point by querying a PostGIS
database. At the time, I also had a number of
records that were at the resolution of a US county. It seemed particularly
efficient to use the geonames URI's for county and then query a triple store
to get county level information. I thought that by creating geogrids that
were uniform and smaller than county, I would be able to do these kinds of
queries uniformly, efficiently and at a smaller scale.

Your note has made me think that what you propose might be a better.

Since the proportion of insects that have vector base range maps if fairly
small compared to the number of species, it seems that your approach might
also help in creating vector range maps from collection records. This would
be going in the opposite direction i.e points => vector range map
"hypothesis".

One of the issues I am wondering about is how quick would these kinds of
queries be? In the past, my attempts to query what species have ranges that
overlap point(x,y) were fairly slow compared to what species
*areExpectedIn*this geonames location.

You have also made me think about what would be the best way to model the
following:

<SpeciesConceptX> <hasHypothesizedRangeOf> <?>

I was thinking of *HypothesizedRange*, since we can only estimate what the
actual range is, and different groups might have different *
HypothesizedRange* for the same species concept.

There might also be a difference between *CurrentHypothesizedRange* and *
FutureHypothesizedRange_2050.*
*
*
One aspect of the geo: solution is that it is a uniform vocabulary, you
could achieve a similar result if some standards body created a standard set
of geogrid-like URI's that everyone would use. However, I am concerned that
different groups will have different URI's for what are the essentially the
same geogrids.
*
*
Thanks again. I will be thinking over your suggestions over the next few
days and it might be interesting to try it with some test data :-)

- Pete


On Thu, Jun 17, 2010 at 2:57 AM, Sean Gillies <sean.gillies@gmail.com>wrote:

> Peter,
>
> geo: URIs are a good fit for geographic axioms such as the points in our
> shared, global coordinate reference systems. IMO, we shouldn't be encoding
> non-axiomatic concepts like application-specific regional partitions (grids)
> into geo: URIs and should use http: URIs.
>
> I'm working in partitioned space in a project and have realized that if I
> distinguish between a spatial object and its location and use predicates
> from 9IM or RCC, I can take advantage of a large field of knowledge in
> qualitative spatial reasoning and handle change in location over time. For
> example, instead of
>
>   Species_A expectedIn GridCell_42
>
> model
>
>   Range(Species_A) hasLocation X
>   X partiallyOverlaps GridCell_42
>
> There's not a lot of qualitative spatial reasoning tools out there, but
> there is abundant theory and guidance on what can and can't be reasoned.
> This sort of model for species range also seems to align well with
> conventional GIS vector and raster models.
>
> Cheers,
>
> --
> Sean
>
>
> On Mon, Jun 14, 2010 at 10:30 PM, Peter DeVries <pete.devries@gmail.com>wrote:
>
>> Hi Søren,
>>
>> People will correct me if I am wrong but I think that rdf:Bag causes
>> problems with SPARQL queries, but I like what you are suggesting and it may
>> be that there is some other way to get this goal
>> achieved. In the RDF example, I think I have the geonames URI for the
>> Country "US". This then tags this geogrid as being in the US.
>>
>> The difference between this an other approaches is that each box is
>> "square" and has the same area. Solutions that create grids that are based
>> on degrees will get more rectangular the farther that you get from the
>> equator. The nearly equal area of this approach will be helpful for species
>> or individuals / area.
>>
>> I kind of like the idea of keeping the extent in the URI. If you start
>> making geogrids of 1km x 1km as regular resources you will need a lot of RDF
>> just to cover the planet. It would seem to be a big
>> RAM commitment for your triple store. Having the extent included in the
>> URI means that supporting triple stores would know how to interpret all of
>> them. This way I just need to make statements about
>> the geogrids for which I have records, not the entire surface of the
>> planet.
>>
>> - Pete
>>
>> On Mon, Jun 14, 2010 at 7:30 AM, Søren Roug <Soren.Roug@eea.europa.eu>wrote:
>>
>>>  I doubt that encoding the geospatial extent into the URI is a good
>>> idea. It would be preferable to add a bounding box property to existing
>>> resources. If you go to Wisconsin in GeoNames (
>>> http://linkeddata.uriburner.com/about/html/http/sws.geonames.org/5279468/)
>>> you'll see a "geo:geometry" property. It has the limitation that it can only
>>> handle points. But you could have an x:boundedBy property that takes four
>>> values. West, South, East, North.
>>>
>>>
>>>
>>> Now, this matches your need for a geogrid URI, and it is quite easy to
>>> convert to KML. But as soon as you try to put a bounding box around USA, you
>>> run into problems with Hawaii and Alaska. My proposal allows you to have
>>> several bounding boxes inside an <rdf:Bag> or by just repeating the
>>> property.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Søren Roug
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* public-lod-request@w3.org [mailto:public-lod-request@w3.org] *On
>>> Behalf Of *Peter DeVries
>>> *Sent:* 11 June 2010 17:20
>>> *To:* public-lod@w3.org
>>> *Subject:* URI's for Geogrid like Resource
>>>
>>>
>>>
>>> Hi LOD'ers,
>>>
>>>
>>>
>>> In the GeoSpecies data set I have a predicate isExpectedIn.
>>>
>>>
>>>
>>> This is used to state that a given species is expected in a geographical
>>> area.
>>>
>>>
>>>
>>> Most of the time I use the geonames features as the object
>>>
>>>
>>>
>>> So <
>>> http://linkeddata.uriburner.com/about/html/http/lod.geospecies.org/ses/mCcSp>
>>>
>>> http://lod.geospecies.org/ses/mCcSp<http://linkeddata.uriburner.com/about/html/http/lod.geospecies.org/ses/mCcSp>
>>>
>>> geospecies:isExpectedIn<http://linkeddata.uriburner.com/about/html/http/rdf.geospecies.org/ont/geospecies%01isExpectedIn>
>>>
>>> §  http://sws.geonames.org/6255149/<http://linkeddata.uriburner.com/about/html/http/sws.geonames.org/6255149/>
>>>
>>> §  http://sws.geonames.org/5279468/<http://linkeddata.uriburner.com/about/html/http/sws.geonames.org/5279468/>
>>>
>>> §  http://sws.geonames.org/4862182/<http://linkeddata.uriburner.com/about/html/http/sws.geonames.org/4862182/>
>>>
>>> §  http://sws.geonames.org/5037779/<http://linkeddata.uriburner.com/about/html/http/sws.geonames.org/5037779/>
>>>
>>> §  http://sws.geonames.org/5001836/<http://linkeddata.uriburner.com/about/html/http/sws.geonames.org/5001836/>
>>>
>>> I also do the reverse link so you can query what species are in what
>>> geonames feature
>>>
>>>
>>>
>>>
>>>
>>> <!-- Wisconsin State Link Out -->
>>>
>>>   <geospecies:State rdf:about="http://sws.geonames.org/5279468/">
>>>
>>>     <geospecies:hasExpectationOf rdf:resource="http://lod.geospecies.org/ses/mCcSp"/>
>>>
>>>   </geospecies:State>
>>>
>>>  At present this just get's me to county, and I have always wanted to
>>> get something that was more uniform and global.
>>>
>>>
>>>
>>> This would need URI's that are of a grid equally sized polygons that are
>>> either equal in X, Y by either decimal degrees or meters.
>>>
>>>
>>>
>>> I marked up this example, that is a one tenth decimal degree by 1 tenth
>>> decimal degree. It is rectangular in actual distance (meters/kilometers)
>>>
>>>
>>>
>>>
>>> http://lod.taxonconcept.org/examples/geogrid/10/N93d0_37d1_W93d0_37d1.html
>>>
>>>
>>>
>>> http://lod.taxonconcept.org/examples/geogrid/10/N93d0_37d1_W93d0_37d1.rdf
>>>
>>>
>>>
>>> What I am wondering is, is there already an existing set of URI's that do
>>> the same sort of thing?
>>>
>>>
>>>
>>> Has anyone been able to create valid RDFa that also works with
>>> GoogleMaps?
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> - Pete
>>>
>>>
>>>
>>>
>>>
>>>
>>> ----------------------------------------------------------------
>>> Pete DeVries
>>> Department of Entomology
>>> University of Wisconsin - Madison
>>> 445 Russell Laboratories
>>> 1630 Linden Drive
>>> Madison, WI 53706
>>> GeoSpecies Knowledge Base
>>> About the GeoSpecies Knowledge Base
>>> ------------------------------------------------------------
>>>
>>
>>
>>
>> --
>> ----------------------------------------------------------------
>> Pete DeVries
>> Department of Entomology
>> University of Wisconsin - Madison
>> 445 Russell Laboratories
>> 1630 Linden Drive
>> Madison, WI 53706
>> GeoSpecies Knowledge Base
>> About the GeoSpecies Knowledge Base
>> ------------------------------------------------------------
>>
>
>
>
> --
> Sean Gillies
> Programmer
> Institute for the Study of the Ancient World
> New York University
>



-- 
----------------------------------------------------------------
Pete DeVries
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
GeoSpecies Knowledge Base
About the GeoSpecies Knowledge Base
------------------------------------------------------------
Received on Thursday, 17 June 2010 16:05:42 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:27 UTC