I thought that some of the semantic web community might be able to provide some insight as to how we might be able to extend the geo vocabulary without breaking compatibility with existing tools and services.
I think it would be best to try the suggestion below with some additional sample data to see if it works as we expect before making any real decision.
Also note that this is most relevant to the fully semantic RDF version of the DarwinCore, and less relevant in the XML/CSV implementations.
Below is my original question, my test vocabulary and RDF as well as abbreviated versions of the suggestions from others:
# Original Question There was some discussion about ways to record species observations using the geo vocabulary at a recent biodiversity informatics meeting.
Some see the advantages of using the geo standard, but we really need to have a way to incorporate and error or extent in meters.
What would be the best way to extend the current geo vocabulary so that it includes this radius measure but still works well with geo aware tools and services?
The addition would be defined as the total extent including calculated error (PointRadiusSpatialFit).
This would be used to record that a species or "thing" was observed or collected within this geographical defined area.
Something like the example below, but I suspect that this might not make it a real geo:Point?
geo:Point geo:lat55.701</geo:lat> geo:long12.552</geo:long> dwc:radius10</dwc:radius> </geo:Point>
This should work so that if I have 10,000 records recorded from within this same area, I can define it once and then refer to that area description RDF in the 10,000 species occurrence records with one simple URI to that area definition.
One solution would be for the geo authors to add the radius to the geo vocabulary.
Also there may be unrelated groups that might like the radius attribute for some other use.
Another alternative would be to somehow extend the geo vocabulary within a separate vocabulary.
It is not clear to me what is the best way to do this and still retain geo compatibility.
I look forward to ideas and suggestions,
# End of Original Question ...
After reviewing the feedback I created a test vocabulary and RDF file.
The test vocabulary is in it's own namespace and called dwc_area.
It is here: http://lod.taxonconcept.org/ontology/dwc_area.owl
The HTML Document is here http://lod.taxonconcept.org/ontology/dwc_area_doc/index.html (For some reason it did not include the imported geo vocabulary)
I also made up a small test file that uses both the new geo URI and an shows the suggested way to include a radius measure.
It is here: http://lod.taxonconcept.org/rdf/area_example.rdf
It should show up in URIburner and Sindice soon. I did submit an earlier incorrect version into Sindice so that might show up as well.
Here is what the RDF looks like in URIBurner
< http://linkeddata.uriburner.com/about/html/http/lod.taxonconcept.org/rdf/are...
To get to each of the three "Areas" you need to click on the links in the * topics* list
* Note that the final location of the vocabulary is unclear. It will probably end up in the DarwinCore vocabular or in my txn vocabulary.
# Below is background info and the suggestions from the LOD community.
1) There is proposed standard that everyone should know about *A Uniform Resource Identifier for Geographic Locations ('geo' URI)* http://tools.ietf.org/html/rfc5870 (from Sean Gillies) * 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.
2) I got the following back from Bernard Vatan.
What about something as the following, since the radius is not really a
property of the point ... * Note this differs from my final examples
dwc:Area geo:center geo:Point geo:lat55.701</geo:lat> geo:long12.552</geo:long> </geo:Point> </geo:center> dwc:radius10</dwc:radius> </dwc:Area>
3) I also got this back from Paul Houle,
For Ookaboo I've worked out an internal data model for points; Ookaboo
also knows about real shapes, but the fact is that most people out there will throw points at you and only know how to consume points.
Here are a few bits of extra data that are useful to add to a point
(1) provenance (2) datum (I try to stick to WGS84, but points from freebase occasionally
have a Datum attached, so I store it)
(3) circular error (the accuracy of the determination of the point, for
instance the technical limitation of a GPS receiver)
(4) scale length of feature (how accurate do we have to be? it's not
worth getting into an edit war over the exact point that represents, say, Finland.)
(5) an overall quality rating (so if we've got ten points we can pick the
best)
# I am looking forward to comments and suggestions. If people want, this can be incorporated into the DarwinCore, but it would be best if it was done that did not entail some specific TDWG domain and ranges. This would allow it to be use by others, (perhaps for completely different kinds of things) without having to tie their work into some specific conceptualization.
Respectfully,
- Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base http://www.taxonconcept.org/ / GeoSpecies Knowledge Base http://lod.geospecies.org/ About the GeoSpecies Knowledge Base http://about.geospecies.org/ ------------------------------------------------------------