Subject: Does atom:author apply to document pointed by atom:link@rel=alternate?

From: "Teo Hui Ming" <[email-masked]>
Date: Tue, 31 Jul 2007 10:34:39 +0800

Here's a scenario:

Bob wrote an article, and published it as an Atom document.

Alice published a translation of the article, and Bob wish to include
a link in his Atom document to point to Alice's translation.

<entry>
  <title>The Article Title</title>
  <link rel="alternate" hreflang="fr" href="http://example.org/123" />
  <author><name>Bob</name></author>
  <content> .. (content) .. </content>
</entry>

The question is, when the link is added (as above), does it imply that
Bob owns the translated document? (which is not true, in this case)

----
This raises a more general question: how does metadata like
    * authorship: <contributor>, <author>
    * rights: <rights>
    * licensing: <link rel="license"> (in RFC4946)

apply to documents pointed by <link rel=""> and <content src=""> ?

IMHO, the assumption is, when these metadata appear in an Atom
document, they apply to the data in that document, and do not apply to
other documents pointed by atom:link.

In other words, I assume atom:link is "normal link" [1] and authors
have freedom to link to any document on Web.

But, what about atom:content@src ?

[1] http://www.w3.org/DesignIssues/LinkLaw.html#Normal

----
I strongly feel that it's important to make this clear to avoid
confusion and uncertainly.

For example:
Quoted from http://www.imc.org/atom-syntax/mail-archive/msg19607.html
>
> Linking to the RFC as an alternate representation of the entry suggests
> that the entry and the RFC issue from the same source. (ie. if the
> entry appears in a feed that lists me as an author it implies that
> RFC4287 was written by me)

Thanks,
-- 
Teo Hui Ming

---

From: Eric Scheid <[email-masked]>
Date: Tue, 31 Jul 2007 13:54:44 +1000

On 31/7/07 12:34 PM, "Teo Hui Ming" <[email-masked]> wrote:

>>   <title>The Atom Syndication Format</title>
>>   <summary>An alternative to RSS2.</summary>
>>   <link href="http://www.ietf.org/rfc/rfc4287"/>
>>   <category term="rfc"/>
>> </entry>
>>
>> RFC4287 was written by me) -- Brendan Taylor

The author of that entry is Brendan. The author of the referenced document
is [whoever] ... but the conflict can be resolved if Brendan avoids linking
to the RFC as an "alternate" of his bookmark. It's not an alternate
representation of his bookmark, it's the full thing.

It's like if I wrote an essay on Shakespeare's "Romeo et Juliet" ... my
essay is not an alternate to the play, and vice versa, so there is no
conflict regarding which author to put on my entry.

So, don't use rel="alternate" (or the null expression which defaults to the
same value). Use some other relationship ... However, rel="related" doesn't
really communicate the relationship between the reference and the referent,
so I'm tempted to propose a new relationship. rel="referent" seems
appropriate.

Thus, we get:

> <entry>
>   <title>The Atom Syndication Format</title>
>   <summary>An alternative to RSS2.</summary>
>   <link rel="referent" href="http://www.ietf.org/rfc/rfc4287"/>
>   <category term="rfc"/>
>   <author><name>Brendan Taylor</name></author>
> </entry>

> a link in his Atom document to point to Alice's translation.

Bob would put his name into the entry he authored, but not because he wrote
the original article. If a third party (Charles) were to write an entry
linking to Bob's article or Alice's translation, then Charles would be the
author.

BTW, the "author" of Alice's translation would properly still be Bob, but
Alice would qualify as a "contributor".

e.

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Jul 2007 22:15:31 -0700

> so I'm tempted to propose a new relationship. rel="referent" seems

How about rel="bookmark"?

