> > This element already exists. It's called "id".
> But that's defined as a local identifier. I think the suggestion is an
> actionable uri.
Yes, but the id element is exactly what the persistant URI needs. It's
not an identifier from the data, it's a metadata identifer for the
record within the system.
So, assuming that this identifier is persistant and unique, we already
have persistent URIs:
http://srw.o-r-g.org:8080/database/?query=rec.id exact "ident1"
This isn't a big assumption to make, as this sort of identifier will be
required to create any other sort of persistant URI anyway.
If a server also wants to expose their records in another fashion, then
there's nothing preventing them from doing this. Eg the same record might
be available raw at:
-But- the obvious issue is the different schemas in which records are
available. A persistant ID in the rec sense is for the record, not the
exact way in which the record was returned to account for recordPacking
and recordSchema. At which point all you're missing from the query is
maximumRecords (which may default to 1) and record position (which does
default to 1) ... so any persistant identifier just duplicates SRU anyway.
In summary: We have persistant identifiers now. What we don't have is a
way to associate the metadata with the record in the response, and this
impacts more than just identifiers, but also rank and so forth.
,'/:. Rob Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I