Where we are on the RDF Guide revisions

[Steve Baskauf]

1. Towards the end of last week, I got some really good feedback from Bob Morris and Paul Morris.  It was primarily about section 3.8.  Section 3.8 was the place where I threw all of the terms we couldn't figure out how to deal with.  It's title was confusing and implied that the terms in that section were not "allowed" to have dwciri: analogues.  But in reality, it was that we couldn't figure out how a dwciri: analogue would be used in a sensible way.  Paul provided me with a number of wording suggestions and an example of a dwc:MeasurementOrFact instance which I incorporated into a new section 2.9 .  The entire set of changes that I made are detailed in items 30-35 in the DwC RDF Guide revisions 2014 document that I shared previously:
https://docs.google.com/document/d/153h1_kyfMllKGgfehVLB7ubzRDDaWtnaGHDDwJ6nkwE/edit?usp=sharing

2. The bottom line is that I have cleared out much of Section 3.8.  This reduces the number of problematic terms to about 3 (dwc:relationshipOfResource, dwc:relationshipAccordingTo, and dwc:previousIdentifications; the associatedWhatever terms are still in the table, but there is an explanation of what to do about them in the table and in Section 2.8).  I think that this is a good thing because it means that users now have guidance for handling almost any Darwin Core term as RDF, and that wasn't the case in the previous draft. 

3. Bob had made some comments on the draft, which I have now deleted from the wiki and pasted in to the Google Doc for the record.  I think I've addressed his first issue which was about the lack of clarity in the title of section 3.8 and  lack of explanation for why the two ResourceRelationship terms are problematic.  The explanation is that creating ResourceRelationship instanced requires the two dwc: namespace terms: dwc:resourceID and dwc:relatedResourceID.  Since they are "ID" terms, they can't be used as RDF for the reasons explained in section 2.6 of the guide.  We could easily mint two object properties to replace them, but I don't think that there is sufficient consensus that this is a good idea.  We had a previous discussion, which resulted in the wiki page: https://code.google.com/p/tdwg-rdf/wiki/OpenAnnotationAndTDWG .  During that discussion, there were several opinions expressed, including:
- we could use Open Annotation to replace ResourceRelationship terms as RDF
- it was an abuse to use Open Annotation to replace ResourceRelationship terms as RDF
- we could use reification to replace ResourceRelationship terms as RDF.
- it was a bad idea to use reification to replace ResourceRelationship terms as RDF
- Why are we using RDF to create RDF (i.e. the ResourceRelationship instances were effectively RDF triples)?

I decided to take off my RDF Guide lead author hat and put on my RDF Task Group co-convener hat and decide that there isn't sufficient consensus to take action on this item at the present, and that it would be a bad idea to hold up the guide until there was consensus.  I took a play from the DCMI playbook [1] and put in this notation for the two problematic ResourceRelationship terms:

"As of November 2014, the RDF/OWL Task Group is seeking a way to express resource relationships as RDF. For the present, dwciri: analogues have not been adopted for these two terms. See the informative ancillary web page for further discussion."

Until somebody cares enough about expressing ResoureRelationship instances as RDF to lead the effort to develop a consensus strategy,we can leave that comment in the Guide and move on. 

4. Bob raised another important issue, which I have NOT addressed.  He noted that he would prefer use of the IETF Key words for use in RFCs to Indicate Requirement Levels ("SHOULD NOT", "MAY", "SHOULD", etc. https://tools.ietf.org/html/rfc2119 ).  I purposefully did not refer to RFC 2119 because the guide was written using many of those words in a colloquial fashion and nobody has gone through the document to make sure that our use of those words conform to their meaning as stated in RFC 2119.  I don't have time to do that now.  If anyone feels strongly that this must be done now before we go to public comment, please express that opinion and volunteer to do the editing.  Otherwise I would prefer to move forward into the comment period.  If anyone feels strongly that making the document conform to RFC 2119 should be done before adoption, then please express that opinion during the comment period and it can be discussed.  I am not aware that it has been a requirement for TDWG standards documents to conform to RFC 2119.  Perhaps they should and this could be discussed on the email list.

5. I feel once again that the draft may be ready for public comment.  I will wait a couple more days for additional comments and feedback, particularly about the wording of the new sections 2.8 and 2.9 .  After that, I'll give another careful proofread and if there are no objections, move on to opening public comment.

Steve

[1] "As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration." As far as I can tell, they have not taken action on that item since 2007.  

-- 
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
PMB 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) 322-4942
If you fax, please phone or email so that I will know to look for it.
http://bioimages.vanderbilt.edu
http://vanderbilt.edu/trees

[Steve Baskauf]

For anyone who zoned out and didn't read to the end of the previous
message, this is the short version:

I think I've edited the draft to address all of the concerns that were
raised and if there are no significant objections in the next couple of
days, I plan to initiate public comment. The "clean" draft is:
https://code.google.com/p/tdwg-rdf/wiki/DwcRdfGuideProposalRevised
The draft showing strikeout for deletions and bold for additions is:
https://code.google.com/p/tdwg-rdf/wiki/DwcRdfGuideProposalChanges

Steve