At Wed, 5 Dec 2007 18:16:57 -0500,
"Ray Denenberg, Library of Congress" <[log in to unmask]> wrote:
>
> From: "Erik Hetzner" <[log in to unmask]>
> > The point of atom:id is NOT to provide a URL
> > for retrieving the document; it is to provide an ID so that systems
> > know when one entry is the same as another.
>
> This is a very interesting point. First of all I could interpret
> that to mean either (1) to provide a clue that two records in a
> result set are the same (an aid to deduplication), or (2) that
> records in different result sets are the same. Could be both, but I
> suspect the second is the more important case. If so, I think the
> implications are deep: While I think this is potentially useful, we
> cannot define such a parameter (with those semantics) unless
> implementors are prepared to support it (again, support it in good
> faith) but this is something totally foreign to Z39.50 and SRU so I
> have no idea who, if anyone, is prepared to support it.

Atom also specifies that if a feed returns two entries with the same
atom:id, they must differ in atom:updated (in other words, they must
be ordered in time). So I don’t know if it a help in deduping in the
same result set, but rather in multiple result sets.

> > > Ralph says not all records have an id. But if you can create a
> > > URI for the result set, you can create a URI for each record - I
> > > content that it is sufficient to merely append the result set
> > > position. Then you have created a good faith identifier.
> >
> > Agreed, presuming that you can be certain that this ID will never
> > mean a different record, and that atom:id is read to mean the ID
> > for this result, not this record.
>
> I don't know if I agree with this presumption.

I don’t either. I think that atom:id should mean (semantically) an ID
for the record. But if it does, atom requires that it not change from
result set to result set, which means that you cannot simply make up
an id which is specific to the result set.

> […]

> > Doesn't this presume that the data behind the service will never
> > change?
>
> No. It definitely does not presume that. But we do have parameters
> like "time to live" which the server supplies as an estimate of how
> long it the data will remain stable. Not a guarantee, but a good
> faith estimate.

But a ttl can’t apply to an atom:id which is read as a record id. This
id must always identify the same record.

best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3