Subject: who is the entry author?

From: Zhiwu Xie <[email-masked]>
Date: Mon, 30 Jul 2007 10:53:12 -0600

Hi,

Just a question on the syntax of atom:author. Is it the author of the 
content an entry refers to, or is it the one who posts the content to a 
content management system therefore generates an atom entry? I checked 
google blog and it seems the later is the case (snippet below), but then 
earlier discussions seems to suggest the former, e.g., multiple 
authors/contributors discussion.

The same question can be asked on all the other metadata, e.g., rights, 
updated, published, etc. A more general question is, what all these 
entry metadata are about. The spec says they are all about the feed or 
entry, but it's not immediately clear to me what does the entry metadata 
are about, the XML element itself or the content an entry points to. 
This has much different implications, e.g., if atom:right says do not 
copy, does it mean this atom entry cannot be aggregated by other Atom 
feed aggregator or the contents cannot be distributed within the 
atom:content?

Thanks,

Zhiwu Xie

-----------------------

google blog snippet: The author of the content should be Matthew 
Glotzbach, inferred from the content, but the entry author is set to Karen.

<entry>
   <id>tag:blogger.com,1999:blog-10861780.post-4599612599595997166</id>
   <published>2007-07-26T11:13:00.000-07:00</published>
   <updated>2007-07-26T11:43:42.465-07:00</updated>
   <title type="text">Earth to the Enterprise</title>
   <content type="html">
     &lt;span class="byline-author"&gt;Posted by Matthew
     Glotzbach, Product Management Director, Google
     Enterprise&lt;/span&gt;&lt;br /&gt;&lt;br /&gt;...
   </content>
   ...
   <author>
     <name>Karen</name>
   </author>
</entry>

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 30 Jul 2007 18:03:07 +0100

One idea could be to use DublinCore to make the distinction easier to 
define.

- Sylvain

Zhiwu Xie a écrit :
> content an entry refers to, or is it the one who posts the content to 
> a content management system therefore generates an atom entry? I 
> checked google blog and it seems the later is the case (snippet 
> below), but then earlier discussions seems to suggest the former, 
> e.g., multiple authors/contributors discussion.
>
> The same question can be asked on all the other metadata, e.g., 
> rights, updated, published, etc. A more general question is, what all 
> these entry metadata are about. The spec says they are all about the 
> feed or entry, but it's not immediately clear to me what does the 
> entry metadata are about, the XML element itself or the content an 
> entry points to. This has much different implications, e.g., if 
> atom:right says do not copy, does it mean this atom entry cannot be 
> aggregated by other Atom feed aggregator or the contents cannot be 
> distributed within the atom:content?
>
> Thanks,
>
> Zhiwu Xie
>
> -----------------------
>

---

From: Zhiwu Xie <[email-masked]>
Date: Mon, 30 Jul 2007 14:31:59 -0600

Many thanks Sylvain. Using Dublin Core surely can clarify the issue to 
some extent, but what I'm trying to figure out is the exact meaning and 
common practice (if any) for the elements defined by the Atom spec, 
especially those compulsory ones, because this relates to how these 
metadata are and can be used for.

1. atom:updated: I guess the atom:updated value is used to alert the 
downstream application of the changes in the entry therefore prompt 
appropriate actions. The nature of the change, whether it's a content 
change or entry link change, is not specified.

2. atom:published: The spec says this is "associated with an event early 
in the life cycle of the entry", while typically "be associated with the 
initial creation or first availability of the resource". If the resource 
(I think this refer to the web content?) is created or made available 
before the atom:entry is created (which seems to be always the case for 
google blog), then the resource dates can not be within the life cycle 
of the entry, right?

3. If an entry x from feed A is aggregated into another feed B as entry 
x', should the atom:updated, atom:published, atom:author, 
atom:contributor, and other metadata of the entry x' be modified 
accordingly or strictly copied over from x? Is there an implied or 
expected behavior for an aggregator in this aspect? If just copied over, 
how can the aggregating feed B alert its subscribers of the addition of 
this new aggregated entry x'? By change the updated of the feed B I 
guess, but then the updated datetime of the copied entry x' may be much 
older than the other entries and a feed reader may have difficulty 
noticing it. If changed accordingly, how do I know which version of the 
source entry I'm aggregating if there are multiple versions of the entry 
x, each with a different updated datetime? If the original entry x is 
updated, should entry x' also be updated?

4. atom:author and atom:contributor of the feed: I guess this is to 
convey information about some authoritative source of the feed, and used 
to keep some lineage information, because the spec say the aggregators 
should keep the authors of the originating feed. But if the aggregation 
is chained, shouldn't I have multiple source element or just the 
metadata about the ultimate source? The spec says entry can only have 
zero or one source, so I guess it's only the ultimate source and the 
lineage is somewhat lost.

Thanks,

Zhiwu Xie

---

From: Bill de hOra <[email-masked]>
Date: Tue, 31 Jul 2007 00:06:02 +0100

> authors/contributors discussion.

There's no right answer.

> feed aggregator or the contents cannot be distributed within the 

(I assume you mean "implication" in a technical sense)

The only sensible answer I can give is that these facts are typically 
about whatever is denoted by atom:id. If your system for whatever reason 
needs to disambiguate the referent of metadata, the best you can do is 
make sure it's internally consistent, and document that. I would expect 
that to result in treating atom:id as a primary key.

The WG chose not to depend on technology that might help with this kind 
of issue (such as RDF), and Atom does not have its own semantics. Atom 
then doesn't go beyond common sense interpretation - ie, your rights 
attribution issue is as likely to be settled as a matter of case law as 
specification. It's easy enough to get muddled around whether metadata 
is about the entry, the markup you received representing the entry, or 
some other entity. Even then formal models are limited and a surprising 
number of standards and notional keys have had problems like this 
(Dublin Core is a good example for the web, abuse of SSNs as identifiers 
is a classic).

There are/have been efforts to create formal models of Atom, dependingon 
Semantic Web technology, but none of these have standing as they are not 
products of the WG - all Semantic Web vocabularies boil down to URI 
ownership so the WG has to agree that certain URIs can stand for Atom; 
these do not have be in the Atom/AtomPub namespaces.

cheers
Bill