Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] WebStatement and attributionURL

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: Jonas Öberg <jonas AT coyote.org>
  • Cc: "cc-devel AT lists.ibiblio.org" <cc-devel AT lists.ibiblio.org>
  • Subject: Re: [cc-devel] WebStatement and attributionURL
  • Date: Mon, 24 Jun 2013 15:03:58 -0700

The subject of both statements is the work. The only way to stay sane
is to check with the RDFa Distiller.

Maybe the formatting is unclear, but that's a critique of that example
(attribution URL should have copyright info for work in question;
author's home page unlikely it) and/or of HTML annotation/RDFa/RDFa
1.0/CC REL/take your pick.

The licensor can make whatever URL they want be the object of
attributionURL or WebStatement, but in terms of requesting attribution
for compliance with the license or for "verification", it needs to
provide copyright info valid for the work in question.

This can be pretty unclear in the case of something like
creativecommons.org/choose where what one gets is a generic bit of
markup that one might apply to a particular work, but one might just
put in a template. The only data I know of shows that many people
probably just copy the same URL into every available URL field, so
"correct" attributionURL (& co) are rare in practice, see
http://gondwanaland.com/mlog/2012/01/23/attribution-crawl/

CC recommending use of WebStatement in XMP preceeds attributionURL by
a few years. Former came about due to (entirely valid) concern that
embedded metadata has no provenance and is completely untrustworthy;
webstatement (& analogous for other file types) and "web verification"
meant to mitigate that. (I have no data, but personal anecdote, CC
file embedding recommendations almost never followed correctly, and
software consuming them, specifically LimeWire, just led to spamming
and making false/naive assertions in them; as was pointed out by
various people back then, and I specifically recall Lucas Gonze, CC
didn't help much as its embedding tools were mere prototypes; I didn't
really try to do anything about it due to lack of resources and
evaluation of task as sisyphean.)

Possibly should've recommended WebStatement for use in HTML-hosted
RDFa rather than making up attributionURL. I don't think the idea of
doing so came up, probably due to XMP being a weird thing that does
its best to ignore RDF and RDF people to ignore it, and lack of
imagination and inspiration to see past that.

Mike


On Fri, Jun 14, 2013 at 12:58 AM, Jonas Öberg <jonas AT coyote.org> wrote:
> Dan,
>
> apologies for my harsh comments yesterday -- I realize they were not helpful
> to advance the dialogue -- and I'd like to continue on a more positive note:
> you're right.
>
> The URL can indeed be whatever the author would like it to be. In order for
> the verification to work, that URL needs be something that includes the
> license RDFa and a SHA1 sum of the work. This seems to lend itself more
> towards thinking of the URL as referring to the work itself, however,
> there's nothing preventing an author -- and some might even chose this -- to
> list all the works on a single URL and use this URL as the attribution URL.
>
> I'd say associating the attributionURL with work is thus as wrong as
> associating it with attributionName: it can be either, or neither.
>
> It does seem useful to write this up and clarify though, but it needs not be
> part of the standard document itself but can be part of implementation
> guides, examples, etc. Where do you think it makes most sense to gather
> information like this -- suggestions for improvement s, clarifications, and
> guidance for people implementing it?
>
> Sincerely,
> Jonas
>
>
>
>
> On Thu, Jun 13, 2013 at 9:18 PM, Dan Mills <dan AT creativecommons.org> wrote:
>>
>> Sorry, maybe I missed something. Where does it say that? The links I found
>> (and quoted below) were pretty clear that the URL is whatever the author
>> would like it to be.
>>
>> Dan
>>
>> On Thursday, June 13, 2013 at 12:16 PM, Jonas Öberg wrote:
>>
>> Dan,
>>
>> I appreciate your input but respectfully disagree on this, since they
>> visually (if not semantically) associate the URL with the author, and not
>> the work (where the standard says it should refer to the work). However, it
>> doesn't feel as if we'll get much further in this discussion. :-)
>>
>> Jonas
>>
>>
>> On Thu, Jun 13, 2013 at 9:12 PM, Dan Mills <dan AT creativecommons.org>
>> wrote:
>>
>> Sure. Though those are just as valid, since the URL can really point to
>> anything.
>>
>> Dan
>>
>> On Thursday, June 13, 2013 at 12:10 PM, Jonas Öberg wrote:
>>
>> Dan,
>>
>> Yes, the only issue I see now is that the examples associate the URL with
>> the person, not the work. We do not need go change the semantics of the
>> standard, but we should rework some examples and use cases, as well as
>> clarify the intended use.
>>
>> Jonas
>>
>> On 13 Jun 2013 20:52, "Dan Mills" <dan AT creativecommons.org> wrote:
>>
>> Hi Jonas,
>>
>> I think that should already be possible, no?
>>
>> http://creativecommons.org/ns says that cc:attributionURL is:
>>
>> "The URL the creator of a Work would like used when attributing re-use."
>>
>> http://labs.creativecommons.org/2011/ccrel-guide/ says:
>>
>> "The attribution URL is important when you want to indicate what URL
>> re-users of your CC-licensed work should link to when they attribute your
>> work."
>>
>> It's whatever the author wants it to be, so it could be a link to the
>> work.
>>
>> Dan
>>
>> On Thursday, June 13, 2013 at 4:00 AM, Jonas Öberg wrote:
>>
>> Hi Maarten,
>>
>> I think it's reasonable to just clarify in the ccREL standard that the two
>> are synonymous.
>>
>> For the RDFa generated, I think that the attributionURL should be
>> associated with the work and not the author. Ie.,
>>
>> This <a xmlns:cc="http://creativecommons.org/ns#";
>> href="http://jonasoberg.net/this-work"; rel="cc:attributionURL">work</a> by
>> <span xmlns:cc="http://creativecommons.org/ns#";
>> property="cc:attributionName">Jonas Öberg</span>
>>
>> However, I don't think it's reasonable to make any changes to the chooser
>> output without at the same time revising the examples in the ccREL standard
>> document.
>>
>> So what I'm saying is that having a process for how we record "change
>> requests" to the standard and how the revision process look like is
>> probably
>> more important than correcting these specific issues.
>>
>>
>> Jonas
>>
>>
>>
>> On Thu, Jun 13, 2013 at 10:20 AM, Maarten Zeinstra <mz AT kl.nl> wrote:
>>
>> So Jonas what do you propose.
>>
>> Would it be better to adjust XMP output of the chooser?
>>
>> Cheers,
>>
>> Maarten
>> --
>> Kennisland | www.kennisland.nl | t +31205756720 | m +31643053919 |
>> @mzeinstra
>>
>>
>>
>>
>> On Jun 11, 2013, at 18:36 , Nathan Yergler <nathan AT yergler.net> wrote:
>>
>> > That's a great point, the formatting does conflate the creator and the
>> > work a bit.
>> >
>> > On Tue, Jun 11, 2013 at 9:11 AM, Jonas Öberg <jonas AT coyote.org> wrote:
>> >> Hi Nathan!
>> >>
>> >> I'd be hard pressed to argue semantics with one of the ccREL authors
>> >> :-)
>> >>
>> >> The specification is clear that attributionURL is "the URL to link to
>> >> when providing attribution", which is a reference to the license
>> >> requirement. I think what confuses it is that this is most often used,
>> >> even in the ccREL examples, to refer to what can be interpreted as the
>> >> URL of the attributionName. For example in the RDFa:
>> >>
>> >> This work by <a xmlns:cc="http://creativecommons.org/ns#";
>> >> href="http://jonasoberg.net/"; property="cc:attributionName"
>> >> rel="cc:attributionURL">Jonas Öberg</a> is licensed under a <a
>> >> rel="license"
>> >> href="http://creativecommons.org/licenses/by/3.0/deed.en_US";>Creative
>> >> Commons Attribution 3.0 Unported License</a>.
>> >>
>> >> Sincerely,
>> >> Jonas
>> >>
>> >>
>> >>
>> >> On Tue, Jun 11, 2013 at 5:31 PM, Nathan Yergler <nathan AT yergler.net>
>> >> wrote:
>> >>> How do you believe a web statement differs from the attribution URL,
>> >>> functionally?
>> >>>
>> >>> IIRC a "web statement" is supposed to be a web accessible resource
>> >>> that contains information about the rights, permissions, etc related
>> >>> to the work. CC licenses state that the attribution URL only needs to
>> >>> be cited with the work when it includes copyright information or
>> >>> license notice (4(b)(iii) in
>> >>> http://creativecommons.org/licenses/by/3.0/legalcode). So both need to
>> >>> be web-accessible resources that contain license, copyright, or rights
>> >>> information. I believe that was the basis for treating them as
>> >>> synonyms.
>> >>>
>> >>> NRY
>> >>>
>> >>>
>> >>> On Tue, Jun 11, 2013 at 7:19 AM, Jonas Öberg <jonas AT coyote.org> wrote:
>> >>>> Dear all,
>> >>>>
>> >>>> I was just made aware that in the license chooser, when a user enters
>> >>>> a URL to attribute the work to, this is stored in different
>> >>>> properties
>> >>>> in the XMP and RDFa formats. In XMP, it's stored in
>> >>>> xapRights:WebStatement and in RDFa it's stored in cc:attributionURL.
>> >>>> I
>> >>>> understand the difference between the two, but it's not clear to me
>> >>>> why there is a difference between how the information from the
>> >>>> license
>> >>>> chooser is encoded in the various formats.
>> >>>>
>> >>>> It seems to me that there ought to be a separate field that allows a
>> >>>> user to specify a WebStatement, and that the URL to attribute the
>> >>>> work
>> >>>> to should be encoded in the cc:attributionURL regardless of what
>> >>>> format is used.
>> >>>>
>> >>>> Any thoughts?
>> >>>>
>> >>>>
>> >>>> Sincerely,
>> >>>> Jonas
>> >>>> _______________________________________________
>> >>>> cc-devel mailing list
>> >>>> cc-devel AT lists.ibiblio.org
>> >>>> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>> > _______________________________________________
>> > cc-devel mailing list
>> > cc-devel AT lists.ibiblio.org
>> > http://lists.ibiblio.org/mailman/listinfo/cc-devel
>>
>>
>> _______________________________________________
>> cc-devel mailing list
>> cc-devel AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> cc-devel mailing list
> cc-devel AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>




Archive powered by MHonArc 2.6.24.

Top of Page