 |
 |
As an aside, please note that this is just one of many mandatory elements in ATOM. When we're done with atom:id, there's a whole raft of semantics for other elements to discuss ;) Like... who is the author of a search result? ( atom:feed elements MUST contain one or more atom:author elements, unless all of the atom:feed element's child atom:entry elements contain at least one atom:author element ) What does it mean to have an updated timestamp for a search result? Does it change every time? What if you just repeat the same search and none of the entries have changed? What if you repeat the same search, the results are the same, but the sort is different? ( atom:feed elements MUST contain exactly one atom:updated element. ) etc. Rob On Wed, 5 Dec 2007, Ray Denenberg, Library of Congress 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. > >>> 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 >