Wednesday, January 23rd 2019
Ian Ibbotson [10:34 AM]
Hey all! I'm working on some stories for @Chas Woodfield and I'd like to write some scenarios which contain real-world data. Chas and I have decided that it makes most sense to start with receiving a request (Because we can't test sending until we have someone to send to).
Could anyone please suggest some institutions that I can use in the scenario? I need 1 to be identified as the patron home institution - the source of the request, and 2 or 3 institutions who -in real life- might respond to that request.
In an ideal world, I'd really like it if we could yank and anonymise a real patron request.
All help gratefully received - this scenario should be end-user testable, so the more realistic the better - warts and all!
Kurt Munson [5:48 PM]
@ianibbo I don't know if this is what you need. Mostly request start as an openURL string and then in existing systems we would authenticate the patron and then use a webservie to send the request via OCLC worldshare to a partner library. An example open URL from Northwestern's Primo instance is below. My university identifier (NetID, we call it here) would be sent as part of the header. That may be too far into the weeds or totally off mark of what you are asking for.
https://northwestern-illiad-oclc-org.turing.library.northwestern.edu/illiad/illiad.dll?Action=10&Form=30&rft.genre=book&rft.title=Property+and+wealth+in+classical+Sparta+%2F&rft.stitle=Property+and+wealth+in+classical+Sparta+%2F&rft.atitle=&rft.date=2000.&rft.month=&rft.volume=&rft.issue=&rft.number=&rft.epage=&rft.spage=&rft.edition=&rft.isbn=0715630407&rft.eisbn=&rft.au=,&rft.auinit=&rft.pub=Duckworth+and+the+Classical+Press+of+Wales&rft.publisher=Duckworth+and+the+Classical+Press+of+Wales&rft.place=London+%3A&rft.doi=&rfe_dat=44786349&rfr_id=info%3Asid%2Fprimo.exlibrisgroup.com-01NWU_ALMA
Mike Taylor [5:50 PM]
@Kurt Munson In that OpenURL, what are Action=10
and Form=30
?
Kurt Munson [6:01 PM]
@mike In that OpenURL, what are Action=10
and Form=30
? are unique to the ILLiad software. The form specifies the type of request form to populate with the data. This is a loan request.
This OpenURL breaks down as
https://northwestern-illiad-oclc-org.turing.library.northwestern.edu/illiad/illiad.dll
Action=10
Form=30
rft.genre=book
rft.title=Property and wealth in classical Sparta /
rft.stitle=Property and wealth in classical Sparta /
rft.atitle=
rft.date=2000.
rft.month=
rft.volume=
rft.issue=
rft.number=
rft.epage=
rft.spage=
rft.edition=
rft.isbn=0715630407
rft.eisbn=
rft.au=,
rft.auinit=
rft.pub=Duckworth and the Classical Press of Wales
rft.publisher=Duckworth and the Classical Press of Wales
rft.place=London :
rft.doi=
rfe_dat=44786349
rfr_id=info:sid/primo.exlibrisgroup.com-01NWU_ALMA
This is a v1.0 OpenURL, recognisable from the use of rft.
prefixes, although it lacks some potentially helpful fields such as ctx_ver
. So we should probably focus intitial development effort of OpenURL v1.0 support
We will need to find out more about the ILLead-specific Action
and Form
fields.
Otherwise, we have a bunch of metadata about the sought item (the "referent" in OpenURL v1.0 terminology), each key prefixed with rft.
, and two other fields:
-
rfr_id
-- specifies the system that generated the OpenURL. The main example given in the OpenURL v1.0 standard isinfo:sid/elsevier.com:ScienceDirect
, aninfo
URL in thesid
space identifying Elsevier's Science Direct platform. The value in the example,info:sid/primo.exlibrisgroup.com-01NWU_ALMA
, is of the same form, evidently identifying Ex Libris's Primo discovery system. Presumably the portion after the hyphen specifically identifies Northwestern University_'s installation. As the specification says (seciton 5.2), "Knowing the identity of the Referrer might help the Resolver to interpret the Private Data" -- in this case, theAction
andForm
fields. -
rfe_dat
somehow identifies the "referring entity" -- that is, the specific work the user was looking at when they generated the OpenURL. This can be specified asrfe_id
, which is an identifier; or as a bunch ofrfe.*
keys, which specify metadata about it. Unfortunately in this case it's anrfe_dat
, which is "private data". There is no good way to interpret the value44786349
, at least not without knowing more about how the referring entity (Primo in this case) generates these private values.
Fortunately, we don't really need to know anything about the referring entity: so long as we know the referer, we can look it up in a table to determine which FOLIO tenant implements its ReShare system, and we're good to go.
The big thing that is completely missing from this OpenURL is any information about the patron who is requesting the item. This is crucial to determine, since without it the borrowing library will not know who to circulate the borrowed item to.
There are two possible solutions.
-
OpenURL v1.0 provides means to convey information about the requester: most simply, a
req_id
field that may contain a URL such asmailto:jane.doe@caltech.edu
; but metadata about the requested can instead be communicated usingreq.*
keys; or private data usingreq_dat
. Finally, reference to an external user descriptor can be provided usingreq_ref
(and an accompanyingreq_ref_fmt
to specify the descriptor's format). -
If none of these can be added to the OpenURL, then it is possible that patron information might be discerned from the HTTP headers of the request that communicates the OpenURL to its resolver. The detail of these will be highly variable, depending on the discovery system and the SSO solution, so this approach should be considered an undesirable backstop.