- tdwg-content - lists.tdwg.org

Fwd: [dwc] quantity (#12)
by John Wieczorek 05 Mar '15

05 Mar '15

Der all, I am forwarding this comment from Simon Cox, which was submitted to the Darwin Core development site on Github. Cheers, John ---------- Forwarded message ---------- From: Simon Cox <notifications(a)github.com> Date: Mon, Dec 15, 2014 at 4:47 AM Subject: Re: [dwc] quantity (#12) To: tdwg/dwc <dwc(a)noreply.github.com> Cc: John Wieczorek <tuco(a)berkeley.edu> 'quantity' usually implies an amount, encoded as a scaled number. In most other domains it does not include a value from an enumerated set. The latter may be called 'quality'. Both quantity and quality are subclasses of 'property'. — Reply to this email directly or view it on GitHub <https://github.com/tdwg/dwc/issues/12#issuecomment-66946784>.

6 9

Best practice for scientificNameAuthorship?
by Andréa Matsunaga 25 Feb '15

25 Feb '15

Dear experts. What is the best practice for the DwC scientificNameAuthorship when there is a specific epithet author as well as infraspecific epithet author in a scientific name? Both names concatenated by some character? Only the infraspecific epithet author? Both pieces of information would go into DwC scientificname, but I'm looking for how users would use scientificNameAuthorship and what is useful to have there. Thank you, --am

2 1

Easting and northing
by Roderic Page 11 Feb '15

11 Feb '15

Pardon my ignorance, but has there ever been a discussion of easting and northing values in regards to Darwin Core? AFAIK the current standard doesn’t mention them. The reason I’m asking is that I’ve just come across some VerbatimLatitude and VerbatimLongitude values in a dataset that is aggregated by VertNet (and hence GBIF) where (after some head scratching) I realised that the verbatim values were actually Easting and Northing (which I didn’t know existed until yesterday). Details are here: https://github.com/ttu-vertnet/ttu-mammals/issues/11 I’m guessing this isn’t a terribly common way to record location information, but it looks like in this case the lack of support for this type of data has resulted in somebody trying to shoehorn them into VerbatimLatitude and VerbatimLongitude, resulting in values which are uninterpretable to aggregators further up the chain. Regards Rod --------------------------------------------------------- Roderic Page Professor of Taxonomy Institute of Biodiversity, Animal Health and Comparative Medicine College of Medical, Veterinary and Life Sciences Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK Email: Roderic.Page(a)glasgow.ac.uk<mailto:Roderic.Page@glasgow.ac.uk> Tel: +44 141 330 4778 Skype: rdmpage Facebook: http://www.facebook.com/rdmpage LinkedIn: http://uk.linkedin.com/in/rdmpage Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com ORCID: http://orcid.org/0000-0002-7101-9767 Citations: http://scholar.google.co.uk/citations?hl=en&user=4Z5WABAAAAAJ ResearchGate https://www.researchgate.net/profile/Roderic_Page

6 21

Re: [tdwg-content] Darwin Core Standard - proposed change in governance
by Simon.Cox＠csiro.au 26 Jan '15

26 Jan '15

A property to indicate membership in an ontology appears to be missing from the standard semweb stack. Some folks use rdfs:isDefinedBy to point from resources to an ontology, but rdfs:isDefinedBy is also used for other things. AFAIK there is no inverse-ish property whose domain includes owl:Ontology that can be used to assemble a set of classes and properties to be deemed to be part of the ontology. I sometimes use dct:hasPart but that doesn't seem quite strong or specific enough. Maybe just rdfs:member . Simon -----Original Message----- Date: Thu, 22 Jan 2015 16:35:36 +0100 From: ?amonn ? Tuama [GBIF] <eotuama(a)gbif.org> Subject: Re: [tdwg-content] Darwin Core Standard - proposed change in governance To: "'Steve Baskauf'" <steve.baskauf(a)vanderbilt.edu>, "'Tim Robertson'" <trobertson(a)gbif.org> Cc: 'TDWG Content Mailing List' <tdwg-content(a)lists.tdwg.org>, '"Markus D?ring (GBIF)"' <mdoering(a)gbif.org> Message-ID: <00d101d03659$119e2330$34da6990$@org> Content-Type: text/plain; charset="iso-8859-1" Dublin Core tackles the issue of ?borrowing? from other vocabularies through the construct of Dublin Core Application Profiles [1] ? something separate from the specification of DC itself. ?amonn [1] http://dublincore.org/documents/2009/05/18/profile-guidelines/ From: tdwg-content-bounces(a)lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Steve Baskauf Sent: 22 January 2015 15:41 To: Tim Robertson Cc: TDWG Content Mailing List; "Markus D?ring (GBIF)" Subject: Re: [tdwg-content] Darwin Core Standard - proposed change in governance I'm not sure whether anyone ever established that there was a consensus on this, but it has been suggested repeatedly that the basic Darwin Core vocabulary should have minimal restrictions and semantics imposed upon it. This allows other layers to be built upon it (XML schemas, RDF-based ontologies, etc.) that are intended to serve more specialized purposes. >From the standpoint of the normative RDF document, that means that it should include very little in the way semantics that would create entailments for semantic clients. That doesn't mean that there is no value in having that RDF, because the resources defined by that document can be nodes that can be linked and restricted by other ontologies. This has been done or is being done by Darwin-SW and BCO, for example. Having the RDF document contain few machine-interpretable properties is a separate issue from whether it is a good idea for that document to be normative. Bob makes a good point that if it is the normative document yet does not contain the information required for defining how the terms should be used, it may be inadequate. We already have that situation with the Dublin Core terms. Since they are defined as RDF by DCMI, we don't include them in our normative RDF document. So if potential users were to try to use Darwin Core by looking solely at the normative document (which they should be able to do, at least in theory), they would not know that Darwin Core includes Dublin Core terms. This is a point that should be considered in discussions on a TDWG-wide policy on vocabulary documentation. It's an even bigger issue in Audubon Core, since a much higher proportion of its terms are "borrowed" from other vocabularies than DwC. Steve Tim Robertson wrote: Hi all, I don?t think there has ever been any intention for DwC to impose that kind of restriction, regardless of the format chosen for the authoritative version (e.g. be it wiki text, RDF, HTML or PDF). I?d expect a schema to define that restriction (xsd, class definition etc). Is that how others see it? I believe this is what John meant when he wrote the spec [1]: "There is meant to be a clear separation between the terms defined in this standard and the applications that make use of them. For example, though the data types and constraints are not provided in the term definitions, recommendations are made about how to restrict the values where appropriate." Cheers, Tim [1] http://rs.tdwg.org/dwc/index.htm

1 0

Darwin Core Standard - proposed change in governance
by John Wieczorek 22 Jan '15

22 Jan '15

Dear all, Peter Desmet, Markus Döring, and I have been working on the transition of Darwin Core maintenance from the Google Code Site to Github. We've taken the opportunity to streamline the process of making updates to the standard when they are ratified, such as scripts to produce the human-readable content and auxiliary files from the RDF document of current terms. As a result of this work, we see further opportunities to simplify the maintenance of the standard. They center on the following proposal. We would like to propose that the *RDF document of current terms* be made to represent the *normative standard for Darwin Core* rather than *Complete History normative document* we use now. We would also like to make that new normative document the only document in the standard. Under this proposal: 1) the normative standard for Darwin Core would consist of a single document at http://rs.tdwg.org/terms/dwc_normative.rdf (not currently active). 2) information currently held in http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf (the current normative document) and the corresponding Complete History web page ( http://rs.tdwg.org/dwc/terms/history/index.htm) would be retained only in a history document http://rs.tdwg.org/terms/history.html (not currently active). 3) all documents other than the proposed normative document would not be part of the standard. The proposed changes require community consensus under the existing rules of governance of the Darwin Core. This means that the proposal must be under public review for at least 30 days after an apparent consensus on the proposal and any amendments to it is reached, where consensus consists of no publicly-shared opposition. The implications of this proposal are many. One of the most important is that the rules governing changes to the standard ( http://rs.tdwg.org/dwc/terms/namespace/index.htm) would no longer be a part of the standard. Instead, we would promote the adoption of these rules across TDWG standards rather than just within Darwin Core. It may be that TDWG is not ready to accommodate this at the moment. If so, the Namespace Policy could remain within the Darwin Core standard until the broader governance process for TDWG can cover it, at which point we would propose to remove the Namespace Policy from the Darwin Core. Other comments about the proposed changes: Having one RDF document for the terms in the dwc namespace will avoid confusion. Only those with status 'recommended' would be in the normative document. Having the term history (all versions, including deprecated, superseded, and recommended ones) in a web page only is what Dublin Core does. It means no one would be able to reason over old versions of the Darwin Core. Would anyone do that? Having no document other than the normative one as part of the standard would free the whole rest of the body of Darwin Core documentation from the requirements of public review and Executive Committee approval. This would make that documentation much more open to broader contributions and easier to adapt to evolving demands. We do not propose to lose any of the documentation we have. Please share your comments! Cheers, John

11 18

Re: [tdwg-content] Darwin Core Standard - proposed change in governance
by John Wieczorek 21 Jan '15

21 Jan '15

Dear all, There seems to be some consensus forming that simplification is good, and that the history should be part of the normative document. Without committing to a stance on RDF versus anything else as a normative document, we (Markus, actually) have made scripts to produce the human readable version from the RDF so that the two will be easy to synchronize. In fact, the script generates several documents to keep everything in sync. Right now that human-readable version is similar to the present standard Quick Reference Guide (http://rs.tdwg.org/dwc/terms/index.htm) with very little explanation aside from the terms, and only a few of the properties for the terms. If we have a normative document, then it must contain all of the properties of the terms, as in the present Complete History document ( http://rs.tdwg.org/dwc/terms/history/index.htm) There is more in those term definitions than most people need. So, if we go with a human-readable document (HTML?), it should contain as little explanatory text that could change over time as possible. I also suggest that we should have an even more prominent human-readable page that has only what most people need (a la the Quick Reference Guide). Every derived document (Quick Reference, RDF document, XML schemas, terms list, term pages on the GBIF Media Wiki) should have a reference to the normative document, and they should absolutely be kept in sync with the normative document. Is this a sound alternative proposal? Do I get the sense that for now the standard should retain the Namespace Policy, until TDWG can set up a broader policy? Cheers, John On Wed, Jan 21, 2015 at 4:59 PM, Bertram Ludaescher <ludaesch(a)gmail.com> wrote: > +1 for "human readable" > > (last time I checked, humans were still doing most of the thinking on > planet Earth :) > > Oh and "parsers" were one of the first things computer scientists invented > to make human-readable things also machine-readable. I think they still > make those ;-) > > Over the years, we might have gone overboard with "one size fits all" > (XML, RDF, <insert your favorite language here> ... ) > > My 2 cents.. > > Bertram > > > On Wed, Jan 21, 2015 at 9:49 AM, Éamonn Ó Tuama [GBIF] <eotuama(a)gbif.org> > wrote: > >> Seems like RDF expression in combination with a privileged XSLT to human >> readable doc might do. I still like the idea of the RDF doc as the >> normative one. At least it is concise. The W3C specification pages are a >> rather messy mix of different sections some headed by "This section is >> non-normative.", and see, e.g., the page for the DCAT vocab [1] "As well as >> sections marked as non-normative, all authoring guidelines, diagrams, >> examples, and notes in this specification are non-normative. Everything >> else in this specification is normative." >> >> While RDF might excel as a graph definition langauge, I think there is >> still value is using it without domain and range statements (if these don't >> exist) to simply define labels, definitions and comments (examples) in a >> machine readable way. >> >> >> >> [1] http://www.w3.org/TR/vocab-dcat/ >> >> -----Original Message----- >> From: tdwg-content-bounces(a)lists.tdwg.org [mailto: >> tdwg-content-bounces(a)lists.tdwg.org] On Behalf Of Bob Morris >> Sent: 21 January 2015 15:13 >> To: John Wieczorek >> Cc: TDWG Content Mailing List >> Subject: Re: [tdwg-content] Darwin Core Standard - proposed change in >> governance >> >> John et al. Thanks for all the work you've put into this >> >> I favored this at first, but thought a lot since it was proposed and now >> oppose item 1). >> >> Short argument: RDF is meant for machines to read, not humans to read. >> If an RDF document is normative, mainly RDF experts will be able to argue >> about it and about conformance to it. >> >> More(?) important, RDF is a graph definition language, not a >> specification definition language. Not even RDF has an RDF file as its >> normative definition. In fact, it seems both W3C and IETF regard most >> (all?) of their normative artifacts for specification (respectively >> "Recommendation" and "Request For Comment") as nothing other than human >> readable documents. >> >> This is not to say there should not be one or more normative RDFS >> serializations of a human readable specification. It may even be that >> there should be a privileged RDFS document, together with a privileged >> transformation (e.g. in xslt) and a privileged platform for synthesizing a >> human readable form of DwC. But it's that web document that should be >> normative (and human readable.) This is what Audubon Core does, except >> that the base "generation data" comprises, annoyingly, but robustly, calls >> to the MediaWiki template language. >> (The annoyance of designing MediaWiki templates may ease in the future >> due to [1]) >> >> Certainly there are exceptions to the principle of "make only human >> readable as the base normative artifact". The XML schemaSchema [2] is an in >> example. But DwC doesn't seem to fit that model. DwC is not a DwC object. >> >> My position is a little influenced by [3], a lot of with which I >> disagree. But it reminds me of something my Daddy taught me: >> "multi-purpose tools are often poor at all their purposes, except in >> simple cases." But really, my reluctance here is that I see no reason we >> should imagine that DwC data is always a graph and that is why we should >> model it with a graph description language. Worse, my experience is that >> the most common potholes in the RDF world arise when using it without >> understanding the underlying graph theory. >> >> Bob Morris >> >> [1] http://www.mediawiki.org/wiki/Lua_scripting >> [2] http://www.w3.org/TR/xmlschema11-1/#normative-schemaSchema >> [3] http://manu.sporny.org/2014/json-ld-origins-2/ >> >> On Tue, Jan 20, 2015 at 10:18 AM, John Wieczorek <tuco(a)berkeley.edu> >> wrote: >> > Dear all, >> > >> > Peter Desmet, Markus Döring, and I have been working on the transition >> > of Darwin Core maintenance from the Google Code Site to Github. We've >> > taken the opportunity to streamline the process of making updates to >> > the standard when they are ratified, such as scripts to produce the >> > human-readable content and auxiliary files from the RDF document of >> > current terms. As a result of this work, we see further opportunities >> > to simplify the maintenance of the standard. They center on the >> following proposal. >> > >> > We would like to propose that the RDF document of current terms be >> > made to represent the normative standard for Darwin Core rather than >> > Complete History normative document we use now. We would also like to >> > make that new normative document the only document in the standard. >> > >> > Under this proposal: >> > >> > 1) the normative standard for Darwin Core would consist of a single >> > document at http://rs.tdwg.org/terms/dwc_normative.rdf (not currently >> active). >> > >> > >> > 2) information currently held in >> > http://rs.tdwg.org/dwc/rdf/dwctermshistory.rdf (the current normative >> > document) and the corresponding Complete History web page >> > (http://rs.tdwg.org/dwc/terms/history/index.htm) would be retained >> > only in a history document http://rs.tdwg.org/terms/history.html (not >> > currently active). >> > >> > >> > 3) all documents other than the proposed normative document would not >> > be part of the standard. >> > >> > >> > The proposed changes require community consensus under the existing >> > rules of governance of the Darwin Core. This means that the proposal >> > must be under public review for at least 30 days after an apparent >> > consensus on the proposal and any amendments to it is reached, where >> > consensus consists of no publicly-shared opposition. >> > >> > >> > The implications of this proposal are many. One of the most important >> > is that the rules governing changes to the standard >> > (http://rs.tdwg.org/dwc/terms/namespace/index.htm) would no longer be >> > a part of the standard. Instead, we would promote the adoption of >> > these rules across TDWG standards rather than just within Darwin Core. >> > It may be that TDWG is not ready to accommodate this at the moment. If >> > so, the Namespace Policy could remain within the Darwin Core standard >> > until the broader governance process for TDWG can cover it, at which >> > point we would propose to remove the Namespace Policy from the Darwin >> Core. >> > >> > >> > Other comments about the proposed changes: >> > >> > >> > Having one RDF document for the terms in the dwc namespace will avoid >> > confusion. Only those with status 'recommended' would be in the >> > normative document. >> > >> > >> > Having the term history (all versions, including deprecated, >> > superseded, and recommended ones) in a web page only is what Dublin >> > Core does. It means no one would be able to reason over old versions >> > of the Darwin Core. Would anyone do that? >> > >> > >> > Having no document other than the normative one as part of the >> > standard would free the whole rest of the body of Darwin Core >> > documentation from the requirements of public review and Executive >> > Committee approval. This would make that documentation much more open >> > to broader contributions and easier to adapt to evolving demands. >> > >> > >> > We do not propose to lose any of the documentation we have. >> > >> > >> > Please share your comments! >> > >> > >> > Cheers, >> > >> > >> > John >> > >> > >> > _______________________________________________ >> > tdwg-content mailing list >> > tdwg-content(a)lists.tdwg.org >> > http://lists.tdwg.org/mailman/listinfo/tdwg-content >> > >> >> >> >> -- >> Robert A. Morris >> >> Emeritus Professor of Computer Science >> UMASS-Boston >> 100 Morrissey Blvd >> Boston, MA 02125-3390 >> >> >> Filtered Push Project >> Harvard University Herbaria >> Harvard University >> >> email: morris.bob(a)gmail.com >> web: http://efg.cs.umb.edu/ >> web: http://wiki.filteredpush.org >> http://wiki.datakurator.net >> http://taxonconceptexplorer.org/ >> http://www.cs.umb.edu/~ram >> _______________________________________________ >> tdwg-content mailing list >> tdwg-content(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-content >> >> _______________________________________________ >> tdwg-content mailing list >> tdwg-content(a)lists.tdwg.org >> http://lists.tdwg.org/mailman/listinfo/tdwg-content >> > >

1 0

Darwin Core Proposal - term content recommendations to comments
by John Wieczorek 19 Jan '15

19 Jan '15

Dear all, During the process of reviewing the recent set of changes to the Darwin Core standard in early November 2014, it was proposed to make the definitions and comments for terms more consistent in their treatment of content recommendations. The specific proposal is logged in the Darwin Core issue tracker as https://github.com/tdwg/dwc/issues/26. The gist of the proposal is that recommendations on how to populate a term are often in the definition whereas we would like them to be consistently in the comments section. The list of affected terms is given below for reference. This message is to elicit responses from any who might have a reason to recommend against these changes, which are not semantic in nature. We will leave this proposal open for commentary until 19 February 2015 unless further discussion arises resulting in amendments. Cheers, John The following terms have recommendations in the definitions, which we would like to move to comments: datasetID occurrenceID sex lifeStage reproductiveCondition behavior establishmentMeans occurrenceStatus organismID organismScope materialSampleID eventID eventDate eventTime locationID higherGeographyID continent waterBody islandGroup island country countryCode municipality locality minimumDistanceAboveSurfaceInMeters maximumDistanceAboveSurfaceInMeters locationAccordingTo decimalLatitude decimalLongitude geodeticDatum coordinateUncertaintyInMeters pointRadiusSpatialFit verbatimCoordinates verbatimLatitude verbatimLongitude verbatimCoordinateSystem verbatimSRS footprintWKT footprintSRS footprintSpatialFit georeferencedDate georeferenceVerificationStatus geologicalContextID identificationID dateIdentified identificationVerificationStatus taxonID scientificName subgenus taxonRank nomenclaturalCode taxonomicStatus measurementID measurementType measurementUnit measurementDeterminedDate relationshipOfResource relationshipEstablishedDate while the following terms already have the recommendations in the comments: institutionID collectionID basisOfRecord dynamicProperties recordedBy preparations disposition associatedMedia associatedReferences associatedSequences associatedTaxa otherCatalogNumbers associatedOccurrences associatedOrganisms previousIdentifications higherGeography georeferencedBy georeferenceSources typeStatus identifiedBy identificationReferences higherClassification measurementDeterminedBy

3 3

Re: [tdwg-content] 'quantity'
by Simon.Cox＠csiro.au 16 Dec '14

16 Dec '14

My intention in raising this concern is not to suggest that you don't need the concept of measurable-property-type-whose-value-is-an-item-from-an-enumerated(-possibly-ordered)-set, but rather just to caution that people from other domains might be surprised to see such a thing referred to as a 'quantity'. My concern is the loss of interoperability. If the latter is a goal, then you might consider tweaking the terminology. Of course if there is a unique mapping from values in the enumerated(-and-ordered)-set to scaled numbers, then 'quantity' is fine. But if the set of 'quantityTypes' that have enumerated values is distinct from the set that have scaled numeric values, then why not recognise this in the name? Simon ------------------------------ Message: 4 Date: Tue, 16 Dec 2014 09:02:19 +0100 From: ?amonn ? Tuama [GBIF] <eotuama(a)gbif.org> Subject: Re: [tdwg-content] Fwd: [dwc] quantity (#12) To: 'Markus D?ring' <m.doering(a)mac.com>, "'Paul J. Morris'" <mole(a)morris.net> Cc: 'TDWG Content Mailing List' <tdwg-content(a)lists.tdwg.org> Message-ID: <000101d01906$9d8f3250$d8ad96f0$@org> Content-Type: text/plain; charset="utf-8" Simon's distinction of scaled number vs discrete set could probably be captured using DWC MeasurementOrFact properties. However, as discussed previously, we felt that because measurements of abundance/density/coverage were of fundamental importance in field studies, and in the spirit of DwC's pragmatic approach, they merited their own high level term(s), rather than "burying" them under MeasurementOrFact - hence the proposal of "quantity" and "quantityType" where the term "quantity" seems the most inclusive label for what we are trying to express. Following John's recommendation, we have removed the references to examples in the definitions and expanded the examples in the comment section so it is clear how they are to be used. quantity #Definition A number or enumeration value for the entity being quantified in quantityType. #Comment The terms quantity and quantityType are required to be used as a pair. The value of quantity is a number or enumeration, e.g., ?27? for a quantityType ?individuals?, ?12.5? for a quantityType ?%biomass?, or ?r? for a quantityType ?BraunBlanquetScale?. quantityType #Definition The entity to which the number or enumeration reported in quantity refers. #Comment The terms quantity and quantityType are required to be used as a pair. The value of quantityType (i.e., the entity being measured) is expected to be drawn from a small controlled vocabulary with terms such as ?Individuals?, ?%Biomass?, ?%Biovolume?, ?%Species?, ?%Coverage?, ?BraunBlanquetScale?, ?DominScale?. Examples when combined with quantity values: + on DominScale; 5 on BraunBlanquetScale; 45 for %Biomass. ?amonn -----Original Message----- From: tdwg-content-bounces(a)lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Markus D?ring Sent: 15 December 2014 15:48 To: Paul J. Morris Cc: TDWG Content Mailing List Subject: Re: [tdwg-content] Fwd: [dwc] quantity (#12) "r" is a value for very few individuals in the Braun Blanquet cover abundance scale which is used a lot in vegetation studies. It is like various others a non continous scale with discrete values. I do not think we should restrict quantity to contious numeric scales. Markus > Am 15.12.2014 um 15:36 schrieb Paul J. Morris <mole(a)morris.net>: > > Markus can probably answer this question: > > What would be the expected value of QuantityType for a Quantity of "r"? > > A comment Bob Morris occasionally makes is: "1 is greater than 2 for > sufficently large values of 1". If some particular quantity type has > a standard set of codes that represent numbers, then it might be > appropriate to use those standard codes as values of quantity. > > -Paul > > On Mon, 15 Dec 2014 12:48:06 +0100 > John Wieczorek <tuco(a)berkeley.edu> wrote: > >> Der all, >> >> I am forwarding this comment from Simon Cox, which was submitted to >> the Darwin Core development site on Github. >> >> Cheers, >> >> John >> >> ---------- Forwarded message ---------- >> From: Simon Cox <notifications(a)github.com> >> Date: Mon, Dec 15, 2014 at 4:47 AM >> Subject: Re: [dwc] quantity (#12) >> To: tdwg/dwc <dwc(a)noreply.github.com> >> Cc: John Wieczorek <tuco(a)berkeley.edu> >> >> >> 'quantity' usually implies an amount, encoded as a scaled number. >> In most other domains it does not include a value from an enumerated >> set. The latter may be called 'quality'. >> Both quantity and quality are subclasses of 'property'. >> >> ? >> Reply to this email directly or view it on GitHub >> <https://github.com/tdwg/dwc/issues/12#issuecomment-66946784>. > > > -- > Paul J. Morris > Biodiversity Informatics Manager > Harvard University Herbaria/Museum of Comparative Zo?logy > mole(a)morris.net AA3SD PGP public key available > _______________________________________________ > tdwg-content mailing list > tdwg-content(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-content _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content ------------------------------ _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content End of tdwg-content Digest, Vol 67, Issue 8 *******************************************

1 0

RFC 2119: Re: Public comment on the Darwin Core RDF Guide
by Paul J. Morris 14 Dec '14

14 Dec '14

Bob Morris noted that it may be appropriate for the DarwinCore RDF Guide to follow RFC 2119 (something for which at least the TDWG GUID applicability statement provides precedent). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Internet Engineering Task Force (IETF). RFC 2119. Key words for use in RFCs to Indicate Requirement Levels. http://www.ietf.org/rfc/rfc2119.txt This RFC notes: "These words are often capitalized" and "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm". There are 69 occurrences of "should" in the guide, many of these instances appear to have the intent of colloqual english and probably other words should be substituted in those cases. I've taken a stab here at a set of cases where it feels like it might be appropriate to use the RFC 2119 imperatives. A question is whether it is the role of the guide to use MUST/MUST NOT/REQURED anywhere (except where that is forced by inheritance from elsewhere)? A potential place for asserting MUST/MUST NOT is the distinction between dwc and dwciri namespaces. I've put more discussion under the headings 2.4.1.2 and 2.5 below. -Paul ---- 1.3.2.1 Persistent Identifiers s/the provider should take care to ensure/the provider SHOULD take care to ensure/ s/it must be converted to an IRI/it MUST be converted to an IRI/ ---- 1.3.2.2 HTTP IRIs as self-resolving GUIDs s/through RDF should plan to implement GUIDs/through RDF MUST plan to implement GUIDs/ For consistency with "Must" in the GUID applicability statement. ---- 1.4.1 Well-known vocabularies s/the provider should assign the term an IRI,/the provider SHOULD assign the term an IRI,/ ---- 1.4.3 Use of Darwin Core terms in RDF s/each value should be referenced/each value MUST be referenced/ By the nature of object references. ---- 1.4.4 Limitations of this guide s/Darwin Core property terms should be used as RDF predicates and specifies that Darwin Core class terms should be used in rdf:type/Darwin Core property terms SHOULD be used as RDF predicates and specifies that Darwin Core class terms SHOULD be used in rdf:type/ ---- 1.5.5 Implications for expressing Darwin Core string values as RDF s/in which RDF should be structured/in which RDF SHOULD be structured/ ---- Example 1: s/Predicates must be identified by IRIs/Predicates MUST be identified by IRIs/ ---- 2.2 Subject resources s/it must be referenced by an IRI/it MUST be referenced by an IRI/ ---- 2.2.2 Associating a string identifier with a subject resource s/dcterms:identifier should be used to/dcterms:identifier SHOULD be used to/ s/it is acceptable to present it as a string literal value for dcterms:identifier/it MAY be presented as a string literal value for dcterms:identifier/ ---- 2.3.1.1 rdf:type statement s/The class should be identified by an IRI reference/The class MUST be identified by an IRI reference/ ---- 2.3.1.3 Explicit vs. inferred type declarations s/data providers should exercise caution in using any such term in a non-standard way/data providers SHOULD NOT use any such term in a non-standard way/ s/the provider should type the resource/the provider MAY type the resource/ ?? Or ?? s/the provider should type the resource/the provider SHOULD type the resource/ ---- 2.3.1.4 Other predicates used to indicate type s/in an RDF description should be considered optional, while including rdf:type should be considered highly recommended/in an RDF description is OPTIONAL, while rdf:type SHOULD be included/ s/A dwciri: analogue (Section 2.5) of dwc:basisOfRecord should not be used/A dwciri: analogue (Section 2.5) of dwc:basisOfRecord MUST NOT be used/ ---- 2.3.1.5 Classes to be used for type declarations of resources described using Darwin Core s/that should also be used/that SHOULD also be used/ ---- Example 9: s/a provider should include an xml:lang/a provider SHOULD include an xml:lang/ ---- Example 10: I'm not sure about this one: /language tags should be interpreted by clients s/may initially choose to expose literals without datatype attributes, they should/MAY initially choose to expose literals without datatype attributes, they SHOULD/ ---- 2.4.1.2 Terms intended for use with literal objects I'll put a stake in the ground for discussion here: Is the guide sufficiently normative to assert MUST (other than where that property is inherited from elsewhere)? If so, then the distinction between dwc and dwciri is the place to make that assertion: s/that terms in the dwc: namespace should be restricted to use with literal objects/that terms in the dwc: namespace MUST be restricted to use with literal objects/ ---- 2.4.2.1.1 Objects identified by LSIDs This one needs to be checked for consistency with the LSID Applicability Statements: s/version of the LSID should be used instead/version of the LSID SHOULD be used instead/ ---- Example 17: s/particular terms should be used with literal objects, or with IRI reference objects/particular terms SHOULD be used with literal objects, or SHOULD be used with IRI reference objects/ ---- 2.4.3.2 Literal values for non-literal resources in Darwin Core s/existing Darwin Core term in the dwc: namespace should have the same structure/existing Darwin Core term in the dwc: namespace SHOULD have the same structure/ ---- 2.5 Terms in the dwciri: namespace This is the companion case to 2.4.1.2 - is the distinction between dwciri and dwc to be asserted as SHOULD or MUST - using them incorrectly does have the "potential for causing harm" in the language of RFC 2119, but does the guide rise to the level of specifying an "absolute requirement of the specification". s/IRI reference objects and should NOT be used with literal/ IRI reference objects and MUST NOT be used with literal/ ---- 2.5.1 Definition of dwciri: terms s/resource described by a dwciri: property should be the subject of a triple for each value on the list/resource described by a dwciri: property SHOULD be the subject of a triple for each value on the list/ A counter example here comes from the Harvard List of Botanists, where http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/305dcac3-a748-4f47-8a18-… references the collector team "J. D. Hooker & A. Gray", that is, http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/cc3b7080-5fbb-4ea5-9655-… and http://purl.oclc.org/net/edu.harvard.huh/guid/uuid/3f8c70aa-1862-4784-8a53-… ---- 2.5.3 Expectation of clients encountering RDF containing dwc: and dwciri: terms Instances of "should" here again cut to the heart of how strong the guidance is concerning dwc and dwciri. ---- Table 3 s/they should be used rather than using the Darwin Core ID/they SHOULD be used rather than using the Darwin Core ID/ ---- Example 22: s/The following points about the Example 22 should be noted:/Note the following points about Example 22:/ s/related non-literal resources should use/related non-literal resources SHOULD use/ /LSIDs are the objects of triples, they should be As with 2.4.2.1.1, this guidance needs to be checked against the GUID and LSID applicability statements. I think I'm reading the GUID applicability statement as s/should/MUST/ here. ---- 2.7.1 What purpose do convenience terms serve? s/In general, it should not be necessary for a data provider/In general, a data provider does not need/ ---- 2.7.3 Ownership of a collection item s/of the collection item should be indicated/of the collection item SHOULD be indicated/ ---- 2.7.4 Description of a taxonomic entity s/It is considered to be out of the scope of this document to specify how taxon concepts should be rendered as RDF/It is out of the scope of this document to specify how to render taxon concepts as RDF/ s/terms for taxonomic entities should be properties of dwc:Identification/terms for taxonomic entities MAY be properties of dwc:Identification/ s/The task of describing taxonomic entities using RDF must be an effort outside of Darwin Core/The task of describing taxonomic entities using RDF is out of scope of this document/ ---- 2.8.3 Expressing Darwin Core association terms as RDF with URI references s/it should be used to declare the type/rdf:type SHOULD be used to declare the type/ ---- Tables 3.4 to 3.7. s/should/SHOULD/ -------- -- Paul J. Morris Biodiversity Informatics Manager Harvard University Herbaria/Museum of Comparative Zoölogy mole(a)morris.net AA3SD PGP public key available

5 16

errata in RDF guide
by Steve Baskauf 13 Dec '14

13 Dec '14

I was examining the definition of dwc:organismScope (http://rs.tdwg.org/dwc/terms/organismScope ) and noticed that its comment specifically says "To describe the kind of Organism using a URI object in RDF, use rdf:type ... instead." The Darwin Core RDF Guide includes dwc:organismScope in the category of terms having analogues in the dwciri: namespace (i.e. having an IRI-reference object). I believe that it should be removed from that list and placed in Table 3.8 [1] with an explanation that rdf:type should be used instead in accordance with the term comment. Steve Baskauf [1] https://code.google.com/p/tdwg-rdf/wiki/DwcRdfGuideProposalRevised#3.8_Darw… -- 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

2 1