On Sat, 7 May 2005, Paul Hoffman wrote:
> At 6:29 PM -0400 5/7/05, Robin Cover wrote:
> >The publication of a new Implementation Guideline by the
> >Open Archives Initiative (OAI) compels me to suggest once
> >again [1], as Norm Walsh [2], Bob Wyman [3], and others have
> >done before, that the name 'atom:rights' would be better
> >than the (current) element name 'atom:copyright'.
>
> As before, -1. In fact, I would prefer to remove atom:copyright from
> the core before we make a post-last-call move to substitute a
> less-defined element such as atom:rights.
>
> >Since this element name change is not likely to have any
> >secondary ramifications that would affect other areas of
> >the format design, it should be harmless.
>
> Fully disagree. Later, you suggested that the renamed element would
> have a URI that pointed to the rights asserted by the author. That
> has a *lot* of effects, including the need for someone to resolve
> that URI before republishing the content in another feed, and storing
> the resolution of that URI with a copy of the contents (so that that
> author can't change the contents and then come after you). That is
> far from harmless.
I distinguished between minimal and optimal: minimally, I simply asked
for 'atom:rights' in place of 'atom:copyright'. How is that harmful
(other than to existing implementations that people don't want to
change)?
As I envisioned both the minimal and optimal encoding, a user is
not under any obligation to read (parse out) the meaning of the
"human-readable, free-text blob" of textual content in the
'atom:copyright' element -- or did I miss some Atom statement about
compliance? My understanding is that users of Atom feeds/entries
are at liberty to either consult or ignore the free-text blob --
not required to behave in some particular way in relation to some
copyright claim that may or may not be stated coherently in
<copyright>...</copyright>
Certainly, in the case of any (I said, "optional") URI reference,
which would be part of an optimal solution but not required by
the minimal element name change: I do not envision any *need* for
anyone to resolve any URI. Its intent would be to provide a
mechanism for unambiguous reference ONLY for parties that wished
to use this mechanism for resource discovery and other purposes.
>
> > Using the element
> >name 'atom:rights', as argued below, could enhance
> >interoperability
>
> Sorry, I didn't see anything in the rest of the post that showed how
> this could increase interop. Please be specific here. To me, you
> can't get much more interoperable than an unstructured,
> human-readable, free-text blob such as atom:copyright.
OK, "interoperability" may not have been the best term. I mean
interoperability in terms of programs that look for a particular
kind of factoid in some predictable place. The alternative is
a hundred and one kinds of adhockery thrown into the free-text blob;
a URI reference would be generically "see also, if you care to",
but also "the license is here, for users that want to fetch
licenses, that's what you'll see if you dereference the URI."
> > and avoid some unforeseen and unintended
> >legal implications that may emerge from use of the term
> >("copyright").
>
> Legal FUD doesn't help here. The current atom:copyright entry has no
> properties different than allowing someone to type in whatever
> human-readable copyright notice they want in an HTML document. If
> someone is comfortable with asserting a copyright, they can; if
> they're not, they don't have to.
No legal FUD intended: I think it's common consensus that the
word "copyright" is a legal term related to intellectual property
law. The term "rights" is not because it can mean moral rights,
civil rights, etc. etc. The term "rights" certainly can subsume
"copyright," and so, this makes sense:
<rights>Copyright (c) 2003, Mark Pilgrim</rights>
However, I ask you, does this make sense:
<copyright>The corporate entity that owns this Atom document as
its intellectual property does not wish to be identified by name,
but I, although not the owner, certify that I am empowered to
declare that you may legally display the text in your browser,
and print it on paper, and display it on any website under your
control, provided that you are an employee of a company having
fewer than 20 employees as of 2005-05-03.</copyright>
It's a silly example, intended to remind that declarations about
rights may be of greater interest with respect to the particular
uses and and particular users of information -- none of which is
(as I understand copyright law and practice) covered by "copyright"
law per se. But of course, IANAL.
>
> >Something non-legal,
> >like 'rightsDescription="URI"'.
>
> Please explain how "rightsDescription" is "non-legal" while
> "copyright" is legal. Seriously, I don't see how they can be
> differentiated. If you claim particular rights, that's a legal
> assertion of the same strength as claiming a copyright.
I only meant that "copyright" is a legal term, and that
"rightsDescription" is not inherently a legal term, because it
could be used of many kinds of rights that are not "legal."
To make the point clearer (WRT this optional attribute
name, hypothetical, only on the optimum solution), the
label could be 'seeAlso'
as in seeAlso="http://example.com/myStuff";
> cat myStuff
<html><head><title>MyStuff Plea for Funding</title></head>
<body><p>I worked on this a ong time, so if you use it
in some public setting, please contribute to my PayPal
account #9586956, but if you're poor, that's OK, just
use it for free.</p></body></html>
> >I predict that if the Atom spec does not make this
> >kind of accommodation to support this widely attested
> >requirement, multiple (incompatible) ad hoc solutions
> >will be invented, alongside widespread "abuse" of the
> >'atom:copyright' element. Surely, "multiple (incompatible)
> >ad hoc solutions will be invented" ANYWAY, but providing
> >the basic markup construct in the Atom syntax spec would
> >point users in the right direction, rather than leaving
> >them directionless.
>
> This goes back to the question of what goes into the core and what is
> done as an extension. I would strongly support the latter because, as
> you posit, people will disagree on how they should be able to assert
> rights. Coming up with a single extension structure that will keep
> everyone happy will take a lot of wrangling, but the effort would
> probably be worth it.
The "optimal" solution that's usef by OAI and DCMI, but also
by many others, is actually quite simple, because it's not
intended to be used for enforcement; there's no need to
agree on how to assert rights, in detail: just point to the
resource via a URI.
I think this is why, irrespective of Atom designers' attempts
to stop this, people will invent a lot of solutions that use
URIs, as in (John Panzer)
http://www.imc.org/atom-syntax/mail-archive/msg13901.html
<q>
<link rel="license" class="moz-txt-link-rfc2396E"
href="http://creativecommons.org/licenses/by/2.0/";>
"http://creativecommons.org/licenses/by/2.0/"; />
</q>
I don't know if 'license' is registered yet, but this will probably be
one of the cleaner solutions, amongst many dirty ones, most of
which ignore the proposed single extension structure.
Thanks for your feedback.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
--
