[tdwg-content] Expressing some relationships in DwC?
steve.baskauf at vanderbilt.edu
Wed Oct 26 19:56:50 CEST 2011
Richard Pyle wrote:
> 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.
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).
> In any case, I don't see why relationshipOfResource cannot be populated with
> a URI-identified predicate. Or, perhaps introduce a
> relationshipOfResourceID term.
It's based on the term definition and examples at
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.
> 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.
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?).
>> and that the relationships should be standardized, then the resource
>> relationships boil down to RDF triples.
> 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
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.
>> The only difference that I see is
>> that the RDF triples could be more efficient to handle.
> ...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).
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.
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.
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235
office: 2128 Stevenson Center
phone: (615) 343-4582, fax: (615) 343-6707
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tdwg-content