(http://microformats.org/wiki/rel-bookmark)

---

From: Eric Scheid <[email-masked]>
Date: Tue, 31 Jul 2007 15:16:17 +1000

> (http://microformats.org/wiki/rel-bookmark)

First reaction: "D'oh! of course."

but ... on reading the referenced documentation ... hmmm ... is the
referenced link an entry-point to the resource ... depends on what is meant
by "the resource" ... which I'm reading as being the entry resource, not the
thing the entry is referencing ... so probably no.

I think of rel="bookmark" for "the link which is recorded when I hit the
bookmark-this-thing-right-here function" ... which would be the bookmark for
the entry, not the referenced resource.

For example, on del.icio.us I might have [1] in my collection, which can be
seen at [2] and also [3].

[1] http://www.w3.org/TR/REC-CSS2/selector.html#id-selectors
[2] http://del.icio.us/url/6bf832bf7d20edc9cd6a6f7ab98fdeb1
[3] 
http://del.icio.us/ironclad?url=http%3A%2F%2Fwww.w3.org%2FTR%2FREC-CSS2%2Fse
lector.html%23id-selectors&jump=no

When I'm at del.icio.us, I'd expect rel=bookmark for both [2] and [3] to
link to [2]. When I follow the link to the referent (ie. to w3c), then I'd
expect rel=bookmark *there* to point to either [4] or even possibly [5] (and
of course it could point to both, with appropriate @title to disambiguate)

[4] http://www.w3.org/TR/REC-CSS2/selector.html
[5] http://www.w3.org/TR/REC-CSS2/cover.html#minitoc

(it couldn't very well point to [1], since it's a document level piece of
metadata, not fragment level -- the syntax just isn't available to do that)

Also, not so sure it would be appropriate for my essay use case example

e.

---

From: "Teo Hui Ming" <[email-masked]>
Date: Tue, 31 Jul 2007 13:31:42 +0800

> linking to Bob's article or Alice's translation, then Charles would be the

I agree. Charles wrote the entry, thus he is the entry's author.

But my concern is, can we safely link to any document using atom:link
(regardless of @rel), just as we can with html:a and html:link, thus
are "normal links" [1].

-OR-

@rel may imply certain meaning on relationship (e.g. ownership)
between documents that authors/implementers must be careful about. If
yes, it seems necessary to make it clear.

and atom:content@src, should we treat it as normal / embedded [2] ?

[1] http://www.w3.org/DesignIssues/LinkLaw.html#Normal
[2] http://www.w3.org/DesignIssues/LinkLaw.html#Embedded

> [..] However, rel="related" doesn't

A new precise relation type is fine for new systems. But existing feed
readers prefer the first alternate atom:link in feed entry. If service
implementers need to compromise, at least they know it's okay to do
so. Which is why, I think, the question above is important.

Thanks,
-- 
Teo Hui Ming

---

From: Eric Scheid <[email-masked]>
Date: Tue, 31 Jul 2007 15:48:44 +1000

> (regardless of @rel), just as we can with html:a and html:link, thus

there is no "regardless of @rel", because RFC 4287 has this to say:

4.2.7.2.  The "rel" Attribute

   atom:link elements MAY have a "rel" attribute that indicates the link
   relation type.  If the "rel" attribute is not present, the link
   element MUST be interpreted as if the link relation type is
   "alternate".

> yes, it seems necessary to make it clear.

I would hope RFC2887#4.2.7.2 is clear :-)

> [2] http://www.w3.org/DesignIssues/LinkLaw.html#Embedded

My understanding is that atom:content@src is the latter.

e.

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 31 Jul 2007 08:59:26 +0200

> yes, it seems necessary to make it clear.

atom:link/@rel has the exact same implications as html:link/@rel / html:a/@rel.

The only difference with HTML is that in Atom there is *always* a
'rel' value (someone might argue that in HTML, when there is no @rel
on an html:link or html:a, you can make it default to rel="related").

> [2] http://www.w3.org/DesignIssues/LinkLaw.html#Embedded

Embedded, as Eric said.

Hence the @src vs. @href

-- 
Thomas Broyer

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 31 Jul 2007 08:20:14 +0100

> Hence the @src vs. @href

Interesting. That would mean that content/@src implies ownership by the 
atom:author of the resource pointed by @src right? This is quite an 
important but subtle warning in regards of licensing issue since a 
content/@src of a copyrighted resource, by someone distinct from 
atom:author, would be prohibited. Am I getting this wrong?

- Sylvain

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 31 Jul 2007 10:47:07 +0200

> atom:author, would be prohibited. Am I getting this wrong?

No.

<atom:content src="http://atomenabled.org/images/atom-logo75px.gif"
type="image/gif" />

Is the exact equivalent to

<atom:content type="image/gif">
R0lGODlhSwBLAMQAAOLcnp61x26Mm9HTx+7qx/z8/GRrQYeMa5Kpt3mU
o7TG1NXMdOfp5MnV3re6ptrh4/b04KywmfP08eTq73d+W/v68u3w8vP2+IWe
q/j5+Z+ki3qevMLEtJSZeoOkwP///yH5BAAAAAAALAAAAABLAEsAQAX/4C
eOZGmeaKqubHsWg0YZ3IUJeJ4rxWFQkYFrqCo4DB3GUCF4iAqKhNPF8H
GIpgESACBAKoXhJMEbZQKYC7HAvkx8QhYDaaoAFgtC8fPwbDyAgX4bCh
kXYSkNCB4KamYHFEooEh2RLhkPAR4BTgp/gqCBfxYVBHhdLg8GERkoE
zo6Ci+YCoABDY5jDYgiFhiyIqV4C11gJg2wOhOuAQk5CMtYIgECFmZoEtK
tFgoBCLfW0iMDPhpTKkzLBc3RKTEGB3Hi8/T19ljIyQIY4ff3DB1+XFnRwJuC
dimOGNCQzZ8ICT7ODcmAAYGjDxYSBBCn5QAWBhQ6ELhDoEKJUlxO/3
khgUzihwZSSlx40M0DAgUNJvD6cKFWgAMHGqK4IMMlCgh38oCB8ikUqA0
IrBXIUHATQhRaHOwsoWWgiUxWt45g2vRpgH51TBGDcOJBEhQP9OXYiPP
qUAwBLr5s4qIUW2dyEYhNCK+VGI2IMm4cYmGGPIcmCljg4OOHBg6S+C
QoiGEEAw4yDCAZIBSywwsNbuAIoNO067aA9QUY/HqIkRlAGGRANEZ2m
DYPIoim4LW2mSMUHqd4VYgnhs4tOIjmQJsjPLQtECToF7fBR8f0VHUozRiv
YZ4IEMyDaGlIRz0fIIwcludLigebSUBJYFe/BZqa2HTLAw9AYlRkwk1hB/8e8J
0gX1IAsMVHNwEEgJNhEyiwiIUTnFfCA4s00EpWK0hX3ElqRWjCBQGU5dQ
f/XFjk4goSKccCZS0N4QpBLDoolOAbDDBBDYdeB8QHpKQgXA3lpDhjGhZ0
CKQgmzgElKnmOSOAQ6sUEBBFmZjAQKEJOlkN8s8ucGamzxQwIIqpgAB
Hmw9gIEzCUDjilw4yPJfTd80gF0v5pHQHQooDVPMB7Elg8FWUMiFgZksIJD
GWFH0t0JvyVjkAnuUEiSAdyJckJ40EohGHj3INYmCpYYdygIMM5zoWgbkC
KSXkhphJMBiJljgwAzxVGdcCVMxMIADGkAi2rMUHKCBAwPoZuz/sdhme0
8BbkxgQaja2nNGMvmFexoCfAJjLj0MMIAfn7MRuG4LGQwr2gHUfkCNPjEN
EEFlxF1r3ADEDkCpnbDkFZkEHBSsbQEPzDDeCm6cJ4GbKwAED8auGbG
xC8iQ+oF2g2JVq2lHTDwENe2ETEQVNNwTsY5DWHoRc9KARDMWwnUpj
Q0KP4SXOAUIZ2sLAWWGxRhllIqGwHDRMcQFPtCn0hfX4rcLpvy0wO0EDd
TkAQYLQV20AQySkOjVWhrKF0tvIzuT2BY+cBFMXLZAIpwSnoTlKRI+QKoh
jjzQjgVVbSLoCRNoUsgRro5gAVClzblWChWUokfjg6z5xy0fNK7A/wMli/Aka
4iApDJWq7yQYt8mEPljlSIzrgnqJmhggJEfLGlA5MFA2DYfVD7VnBkNANKIC
iROUonSK1iexxmzv6gTiG2mskqoOUJPcSYiTlm8KN46sIB9qSCJQgZFtUCT
4oe8VL1ZjvwdJ/OrVGdiChloyEjJDZhfkI6nn781yAQ2UoEEDLYinzwAXNz6kh
+eQohDwC4tp+CFBSagBjbcRzU4IAMfNMWTxLHmW72bAIHUYIgC2K8kKd
ADE2ARExNkAF38EsrX/McIlzDNSaMywXwAl7kR4FAf6hpBXOClL6iAQwW
+CICHZIW5IRKgAI2CxaRKkBE+eQdqT0iPXmDCu6AU7EsftZMcCHVQxhRo
R4eZEse7dKAn/v3HcLthABhJkI5rbBEL5HBTBga5x3HAY1UriEvTJDA0IjRmd
w4RTgdKdwIbCMZ0AkjiCiaXN9dIhwZQa0YHmdDG3kknOdhigO4o4ABK8iGI
FHlUChggnFW40jWf8QEQBiCWZrwyjbgKzQE4cEtscSs4M3jWATogAwo4M
zTQcsAD50XNalpzBSEAADs=
</atom:content>

(and actually also to <atom:content type="image/gif"
src="data:image/gif;base64,R0lGODlhSwBLAMQAAOLcnp61x26Mm9HTx%2B7qx%2Fz8%2FGRrQYeMa5Kpt3mUo7TG1NXMdOfp5MnV3re6ptrh4%2Fb04KywmfP08eTq73d%2BW%2Fv68u3w8vP2%2BIWeq%2Fj5%2BZ%2Bki3qevMLEtJSZeoOkwP%2F%2F%2FyH5BAAAAAAALAAAAABLAEsAQAX%2F4CeOZGmeaKqubHsWg0YZ3IUJeJ4rxWFQkYFrqCo4DB3GUCF4iAqKhNPF8HGIpgESACBAKoXhJMEbZQKYC7HAvkx8QhYDaaoAFgtC8fPwbDyAgX4bChkXYSkNCB4KamYHFEooEh2RLhkPAR4BTgp%2FgqCBfxYVBHhdLg8GERkoEzo6Ci%2BYCoABDY5jDYgiFhiyIqV4C11gJg2wOhOuAQk5CMtYIgECFmZoEtKtFgoBCLfW0iMDPhpTKkzLBc3RKTEGB3Hi8%2FT19ljIyQIY4ff3DB1%2BXFnRwJuCdimOGNCQzZ8ICT7ODcmAAYGjDxYSBBCn5QAWBhQ6ELhDoEKJUlxO%2F3khgUzihwZSSlx40M0DAgUNJvD6cKFWgAMHGqK4IMMlCgh38oCB8ikUqA0IrBXIUHATQhRaHOwsoWWgiUxWt45g2vRpgH51TBGDcOJBEhQP9OXYiPPqUAwBLr5s4qIUW2dyEYhNCK%2BVGI2IMm4cYmGGPIcmCljg4OOHBg6S%2BCQoiGEEAw4yDCAZIBSywwsNbuAIoNO067aA9QUY%2FHqIkRlAGGRANEZ2mDYPIoim4LW2mSMUHqd4VYgnhs4tOIjmQJsjPLQtECToF7fBR8f0VHUozRivYZ4IEMyDaGlIRz0fIIwcludLigebSUBJYFe%2FBZqa2HTLAw9AYlRkwk1hB%2F8e8J0gX1IAsMVHNwEEgJNhEyiwiIUTnFfCA4s00EpWK0hX3ElqRWjCBQGU5d!
 Qf%2FXFjk4goSKccCZS0N4QpBLDoolOAbDDBBDYdeB8QHpKQgXA3lpDhjGhZ0CKQgmzgElKnmOSOAQ6sUEBBFmZjAQKEJOlkN8s8ucGamzxQwIIqpgABHmw9gIEzCUDjilw4yPJfTd80gF0v5pHQHQooDVPMB7Elg8FWUMiFgZksIJDGWFH0t0JvyVjkAnuUEiSAdyJckJ40EohGHj3INYmCpYYdygIMM5zoWgbkCKSXkhphJMBiJljgwAzxVGdcCVMxMIADGkAi2rMUHKCBAwPoZuz%2Fsdhme08BbkxgQaja2nNGMvmFexoCfAJjLj0MMIAfn7MRuG4LGQwr2gHUfkCNPjENEEFlxF1r3ADEDkCpnbDkFZkEHBSsbQEPzDDeCm6cJ4GbKwAED8auGbGxC8iQ%2BoF2g2JVq2lHTDwENe2ETEQVNNwTsY5DWHoRc9KARDMWwnUpjQ0KP4SXOAUIZ2sLAWWGxRhllIqGwHDRMcQFPtCn0hfX4rcLpvy0wO0EDdTkAQYLQV20AQySkOjVWhrKF0tvIzuT2BY%2BcBFMXLZAIpwSnoTlKRI%2BQKohjjzQjgVVbSLoCRNoUsgRro5gAVClzblWChWUokfjg6z5xy0fNK7A%2FwMli%2FAka4iApDJWq7yQYt8mEPljlSIzrgnqJmhggJEfLGlA5MFA2DYfVD7VnBkNANKICiROUonSK1iexxmzv6gTiG2mskqoOUJPcSYiTlm8KN46sIB9qSCJQgZFtUCT4oe8VL1ZjvwdJ%2FOrVGdiChloyEjJDZhfkI6nn781yAQ2UoEEDLYinzwAXNz6kh%2BeQohDwC4tp%2BCFBSagBjbcRzU4IAMfNMWTxLHmW72bAIHUYIgC2K8kKdADE2ARExNkAF38EsrX%2FMcIlzDNSaMywXwAl7kR4FAf6hpBXOClL6iAQwW%2BCICHZIW5IRKgAI2CxaRKkBE%2BeQdqT0iPXmDC!
 u6AU7EsftZMcCHVQxhRoR4eZEse7dKAn%2Fv3HcLthABhJkI5rbBEL5HBTBga5!
 x3HAY1Ur
i
EvTJDA0IjRmdw4RTgdKdwIbCMZ0AkjiCiaXN9dIhwZQa0YHmdDG3kknOdhigO4o4ABK8iGIFHlUChggnFW40jWf8QEQBiCWZrwyjbgKzQE4cEtscSs4M3jWATogAwo4MzTQcsAD50XNalpzBSEAADs%3D"
/>)

-- 
Thomas Broyer

---

From: "Teo Hui Ming" <[email-masked]>
Date: Tue, 31 Jul 2007 16:51:41 +0800

Thanks for the quick replies to clarify the issue.

It seems important for people to understand the implication of
@src vs @href (Embedded vs Normal Link).

-- 
Teo Hui Ming

---

From: "James Holderness" <[email-masked]>
Date: Tue, 31 Jul 2007 21:56:55 +0100

> How about rel="bookmark"?

You'd still have to register it for use in Atom - you can't just throw any 
old HTML rel value into an Atom link. Either use an IRI or a registered link 
relation.

Of course if you actually what people to be able to see the link, you'd be 
better off sticking with "alternate", no matter how inappropriate it may 
seem.

Regards
James