<!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">
Well, I'm not really proposing to create anything as complicated as a
normative rendering of DwC in RDF. I just think it would be useful to
have a guide similar to <br>
<a class="moz-txt-link-freetext" href="http://rs.tdwg.org/dwc/terms/guides/xml/index.htm">http://rs.tdwg.org/dwc/terms/guides/xml/index.htm</a><br>
and <br>
<a class="moz-txt-link-freetext" href="http://rs.tdwg.org/dwc/terms/guides/text/index.htm">http://rs.tdwg.org/dwc/terms/guides/text/index.htm</a><br>
that would help people know how they could use DwC terms as properties
in RDF. People are going to do that whether there is a guide or not -
this would just make it easier. <br>
<br>
If people want to develop more sophisticated systems for doing semantic
reasoning that's facilitated by RDF, all power to them (it's just not
going to be me). I'm really trying to be focused on making it possible
to meet the minimal requirements for exposing metadata as outlined in
the Linked Data/GUID guidelines. That's a much lower bar than, say,
creating formats and applications that "understand" taxonomy. If we
can't do this (quick and dirty RDF for occurrences and the like)
relatively quickly and in a relatively simple way, then let's just
forget about having GUIDs that are actionable and just tell people that
we don't expect actionability. <br>
<br>
Steve<br>
<br>
Roger Hyam wrote:
<blockquote cite="mid:CAA736F1-1697-4309-A2A7-F21171AB44FC@mac.com"
type="cite">
<div><br>
</div>
<div>I am only just keeping up with this thread so excuse me if I
speak out of turn.</div>
<div><br>
</div>
<div>I wonder if we should have a normative rendering of DwC in RDF
at all.</div>
<div><br>
</div>
<div>There will probably be many many decisions to take in developing
such a model. The correct answer to each one of these decisions will
depend on the use-case for the model. If we don't have at least one
clear use-case for *consuming* the data then our decisions will be
either arbitrary or we will argue around and around in circles unable
to decide on the perfect answer. A use-case should involve answering a
real world question not a hypothetical one and it should be testable.</div>
<div><br>
</div>
<div>As an example I am of the growing opinion that taxonomic
classifications would be rendered perfectly adequately in SKOS - each
classification being a free standing thesaurus linked to other
thesauri/classifications using the standard SKOS terms. Any tool that
understood SKOS would then "understand" taxonomy. One could produce a
mapping from DwC checklists to SKOS to do this. It would be totally
inappropriate to convert DwC dataset of specimens into a SKOS thesaurus
as specimens could never be considered concepts.</div>
<div><br>
</div>
<div>I hesitate to formally propose the SKOS model (I thought about
presenting it at TDWG) because I haven't found a decent SKOS browser
even or an application that would demonstrate the utility of this
approach - though I have ideas...</div>
<div><font class="Apple-style-span" color="#2a2a2a" face="Arial"
size="3"><span class="Apple-style-span"
style="font-size: 13px; line-height: 20px;"><br>
</span></font></div>
<div><font class="Apple-style-span" color="#2a2a2a" face="Arial"
size="3"><span class="Apple-style-span"
style="font-size: 13px; line-height: 20px;">Anyhow just my tuppence
worth - before departing for a long weekend :)</span></font></div>
<div><font class="Apple-style-span" color="#2a2a2a" face="Arial"
size="3"><span class="Apple-style-span"
style="font-size: 13px; line-height: 20px;"><br>
</span></font></div>
<div><font class="Apple-style-span" color="#2a2a2a" face="Arial"
size="3"><span class="Apple-style-span"
style="font-size: 13px; line-height: 20px;">All the best,</span></font></div>
<div><font class="Apple-style-span" color="#2a2a2a" face="Arial"
size="3"><span class="Apple-style-span"
style="font-size: 13px; line-height: 20px;"><br>
</span></font></div>
<div><font class="Apple-style-span" color="#2a2a2a" face="Arial"
size="3"><span class="Apple-style-span"
style="font-size: 13px; line-height: 20px;">Roger</span></font></div>
<div><font class="Apple-style-span" color="#2a2a2a" face="Arial"
size="3"><span class="Apple-style-span"
style="font-size: 13px; line-height: 20px;"><br>
</span></font></div>
<br>
<div>
<div>On 7 Oct 2010, at 15:41, Steve Baskauf wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">I agree that it is best to
avoid a proliferation of terms and I agree
that it is best to keep Darwin Core technology independent to the
maximum extent possible. However, I think that the case of
facilitating HTTP URIs is a special one because of the requirements of
GUIDs/Persistent Identifiers. Both the TDWG and GBIF guidelines such
as they currently stand say that GUIDs must be resolvable, that in
their resolution they must return RDF, and that the RDF has to be in an
XML format. Like it or not, that is what we have. Given the amount of
time that it seems to have taken to settle on that much, I think it is
best
for us to decide to live with it, warts and all, rather than re-opening
the discussion and delaying the implementation of GUIDs for another
five years. <br>
<br>
Given that assumption, there needs to be within Darwin Core some way to
support this particular "technology" (Linked Data, RDF/XML) even if we
don't do "special" things to support other technologies such as LSID,
DOI, etc. The point is well taken that most of those other
technologies have mechanisms for turning their identifiers into URIs
and the
aforementioned guidelines lay out how owl:sameAs can be used within the
RDF to
associate the non-HTTP-resolvable forms with the URIs. Based on my
admittedly limited experience with trying to write RDF using Darwin
Core terms, I think that in most cases there already exists appropriate
terms for getting the job done. What may be lacking is concrete
examples and community consensus on what terms to use for what. I also
think that there are probably some "ID" terms where it isn't really
very important (from an RDF point of view) that there exist both a URI
form and a text string form. I'm thinking of something like
dwc:identificationID, which is mostly likely to be needed to allow a
machine to make a connection between some resource and its
identification. The machine isn't going to care if there is a
human-readable version. In contrast, something like dwc:collectionID
is likely to need both a URI version (e.g. proxied version of the BCI
LSID) for the machines and a string version (the name of the collection
as it would be displayed) for humans. I think that trying to make
example/template RDF for various types of resources will help make it
clear in which cases one version (URI), the other (string), or both are
actually necessary.<br>
<br>
I "volunteered" a couple weeks ago to have a go at writing an RDF guide
for Darwin Core. I am still willing to do this, although I'm still
getting caught up at work from being at the TDWG meeting. However,
next week we have fall break and I will make it a priority to come up
with a draft which can be the subject of discussion. As a part of this
process, I think it would be good to create one or more "boilerplate"
RDF files for the various kinds of resources that are likely to be
identified with GUIDs (e.g. Occurrences, Taxa, etc.). This can also be
a subject of discussion and I think it will help to clarify what will
meet the actual needs that we have discussed in this thread. I have a
pretty clear picture of what I think Occurrence RDF should look like.
I'm going to have to depend on Pete and others to deal with the
taxonomy part.<br>
<br>
Steve<br>
<br>
Markus Döring wrote:
<blockquote cite="mid:AA25D85F-2249-4292-AEA9-AF0F1E38B647@mac.com"
type="cite">
<pre wrap="">Steve, Pete,
Id like to draw your attention on a basic DarwinCore design pattern. Dwc has the goal of being technology independent by simply providing a list of abstract terms one can use in various arenas such as xml, rdf, xhtml, csv etc. And even within those there might be various ways of using them (e.g. we have a normalised and a simple flat xml schema), thats why we should have a guideline for each of them on how to use them. We are missing such a guideline for rdf currently, hence this debate.
Whether scientificName is a literal string or some complex object shouldnt matter - its defined to be a scientific name. Such a dwc rdf property could either hold a literal string or a url to some name rdf:resource (potentially with a rdfs:label).
With the introduction if many ID terms we have diluted that idea a little already in my mind. We could have as well used scientificName in xml to hold some identifier for that name. All URNs tell you what they are by their urn prefix (not necessarily how to resolve them), so you can easily detect a UUID, LSID, http(s) url, ftp, doi and apply the conventional resolution mechanism. The hardest problem are the local ids and other plain identifers. For those mainly we created the ID terms (at least in my mind). I am feeling rather uncomfortable discussing the introduction of specific dwc terms for each type of id. Maybe we should remove all id terms in dwc and use the specific guidelines to specify these? At least if you really think having all those id terms for rdf is a good thing I would feel much more comfortable going down this route instead of diluting dwc by adding more and more rather redundant terms. The abstract concept is key to a dwc term, not the actual data type fo
rced by the technology you are using it with. Would you want several date terms for various date formats? In fact we do that already to some degree (eventDate, eventTime, year, month, day, verbatimEventDate) and I always felt this is not a good idea. There are also a number of verbatimXXX terms in dwc which also contradict this pattern.
Talking about new dwc terms - in the examples given properties like "hasScientificName" is not strictly the correct dwc term, which is simply scientificName. I think it would be fine to have the convention in the rdf guidlines to use hasDwcTerm instead of dwcTerm, this is exactly what an rdf guideline is for. On the flip side I am sure this only applies to some terms, recordBy for example is likely to remain as it is. Its unclear to me what is best to do really. Always stick to the original dwc terms? Refine them through some rdfs or owl schema and define the relation to the original term? Should we still use the same namespace in this case?
As an rdf beginner even after a few years exposed I wonder if we cant simply stick to the non ID terms and use them either as literals or with a uri pointer. As in the rdf world a resolvable http is really required for resource relations to work, why not simply mandate this in the guidelines? If you only happen to have non resolvable uris like lsid or dois the guidelines should be asking you to use proxied versions, knowing it will break rdf frameworks and lod conventions otherwise. On the resolving side one could always include such urns with owl:sameAs (or sth alike) I believe. But how many non resolvable ids with no matching http counterpart are really out there yet?
- Markus
On Oct 6, 2010, at 9:02, Peter DeVries wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Steve,
You are probably right that it might be best to use rdfs:Label, but I am thinking we might be able to get the same
result my defining the string variants as subproperties of rdfs:Label.
This would make them an rdfs:Label but a special kind of rdfs:Label.
This is one of those things that I would test with Sindice and URIburner to see if they interpret these correctly.
This would require a live vocabulary that Sindice could look at to determine that hasScientificName is to be
treated as a rdfs:Label.
- Pete
On Mon, Oct 4, 2010 at 10:41 AM, Steve Baskauf <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:steve.baskauf@vanderbilt.edu"><steve.baskauf@vanderbilt.edu></a> wrote:
Although this specific example deals with taxonomic name identifiers, it is related to a previous discussion on this list about how we should use the dwc:xxxxxID terms and other terms (such as recordedBy and identifiedBy) that could have either a string (literal) or URI form. Although I don't really want to see an unnecessary proliferation of Darwin Core terms, I think that in the interest of clarity (particularly where RDF is involved) there either should be multiple terms that make it clear what form of identifier is expected, or else there should be an understanding that in RDF the default for such a term is a URI which would then have an rdfs:Label property which was the string form. I think the former would be preferable to the latter.
I came to this opinion when trying to write RDF describing an herbarium specimen. The collector should be the dwc:recordedBy property of the specimen. Optimally, there would be a database in which known collectors were assigned URIs so that "Glen N. Montz", "Glen Montz", "G. N. Montz", etc. would all be different labels for the same resource. However, realistically, I'm not going to drop what I'm doing to set up such a database (even if I were capable of doing it, which I'm not). So I ended up just writing it as <dwc:recordedBy>Glen N. Montz</dwc:recordedBy> even though I knew it wasn't probably the best thing. In a large Occurrence database that was compiled from the RDF created by a lot of people, there might end up being a mixture of strings and URIs for dwc:recordedBy properties of the specimens. It seems to me like it would be better to have properties like dwc:recordedBy for strings and dwc:recordedByURI for a corresponding URI (and I suppose dwc:reco
rdedByLSID if anyone wants to use it). Of course, this would require a number of term additions to DwC and clarification in the DwC documentation that the generic version was intended for strings.
With respect to the example
<dwc:hasScientificNameLSID rdf:resource="urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010"/>
I think you are right that (with the possible exception of rdfs:seeAlso) there is an expectation that an rdf:resource attribute will be a resolvable URI that produces RDF. So
<dwc:hasScientificNameLSID>urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010</dwc:hasScientificNameLSID>
is probably better.
Steve
Peter DeVries wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I have been thinking about the following pattern. In part after looking at the GBIF vocabulary.
I am not sure if it is even a good idea but might be worth some discussion.
For those fields that have both a string and "ID" form maybe the following pattern might be useful
hasScientificName = string form
hasScientificNameURI = Resolvable LOD compliant identifier
hasScientificNameLSID = LSID identifier which could be resolvable once you add the <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="http:proxy">"http:proxy"</a> etc.
This allows all three forms to be included if desired, it also provides a hint as to how the field should be interpreted or resolved.
One group could also provide a mapping service so that each record does not need to include all three forms, but would allow systems
to find the matching LSID for a given URI or vs. versa.
My concern was that it would be difficult to infer how a scientificNameID should be interpreted by other systems.
Is this an LSD, is it a URI, is it a UUID etc. ?
This impacts the structure of the RDF.
* Note that the actual identifiers might not be correct, the example below is more about the form of the RDF
* For instance, I don't think it is probably correct to see the COL LSID as just a namestring
* Also in this example the GNI name does not exactly match the string name
<dwc:hasScientificName>Puma concolor (Linnaeus 1771)</dwc:hasScientificName>
<dwc:hasScientificNameURI rdf:resource=<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="http://gni.globalnames.org/name_strings/6c3dc35f-d901-5cc5-b9c8-ad241069b9f8">"http://gni.globalnames.org/name_strings/6c3dc35f-d901-5cc5-b9c8-ad241069b9f8"</a>/>
<dwc:hasScientificNameLSID rdf:resource="urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010"/>
Some system may choke on the LSID form assuming that it uses a standard resolution mechanism
So it might be best to use this form
<dwc:hasScientificNameLSID>urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010</dwc:hasScientificNameLSID>
- 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
------------------------------------------------------------
</pre>
</blockquote>
<pre wrap="">--
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 moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bioimages.vanderbilt.edu/">http://bioimages.vanderbilt.edu</a>
--
----------------------------------------------------------------
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
------------------------------------------------------------
_______________________________________________
tdwg-content mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a>
</pre>
</blockquote>
<pre wrap=""><!---->
.
</pre>
</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 moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bioimages.vanderbilt.edu/">http://bioimages.vanderbilt.edu</a>
</pre>
</div>
_______________________________________________<br>
tdwg-content mailing list<br>
<a moz-do-not-send="true" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
</blockquote>
</div>
<br>
</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>