[tdwg-content] Extending the geo vocabulary to include a "radius" in meters example, with example ontology and RDF file

Peter DeVries pete.devries at gmail.com
Mon Oct 11 20:44:55 CEST 2010 

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:lat>55.701</geo:lat>
    <geo:long>12.552</geo:long>
    <dwc:radius>10</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/area_example.rdf>

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:lat>55.701</geo:lat>
            <geo:long>12.552</geo:long>
        </geo:Point>
    </geo:center>
    <dwc:radius>10</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/>
------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20101011/6fc4f760/attachment.html

More information about the tdwg-content mailing list