Closed peterdesmet closed 1 year ago
Affected values:
# samplingDesign
simple random → simpleRandom
systematic random → systematicRandom
clustered random → clusteredRandom
# captureMethod
motion detection → motionDetection
time lapse → timeLapse
# featureType
road paved → roadPaved
road dirt → roadDirt
trail hiking → trailHiking
trail game → trailGame
road underpass → roadUnderpass
road overpass → roadOverpass
road bridge → roadBridge
nest site → nestSite
water source → waterSource
fruiting tree → fruitingTree
# roles
rightsholder → rightsHolder
principal investigator → principalInvestigator
Note: 2 borrowed terms (relationType and resourceTypeGeneral) also borrow their controlled vocabulary which has UpperCamelCase
values. I would leave those as is.
This pattern has been followed pretty consistently as new controlled vocabularies have been created. There are a few exceptions in cases: -where there were existing suggested values that we didn't want to break
Just for full disclosure, there was never any formal decision by the TAG or any other group that established this pattern. I suggested it when the first controlled vocabularies were created in DwC (establishmentMeans, pathway, and degreeOfEstablishment) as a way to reduce the number of possible variants that people could dream up and as a way to clearly distinguish between labels (non-normative and potentially multilingual) and controlled values (normative and invariant among languages). So it's become established as a pattern for controlled value stings in subsequent controlled vocabularies since then. I think that there is value in maintaining these patterns so that the required values are what people have come to expect if they've had experiences with other vocabularies.
Thanks @baskaufs, I suggest we adopt the same pattern (lowerCamelCase
) in Camtrap DP then. @kbubnicki @ben-norton others, any objections?
No objections from my side, full support!
In https://github.com/tdwg/dwc-qa/issues/169#issuecomment-764738530 @baskaufs writes:
In Camtrap DP we currently use
lower case
values with spaces for controlled vocabularies (defined inenum
properties). Should we aim to use camelCase here too (before releasing v1.0)? Our term names are already in camel case. The change would only affect controlled values with more than one word, single words would remain the same.