Consortial NCIP calls from Drupal - Use of Agency ID

[patrickzurek]

JIRA issue created by: rcook Originally opened: 2010-12-13 07:40 PM

Issue body: (nt)

This issue has an attachment associated with it (external link): location.PNG

[patrickzurek]

JIRA Comment by user: rcook JIRA Timestamp: 2011-09-14 09:15 PM

Comment body:

This becomes very critical in a consortia. Patrick has built the Voyager connector to be UB aware (the consortial version of Voyager) and it requires we pass an ORG code as the Agency ID. However, we need to define the correct behavior that Drupal NCIP calls need to make.

Use cases:

1. User searches records in their own school or a specifically selected school - should be similar behavior and just pass Agency ID of selected schools for LUIS calls. Lookup User calls should always be made using the user's home institution code, right?
2. User searching against entire Union Catalog. If result set has found items at the users home school, is that the first LUIS message that should be sent. What happens next.....do we just randomly issue LUIS calls for institutions that have an XC:recordid (bib number and attribute type that contains the Org code) on the aggregated record? Or is there an order?

Issue has been open for almost a year, and I think it is time to start to define it.

Jennifer: how do we even identify the correct Xc:recordid on an aggregated record....right now it could contain bor ORG code and OCLC for example.

[patrickzurek]

JIRA Comment by user: dlindahl JIRA Timestamp: 2011-09-15 12:44 AM

Comment body:

I think we need to start in our software architecture design (if I understand this correctly). One of the many things we should do is to define the NCIP provider endpoint types and what services they offer. Then we can define the Drupal Toolkit's NCIP initiator capability, and the features within the Drupal Toolkit.

For the NCIP providers (OAI Toolkits), I think there are three main types, and perhaps several subtypes:

1) Single ILS (an OAI Toolkit instance in front of one ILS): This would have an ip address that would accept NCIP calls and respond on behalf of a single ILS with a single patron database within that ILS. It might connect to a separate LDAP user database, and this separate database could conceivably be shared with other NCIP providers. For this case, we would want to also consider that each specific ILS (voyager, III, etc) might not support all NCIP features, or might support them slightly differently

2) Multiple ILS (an OAI Toolkit instance in front of multiple ILSs): I do not know if this is supported, but it should be possible with the concept of passing the ORG code as the agency id, and if we code the NCIP Toolkit to be configured to talk to multiple ILSs. I assume that for this situation, a single NCIP Toolkit would only talk to a set of ILS's that are all of the exact same brand (all Voyager 7.x for example). For patron lookups it could support local or LDAP. LDAP might require more coding in this scenario.

3) A union ILS (an OAI Toolkit instance in front of a union catalog ILS like the UB system): I think this is the case discussed in this message. You would need to pass the ORG code as the agency id. I am unclear on what NCIP services are supported in this case, or how they would operate differently compared to a single ILS, but they might use different identifiers, have different records, etc- and they might only support some NCIP services.

On the Drupal end, we need to stay somewhat flexible, so I would start simply with a foundation. Once we get the different types and capabilities of NCIP providers ironed out, and captured, we should build a feature into DT that allows an administrator to "register" (or add using a form) a new NCIP provider, and be able to fill in a form with checkboxes to identify the type, properties, capabilities and limitations of each NCIP Toolkit.

I think User accounts should also be configurable to have a "home" institution, or perhaps to support multiple "home" institutions. The institution code will sometimes refer to the institution that the user is from, but I could imagine it could also refer to a particular system. Let's say an institution has two ILSs and each has it's own ORG code. It might be necessary for a user to have access to both. I am a little fuzzy on the possible scenarios here, but it seems like Drupal needs to know the following for each user:

1) The org code(s) for their institution 2) The NCIP provider(s) for systems that they have user accounts on (where a LookupUser call would work)

In a very real scenario, we hope to build an Illiad connector to support LookupUser, and in this case we would want to pull in user account info from both Voyager and Illiad and show it on one screen. That would involve connecting to 2 different NCIP providers for 1 user.

Another example: it might be necessary for a LookupItem to be able to go to BOTH the home ILS's NCIP provider and the union catalog's NCIP provider to get status on the item, or perhaps to go to several systems to get circa status.

[patrickzurek]

JIRA Comment by user: rcook JIRA Timestamp: 2012-08-29 12:36 PM

Comment body:

[~mwesley], I know that since this issue was written and last commented on you have released the Drupal Toolkit with support for NCIP protocol 2. And I recall that there is a way to set up the NCIP Initiators to speak to specific NCIP Toolkits and that it passes the ORG code.

Patrick should get familiar with the NCIP Module and how these work, and then we can discuss next steps.

[patrickzurek]

JIRA Comment by user: rcook JIRA Timestamp: 2012-10-03 02:53 PM

Comment body:

This issue that has been around since 2010 goes right to the heart of an email that [~cdelis] sent today.

[~pzurek] [~jgibson] [~mwesley] [~pkiraly]

This is one of the things that I wanted to head toward working out when I suggested that we get a small set of "merged/dedupped/aggregated" records into Drupal, so we can have a better base to design what is needed.

[patrickzurek]

JIRA Comment by user: rcook JIRA Timestamp: 2012-11-05 12:04 PM

Comment body:

[~pzurek] [~mwesley] [~cdelis] [~pkiraly]

I think this is the issue that we should continue this mornings discussions under.

[patrickzurek]

JIRA Comment by user: rcook JIRA Timestamp: 2012-11-05 12:12 PM

Comment body:

http://xc-zurek.carli.illinois.edu/xc_dev/?q=node/77/xc/download

This maneifestation has a title of

dcterms:title Three rival versions of moral enquiry : encyclopedia, genealogy, and tradition : being Gifford lectures delivered in the University of Edinburgh in 1988 /

and has XC Record IDs for the following.

xc:recordID •89029275 (@type="LCCN") •267047 (@type="DPUdb") •623878 (@type="ISUdb") •81407 (@type="NCCdb") •282090 (@type="NEIdb") •20691010 (@type="OCoLC") •943021 (@type="SICdb") •665680 (@type="UICdb") •1648942 (@type="UIUdb") •483570 (@type="WIUdb")

I would think that as a starting point, CARLI would setup up all of the above as NCIP agencies except "OCoLC" and "LCCN."

I would think a simple beginning point, and how I expected it to currently work, is an NCIP request would be sent for all the agency IDs that were set up. So that if "DPUdb" "ISUdb" "NCCdb" "NEIdb"

Were the only 4 setup, then an NCIP LUIS message would be sent to these 4 schools.

[~mwesley] and [~pkiraly] How far are we from making that happen?

[~cdelis] [~pzurek]

[patrickzurek]

JIRA Comment by user: rcook JIRA Timestamp: 2013-04-01 12:01 PM

Comment body:

Relates to our team meeting today.

Notice the attachment. Patrick has made changes to LUIS functionality in DT so that it works for a consortia setting (there may still be work to do in this area). This screen shot show 5 different holdings, each at a different CARLI school. But, we can't tell what school each line represents. We need to setup a mapping of Agency ID (e.g. MARC Org code) and a display name for each, and then add that here.

Note, a single institutions would probably not want to take up screen space to show the school, so this should be configurable (show the display name of the Agency ID if you want).

[~pzurek] [~trung] [~pkiraly] [~mwesley]