Hi Steve and Markus,
There are several levels to this so I will start with the advantages of the geo vocabulary.
What I am proposing is that we add this so people can use it if they want to but it would not be required.
Part 1: The geo vocabulary
The geo vocabulary is a widely understood standard that is supported by many tools.
If allows tools to properly interpret and map records as demonstrated by these SPARQL Query.
DESCRIBE ?x WHERE {
?x txn:occurrenceHasSpeciesConcept boloria_selene:.
}
==
DESCRIBE ?x WHERE {
?x txn:areaHasObservedSpeciesConcept boloria_selene:.
}
I am having some issues with my queries going directly to a pretty map but you should be able to tweek the queries above to give you something like the screen shot that is attached to this email.
Part 2
Extending the geo vocabulary with a radius using a
ietf.org proposed standard.
The main problem with it is that it does not directly support an extent / radius / pointRadiusSpatialFit measure.
What I did in this example is that I extended the geo vocabulary to it included a radius measure, using the proposed ietf standard listed below
So it is no longer a Point but an "Area" - Which is an instance of the "Location" described by Markus.
Here is an example with some of the non-relevant stuff taken out.
<dwc_area:Area rdf:about="geo:44.86528100,-87.23147800;u=10">
<dcterms:title>44.86528100, -87.23147800 Radius 10 meters</dcterms:title>
<dcterms:identifier>geo:44.86528100,-87.23147800;u=10</dcterms:identifier>
<dcterms:created>2010-10-28T00:00:00-0500</dcterms:created>
<dcterms:modified>2010-11-19T22:17:37-0600</dcterms:modified>
<geo:lat>44.86528100</geo:lat>
<geo:long>-87.23147800</geo:long>
<dwc_area:radius>10</dwc_area:radius>
What I have done with my examples is standardized on a fixed precision to the lat and log.
The level of precision does not have be this high, we just need to have an agreed on level of precision.
(Probably something that we should do anyway since the actual precision should not be inferred by the significant digits.)
So Steve's 44.86,-87.23 => 44.86000000, -87.23000000.
Now we have a standard urn-like entity for an area that follows the proposed ietf standard.
Other data like soil type, weather etc can be tied to these areas.
Area1 => hasDegreeDayValue "2105"
Other areas can be related to this area Area1 within Area2, AreaB near AreaC etc.
AreaZ within NaturePreserveB
Also the following was recently proposed by the
ietf.org
A Uniform Resource Identifier for Geographic Locations ('geo' URI)
* Not clear that all the systems understand this but URIburner and Virtuoso interprets these as a URN type thing so they work but are not understood in the way that the "geo" vocabulary is understood. Note that if and when this becomes a standard it will allow these "Areas" to be universally understood.
What this means is that I can markup my 10,0000 mosquito records from one location with one URN type id.
In summary, these allow more efficient occurrence records that leverage the existing support for the geo vocabulary and the probably support for the
ietf.org standard.
I have added some predicate to the vocabulary that allow inferencing from the area through the geonames hierarchy.
This would allow one to infer the following about the record above.
Area > areaWithInFeature => Door County => Wisconsin => United States => North America = Earth
This does not mean that additions could also be made that allow inferencing up some other non-geonames hierarchy.
Here is an example of an occurrence record that uses this:
Respectfully,
- Pete
On Fri, Nov 19, 2010 at 12:32 PM, Steve Baskauf
<steve.baskauf@vanderbilt.edu> wrote:
Pete,
I was going to ask questions about this the first time you mentioned
it, but got distracted. I guess the main question I have is: what you
would "do" with it? I guess it could be considered an identifier for a
spot on the earth, but based on what I've read about guids it's
considered to be a "no-no" to try to infer stuff about a resource by
looking at the form of the identifier. Rather one should look at the
metadata associated with the identifier to understand things about the
identifier (which you provide with geo:lat and geo:long). I suppose
that one could consider this to be some kind of identifier that could
be reused, but particularly since the precision of your lat and long
are 8 digits, it is highly unlikely that anybody besides you is ever
going to choose to use this identifier over (vs. 44.86,-87.23 which
would be imprecise enough to include a lot of places to which people
might want to refer). I may just be misunderstanding the purpose you
intend.
The other question is a more general one. Do we need more ways to
specify uncertainty in location than we already have? We already have
dwc:coordinateUncertaintyInMeters and dwc:coordinatePrecision . I've
been using dwc:coordinateUncertaintyInMeters with a seat-of-the pants
estimate on my part about how accurate I think my geolocation is
(expressed in meters). That may be a misuse of this term because I'm
really thinking radius around a point rather than uncertainty of
coordinates. But as a practical matter, if I think my estimate of
location is good to 1000 m (vs. 100 m or 10000 m) does it really matter
if I'm talking about a square or a circle? In any case, I'm saying,
this lat/long could be off from the actual location by a km. If I had
a GPS receiver that allowed me to download the actual estimated
accuracy (based on satellite signals and whatever else), then I would
populate dwc:coordinateUncertaintyInMeters with that, but mine crummy
old one doesn't. To me the most important thing is for users to know
whether this is a ballpark estimate or if they could expect to actually
be able to walk up to the tree using the coordinates they give.
Steve
Peter DeVries wrote:
I wrote about this earlier but I never heard anything back.
I have made something that uses the geo vocabulary but also
allows pointRadiusSpatial fit measure that I call radius.
The advantage is that this adds a standard way to deal use
something like an extent or pointRadiusSpatial while still benefiting
from the widely used geo vocabulary.
It also allows these "Areas" to be referenced in a commonly
understood urn way that using a ietf standard.
For example: "geo:44.86528100,-87.23147800;u=10"
There are still some things I need to fix and check with this
vocabulary but I am wondering if there is any interest in incorporating
this into the DarwinCore.
If not I will probably change the name of the ontology.
There are also things in the example below that are not part of
my proposal.
I have what I call "Areas" that look like this:
<dwc_area:Area
rdf:about="geo:44.86528100,-87.23147800;u=10">
<dcterms:title>44.86528100, -87.23147800 Radius 10
meters</dcterms:title>
<dcterms:identifier>geo:44.86528100,-87.23147800;u=10</dcterms:identifier>
<dcterms:created>2010-10-28T00:00:00-0500</dcterms:created>
<dcterms:modified>2010-11-09T16:33:34-0600</dcterms:modified>
<geo:lat>44.86528100</geo:lat>
<geo:long>-87.23147800</geo:long>
<dwc_area:radius>10</dwc_area:radius>
<txn:elevation>186.54</txn:elevation>
<txn:continent>North
America</txn:continent>
<txn:countryCode>US</txn:countryCode>
<txn:country>United
States</txn:country>
<txn:stateProvince>Wisconsin</txn:stateProvince>
<txn:county>Door</txn:county>
<txn:localityText>Town
of Sevastopol</txn:localityText>
<txn:locationName>Shivering Sands Natural Area
Woods</txn:locationName>
</dwc_area:Area>
I recently added the following
predicates, but have not altered my RDF examples.
#featureContainsArea
#areaWithInFeature
The predicates are a bit awkward, but I wanted to be clear that
this was to link an "Area" like "geo:44.86528100,-87.23147800;u=10" to
a Geonames "Feature".
I thought a different set of predicates could be created to deal
with some other class of "SpatialThing" if needed.
Respectfully,
- Pete
---------------------------------------------------------------
Pete DeVries
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
TaxonConcept Knowledge Base /
GeoSpecies Knowledge Base
About the GeoSpecies Knowledge Base
------------------------------------------------------------
--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences
postal mail address:
VU Station B 351634
Nashville, TN 37235-1634, U.S.A.
delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235
office: 2128 Stevenson Center
phone: (615) 343-4582, fax: (615) 343-6707
http://bioimages.vanderbilt.edu
--