Hi Dave,
nice to see you participate here. I understand your points, and I myself thought the
way you did for a while.
[Oops, I see now that you have retracted your point. Oh well. I had already started writing
the following]
On 5 May 2005, at 17:27, David M Johnson wrote:
I'm -1 on PaceAllowDuplicateIDs
Please consider the following points before you vote.
Reasons:
1) We're supposed to be standardizing current practice not inventing new things. Current best practice is to have unique IDs and current software (e.g. Javablogs.com) is predicated on this practice. I know, this practice is not followed widely enough, but that is another matter.
Atom is standardizing current practice, but it is also adding some features. For example name
spaces and ids. The atom charter also requires us to allow archives
[[ * a complete archive of all entries in a feed ]]
Graham himself thinks that archives are possible, since he supports the use of an
<archive> head element.
2) I think it is *much* more useful to think of an Atom Entry as an event that occurred at a specific time. Typically, an event is the publication of an article or blog entry on the web. For example:
event: CNET published article subject: CNET object: article
But an event it could also represent other events.
event: delivery van delivers package subject: delivery van object: package
event: alarm system sends warning subject: alarm system object: warning
event: server sends load warning subject: server object: load warning
If you think of Atom Entries as events, then it makes sense to consider the Atom Entry ID to be the ID of the event, not the ID of the subject or object of the event.
You are right. There are two types of objects that we need to think about:
A- the event/state of a resource at a particular time
B- the thing that makes these different states the state of the same thing
Clearly we need (B) or else all the talk about an entry changing over time (atom:updated)
would not make sense.
So let us start off, as I did a long time ago, by thinking that the the id of an entry
uniquely identifies the event/state of the entry. For every id there can be only one and
only one "<entry>....</entry>" representation. That id is that representation. It is, if you
wish, the name of a state of something else... and that would be?
I think it is clear that one of the roles of the id is to make it possible for an
entry to be moved from one web site to another, so that if your blog service provider
lets you down, you can still refer to the entry even when you have moved it to a
different "alternate" position. Graham has made such a point quite often. Entries it
has often been said can change, but the id remains the same. I think this is clearly
the consensus on this list. So the id URI is what identifies the different
"<entry>...</entry>" representations as being representations of the same thing.
Events are unique (you can't have more than one version of an event) and can be assigned GUIDs and therefore you cannot have more than one entry with the same ID.
yes. But I don't think that this is the consensus on this group. The good thing is that
you can achieve the same identification of a state through the combination of the id and the
modification time.
[here I noticed that you had changed your mind, anyway. I think I had exactly the same
thought as you did when I first started thinking about this. ]
In the case of earthquake data, each new data report is a new event.
event: agency reports earthquake data subject: agency object: earthquake data
The ID is the ID of the "data reported" event not the ID of the earthquake.
We don't know what subjects and objects people are going to use in the future, so we can't specify Atom elements or IDs for subjects and objects -- that's what extensions are for. If you want to create a feed to syndicate information about earthquakes, then you introduce an extension for uniquely identifying earthquakes. The same goes for earthquakes.
- Dave
