<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div dir="ltr">[oops, sent from wrong address, re-sending... will reply to Paul's reply separately...]</div><div dir="ltr"><br></div><div dir="ltr">I'm very skeptical of applying 2119 to vocabulary specifications. I don't think there's any clear agreement on what constitutes conformance to a vocabulary specification, or even what kind of thing might conform to one, or how you would test conformance. The examples you give are all over the place: conformance is required sometimes of a document, sometimes a curation process, sometimes a person. And what constitutes conformance - is it truth (the taxon MUST be a genus ???), or just intent (the intended claim MUST be that the taxon is a genus ???), or what? How do you test something that uses a vocabulary?<div><br></div><div>I think the talk of "vendors" in 2119 is telling. It gives the intended context of application: you are trying to come to an agreement with someone regarding whether to share some artifact, so you negotiate objective conformance criteria that the provider/seller can verifiably meet and the consumer/buyer can expect and verify. I bet very few of the requirements of this or any other vocabulary are objective enough to meet the kind of standard that engineers and vendors would expect from a specification. Seller/buyer scenarios don't sound much like the use of vocabularies in TDWG community. But even if they did, I think there's too much dissonance between 2119-land and vocabulary-land to risk use of 2119 in a vocabulary spec.<div><br></div><div>Do you know of any precedent for 2119 language to be used in a vocabulary specification? I'd be very interested to see that... TDWG should not be a pioneer when it comes to this kind of thing.<br><div><br></div><div>Also note that in 2119, if an artifact fails to meet a SHOULD, then a justification MUST be provided; this is an escalation of the spec that will need scrutiny and consensus in each case.</div><div><br></div><div>Jonathan</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 4:10 PM, Paul J. Morris <span dir="ltr"><<a href="mailto:mole@morris.net" target="_blank">mole@morris.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bob Morris noted that it may be appropriate for the DarwinCore RDF<br>
Guide to follow RFC 2119 (something for which at least the TDWG GUID<br>
applicability statement provides precedent).<br>
<br>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",<br>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this<br>
document are to be interpreted as described in RFC 2119.<br>
<br>
Internet Engineering Task Force (IETF). RFC 2119. Key words for use in<br>
RFCs to Indicate Requirement Levels. <a href="http://www.ietf.org/rfc/rfc2119.txt" target="_blank">http://www.ietf.org/rfc/rfc2119.txt</a><br>
<br>
This RFC notes: "These words are often capitalized" and "Imperatives of<br>
the type defined in this memo must be used with care and sparingly. In<br>
particular, they MUST only be used where it is actually required for<br>
interoperation or to limit behavior which has potential for causing<br>
harm". There are 69 occurrences of "should" in the guide, many of<br>
these instances appear to have the intent of colloqual english and<br>
probably other words should be substituted in those cases.<br>
<br>
I've taken a stab here at a set of cases where it feels like it might<br>
be appropriate to use the RFC 2119 imperatives.<br>
<br>
A question is whether it is the role of the guide to use MUST/MUST<br>
NOT/REQURED anywhere (except where that is forced by inheritance from<br>
elsewhere)? A potential place for asserting MUST/MUST NOT is the<br>
distinction between dwc and dwciri namespaces. I've put more<br>
discussion under the headings 2.4.1.2 and 2.5 below.<br>
<br>
-Paul<br>
<br>
----<br>
<br>
1.3.2.1 Persistent Identifiers<br>
<br>
s/the provider should take care to ensure/the provider SHOULD take care<br>
to ensure/<br>
<br>
s/it must be converted to an IRI/it MUST be converted to an IRI/<br>
<br>
----<br>
<br>
1.3.2.2 HTTP IRIs as self-resolving GUIDs<br>
<br>
s/through RDF should plan to implement GUIDs/through RDF MUST plan to<br>
implement GUIDs/<br>
<br>
For consistency with "Must" in the GUID applicability statement.<br>
<br>
----<br>
<br>
1.4.1 Well-known vocabularies<br>
<br>
s/the provider should assign the term an IRI,/the provider SHOULD<br>
assign the term an IRI,/<br>
<br>
----<br>
<br>
1.4.3 Use of Darwin Core terms in RDF<br>
<br>
s/each value should be referenced/each value MUST be referenced/<br>
<br>
By the nature of object references.<br>
<br>
----<br>
<br>
1.4.4 Limitations of this guide<br>
<br>
s/Darwin Core property terms should be used as RDF predicates and<br>
specifies that Darwin Core class terms should be used in<br>
rdf:type/Darwin Core property terms SHOULD be used as RDF predicates<br>
and specifies that Darwin Core class terms SHOULD be used in rdf:type/<br>
<br>
----<br>
<br>
1.5.5 Implications for expressing Darwin Core string values as RDF<br>
<br>
s/in which RDF should be structured/in which RDF SHOULD be structured/<br>
<br>
----<br>
<br>
Example 1:<br>
<br>
s/Predicates must be identified by IRIs/Predicates MUST be identified<br>
by IRIs/<br>
<br>
----<br>
<br>
2.2 Subject resources<br>
<br>
s/it must be referenced by an IRI/it MUST be referenced by an IRI/<br>
<br>
----<br>
<br>
2.2.2 Associating a string identifier with a subject resource<br>
<br>
s/dcterms:identifier should be used to/dcterms:identifier SHOULD be<br>
used to/<br>
<br>
s/it is acceptable to present it as a string literal value for<br>
dcterms:identifier/it MAY be presented as a string literal value for<br>
dcterms:identifier/<br>
<br>
----<br>
<br>
2.3.1.1 rdf:type statement<br>
<br>
s/The class should be identified by an IRI reference/The class MUST be<br>
identified by an IRI reference/<br>
<br>
----<br>
<br>
2.3.1.3 Explicit vs. inferred type declarations<br>
<br>
s/data providers should exercise caution in using any such term in a<br>
non-standard way/data providers SHOULD NOT use any such term in a<br>
non-standard way/<br>
<br>
s/the provider should type the resource/the provider MAY type the<br>
resource/ ?? Or ??<br>
s/the provider should type the resource/the provider SHOULD type the<br>
resource/<br>
<br>
----<br>
<br>
2.3.1.4 Other predicates used to indicate type<br>
<br>
s/in an RDF description should be considered optional, while including<br>
rdf:type should be considered highly recommended/in an RDF description<br>
is OPTIONAL, while rdf:type SHOULD be included/<br>
<br>
s/A dwciri: analogue (Section 2.5) of dwc:basisOfRecord should not be<br>
used/A dwciri: analogue (Section 2.5) of dwc:basisOfRecord MUST NOT be<br>
used/<br>
<br>
----<br>
<br>
2.3.1.5 Classes to be used for type declarations of resources described<br>
using Darwin Core<br>
<br>
s/that should also be used/that SHOULD also be used/<br>
<br>
----<br>
<br>
Example 9:<br>
<br>
s/a provider should include an xml:lang/a provider SHOULD include an<br>
xml:lang/<br>
<br>
----<br>
<br>
Example 10:<br>
<br>
I'm not sure about this one:<br>
<br>
/language tags should be interpreted by clients<br>
<br>
s/may initially choose to expose literals without datatype attributes,<br>
they should/MAY initially choose to expose literals without datatype<br>
attributes, they SHOULD/<br>
<br>
----<br>
<br>
2.4.1.2 Terms intended for use with literal objects<br>
<br>
I'll put a stake in the ground for discussion here: Is the guide<br>
sufficiently normative to assert MUST (other than where that property<br>
is inherited from elsewhere)? If so, then the distinction between dwc<br>
and dwciri is the place to make that assertion:<br>
<br>
s/that terms in the dwc: namespace should be restricted to use with<br>
literal objects/that terms in the dwc: namespace MUST be restricted to<br>
use with literal objects/<br>
<br>
----<br>
<br>
2.4.2.1.1 Objects identified by LSIDs<br>
<br>
This one needs to be checked for consistency with the LSID<br>
Applicability Statements:<br>
<br>
s/version of the LSID should be used instead/version of the LSID SHOULD<br>
be used instead/<br>
<br>
----<br>
<br>
Example 17:<br>
<br>
s/particular terms should be used with literal objects, or with IRI<br>
reference objects/particular terms SHOULD be used with literal objects,<br>
or SHOULD be used with IRI reference objects/<br>
<br>
<br>
----<br>
<br>
2.4.3.2 Literal values for non-literal resources in Darwin Core<br>
<br>
s/existing Darwin Core term in the dwc: namespace should have the same<br>
structure/existing Darwin Core term in the dwc: namespace SHOULD have<br>
the same structure/<br>
<br>
----<br>
<br>
2.5 Terms in the dwciri: namespace<br>
<br>
This is the companion case to 2.4.1.2 - is the distinction between<br>
dwciri and dwc to be asserted as SHOULD or MUST - using them<br>
incorrectly does have the "potential for causing harm" in the language<br>
of RFC 2119, but does the guide rise to the level of specifying an<br>
"absolute requirement of the specification".<br>
<br>
s/IRI reference objects and should NOT be used with literal/ IRI<br>
reference objects and MUST NOT be used with literal/<br>
<br>
----<br>
<br>
2.5.1 Definition of dwciri: terms<br>
<br>
s/resource described by a dwciri: property should be the subject of a<br>
triple for each value on the list/resource described by a dwciri:<br>
property SHOULD be the subject of a triple for each value on the list/<br>
<br>
A counter example here comes from the Harvard List of Botanists, where<br>
<a href="http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/305dcac3-a748-4f47-8a18-3aaa9503c471" target="_blank">http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/305dcac3-a748-4f47-8a18-3aaa9503c471</a><br>
references the collector team "J. D. Hooker & A. Gray", that is,<br>
<a href="http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/cc3b7080-5fbb-4ea5-9655-49302d3e6a1b" target="_blank">http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/cc3b7080-5fbb-4ea5-9655-49302d3e6a1b</a><br>
and<br>
<a href="http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/3f8c70aa-1862-4784-8a53-f69ffe810fa0" target="_blank">http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/3f8c70aa-1862-4784-8a53-f69ffe810fa0</a><br>
<br>
----<br>
<br>
2.5.3 Expectation of clients encountering RDF containing dwc: and<br>
dwciri: terms<br>
<br>
Instances of "should" here again cut to the heart of how strong the<br>
guidance is concerning dwc and dwciri.<br>
<br>
----<br>
<br>
Table 3<br>
<br>
s/they should be used rather than using the Darwin Core ID/they SHOULD<br>
be used rather than using the Darwin Core ID/<br>
<br>
----<br>
<br>
Example 22:<br>
<br>
s/The following points about the Example 22 should be noted:/Note the<br>
following points about Example 22:/<br>
<br>
s/related non-literal resources should use/related non-literal<br>
resources SHOULD use/<br>
<br>
/LSIDs are the objects of triples, they should be<br>
<br>
As with 2.4.2.1.1, this guidance needs to be checked against the GUID<br>
and LSID applicability statements. I think I'm reading the GUID<br>
applicability statement as s/should/MUST/ here.<br>
<br>
----<br>
2.7.1 What purpose do convenience terms serve?<br>
<br>
s/In general, it should not be necessary for a data provider/In<br>
general, a data provider does not need/<br>
<br>
----<br>
<br>
2.7.3 Ownership of a collection item<br>
<br>
s/of the collection item should be indicated/of the collection item<br>
SHOULD be indicated/<br>
<br>
----<br>
<br>
2.7.4 Description of a taxonomic entity<br>
<br>
s/It is considered to be out of the scope of this document to specify<br>
how taxon concepts should be rendered as RDF/It is out of the scope of<br>
this document to specify how to render taxon concepts as RDF/<br>
<br>
<br>
s/terms for taxonomic entities should be properties of<br>
dwc:Identification/terms for taxonomic entities MAY be properties of<br>
dwc:Identification/<br>
<br>
s/The task of describing taxonomic entities using RDF must be an effort<br>
outside of Darwin Core/The task of describing taxonomic entities using<br>
RDF is out of scope of this document/<br>
<br>
----<br>
<br>
2.8.3 Expressing Darwin Core association terms as RDF with URI<br>
references<br>
<br>
s/it should be used to declare the type/rdf:type SHOULD be used to<br>
declare the type/<br>
<br>
----<br>
<br>
Tables 3.4 to 3.7.<br>
<br>
s/should/SHOULD/<br>
<br>
--------<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Paul J. Morris<br>
Biodiversity Informatics Manager<br>
Harvard University Herbaria/Museum of Comparative Zoölogy<br>
<a href="mailto:mole@morris.net">mole@morris.net</a> AA3SD PGP public key available<br>
_______________________________________________<br>
tdwg-content mailing list<br>
<a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
</font></span></blockquote></div><br></div>
</body></html>