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.

> > 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.

>
> > Or If you have a real id for the record, but retrieval by that id
> > won't retrieve result-set-related metadata, I would say that passes
> > the "good faith" test. If you want to provide an id that allow
> > subsequent retrieval of the record plus its result-set-related
> > metadata, good, but I don't see that as a requirement.
>
> Agreed, but in this case I would say that the atom:id identifies the
> record only, and therefore the same id must always be used for the
> same record in a result set.

I agree.


> > I would go so far as to suggest that you could use the SRU URL used
> > to create the result set (perhaps modified so maxRecords is set to
> > zero) as the URI for the set; and for a given record, the same url
> > modified to retrieve that single record.
>
> 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.

--Ray