Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] Missing machine readable notice statement in all CC4.0 licenses

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: Mike Linksvayer <ml AT gondwanaland.com>
  • To: Antoine Isaac <aisaac AT few.vu.nl>
  • Cc: "cc-devel AT lists.ibiblio.org devel" <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] Missing machine readable notice statement in all CC4.0 licenses
  • Date: Fri, 14 Mar 2014 12:22:14 -0700

On Fri, Mar 14, 2014 at 10:27 AM, Antoine Isaac <aisaac AT few.vu.nl> 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 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/> | t +31205756720 <tel://t%20+31205756720> | m +31643053919 <tel://m%20+31643053919> | @mzeinstra


On 14 Mar 2014 at 6:25:14 , Mike Linksvayer (ml AT gondwanaland.com <mailto:ml AT gondwanaland.com>) 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 <tarmo.toikkanen AT iki.fi <mailto:tarmo.toikkanen AT iki.fi>> 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
    tarmo AT iki.fi <mailto:tarmo AT iki.fi>

    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/ (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)
    to
    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

    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/> | t +31205756720 | m +31643053919 | @mzeinstra
    _______________________________________________
    cc-devel mailing list
    cc-devel AT lists.ibiblio.org <mailto:cc-devel@lists.ibiblio.org>
    http://lists.ibiblio.org/mailman/listinfo/cc-devel


    _______________________________________________
    cc-devel mailing list
    cc-devel AT lists.ibiblio.org <mailto:cc-devel@lists.ibiblio.org>
    http://lists.ibiblio.org/mailman/listinfo/cc-devel







Archive powered by MHonArc 2.6.24.

Top of Page