Hi all, Since Matt is now working at CC we should really press for a follow up on https://github.com/creativecommons/creativecommons.org/pull/18
As long as this isn’t properly fixed we cannot say we have a truly three tiered model of human readable, lawyer readable en machine readable legal tools. As I read the conversation between Mike and Antoine I don’t see anything in the way of fixing this bug. @Matt is this on your radar? Cheers, Maarten -- Kennisland | www.kennisland.nl | t +31205756720 | m +31643053919 | @mzeinstra On 20 Mar 2014 at 20:29:18 , Antoine Isaac ([email protected]) wrote: OK! Thanks for the forward, Mike. Antoine On 3/20/14 5:50 PM, Mike Linksvayer wrote: > Hi Antoine, > > I'm mostly replying to get your reply to the list. You make a good case for > not changing the CC vocabulary, and that it makes sense to review what others > are doing to describe licenses and cooperate with them before making any > changes. > > That leaves the discrepancy you noted, which Maarten's pull request fixes, > nevermind quibbling about exactly where the annotation should go. Someone at > CC will have to accept or edit further and roll out. > > Mike > > > On Sat, Mar 15, 2014 at 3:31 PM, Antoine Isaac <[email protected] > <mailto:[email protected]>> wrote: > > Hi Mike, > > (please still replying with full quotes, my emails indeed cannot reach > cc-devel) > > Half-baked is useful! If you don't start it, chances are that it will never > be carried out... > > The idea of 'merging' cc:Notice and cc:Attribution is probably tempting. I do > not have the experience in licenses to judge, though. My own caveat would be > that keeping a fine grain may prove useful for interoperability reasons. > > I've looked at what the W3C-hosted ODRL initiative does in term of cc:Notice > and cc:attribution: > http://www.w3.org/community/__odrl/work/cc/#section-31 > <http://www.w3.org/community/odrl/work/cc/#section-31> > They seem to have kept the difference between the two notions (perhaps having > a clearer label for their odrl:attachPolicy resource). Even if ODRL would > focus on describing non-CC licenses, I'd say it would be good to keep a > parallel between what ODRL and CCrel respectively allow. > > I take your point that not many are using these machine-readable descriptions > of licenses. But in the semantic web / linked data domain, the issue of > assigning proper, precise license to data is becoming acknowledged as very > important. And in spite of CC's great contribution to homogeneization, we > still see new licenses or rights statements coming in. > Making sure that we have the right (and rightfully applied) frameworks to > describe, compare and exploit these rights statements will become important, > when people start exploiting varied sources in their applications. > That is probably something that my organization (Europeana) would find useful > one day. So I'm personally reluctant to removing details from existing > descriptions, which may turn out to be useful later. > > Cheers, > > Antoine > > On 3/14/14 8:22 PM, Mike Linksvayer wrote: > > On Fri, Mar 14, 2014 at 10:27 AM, Antoine Isaac <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > Hi Mike, all > > (I'm not sure this mail will reach cc-devel so please forward if needed!) > > > I'm quoting in full in case it doesn't. > > Some first two cents by a "semantic web expert"... > > > Thank you very much! No need for scare quotes, I was completely serious in > wanting feedback from experts. I only know enough to be misinformed. :) > > 1. If cc:Notice was a subclass of cc:Attribution, then it would be > semantically possible to remove cc:Attribution (because it's implied by the > presence of cc:Notice) but not cc:Notice (because it's not implied by the > presence of cc:Attribution). > > 2. I'm not sure I would recommend removing statements because there are > sub-class axioms. This is ok in principle, but in practice many data > consumers do not apply the sort of reasoning tools that would enable to find > the "implied" statements. I guess this is especially true for consumers of > CC(rel) data. So I would still recommend to keep all important statements > explicit in the RDF data and the corresponding mark-up. > > 3. I am raising points 1 and 2 just for the sake of the argument. Because in > fact with the current data it wouldn't work, from a formal perspective. The > resources cc:Notice and cc:Attribution are not represented as (RDFS/OWL) > classes in the data, they are 'instances'. > The statements are indeed of the form: > (i) aLicense cc:requires cc:Notice . > (ii) aLicense cc:requires cc:Attribution . > If one defines the axiom > cc:Notice rdfs:subClass cc:Attribution > Then it does not help to infer any additional statement from the statement > (i). > One would have to use more complex axioms, possibly even outside of basic > RDFS/OWL expressivity. > > > Ok, subclass idea was half-baked and wrong. Discard it, but the other half > would be to change the description of cc:Attribution to include retaining > notices. How cc:Notice is described would be irrelevant, for it would not be > used at all in describing any CC licenses.* There are no CC licenses > described as requiring only one of Notice or Attribution, and the concepts > are generally mingled in descriptions and understandings of the licenses, > including on the deed. There's no reason for both. The > description-of-a-license part of CCREL isn't intended to be precise, and > maybe it is too precise in this case, for no gain. > > Further half-baked, which might mean 1/4 or 3/4 or 0 or 1 or something else > depending on operation applied... > Mike > > * At one time CC published deeds and metadata for a few software licenses, > and those required only cc:Notice not cc:Attribution eg > http://web.archive.org/web/__20100904085343/http://__creativecommons.org/licenses/__MIT/rdf > > <http://web.archive.org/web/20100904085343/http://creativecommons.org/licenses/MIT/rdf> > but those now redirect to the relevant OSI and FSF pages and to my knowledge > nobody ever used the RDF license descriptions (actually you can almost say > that about the descriptions of CC licenses, except internally). Anyway > cc:Notice could sit there in the CC schema, and someone could figure out what > relationship to make between it and cc:Attribution and add that to the schema > if anyone really wanted to. > > > Kind regards > > Antoine > > > > On 3/14/14 5:03 PM, Mike Linksvayer wrote: > > On 03/14/2014 02:04 AM, Maarten Zeinstra wrote: > > Hi Mike, > > Putting the implications of CC-rel aside you agree that we need to modify > that document. > > If it were up to you where would you place that RDFa? You indicated that > putting it on top of “indicate if changes were made” is not ideal, I agree. > But it is the best possible place on the page as it is now, if you ask me. > Antoine and I also considered creating an empty span to communicate this RDF, > however according to Antoine (who know way more about this than I) search > engine consider them spam and might lower the ranking of CC’s pages. > > The ideal solution could be to change the explanation from: > > Attribution — You must give appropriate credit, provide a link to the > license, and indicate if changes were made. You may do so in any reasonable > manner, but not in any way that suggests the licensor endorses you or your > use. > > to > > Attribution — You must give appropriate credit, provide a link to the > license, and indicate if changes were made *while keeping any notices > intact*. You may do so in any reasonable manner, but not in any way that > suggests the licensor endorses you or your use. > > > and add the RDFa to the newly added words. That is however something that the > lawyers and community need to discuss. > > > Those added words would be the ideal place to add a cc:requires cc:Notice > annotation. I assume the current text was crafted very carefully, so I've no > opinion. Without the added words, maybe a span around "do so". > > Another option would be to remove the Notice statement from the RDF/XML as > well and change the schema such that cc:Notice is a subclass of > cc:Attribution. This would reflect how most people bundle the concepts, > including now on the deeds, and also outside CC -- some people call BSD and > MIT attribution licenses, though their only such requirement is to retain > copyright notices. I'd recommend getting more expert semweb feedback before > implementing this option. > > Mike > > > What do you guys think? > > > > Bottom line: as it stands now we provide two machine readable resources that > claim different requirements of the licenses, that needs to be fixed. > > Best, > > Maarten > -- > Kennisland > | www.kennisland.nl <http://www.kennisland.nl> <http://www.kennisland.nl> > <http://www.kennisland.nl/> | t +31205756720 <tel:%2B31205756720> > <tel:%2B31205756720> <tel://t%20+31205756720 <tel:%2B31205756720> > <tel:%2B31205756720>> | m +31643053919 <tel:%2B31643053919> > <tel:%2B31643053919> <tel://m%20+31643053919 <tel:%2B31643053919> > <tel:%2B31643053919>> | @mzeinstra > > > > On 14 Mar 2014 at 6:25:14 , Mike Linksvayer ([email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>) wrote: > > RDFa in the deed describes the corresponding license, and cc:Notice is a > cc:Requirement which is in the range of cc:requires which has a domain of > cc:License. A specific copyright notice would be pertinent to a licensed work > -- if this were called out with RDFa, perhaps dc:rights or another > refinement(s...there are potentially notices of copyright, license, > modification, warranty disclaimer) thereof, it'd go in the HTML published > with the licensed work. > > If I were writing an automatic remixing tool I'd go with "...it may be > reasonable to satisfy the conditions by providing a URI or hyperlink to a > resource that includes the required information." -- hyperlink to the > publisher's site, possibly including various notices in languages I can't > discern, and archive that page if you want to do something extra. You can't > count on anyone to properly annotate such notices anyway, so a tool that > looks for them can't be foolproof. You can pretty much count on them not > being properly annotated, as title and creator name usually aren't despite > being in the CC chooser forever. IANAL etc. > > Maarten is right that the cc:Notice annotation ought be added back to the > deed. I might not add it to the text concerning indication of modification as > notice isn't specific only to that, but that's very close to right. IMHO etc. > > > Mike > > > On Thu, Mar 13, 2014 at 12:12 AM, Tarmo Toikkanen <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>__> <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>__>__>> wrote: > > As the 4.0 license allows for licensees to specify a custom copyright notice, > which reusers must retain in any reproductions and redistributions, would the > new cc:Notice tag actually contain this custom copyright notice, or is it for > something else? > > I for one would like to see the copyright notice be part of the license RDFa, > since it’s unrealistic to expect reusers to retain information that can only > be found by visually browsing the publisher’s site, and trying to locate such > information (possibly in a foreign language, even). > > -- > Tarmo Toikkanen > [email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > http://tarmo.fi > > On Thursday 13. 03 2014 at 1.30, Maarten Zeinstra wrote: > > Hi all, > > Recently I’ve been working with Antoine Isaac (in cc) from Europeana on the > machine readability of the deed pages of the 4.0 licenses. Antoine noticed > that the RDF attached to the attribution license (and all other licenses) was > not in sync with the separate RDF file. > > Compare: > > the RDFa of http://creativecommons.org/____licenses/by/4.0/ > <http://creativecommons.org/__licenses/by/4.0/> > <http://creativecommons.org/__licenses/by/4.0/ > <http://creativecommons.org/licenses/by/4.0/>> (using > http://www.w3.org/2012/pyRdfa/____extract?uri=http%3A%2F%____2Fcreativecommons.org%____2Flicenses%2Fby%2F4.0%2F&____format=turtle&rdfagraph=____output&vocab_expansion=false&____rdfa_lite=false&embedded_rdf=____true&space_preserve=true&____vocab_cache=true&vocab_cache_____report=false&vocab_cache_____refresh=false > > <http://www.w3.org/2012/pyRdfa/__extract?uri=http%3A%2F%__2Fcreativecommons.org%__2Flicenses%2Fby%2F4.0%2F&__format=turtle&rdfagraph=__output&vocab_expansion=false&__rdfa_lite=false&embedded_rdf=__true&space_preserve=true&__vocab_cache=true&vocab_cache___report=false&vocab_cache___refresh=false> > > <http://www.w3.org/2012/__pyRdfa/extract?uri=http%3A%2F%__2Fcreativecommons.org%__2Flicenses%2Fby%2F4.0%2F&__format=turtle&rdfagraph=__output&vocab_expansion=false&__rdfa_lite=false&embedded_rdf=__true&space_preserve=true&__vocab_cache=true&vocab_cache___report=false&vocab_cache___refresh=false > > <http://www.w3.org/2012/pyRdfa/extract?uri=http%3A%2F%2Fcreativecommons.org%2Flicenses%2Fby%2F4.0%2F&format=turtle&rdfagraph=output&vocab_expansion=false&rdfa_lite=false&embedded_rdf=true&space_preserve=true&vocab_cache=true&vocab_cache_report=false&vocab_cache_refresh=false>>) > > to > http://creativecommons.org/____licenses/by/4.0/rdf > <http://creativecommons.org/__licenses/by/4.0/rdf> > <http://creativecommons.org/__licenses/by/4.0/rdf > <http://creativecommons.org/licenses/by/4.0/rdf>> > > > The latter has a cc:requires cc:Notice which is missing in the former. > > The consequence of this is that machine readers could get confused because > there are contradicting sources. Also software based on this standard could > produce wrong information. > > To fix this problem we propose to move the the rdfa of cc:Attribution and add > a cc:Notice RDFa tag. We’ve created a pull request that details this change > here: https://github.com/____creativecommons/____creativecommons.org/pull/18 > <https://github.com/__creativecommons/__creativecommons.org/pull/18> > <https://github.com/__creativecommons/__creativecommons.org/pull/18 > <https://github.com/creativecommons/creativecommons.org/pull/18>> > > > What do you guys think of this change request? Did we overlook something and > is this the most elegant way to fix this problem? > > Many thanks to Antoine for pointing this out and working on a fix with me. > > Cheers, > > Maarten > > -- > Kennisland > | www.kennisland.nl <http://www.kennisland.nl> <http://www.kennisland.nl> > <http://www.kennisland.nl/> | t +31205756720 <tel:%2B31205756720> > <tel:%2B31205756720> | m +31643053919 <tel:%2B31643053919> > <tel:%2B31643053919> | @mzeinstra > ___________________________________________________ > cc-devel mailing list > [email protected] <mailto:[email protected]> > <mailto:cc-devel@lists.__ibiblio.org <mailto:[email protected]>> > <mailto:cc-devel@lists. <mailto:cc-devel@lists.>__ibibl__io.org > <http://ibiblio.org> <mailto:cc-devel@lists.__ibiblio.org > <mailto:[email protected]>>> > http://lists.ibiblio.org/____mailman/listinfo/cc-devel > <http://lists.ibiblio.org/__mailman/listinfo/cc-devel> > <http://lists.ibiblio.org/__mailman/listinfo/cc-devel > <http://lists.ibiblio.org/mailman/listinfo/cc-devel>> > > > > ___________________________________________________ > cc-devel mailing list > [email protected] <mailto:[email protected]> > <mailto:cc-devel@lists.__ibiblio.org <mailto:[email protected]>> > <mailto:cc-devel@lists. <mailto:cc-devel@lists.>__ibibl__io.org > <http://ibiblio.org> <mailto:cc-devel@lists.__ibiblio.org > <mailto:[email protected]>>> > http://lists.ibiblio.org/____mailman/listinfo/cc-devel > <http://lists.ibiblio.org/__mailman/listinfo/cc-devel> > <http://lists.ibiblio.org/__mailman/listinfo/cc-devel > <http://lists.ibiblio.org/mailman/listinfo/cc-devel>> > > > > >
_______________________________________________ cc-devel mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/cc-devel
