II · 18
Referrer (rfr)
The Referrer identifies the system that generated the ContextObject — the database, search engine, or citation manager that produced the OpenURL.
The Referrer entity identifies the system that produced the ContextObject: the database, discovery service, catalogue or citation manager that generated the OpenURL. In KEV form the prefix is rfr. It is optional, but the KEV implementation guidelines "strongly encourage" sources to include a genuine Referrer identifier, and almost every well-formed OpenURL does.
The info:sid/ convention
The Referrer is identified with an info:sid/ URI. The sid namespace was registered by NISO in 2003 for "Source Identifiers". Its identifiers have two parts:
- an Internet domain name, sub-domain or host name associated with the source (this guarantees uniqueness), and
- optionally, a colon followed by a string that says more about the source, such as a database name.
rfr_id=info:sid/elsevier.com:ScienceDirect
rfr_id=info:sid/ncbi.nlm.nih.gov:pubmed
rfr_id=info:sid/example.com:database
The domain is written normally, not reversed. sid identifiers are case-insensitive. There is no central list of sid values: each source chooses its own under a domain it controls.
Why include it
- Statistics. Resolvers report which sources send traffic.
- Source-specific handling. Resolvers can correct known metadata problems from particular databases.
- Avoiding circular links. A resolver can avoid offering a link back to the very source the user came from.
- Interpreting private data. If the ContextObject contains Private Data (
rft_dat), a genuine Referrer identifier is needed to know whose format it is. - Link-quality analysis. NISO's IOTA project measured OpenURL completeness per source using exactly this field; see Related Work.
The legacy sid parameter
OpenURL 0.1 used a flat sid parameter of the form VendorID:DatabaseID, for example sid=EBSCO:MFA or sid=Ovid:Medline. Many sources still send it, sometimes alongside rfr_id in a hybrid OpenURL. Resolvers should accept both.