Hi Steve, <div><br></div><div>I think that in many cases terms that are currently literals should be replaced with URI&#39;s. The note below explains a major reason, but also consider all the potential misspellings etc. The choice of a literal requires that all the potentially consuming applications will know which of the various ways of saying &quot;University of Louisiana at Monroe Herbarium&quot; mean the same thing and which mean different things.</div>
<div><br></div><div>Also, I am assuming that the URI below maps to the same thing listed in the label and not a collection within that Herbarium?</div><div><br></div><div>I would have GBIF/TDWG have a controlled list of Institutions that are represented with URI&#39;s. The label would occur in that vocabulary document and not repeated in each occurrence record. Using this approach the label would still be seen in a LOD browser but it would not be duplicated millions of times.</div>
<div><br></div><div>The other issue is that URI&#39;s are stored much more efficiently than literals. See below:</div><div><br><div>--</div><div><div>The section below provides some insight as to why I think it is good to replace literals with URI&#39;s.</div>
<div><br></div><div>It is from the Virtuoso FAQ page, but I also noticed a substantial improvement in performance in the Sesame triple store when I changed some of my literal fields into URI&#39;s <a href="http://docs.openlinksw.com/virtuoso/virtuosofaq.html#virtuosofaq1">http://docs.openlinksw.com/virtuoso/virtuosofaq.html#virtuosofaq1</a></div>
<div><br></div><div>There are many places with in the current DarwinCore that a standard vocabulary is used. However, these are represented as literals in the RDF.</div><div><br></div><div>It might be useful to think of making URI versions of some of these such as datum, taxon level, lifestage etc. </div>
<div><br></div><div>Another option would be to having these represented as URI&#39;s in some GBIF processed version of the originally submitted data.</div><div><br></div><div>Respectfully,</div><div><br></div><div>- Pete</div>
<div><br></div><div>-------------------------------------------------------------------------</div><div><br></div><div>1.4.1. What is the storage cost per triple?</div><div><br></div><div>This depends on the index scheme. If indexed 2 ways, assuming that the graph will always be stated in queries, this is 31 bytes.</div>
<div><br></div><div>With 4 indices, supporting queries where the graph can be left unspecified (i.e., triples from any graph will be considered in query evaluation), this is 39 bytes. The numbers are measured with the LUBM validation data set of 121K triples, with no full-text index on literals.</div>
<div><br></div><div>With 4 indices and a full text index on all literals, the Billion Triples Challenge data set, 1115M triples, is about 120 GB of database pages. The database file size is larger due to space in reserve and other factors. 120 GB is the number to use when assessing RAM-to-disk ratio, i.e., how much RAM the system ought to have in order to provide good response. This data set is a heterogeneous collection including social network data, conversations harvested from the Web, DBpedia, Freebase, etc., with relatively numerous and long text literals.</div>
<div><br></div><div>-----</div><div><br></div><br><div class="gmail_quote">On Wed, Sep 1, 2010 at 9:40 AM, Steve Baskauf <span dir="ltr">&lt;<a href="mailto:steve.baskauf@vanderbilt.edu">steve.baskauf@vanderbilt.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  

<div bgcolor="#ffffff" text="#000000">
Pete,<br>
Thanks for the response about term resolution.  I&#39;m over my head on
that topic, so I&#39;ll let others respond to that part.<br>
<br>
With regards to a vocabulary that uses URIs rather than literals, I&#39;m
in favor of that.  At one point in a previous discussion, I think it
was suggested that separate terms be created for literal and URI
versions of terms like dwc:recordedBy.  At first I liked that idea, but
after thinking about it and playing with it for a while, I think that
the suggestion of just applying a label property to the resource
identified by the URI is simpler and wouldn&#39;t require a proliferation
of new terms.  For example:<br>
<br>
            &lt;dcterms:creator&gt;<br>
                &lt;rdf:Description
