<!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">
Richard Pyle wrote:<br>
<blockquote cite="mid:000f01cc9402$64e73060$2eb59120$@bishopmuseum.org"
type="cite">
<pre wrap="">
Hmmm... not sure I follow. My understanding is that resourceRelationship is
just a DwC wrapper to exchange what effectively amounts to triples, but with
some additional properties tied to each triple. In other words, a
generalized way of packaging any kind of relationship (1:1, 1:M, M:M) in a
format that is more in keeping with the way DwC works than RDF is. Perhaps
we should just focus on RDF/triples and not bother with a DwC package for
these kinds of relationships.
</pre>
</blockquote>
Well, I guess one could make the case that people who are not
interested in RDF might want a DwC-only way to express this. I guess
my point was that we seem to be talking about trying to invent a method
to accomplish something where there already is a well-established way
to do it. DwC at the present has a very "flat" database orientation
and I think the resource-relationship terms were introduced to allow
for a "flat" way to describe resources that aren't really flat (i.e.
1:M or M:M). <br>
<blockquote cite="mid:000f01cc9402$64e73060$2eb59120$@bishopmuseum.org"
type="cite">
<pre wrap="">
In any case, I don't see why relationshipOfResource cannot be populated with
a URI-identified predicate. Or, perhaps introduce a
relationshipOfResourceID term.
</pre>
</blockquote>
It's based on the term definition and examples at
<a class="moz-txt-link-freetext" href="http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource">http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource</a> which
recommend a controlled vocabulary and give strings as the only
examples. I think that in keeping with other precedents in DwC your
suggestion of "relationshipOfResourceID" might be better. <br>
<blockquote cite="mid:000f01cc9402$64e73060$2eb59120$@bishopmuseum.org"
type="cite">
<pre wrap="">
A suggestion was made by John Deck within BiSciCol to propose two new terms
for this class: resourceType and relatedResourceType, which would be
populated by the name of the DwC class from which the respective two
identifiers are drawn. This would include the kinds of things being related
without needing to resolve the two identifiers to determine that (e.g., via
dcterms:type from each record). Whether or not BiSciCol utilizes this DwC
class, I think it's still worth exploring and putting some use cases out
there to test its efficacy.
</pre>
</blockquote>
Well, in terms of the type for the subject, I don't think there is any
reason to create a new term for that. There is already rdf:type to do
exactly that. Whether it would matter if DwC imports that term or not,
I don't know. It is certainly already "well known".
relatedResourceType could be a shortcut to accomplish what you want for
the object. We are still left with the problem that there is no
consensus about what are the core "types" (which I consider to be
equivalent to the question of what are the core classes) in our
community. I've argued for adopting the DwC classes where they will do
the job, but I haven't heard too many people express support for that
and there are necessary classes that don't exist (yet) within DwC
(e.g. a class for agents). Also, there are classes in the TDWG
ontology that may or may not overlap with DwC classes (most notably
dwc:Taxon). Do we use therm? So in order for this to be of much
value, it seems to me that there is a need to hash out the core
classes/types. I was hoping the RDF group would take that up, but it's
not clear to me that there is support for doing that at this stage (was
it discussed at the meeting?). <br>
<blockquote cite="mid:000f01cc9402$64e73060$2eb59120$@bishopmuseum.org"
type="cite"><br>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">and that the relationships should be standardized, then the resource
relationships boil down to RDF triples.
</pre>
</blockquote>
<pre wrap=""><!---->
Effectively, yes. But as I mentioned above, there may be value in defining
a DwC mechanism (indeed, it's already defined, just not really used -- so I
should have said "refining" instead of "defining") that allows packaging of
these "triples" with associated metadata (relationshipAccordingTo,
relationshipEstablishedDate, relationshipRemarks, and possibly resourceType
and relatedResourceType) in a package that's easier for many providers to
generate and digest than full-blown serialized RDF. Perhaps I'm way off
base here, but my discussions at TDWG gave me the sense that I'm not the
only one who sees this as a desirable mechanism for data exchange that has
its own space of utility separate from full RDF-serialized content. My
sense (and again, I may be way off base) is that the RDF becomes really
valuable when it is broadly implemented, and is working off a reasonably
functional and well-defined ontology. The day when those are reality will
certainly come (I hope!), but in the mean time, we still need an exchange
mechanism for certain content that is more complex than what can be met with
DwCA.
</pre>
</blockquote>
I agree. I don't see any reason why the same relationships that one
can express in RDF triples couldn't be expressed in a database table.
But some of the issues that must be addressed to make that work are (in
my mind) the same ones that need to be addressed to make RDF work as a
metadata transfer mechanism. They could probably both be worked out at
the same time to some extent.<br>
<blockquote cite="mid:000f01cc9402$64e73060$2eb59120$@bishopmuseum.org"
type="cite">
<blockquote type="cite">
<pre wrap="">The only difference that I see is
that the RDF triples could be more efficient to handle.
</pre>
</blockquote>
<pre wrap=""><!---->
...or more difficult to handle, depending on who you are, what your area of
technical expertise is, and what you want to use the standard for (e.g.,
content exchange vs. reasoning).
</pre>
</blockquote>
Well, I actually wasn't so much concerned with the mechanics of
actually handling the RDF as the fact that it makes more sense to me to
have a generic URI to describe a particular kind of resource
relationship than to have to parse out and interpret a string for every
relationship that is to be described. One of the points of RDF is that
it doesn't have a single representation (e.g. it doesn't have to be
represented as XML). But the subject, predicate, object relationship
is basic and that's pretty much what we are talking about here.<br>
<br>
Steve<br>
<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>