<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Tue, 3 Mar 2015 18:55:35 +0100<br>Tim Robertson <<a href="mailto:trobertson@gbif.org">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 class="Apple-converted-space"> </span><br></div></blockquote><div><br></div><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><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 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><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><div>Tim</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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 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">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">mole@morris.net</a>><br>wrote: On Tue, 3 Mar 2015 13:18:35 +0100<br>Kyle Braak <<a href="mailto:kbraak@gbif.org">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">mole@morris.net</a>  AA3SD  PGP public key available<br>_______________________________________________<br>IPT mailing list<br><a href="mailto:IPT@lists.gbif.org">IPT@lists.gbif.org</a><br>http://lists.gbif.org/mailman/listinfo/ipt<br><br>_______________________________________________<br>IPT mailing list<br>IPT@lists.gbif.org<br>http://lists.gbif.org/mailman/listinfo/ipt<br></blockquote><br></blockquote><br><br>--<span class="Apple-converted-space"> </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">mole@morris.net</a><span class="Apple-converted-space"> </span> AA3SD  PGP public key available</div></blockquote></div><br></body></html>