Re: Semantics

[Henry Story <henry.story@xxxxxxxxxxx>]

Thanks a lot for helping me think about this. There is a lot in your 
comments. Here are some of my initial thoughts, reading your reply...

On 10 Jun 2004, at 18:50, Bob Wyman wrote:

> Henry Story wrote in:
> http://www.imc.org/atom-syntax/mail-archive/msg04494.html
> > Now an Entry in this second model could never
> > be more than one Feed, and this may be
> > considered a limitation.
> 	It is certainly a limitation; however, this limitation is one that I
> believe there is consensus to accept. If the limitation didn't exist, 
> we
> would be opening up the "Pandora's Box" of supporting a 
> "Feed-of-Feeds."
> Doing so is something that folk clearly don't seem to want to support.

Ok. That is the impression I had.

To be precise the first model allows an entry to be the header entry of 
numerous feeds, the second model only allows an entry to be the header 
of one feed. The second model allows an Entry to be cast to a Feed in 
OO-speak. This could be nice as it may be a nice way to represent what 
happens when someone leaves a comment on an entry. Suddenly that entry 
is turned into a feed, with the original entry as the head.
I have tried to represent this graphically below:

The rectangles represent the Feed Objects. MyFeed can only point to 
Entrys. But Entry2 at some point also became a Feed (hence it is 
surrounded by a rectangle). Entry2 as a feed can point to other 
entries.

Note that neither of these models very well supports feeds of randomly 
selected entries just like that. This is because there is no numbering 
of the links from feed to entry. The only order than can be imposed on 
a Feed is through the creation date of an Entry.

One can make entries that point to other people's entries of course, 
and in that way one can make a log of one's web browsing, which as I 
understand is the original meaning of 'blog'.

> 	The most common case where a "Feed-of-Feeds" might be considered
> useful is in the construction of "synthetic-feeds". I.e. Feeds that are
> composed of entries which have been extracted from other feeds. I 
> recently
> proposed a new element of Entry, atom:source-feed, which would permit 
> the
> insertion of feed-level metadata into an entry so that even if an 
> entry is
> extracted from its source feed and inserted into a new feed, the 
> meta-data
> relating to the source-feed remains with the entry.

If I have understood you correctly this could be done in (at least) two 
other ways:
  - One of the ways I mentioned above, namely by creating new entries 
for this feed of feed, where each of these entries points to the entry 
that one wishes to blog.
  - One could make the link from feed to entry be bidirectional, where 
every entry also points to its feed. This is nice because it means that 
one only needs to ship a link around and not any metadata. Perhaps one 
could make this extra link mandatory only for feeds that link to 
entries that don't belong to them. The problem with this solution, is 
as I mentioned above, both of these models do not order their entries 
other than by creation date (or perhaps modification date).

> 	Your model could be adjusted to incorporate support for
> atom:source-feed by creating a class "meta-data" which would contain 
> that
> meta-data common to atom:feed, atom:entry, and atom:source-feed.

> 	Note: Another proposal that I've created a PACE for suggests that
> atom:copyright be supported in Entries since they sometimes have 
> copyrights
> (or other rights) which are distinct from those of the Feed as a 
> collection.

That makes sense to me. Of course if we are to have a copyright on a 
feed and an entry then these two properties will need to be 
distinguished, since presumably the copyright of the entry header, may 
not be the same as the one for the feed that has that entry as a 
header. On model 2 this requires a differently named property, on model 
1 one could have a property with a domain of Entry and Feed.

 Speaking of this I thought I should note that by placing the Copyright 
on the feed, and not on a State object, the Feed's identity is linked 
to its copyright. You cannot change a copyright without making a new 
feed. The same would be true if it were added to an entry. Changing a 
copyright is a major undertaking. It can not be placed at the same 
level as changing a title. So I think this is justified.

> Also, I believe you'll find that entries can have xml:lang tags that 
> are
> different from those of the enclosing feed. Thus, in your model,
> atom:copyright and xml:lang should be moved to Entry rather than being
> specific to Feed.

Ok. Thanks for pointing that out. I could not find any mention that an 
entry had a lang attribute here:
http://atomenabled.org/developers/syndication/atom-format-spec.php

But it does make sense for entries to have a lang attribute, or at 
least for the entry contents to have one.

Some questions that popped into my mind:

I wonder if I could not just remove the contributor field altogether. 
Are the contributors to a feed not simple the set of all the entry 
creators?
And perhaps if we take the second model, then the contributors to an 
entry are simply the contributors to that entry when thought of as a 
feed, namely the people who posted comments to that entry....

> 	Finally, please note that your model seems to have confused the
> various dates that are currently defined for Atom feeds. Both 
> atom:feed and
> atom:entry support an atom:modified element, however, only atom:entry
> supports atom:created and atom:issued elements. The model could, of 
> course,
> be simplified by supporting all three dates in both atom:feed and
> atom:entry.

Thanks for pointing this out. I had not realized that feeds did not 
have a creation date. Of course in model 2 they will necessarily have 
one. In the first model it would be easy to remove the created element. 
It make sense to me that feeds have creation dates, so this does not 
seem like a huge problem.

The mappings to atom would currently be
atom:entry's atom:created is just my Entry.created property
atom:entry's atom:modified is just my EntryState.created property

Writing a good xslt will help clarify all these mappings...


> 		bob wyman