<div dir="ltr">I understand. The recommendation is clear and concise, which is good at least. I hope the number affected will be few.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 9:54 AM, Kyle Braak <span dir="ltr"><<a href="mailto:kbraak@gbif.org" target="_blank">kbraak@gbif.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi John, Paul,</div><div><br></div><div>Reporting back.. </div><div><br></div><div>I did some investigation into what DataCite intends a list of rights to be used for. </div><div><br></div><div>The DataCite Metadata Working Group has explained that a list of rights is intended to support applying multiple licenses that apply to the dataset as a whole. Here’s the answer provided to me on behalf of their chair:</div><div><br></div><div><div style="word-wrap:break-word"><div style="word-wrap:break-word"><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div><div style="margin:0in 0in 0.0001pt;font-family:'Times New Roman',serif;font-size:12pt"><span style="font-family:Calibri,sans-serif;font-size:11pt">the Metadata Working Group has discussed your question and would like to say that the intension was (a) to allow for multiple licenses to be applied to a dataset. Moreover, </span><span style="font-family:Calibri,sans-serif;font-size:11pt">we suggest that if different licenses apply to separable components of a dataset, those (various) components ought to have separate metadata records (and so also separate DOIs).</span></div></div></div></blockquote><br></div><div style="word-wrap:break-word">From the DataCite mailing list, I’m told datasets with multiple licenses are pretty common. For example, OpenAIRE applies multiple <i>complementary</i> licenses to their datasets sometimes [1]. </div><div style="word-wrap:break-word"><br></div><div style="word-wrap:break-word">As for EML, we did an investigation last year into how it allows licenses to be expressed for datasets. We did discover the license [2] and licenseURL fields, however, they relate to software not datasets. The EML mailing list was consulted for guidance on this topic with no answer ever received unfortunately [3]. Furthermore, EML documentation includes no guidance for applying multiple licenses to a dataset (or its components) as far as I can see. </div><div style="word-wrap:break-word"><br></div><div style="word-wrap:break-word">Nevertheless, EML does allow one free-text intellectualRights [4] element per dataset and this is where GBIF expresses a license in its own metadata profile (based on EML).  To make the license machine readable/parseable, what we do is use the ulink [5] element inside the intellectualRights to store the license and license URL separately. Since we need to enforce the GBIF licensing Policy [6], we only allow a single license to be expressed though. </div><div style="word-wrap:break-word"><br></div><div style="word-wrap:break-word">To sum up, it’s great we now have a clear recommendation from DataCite on how to apply licenses to datasets. To better integrate with DataCite we will benefit from adopting recommendations in line with theirs. </div><div style="word-wrap:break-word"><br></div><div style="word-wrap:break-word">With kind regards,</div><div style="word-wrap:break-word"><br></div><div style="word-wrap:break-word">Kyle</div><div style="word-wrap:break-word"><br></div><div style="word-wrap:break-word">[1] <a href="https://guidelines.openaire.eu/wiki/OpenAIRE_Guidelines:_For_Data_Archives#Access_rights_and_license_information" target="_blank">https://guidelines.openaire.eu/wiki/OpenAIRE_Guidelines:_For_Data_Archives#Access_rights_and_license_information</a></div><div style="word-wrap:break-word">[2] <a href="https://knb.ecoinformatics.org/#external//emlparser/docs/eml-2.1.1/./eml-software.html%23license" target="_blank">https://knb.ecoinformatics.org/#external//emlparser/docs/eml-2.1.1/./eml-software.html#license</a></div><div style="word-wrap:break-word">[3] <a href="https://github.com/peterdesmet/awesome-metadata/issues/2#issuecomment-62885616" target="_blank">https://github.com/peterdesmet/awesome-metadata/issues/2#issuecomment-62885616</a></div><div style="word-wrap:break-word">[4] <a href="https://knb.ecoinformatics.org/#external//emlparser/docs/eml-2.1.1/./eml-resource.html%23intellectualRights" target="_blank">https://knb.ecoinformatics.org/#external//emlparser/docs/eml-2.1.1/./eml-resource.html#intellectualRights</a></div><div style="word-wrap:break-word">[5] <a href="https://knb.ecoinformatics.org/#external//emlparser/docs/eml-2.1.1/./eml-text.html%23ulink" target="_blank">https://knb.ecoinformatics.org/#external//emlparser/docs/eml-2.1.1/./eml-text.html#ulink</a></div><div style="word-wrap:break-word">[6] <a href="http://www.gbif.org/terms/licences" target="_blank">http://www.gbif.org/terms/licences</a></div><div style="word-wrap:break-word"><br></div></div></div><div><div class="h5"><div><div>On 04 Mar 2015, at 07:01, John Wieczorek <<a href="mailto:tuco@berkeley.edu" target="_blank">tuco@berkeley.edu</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">With the latter, I agree. Looking forward to the outcome of the first item. And thanks, Paul, for realizing this and bringing it forward to everyone's attention.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 3, 2015 at 3:30 PM, Tim Robertson <span dir="ltr"><<a href="mailto:trobertson@gbif.org" target="_blank">trobertson@gbif.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, 3 Mar 2015 18:55:35 +0100<br>Tim Robertson <<a href="mailto:trobertson@gbif.org" target="_blank">trobertson@gbif.org</a>> wrote:<br><blockquote type="cite">Thanks Paul and Tuco for the feedback - useful food for thought and I<br>note that the DataCite metadata kernel also uses a list for rights,<br>not a single statement.  Allowing a collection of rights might be the<br>most applicable solution here.<br></blockquote><br>That still leaves uncertainty, does the list CC-BY, CC-BY-NC mean that<br>the data set in it's entirety is licensed under both CC-BY and<br>CC-BY-NC, or that there are parts under one license and parts under the<br>other.  At the data set level, collection of rights statements could<br>easily be interpreted differently than a statement that rights are<br>stated at the record level.<span> </span><br></div></blockquote><div><br></div></span><div>Agreed.  We need to understand how this will relate to DataCite, EML etc and other networks we need to integrate with.</div><div>I am not yet sure if DataCite intends to use it to indicate dual licensing (e.g. it can be used in either license) or if it indicates variance.  </div><div>This needs further investigation and we’ll reply.</div><span><br><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite">A point of clarity though - an image extension allows you to provide<br>metadata about an image that exists on a URL, but the image itself is<br>not part of the DwC-A / dataset.  One field of the image metadata is<br>the license applicable for the image but that should not be<br>transferred to the dataset being put out by the IPT.  Or are we not<br>in agreement on that?  E.g. the DwC-A can be available under CC0 but<br>contain links to online images that could be behind some far more<br>restrictive license.<br></blockquote><br>This does seem fairly clear in an AudobonCore or other media extension<br>where metadata about the rights associated with external media objects<br>are being asserted in the metadata in association with the retrieval<br>locations of those media objects are being asserted.   It seems less<br>clear if dwc:associatedMedia is present in a flat Occurrence record, is<br>an assertion about the rights made in the dataset level metadata to be<br>taken to extend to the digital object at the other end of a link found<br>in dwc:associatedMedia?   <br></div></blockquote><div><br></div></span><div>That is one of the common questions - we always advise folk to use a more expressive model (i.e. extensions) where it is necessary to associate titles, rights statements etc.</div><div><br></div><div>More tomorrow.</div><span><font color="#888888">Tim</font></span><div><div><div><br></div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite">Thanks,<br>Tim<br><br><br><br><br><br>On 03 Mar 2015, at 17:13, John Wieczorek <<a href="mailto:tuco@berkeley.edu" target="_blank">tuco@berkeley.edu</a>> wrote:<br><br><blockquote type="cite">I agree. This is particularly problematic in a resource that<br>includes a media extension, where the rights of the core records<br>may well differ from that of the media, and where the rights on<br>individual media vary within the extension. I think creates an<br>unacceptable barrier. Instead, could the IPT allow a set of rights<br>at the dataset level or validate for rights at the record level?<br><br>On Tue, Mar 3, 2015 at 12:12 PM, Paul J. Morris <<a href="mailto:mole@morris.net" target="_blank">mole@morris.net</a>><br>wrote: On Tue, 3 Mar 2015 13:18:35 +0100<br>Kyle Braak <<a href="mailto:kbraak@gbif.org" target="_blank">kbraak@gbif.org</a>> wrote:<br><blockquote type="cite">Best practice is that the license applied to the dataset should<br>not contradict the license(s) applied at the record level.<br></blockquote><br>I think this imposes a requirement that the dataset level metadata<br>can have a value which indicates that rights are described at the<br>record level rather than at the dataset level.  Otherwise, it<br>imposes a requirement on data providers that they create a unique<br>resource for each separate rights statement, this will be a problem<br>for any provider who has more than one rights assertion in their<br>data, and for intermediate aggregators who are combining data sets<br>from downstream profiders and passing them on to other aggregators<br>upstream.<br><br>-Paul<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" target="_blank">mole@morris.net</a>  AA3SD  PGP public key available<br>_______________________________________________<br>IPT mailing list<br><a href="mailto:IPT@lists.gbif.org" target="_blank">IPT@lists.gbif.org</a><br><a href="http://lists.gbif.org/mailman/listinfo/ipt" target="_blank">http://lists.gbif.org/mailman/listinfo/ipt</a><br><br>_______________________________________________<br>IPT mailing list<br><a href="mailto:IPT@lists.gbif.org" target="_blank">IPT@lists.gbif.org</a><br><a href="http://lists.gbif.org/mailman/listinfo/ipt" target="_blank">http://lists.gbif.org/mailman/listinfo/ipt</a><br></blockquote><br></blockquote><br><br>--<span> </span><br>Paul J. Morris<br>Biodiversity Informatics Manager<br>Harvard University Herbaria/Museum of Comparative Zoölogy<br><a href="mailto:mole@morris.net" target="_blank">mole@morris.net</a><span> </span> AA3SD  PGP public key available</div></blockquote></div></div></div><br></div></blockquote></div><br></div>
_______________________________________________<br>IPT mailing list<br><a href="mailto:IPT@lists.gbif.org" target="_blank">IPT@lists.gbif.org</a><br><a href="http://lists.gbif.org/mailman/listinfo/ipt" target="_blank">http://lists.gbif.org/mailman/listinfo/ipt</a><br></blockquote></div><br></div></div></div></blockquote></div><br></div>