[tdwg-content] Expressing some relationships in DwC?

Steve Baskauf steve.baskauf at vanderbilt.edu
Wed Oct 26 20:44:54 CEST 2011



Richard Pyle wrote:
>   
>> 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).
>>     
>
> Agreed.  But resourceRelationship is already in there, and as we both seem
> to have discovered, nobody appears to be using it.  So...I think we at least
> need to clarify how it's supposed to be used in a DwC context; or we should
> let it die a slow, quiet death of non-use.  I guess I'm OK either way; but
> given that it exists, and given that we seem to have people who don't want
> to go all the way to RDF triples for all data exchange purposes (yet),
> perhaps we should examine how best to use this already-existing DwC class,
> modify it as needed to make it actually useful to those who want to use it,
> and let it die after we're all pumping our data out via RDF that works
> against a solid, stable ontology.
>   
If one were able to establish an understanding of how to populate the 
seven or so "resource relationship" database columns that you want, 
converting that information to RDF in any or all of its forms would be 
an academic exercise.  Somebody who knew what they were doing could 
probably write a program to do the conversion in less than an hour.  
That's not really the impediment. 
>   
>
>   
>> 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.
>
> Well...there's also dcterms:type, which is already part of DwC.  The
> problem, though, that this would apply to resourceRelationshipID (i.e., the
> "type" of relationship itself); not to the resourceID.  Technically, you'd
> need to resolve resourceID to retrieve dcterms:type for the subject item.  I
> don't know how rdf:type is intended to work in this context.
>   
There is probably somebody who is more qualified than me to address 
this, but I would say that because it is described as a part of RDF, 
rdf:type implicitly identifies the class of which the subject of a set 
of relationships is an instance.  That is exactly what is wanted here.  
I think that in contrast dcterms:type means whatever you want it to mean 
as long as it fits the description of  "The nature or genre of the 
resource." The best practice is to follow a controlled vocabulary, but 
otherwise I think people can use it to describe whatever they want.  I 
may be in need of correction on this statement...
>   
>
> OK, I agree.  It could be that resourceRelationship is a "gateway drug" to
> get people into thinking in terms of triples.
>   
Now that brings up some interesting images in my brain!  :-)

Steve
> Rich
>
>
>
> 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.
>
> .
>
>   

-- 
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/cb40c1fb/attachment.html 


More information about the tdwg-content mailing list