rdf:about=<a href="http://biocol.org/urn:lsid:biocol.org:col:15539" target="_blank">&quot;http://biocol.org/urn:lsid:biocol.org:col:15539&quot;</a>&gt;<br>
                    &lt;rdfs:label&gt;University of Louisiana at Monroe
Herbarium&lt;/rdfs:label&gt;<br>
                &lt;/rdf:Description&gt;<br>
            &lt;/dcterms:creator&gt;<br>
<br>
could be used if both a literal and URI were available and <br>
<br>
            &lt;dcterms:creator&gt;University of Louisiana at Monroe
Herbarium&lt;/dcterms:creator&gt;<br>
<br>
could be used if a URI were not available.  It seems like it should be
relatively easy for a linked data client to have contingencies to deal
with this.  Even with technology that&#39;s semantically &quot;dumb&quot; like XSLT,
it&#39;s pretty easy to code for the two possibilities.<br>
<br>
But I suppose it would be good to have some kind of consensus that this
is the preferred approach.  Otherwise, separate terms might be better. 
There aren&#39;t a whole lot of dwc terms to which this situation would
apply.<br>
<br>
Steve<br>
<br>
Peter DeVries wrote:
<blockquote type="cite">
  <div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><br>
  <div><br>
  </div>
  <div>By &quot;efficient&quot;, I mean a vocabulary that uses standard
resolvable URI&#39;s instead of literals for standard terms etc. This
solution would also avoid the problem that Markus just mentioned. </div>
  <div><br>
  </div>
  <div>I am also wondering if the &quot;individual&quot; definition should be
changed to mean one individual organism rather than a potential
collection of individuals. Individuals from the same colony could be
represented using a separate related vocabulary. Allowing multiple</div>
  <div>individuals will cause problems for consuming applications. For
instance, is the queen a separate individual or not? How do you
differentiate between a photo of the queen vs. a photo of one of the
workers. There are also potential problems even if the individuals</div>
  <div>are all workers.</div>
  <div><br>
  </div>
  <div>I have been thinking that for some attributes like character
states, it might be best to have a family level ontology. In this
example, you might have a &quot;formicidae_ontology&quot;, that could be used to
deal with individuals from the same colony as well as ant specific
character states.</div>
  <div><font face="monospace"><span style="white-space:pre-wrap"><br>
  </span></font></div>
  <div><font face="monospace"><span style="white-space:pre-wrap">
  <div><br>
xmlns:ant=&quot;<a href="http://rs.gbif.org/family_ontology/ant.owl#" target="_blank">http://rs.gbif.org/family_ontology/ant.owl#</a>&quot;</div>
  <div><br>
  </div>
  <div>&lt;rdf:Description rdf:about=&quot;<a href="http://example.org/individual/123412" target="_blank">http://example.org/individual/123412</a>&quot;&gt;</div>
  <br>
  <div> &lt;ant:colonyMateOf rdf:resource=&quot;<a href="http://example.org/individual/123414" target="_blank">http://example.org/individual/123414</a>&quot;/&gt;</div>
  <div>&lt;/rdf:Description&gt;</div>
  <div><br>
  </div>
  </span></font></div>
  <div>This could be defined as a subproperty of dc:relation or
something similar in the gbif/tdwg vocabulary.</div>
  <div><br>
  </div>
  <div>- Pete</div>
  </span><br>
  <div class="gmail_quote">On Tue, Aug 24, 2010 at 6:43 PM, Steve
Baskauf <span dir="ltr">&lt;<a href="mailto:steve.baskauf@vanderbilt.edu" target="_blank">steve.baskauf@vanderbilt.edu</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">I
was doing some GUID testing using a Linked Data client and I noticed<br>
that some Darwin Core terms did not seem to resolve to anything.  I ran<br>
a test using<br>
    <a href="http://demo.openlinksw.com/rdfbrowser2/" target="_blank">http://demo.openlinksw.com/rdfbrowser2/</a><br>
    <a href="http://api.talis.com/stores/iand-dev1/items/dipper.html" target="_blank">http://api.talis.com/stores/iand-dev1/items/dipper.html</a><br>
    <a href="http://www5.wiwiss.fu-berlin.de/marbles/" target="_blank">http://www5.wiwiss.fu-berlin.de/marbles/</a><br>
