Subject: Re: PaceExplainDuplicateIds

From: Henry Story <[email-masked]>
Date: Sun, 1 May 2005 20:10:17 +0200

On 1 May 2005, at 18:18, Eric Scheid wrote:

> On 2/5/05 1:51 AM, "A. Pagaltzis" <[email-masked]> wrote:
>
>> I would +1 allowing identical IDs if it was required that the
>> entries sharing an ID had different sources.
>>
>>
>
> perhaps we need to explain the concept of 'entries' (as resources), as
> distinct from <entry>s (as representations), and explain that  
> 'entries' must
> have unique IDs, and that the <atom:id> element of any <atom:entry>  
> ties it
> back to the 'entry' resource. It would then follow that multiple  
> <entry>
> representations which happen to have the same <atom:id> value are just
> different representations of the source 'entry', and possibly even  
> different
> instantiations in time.
>

Exactly. I think this will help dissolve the issue very easily.

The way I am currently thinking of this is as follows.

The <entry>....</entry> xml we find in a atom feed is a time stamped
representation of a resource. It is the state of a resource at a  
particular
time. Or perhaps better: it is metadata about the state of a resource at
a particular time.

If we then think of the entry id as a resource, then we may think of  
all of
these xml representations as representations of that id, where the  
representations
each specify the date and time of their validity. Because the  
representations
contain the date and time of their validity they can be placed in a  
collection
without ambiguity.

So there is a little distinction we need to be careful of: an  
"<entry>...</entry>"
representation is a representation *of* the id resource, but these  
representations
are *about* the state of some other resources at a particular time  
(most notably the
link "alternate" resource).

Henry Story
http://bblfish.net/blog/

> e.