<!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">
I'm interested to see that the subject of the dwc:ResourceRelationship
class has come up again. I have lost track of the number of times I've
asked this question (I think it's somewhere around 4 times now) on the
list without an answer: can anyone show me a functioning example where
somebody is actually using the ResourceRelationship terms in any form?
I have previously concluded from lack of response that there isn't
actually anybody who has used them, but I would be happy to for someone
to show that I'm wrong.<br>
<br>
If I am understanding the use of the ResourceRelationship terms
correctly (which I'm not at all sure about), dwc:resourceID represents
an identifier for the subject of the relationship,
dwc:relatedResourceID represents an identifier for the object of the
relationship, and resourceRelationshipID represents an identifier for
an _instance_ of a relationship which is further elaborated in the
record for that instance by providing a string value for
relationshipOfResource (using a controlled vocabulary) along with
additional information about the relationships (according to whom,
date, remarks). What I think I'm hearing in this thread is a desire to
start using these terms more widely and to improve interoperability by
standardizing the vocabulary used for relationshipOfResource. I also
think I'm hearing that it would be a good idea for values the xxID
terms to be GUIDs. <br>
<br>
So what I'm wondering is why doing that would be better than just
creating URI-identified object properties (a.k.a. predicates) that
describe the relationship between the object and subject? Using the
ResourceRelationship terms just makes "understanding" the relationship
harder by requiring that the data consumer "look up" the value of the
relationshipOfResource string for every instance of a relationship and
then figure out if it's the same kind of relationship as one that the
consumer already knows or cares about. As I see it, the bottom line is
that if we agree that it would be a best-practice for the xxID values
to be GUIDs (which would either be URIs or could be URIs that are
proxied UUIDs for UUID believers) and that the relationships should be
standardized, then the resource relationships boil down to RDF
triples. There's a URI for the subject, a URI for the object, and
there could be a URI for the relationshipOfResource which would have an
rdfs:label property that was the controlled value for the string that
describes the relationship. The only difference that I see is that the
RDF triples could be more efficient to handle.<br>
<br>
Don't like RDF or are scared of it? Fine, make yourself an Excel
spreadsheet with three columns headed "subject", "predicate", and
"object" (or use your favorite database method). Put the appropriate
URI in each column. Viola! Resource relationships. <br>
<br>
The one thing about implementing the ResourceRelationship class
vocabulary that I think may be an improvement is use of the generic
terms for "by whom", "date", and "remarks". At the present moment, we
are in the process of expanding DwC by adding class-specific terms to
do these things in nearly every class. We have recordedBy,
georeferencedBy, identifiedBy, occurrenceRemarks, locationRemarks,
eventDate, georeferencedDate, etc. rather than just using
relationshipAccordingTo, relationshipEstablishedDate, and
relationshipRemarks which could do the same thing generically in any
class. Add columns to the above-described Excel spreadsheet for
relationshipAccordingTo, relationshipEstablishedDate, and
relationshipRemarks if you want to track those things.<br>
<br>
I think I understand why the ResourceRelationship class was created.
It seems like a way to move forward under the worse-case scenario where
GUIDs never get off the ground, where no one ever agrees what the core
biodiversity classes are, and where no one ever establishes object
properties that connect those classes. But if no one ever has the guts
to try to lay out the core classes and object properties that connect
them, then what good are a million unstandardized ResourceRelationship
instances that can't be unambiguously IDed? Nobody will ever be able
to figure out anything useful from them and Rod Page's prophecy of doom
will come true. <br>
<br>
Somebody please show me where I'm wrong here...<br>
Steve<br>
<br>
Richard Pyle wrote:
<blockquote cite="mid:003c01cc9369$93fc33d0$bbf49b70$@bishopmuseum.org"
type="cite">
<pre wrap="">Hmmm.... watch out for that tricky word "valid". It means different things
to botanists & zoologists. The term "accepted" is generally seen as a more
code-neutral term to mean "valid" (sensu zoology) or "correct"/"accepted"
(sensu botany). But if you mean "valid" in the botanical sense (="validly
published", or "available" sensu zoology). I'm not entirely sure which
sense of "valid" is meant in this context.
More fundamentally, however, I'd like to report that a number of folks at
TDWG seemed to have converged on the same idea that, perhaps, we should be
using resourceRelationship more frequently (perhaps a *LOT* more
frequently). A lot of these terms that effectively represent the functional
equivalent to "foreign keys" might be better packaged in the more open-ended
structure of resourceRelationship. In fact, at one of the sessions at TDWG
(I believe it was at the AudubonCore break-out session), we discussed the
idea of DwCA "2.0", which would essentially define n-number of "Cores", and
then package the relationships among them via a set of resourceRelationship
records. This idea emerged from a discussion about how people have been
trying to "force" many-to-many sorts of data into the one-to-many DwCA
format. The beauty of using a more generic resourceRelationship set for
this function is that it allows one-to-one, one-to-many, and many-to-many
relationships all in one structure. It may seem klunky now, but if we used
it as a general method to describe all relationships between instances of
DwC "classes", it would become pretty straightforward, I think.
Something to think about, anyway...
Aloha,
Rich
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:tdwg-content-bounces@lists.tdwg.org">tdwg-content-bounces@lists.tdwg.org</a> [<a class="moz-txt-link-freetext" href="mailto:tdwg-content">mailto:tdwg-content</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces@lists.tdwg.org">bounces@lists.tdwg.org</a>] On Behalf Of <a class="moz-txt-link-abbreviated" href="mailto:Tony.Rees@csiro.au">Tony.Rees@csiro.au</a>
Sent: Tuesday, October 25, 2011 4:34 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:mdoering@gbif.org">mdoering@gbif.org</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Markus,
You wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I begin to wonder if a new term dwc:validNameUsageID would solve this
issue gracefully and remove the need for a relationship extension.
</pre>
</blockquote>
<pre wrap="">Yes, I believe this would cover both the cases I need, I think, when
accompanied by nomenclatural status = misspelling / nomenclatural status =
nomen nudum... - comments, anyone?
Cheers - Tony
________________________________________
From: "Markus Döring (GBIF)" [<a class="moz-txt-link-abbreviated" href="mailto:mdoering@gbif.org">mdoering@gbif.org</a>]
Sent: Wednesday, 26 October 2011 1:43 AM
To: Rees, Tony (CMAR, Hobart)
Cc: <a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
Subject: Re: [tdwg-content] Expressing some relationships in DwC?
Hi Tony,
thanks for these practical questions. See inline for answers.
Markus
</pre>
<blockquote type="cite">
<pre wrap="">I have a few nomenclatural relationships between name that I would like
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->to
</pre>
<blockquote type="cite">
<pre wrap="">express using DwC, and would like to know the preferred way to do this if
any. The relationships are as follows:
</pre>
<blockquote type="cite">
<pre wrap="">(1) Point a nomen novum to the basionym it replaces. From reading there
</pre>
</blockquote>
<pre wrap="">was formerly a concept basionym/basionymID, apparently this is now
replaced with originalNameUsage/originalNameUsageID. So one quesiton is,
is this sufficient to infer this is a basionym, when accompanied by
noneclaturalStatus = 'nomen novum'?
yes, that is exactly right. As far as I understand the term basionym is
</pre>
</blockquote>
<pre wrap=""><!---->more of
</pre>
<blockquote type="cite">
<pre wrap="">a botanical term and was not used as the final dwc term therefore.
</pre>
<blockquote type="cite">
<pre wrap="">(2) Point an orthographic variant to the name which it is a variant of
</pre>
</blockquote>
<pre wrap="">(whether or not the latter is now the accepted name). In other words, if
name A is a variant of name B which is now a synonym of name C, I capture
the A=>C relationship with a synonym assertion, but I want a way to
capteure the A=>B relationship too.
This is only possible with an extension I am afraid. For example the
</pre>
</blockquote>
<pre wrap=""><!---->generic
</pre>
<blockquote type="cite">
<pre wrap="">dwc relationship one:
<a class="moz-txt-link-freetext" href="http://rs.gbif.org/extension/dwc/resource_relation.xml">http://rs.gbif.org/extension/dwc/resource_relation.xml</a>
</pre>
<blockquote type="cite">
<pre wrap="">(3) Point a nomen nudum to a validly published instance that comes later
</pre>
</blockquote>
<pre wrap="">(or do the same in reverse, i.e. this name was preceded by xxx as a nomen
nudum). Again, this should be independent of whether the validly published
name is an accepted name or now a synonym of something else.
same problem as above.
I begin to wonder if a new term dwc:validNameUsageID would solve this
issue gracefully and remove the need for a relationship extension.
</pre>
<blockquote type="cite">
<pre wrap="">Advice appreciated,
Regards - Tony Rees
_______________________________________________
tdwg-content mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
<a 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="">_______________________________________________
tdwg-content mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
<a 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=""><!---->
This message is only intended for the addressee named above. Its contents may be privileged or otherwise protected. Any unauthorized use, disclosure or copying of this message or its contents is prohibited. If you have received this message by mistake, please notify us immediately by reply mail or by collect telephone call. Any personal opinions expressed in this message do not necessarily represent the views of the Bishop Museum.
_______________________________________________
tdwg-content mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
<a 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>
<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>