{"action":"created","issue":{"url":"https://api.github.com/repos/JATS4R/elements/issues/8","labels_url":"https://api.github.com/repos/JATS4R/elements/issues/8/labels{/name}","comments_url":"https://api.github.com/repos/JATS4R/elements/issues/8/comments","events_url":"https://api.github.com/repos/JATS4R/elements/issues/8/events","html_url":"https://github.com/JATS4R/elements/issues/8","id":39386285,"number":8,"title":"Questions / concerns about Open Book Publishers permissions example","user":{"login":"Klortho","id":77226,"avatar_url":"https://avatars.githubusercontent.com/u/77226?v=3","gravatar_id":"","url":"https://api.github.com/users/Klortho","html_url":"https://github.com/Klortho","followers_url":"https://api.github.com/users/Klortho/followers","following_url":"https://api.github.com/users/Klortho/following{/other_user}","gists_url":"https://api.github.com/users/Klortho/gists{/gist_id}","starred_url":"https://api.github.com/users/Klortho/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Klortho/subscriptions","organizations_url":"https://api.github.com/users/Klortho/orgs","repos_url":"https://api.github.com/users/Klortho/repos","events_url":"https://api.github.com/users/Klortho/events{/privacy}","received_events_url":"https://api.github.com/users/Klortho/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/JATS4R/elements/labels/permissions","name":"permissions","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":22,"created_at":"2014-08-04T02:23:35Z","updated_at":"2015-01-26T03:10:49Z","closed_at":null,"body":"Questions / concerns about Open Book Publishers permissions example\r\n\r\n1. In many places, there are two \\<license> elements side-by-side, which is ambiguous (not machine-readable).  It would not clear to a machine whether it indicates a dual license, or two ways of calling out the same license.  After looking it over, it's clear what it means:  that the content is generally under the CC license, but that the document at the second URL has qualifications and caveats.\r\n\r\n2. In that \\<license> elements' xlink:href attribute, the URL \"http://www.openbookpublishers.com/isbn/9781783740178#copyrighttab\" appears.  This is not the canonical URI *identifier* of any license, but rather a URL link to a page that has the license documentation.  The link is broken, too: it seems that it has changed to this: http://www.openbookpublishers.com/product/233#copyright.  This is a good illustration of why only canonical, published, persistent URIs should be used in that attribute.\r\n\r\n3. So, for the first \\<permissions> element in that example, I would retag it something like this:\r\n\r\n      ```xml\r\n      <license license-type=\"open-access\"\r\n               xlink:href=\"http://creativecommons.org/licenses/by-nc-nd/4.0/\"/>\r\n        <license-p>This entire volume is published under a Creative Commons\r\n          Attribution-NonCommercial-NoDerivatives 4.0 ...\r\n          See permissions relating to individual images. Detailed information \r\n          is available at \r\n          <ext-link ext-link-type=\"uri\" \r\n            xlink:href=\"http://www.openbookpublishers.com/product/233#copyright\"\r\n              >http://www.openbookpublishers.com/product/233#copyright</ext-link>.</license-p>\r\n      </license>\r\n      ```\r\n\r\n4. Inside \\<fig id=\"fig1\">, there is this: \"\\<copyright-statement>The National Portrait Gallery, London. All rights reserved\\</copyright-statement>\".  Here, the \\<license> element, that has the same URL as the others. In order to have this machine-readable, do we need a canonical persistent URI that means \"all rights reserved\"?"},"comment":{"url":"https://api.github.com/repos/JATS4R/elements/issues/comments/71409861","html_url":"https://github.com/JATS4R/elements/issues/8#issuecomment-71409861","issue_url":"https://api.github.com/repos/JATS4R/elements/issues/8","id":71409861,"user":{"login":"Daniel-Mietchen","id":465923,"avatar_url":"https://avatars.githubusercontent.com/u/465923?v=3","gravatar_id":"","url":"https://api.github.com/users/Daniel-Mietchen","html_url":"https://github.com/Daniel-Mietchen","followers_url":"https://api.github.com/users/Daniel-Mietchen/followers","following_url":"https://api.github.com/users/Daniel-Mietchen/following{/other_user}","gists_url":"https://api.github.com/users/Daniel-Mietchen/gists{/gist_id}","starred_url":"https://api.github.com/users/Daniel-Mietchen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Daniel-Mietchen/subscriptions","organizations_url":"https://api.github.com/users/Daniel-Mietchen/orgs","repos_url":"https://api.github.com/users/Daniel-Mietchen/repos","events_url":"https://api.github.com/users/Daniel-Mietchen/events{/privacy}","received_events_url":"https://api.github.com/users/Daniel-Mietchen/received_events","type":"User","site_admin":false},"created_at":"2015-01-26T03:10:49Z","updated_at":"2015-01-26T03:10:49Z","body":"@Melissa37 Having a figure or subfigure non-compliant with CC BY is technically possible, but a CC BY journal doing so would cease to be one.\r\n\r\nOn a sidenote, composite figures in non-editable formats are a reuse barrier in and of themselves, even if openly licensed, because adapting them to different reuse scenarios (e.g. translation into another language) can be difficult and sometimes impossible, and there is always a quality loss when downscaling original images or adding label text or arrows in bitmap layers.\r\n"}}