and<br>
    <a href="http://dataviewer.zitgist.com/" target="_blank">http://dataviewer.zitgist.com/</a><br>
I first I looked up<br>
    <a href="http://purl.org/dc/terms/creator" target="_blank">http://purl.org/dc/terms/creator</a><br>
and all four clients reported the properties of the term.  Then I tried<br>
    <a href="http://rs.tdwg.org/dwc/terms/basisOfRecord" target="_blank">http://rs.tdwg.org/dwc/terms/basisOfRecord</a><br>
and nothing happened with any of them.  I ran a Vapour<br>
    <a href="http://validator.linkeddata.org/vapour" target="_blank">http://validator.linkeddata.org/vapour</a><br>
validation on the basisOfRecord URI and got the following message:<br>
    <br>
Vapour was unable to complete the request due to the following
exception:<br>
    <br>
ForbiddenAddress: forbidden request from 98.87.45.8 to <a href="http://rs.tdwg.org/dwc/terms/basisOfRecord" target="_blank">http://rs.tdwg.org/dwc/terms/basisOfRecord</a>
(resolves to IP 192.38.28.106), internal IP addresses are forbidden<br>
    <br>
I have no idea what that means, but all of this seems to mean that<br>
Darwin Core is currently &quot;broken&quot; from a Linked Data point of view.<br>
    <br>
Steve<br>
    <br>
--<br>
Steven J. Baskauf, Ph.D., Senior Lecturer<br>
Vanderbilt University Dept. of Biological Sciences<br>
    <br>
postal mail address:<br>
VU Station B 351634<br>
Nashville, TN  37235-1634,  U.S.A.<br>
    <br>
delivery address:<br>
2125 Stevenson Center<br>
1161 21st Ave., S.<br>
Nashville, TN 37235<br>
    <br>
office: 2128 Stevenson Center<br>
phone: (615) 343-4582,  fax: (615) 343-6707<br>
    <a href="http://bioimages.vanderbilt.edu" target="_blank">http://bioimages.vanderbilt.edu</a><br>
    <br>
_______________________________________________<br>
tdwg-tag mailing list<br>
    <a href="mailto:tdwg-tag@lists.tdwg.org" target="_blank">tdwg-tag@lists.tdwg.org</a><br>
    <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-tag" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-tag</a><br>
  </blockquote>
  </div>
  <br>
  <br clear="all">
  <br>
-- <br>
----------------------------------------------------------------<br>
Pete DeVries<br>
Department of Entomology<br>
University of Wisconsin - Madison<br>
445 Russell Laboratories<br>
1630 Linden Drive<br>
Madison, WI 53706<br>
  <a href="http://www.taxonconcept.org/" target="_blank">TaxonConcept Knowledge Base</a> / <a href="http://lod.geospecies.org/" target="_blank">GeoSpecies Knowledge Base</a><br>
  <a href="http://about.geospecies.org/" target="_blank">About the GeoSpecies Knowledge Base</a><br>
------------------------------------------------------------<br>
  </div>
</blockquote>
<br>
<pre 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 href="http://bioimages.vanderbilt.edu" target="_blank">http://bioimages.vanderbilt.edu</a>
</pre>
</div>

</blockquote></div><br><br clear="all"><br>-- <br>----------------------------------------------------------------<br>Pete DeVries<br>Department of Entomology<br>University of Wisconsin - Madison<br>445 Russell Laboratories<br>
1630 Linden Drive<br>Madison, WI 53706<br><a href="http://www.taxonconcept.org/" target="_blank">TaxonConcept Knowledge Base</a> / <a href="http://lod.geospecies.org/" target="_blank">GeoSpecies Knowledge Base</a><br><a href="http://about.geospecies.org/" target="_blank">About the GeoSpecies Knowledge Base</a><br>
------------------------------------------------------------<br>
</div></div>