[tdwg-content] Expressing some relationships in DwC?

[Steve Baskauf]

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 
http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource 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. 
> 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
> DwCA.
>   
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.

Steve

-- 
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
http://bioimages.vanderbilt.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20111026/6888cee6/attachment.html