cd
cd copied to clipboard
tdwg
Property:license
| Label | License |
| Definition | A legal document giving official permission to do something with the resource. |
| Usage | A legal document giving official permission to do something with the collection description record. |
| Existing property | dc:license |
| Existing class | Rights (http://purl.org/dc/elements/1.1/rights), Rights (http://purl.org/dc/terms/rights) |
| Existing property identifier | http://purl.org/dc/terms/license |
| Format | Text |
| Required | Yes |
| Repeatable | No |
| Constraints | |
| Examples | https://creativecommons.org/licenses/by/4.0/, https://creativecommons.org/publicdomain/zero/1.0/, https://creativecommons.org/licenses/by/4.0/legalcode, https://opendatacommons.org/licenses/by/1.0/, http://unlicense.org/ |
| Notes | Recommended practice is to identify the license document with a URI. If this is not possible or feasible, a literal value that identifies the license may be provided. |
Does license refer to the collection description data or the license use for the data on the specimens themselves? I presume the latter, but it is not clear.
I had presumed the former, although possibly incorrectly. However it seemed a good principle to have a digital CDD object include license along with the other usage information. For related datasets like specimen records, I think it might be better practice for license info be held within those datasets' metadata rather than the CD record. Also potential for multiple related datasets per CD, so we'd probably need to revisit the current onlineResources and/or datasetDOIs properties, currently simple lists, with a view to expanding into a class. That having been said, we still need to figure out the best way to link CDs to individual specimen records in the model.
If the cd:license refers to the cd document itself, then every cd entry could have a different license, whereas I'm sure we would prefer that the whole cd repository would have one overall license. Any other option would be a nightmare for usage.
Might make sense to move this to CollectionDescriptionScheme, in that case?
| Definition | A legal document giving official permission to do something with the resource. |
| Dimension | |
| Existing property | dc:license |
| Existing class | Rights |
| Existing property identifier | http://purl.org/dc/terms/license |
| Format | |
| Required | |
| Repeatable | |
| Constraints | |
| Examples | https://creativecommons.org/licenses/by/4.0/, https://creativecommons.org/publicdomain/zero/1.0/, https://creativecommons.org/licenses/by/4.0/legalcode |
| Notes | Recommended practice is to identify the license document with a URI. If this is not possible or feasible, a literal value that identifies the license may be provided. |
In case we align with DC
@debpaul @mswoodburn Is License a Required field? Is a default license assumed?
@WUlate I'm not sure we can assume a default license as far as the standard goes... Would love to have a CC0 default and make it a required field to encourage the practice, but suspect it might be a bit restrictive for the standard, and the onus would need to go on each implementation of the standard instead?
The following licenses allow fully open reuse of metadata: • Public Domain Mark • Creative Commons Zero Public Domain Dedication • Open Data Commons Public Domain Dedication and license (PDDL)
The following licenses are also used but lead to “attribution stacking”, the need to keep track of a chain of attributions: • CC-BY • ODC Attribution • ISA Open Metadata licence 1.1 • Open Government licence
from: https://www.europeandataportal.eu/sites/default/files/d2.1.2_training_module_2.5_data_and_metadata_licensing_en_edp.pdf
It occurs to me that license is something that usually goes in the metadata to a resource, not in the resource itself. Having said that Darwin Core also embeds it at a record level, but it is also used at the dataset level in GBIF.
Each CD record is metadata on a collection and each collection of CD records will also have its own metadata.
@WUlate I'm not sure we can assume a default license as far as the standard goes... Would love to have a CC0 default and make it a required field to encourage the practice, but suspect it might be a bit restrictive for the standard, and the onus would need to go on each implementation of the standard instead?
So there is also the license on the standard itself, which I agree should be as open as possible.
Therefore, based upon where this is in the structure, it does appear to be a license at the record level and I suppose this might be useful if datasets with different licenses are combined.
I added this in the notes to try to clarify: "In this term, "resource" refers to "the Collections Description record", not the collection itself."
(If that's not wrong, and/or if changing the definition itself is better, all ears)
