<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Pete,<br>
This topic has come up several times before and each time I've left the
email sitting in my inbox with the intention of trying to understand it
better.&nbsp; I guess what I don't understand is what one "does" with it.&nbsp; I
suppose I could dig in and do some research, but the multiple times the
message has sat in my inbox without action tells me that I'm probably
not going to get around to doing that.&nbsp; So maybe you can explain it
further.&nbsp; <br>
<br>
Is this supposed to be usable as a "Linked Data" resource (i.e. object
of a predicate such as "hasLocation")?&nbsp; It isn't an HTTP URI, so it
can't get dereferenced via http.&nbsp; I guess one parses it as a string and
interprets the string directly based on some rules.&nbsp; Isn't that a no-no
in the GUID rules?&nbsp; I guess with enough community support, applications
would know what do do with it, but look what happened with
"urn:lsid:my_organization.com:location:123".&nbsp; Web browsers and
"regular" Linked Data clients (e.g. Linked Data browsers) didn't know
what to do with it.<br>
<br>
The whole issue of provenance is pretty satisfactorily handled in the
existing Darwin Core. There are a multitude of terms available to
express all kinds of uncertainty and shapes.&nbsp; For example, if I create
a record like:<br>
<br>
&lt;rdf:Description about=<a class="moz-txt-link-rfc2396E" href="http://my_organization.com/location/123">"http://my_organization.com/location/123"</a>&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;rdf:type resource=<a class="moz-txt-link-rfc2396E" href="http://purl.org/dc/terms/Location">"http://purl.org/dc/terms/Location"</a>/&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;geo:lat&gt;36.144719&lt;/geo:lat&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;geo:long&gt;-86.801498&lt;/geo:long&gt;<br>
&nbsp;&nbsp;&nbsp;
&lt;dwc:coordinateUncertaintyInMeters&gt;1000&lt;/dwc:coordinateUncertaintyInMeters&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;dwc:georeferenceRemarks&gt;Location determined from Google
maps&lt;/dwc:georeferenceRemarks&gt;<br>
&lt;/rdf:Description&gt;<br>
<br>
I very explicitly express the type of thing, geocoordinates, datum
(implicit in the use of geo:), uncertainty, and method of generating
the data.&nbsp; If necessary, I could also use dwc:dataGeneralizations and
dwc:informationWithheld to explain how and why I have provided less
precise coordinates than I actually know.&nbsp; This is clearly more
verbose, but hey, Linked data in xml IS verbose, and existing Linked
Data applications would be able to "understand" something like what I
wrote without any kind of special "plug-in" to interpret the spring.&nbsp; I
guess I don't really understand why you are proposing this, especially
since you are a passionate advocate of Linked Data.&nbsp; Your proposed
thing is more succinct, but it doesn't seem like it would be usable by
normal Linked Data clients.<br>
<br>
Steve<br>
<br>
Bob Morris wrote:
<blockquote
 cite="mid:AANLkTi=eehmBSh-+y0bpeSsY_LpecVjXifS5CVK-zZkJ@mail.gmail.com"
 type="cite">Your arguably reasonable recoding of the geo uri's of your
example illustrates an issue on which so much metadata is silent:
provenance. Once exposed, it is probably impossible for someone to know
how the uncertainty (or any other data that might be the subject of
opinion or estimate) was determined and whether the data is fit for
some particular purpose, e.g. that the species were observed near each
other.&nbsp;
  <div><br>
  </div>
  <div>BTW, the IETF geo proposal was adopted in 2010, in the final
form given at&nbsp;
  <meta http-equiv="content-type" content="text/html; ">
  <a moz-do-not-send="true" href="http://tools.ietf.org/html/rfc5870">http://tools.ietf.org/html/rfc5870</a>&nbsp;.
One interesting point is&nbsp;
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
  <a moz-do-not-send="true"
 href="http://tools.ietf.org/html/rfc5870#section-3.4.3">http://tools.ietf.org/html/rfc5870#section-3.4.3</a>&nbsp;which
says&nbsp;</div>
  <div>&nbsp;&nbsp;"<span class="Apple-style-span" style="white-space: pre;"><font
 class="Apple-style-span" face="arial, helvetica, sans-serif">Note: The
number of digits of the values in &lt;coordinates&gt; MUST NOT be</font></span><span
 class="Apple-style-span"
 style="font-family: arial,helvetica,sans-serif; white-space: pre;">
interpreted as an indication to the level of uncertainty." The section
following is also interesting, albeit irrelevant for your procedure. It
implies that when uncertainty is omitted (and therefore unknown), then "</span>geo:41.53000000,-70.67000000"
&nbsp;and "geo:41.53,-70.67" &nbsp;identify &nbsp;the same geo resource.</div>
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
  <div><br>
  </div>
  <div><br>
  </div>
  <div>Bob Morris</div>
  <div><br>
  <div class="gmail_quote">On Wed, Feb 23, 2011 at 4:56 PM, Peter
DeVries <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:pete.devries@gmail.com">pete.devries@gmail.com</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br
 clear="all">
[...]<br>
    <div><br>
    </div>
    <div>5) I added in my proposed "area" so that it is easy to see
what species were observed near each other. Since there was no measure
of radius in these longitude and latitudes I made the radius 100 meters.</div>
    <div>&nbsp;&nbsp; &nbsp;Normally I would estimate the radius for a GPS reading to
be within 10 meters but some of these observations were made where the
GPS reading was taken and the readings were given only to two decimals.</div>
    <div><br>
    </div>
    <div>Area = long, lat; radius in meters following the ietf proposal
but with the precision of the long and lat standardized
example&nbsp;"geo:41.53000000,-70.67000000;u=100"</div>
    <div><br>
    </div>
    <div>[...]</div>
  </blockquote>
  </div>
-- <br>
Robert A. Morris<br>
Emeritus Professor&nbsp; of Computer Science<br>
UMASS-Boston<br>
100 Morrissey Blvd<br>
Boston, MA 02125-3390<br>
Associate, Harvard University Herbaria<br>
email: <a moz-do-not-send="true" href="mailto:morris.bob@gmail.com"
 target="_blank">morris.bob@gmail.com</a><br>
web: <a moz-do-not-send="true" href="http://efg.cs.umb.edu/"
 target="_blank">http://efg.cs.umb.edu/</a><br>
web: <a moz-do-not-send="true"
 href="http://etaxonomy.org/mw/FilteredPush" target="_blank">http://etaxonomy.org/mw/FilteredPush</a><br>
  <a moz-do-not-send="true" href="http://www.cs.umb.edu/%7Eram"
 target="_blank">http://www.cs.umb.edu/~ram</a><br>
phone (+1) 857 222 7992 (mobile)<br>
  <br>
  </div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
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
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>