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.
Thanks for the forward, Mike.
Post by Mike LinksvayerHi 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
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.
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
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'.
(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
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.
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
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
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
tarmo at iki.fi <mailto:tarmo at iki.fi> <mailto:tarmo at iki.fi <mailto:tarmo at iki.fi>> <mailto:tarmo at iki.fi <mailto:tarmo at iki.fi> <mailto:tarmo at iki.fi <mailto:tarmo at iki.fi>>>
http://tarmo.fi
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.
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
___________________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org <mailto:cc-devel at lists.ibiblio.org> <mailto:cc-devel at lists.__ibiblio.org <mailto:cc-devel at lists.ibiblio.org>> <mailto:cc-devel at lists. <mailto:cc-devel at lists.>__ibibl__io.org <http://ibiblio.org> <mailto:cc-devel at lists.__ibiblio.org <mailto:cc-devel at lists.ibiblio.org>>>
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
cc-devel at lists.ibiblio.org <mailto:cc-devel at lists.ibiblio.org> <mailto:cc-devel at lists.__ibiblio.org <mailto:cc-devel at lists.ibiblio.org>> <mailto:cc-devel at lists. <mailto:cc-devel at lists.>__ibibl__io.org <http://ibiblio.org> <mailto:cc-devel at lists.__ibiblio.org <mailto:cc-devel at lists.ibiblio.org>>>
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>>
An HTML attachment was scrubbed...
URL: <http://lists.ibiblio.org/pipermail/cc-devel/attachments/20140417/65dd6e19/attachment-0001.html>