On 10/11/04 3:52 PM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> Eric Scheid wrote: >> <origin href="..." type="application/rdf+xml" title="My RDF Feed"/> > > That's more expressive than RSS V2.0's <source/> since it provides > type as well as URL and title, however, it still doesn't provide feed-level > metadata such as "author", "copyright", etc. that are potentially vital to > the proper interpretation of an entry. ah, but now you do have the @href, so it won't be hard to go fetch it except ... besides the roundtrip pain you might encounter the current feed with changed meta-data (eg. a guest author), different from when the entry was actually published. Life would be so much simpler with a SSFF with discrete <entry> documents ;-) > Some feed-level metadata is > inheritable by entries, other feed-level metadata is important for > understanding the context in which the entry was published or within which > it was intended to be interpreted. just how far do we push the need for context though? >> If an entry is originally published in Feed-A, picked up by an >> aggregator and republished in Feed-B, which is then picked up by >> another aggregator and republished in Feed-C ... what should the value >> of atom:origin in Feed-C be? Should it be the atom:id of Feed-B, >> or Feed-A? > > I believe that an entry can only have one "origin". In the case > above, clearly the "origin" is Feed-A. It might, for some applications, be > interesting to note from where the entry was most recently copied, however, > that would be something other than origin. so an (unwritten?) rule of atom:origin is that when aggregating entries from source feeds, if the entry already has an atom:origin don't replace it with a new one? e.
