RFC: user stories / use cases

[mvesper]

The circulation module is going to be rewritten from scratch in Invenio 2, making it more flexible and covering more library use cases. The purpose of this RFC is to discuss current development stages regarding user stories / use cases.

CERN User stories

After a couple of meetings with the CERN library team, we came up with the following diagram displaying the actors, entities and statuses of the what would be required for the CERN library workflows.

+------+    has many             +--------------------------------------------+    
|Record+------------------------>|Item                                        |    
+------+                         +--------------------------------------------+    
                                 |                                            |    
                                 |    +----------------+returned              |    
                                 |    |                    ^                  |    
                                 |    |                    +                  |    
                                 |    | +->in_process+-+on shelf+->on loan    |    
                                 |    |          ^  +   ^   +  ^      +       |    
                           +---->|    |          |  |   |   |  |      |       |    
                           |     |    v          |  +-------+  |      v       |    
                           |     | +->requested+--------+   |  +--+missing    |    
                           |     |               |      |   |                 |    
                           |     |               |      |   |                 |    
                           |     | +->ordered+----------+   +-----+in_binding |    
                           |     |               |      |   |                 |    
                           |     |               |      |   |                 |    
                           |     | +->claimed+---+------+   +-----+scanning   |    
                           |     |                                            |    
                           |     +--------------------------------------------+    
                           |             ^                                         
                           |             |refers to one/multiple items             
          creates          |             |                                         
          administrates    |     +-------+----------------------------------------+
Librarian+-----------------+---->|Loan Cycle                                      |
                                 +------------------------------------------------+
                                 |                                                |
                                 | +------------+->pick_up                        |
                                 |              |  +                              |
                                 |              |  V                              |
          manages                | +-------------->on_loan+-->finished            |
          creates                |              |  ^      |   ^                   |
          owns multiple          |              |  |      |   +                   |
User+--------------------------->| +->pending+--+  |      +-->overdue             |
                                 |       ^      |  |            +                 |
                                 |       +      |  +------------+                 |
          sets configuration     | +->reserved+-+                                 |
Library+------------------------>|                                                |
                                 +------------------------------------------------+

This diagram leads to the following stories:

The user requests a book:

+--------------------+                                                
|User requests a book|                                                
+---+----------------+                                                
    |                                                                 
    |                                                                 
    v                                                                 
                                                              +------+
 for right now? +----> date available? +----> waitlist? +---->|cancel|
                  no                     no               no  +------+
    +                     +                      +                    
    |                     |yes                   |yes                 
    |                     v                      v                    
    |                 +----------------+     +----------------+       
    |                 |notification    |     |notification    |       
    |                 |request:reserved|     |request:pending |       
    |yes              |request.mail?   |     |request.mail?   |       
    |                 |request.pick_up?|     |request.pick_up?|       
    |                 +----------------+     +----------------+       
    |                                                                 
    |                                                                 
    v                                                                 
                                             +------+                 
 available? +--------> waitlist? +---------->|cancel|                 
                                      no     +------+                 
    +                     +                                           
    |                     |yes                                        
    |                     v                                           
    |                 +----------------+                              
    |                 |notification    |                              
    |                 |request:pending |                              
    |yes              |request.mail?   |                              
    |                 |request.pick_up?|                              
    |                 +----------------+                              
    |                                                                 
    |                                                                 
    v                                                                 
                                             +------------------+     
 pick up later? +----> library desk? +------>|notification      |     
                                         no  |request:on_loan   |     
    +                     +                  |item:+>on_loan    |     
    |yes                  |yes               |task:internal mail|     
    v                     v                  +------------------+     
+---------------+     +---------------+                               
|notification   |     |request:on_loan|                               
|request:pick_up|     |item:+^on_loan |                               
|item:+>on_loan |     +---------------+                               
|task:put aside |                                                     
+---------------+                                                     

The user returns a book:

+-----------------+                       
|User returns book|                       
+---+-------------+                       
    |                                     
    |                                     
    v                                     
+------------------+                      
|request:->finished|                      
|item:->on_shelf   |                      
+---+--------------+                      
    |                                     
    |                                     
    v                                     
                         +-------------+        
 requests on item? +---->|task:put back|        
                     no  +-------------+        
    +                                     
    |yes                                  
    v                                     
                         +---------------+
 request for mail? +---->|notification   |
                     no  |request:pick_up|
    +                    |task:put aside |
    |yes                 +---------------+
    v                                     
+------------------+                      
|notification      |                      
|request:on_loan   |                      
|task:internal_mail|                      
+------------------+    

User extends a loan:

+-----------------------+                        
|User requests extension|                        
+---+-------------------+                        
    |                                            
    |                                            
    v                                            
                         +---------------------+
 requests on item? +---->|notification         |
                     no  |update request:period|
    +                    +---+-----------------+
    |yes                     |                   
    v                        |                   
+-------+                    v                   
|nothing|                                        
+-------+                 request:overdue?       

                             +                   
                             |yes                
                             v                   
                          +---------------+      
                          |request:on_loan|      
                          +---------------+      

It seems apparent that the general circulation of books comes down to changing the state of an item and/or a request from one value to another. Conversations with people managing different libraries showed that those statuses differ for every instance using a library management system of some sort. This leads to the programming approach introduced in this RFC: #3 .

[kaplun]

@mvesper I have in general one remark related to the management of the item status. When a user puts a request for a book, what the user really is doing is not to make it over a specific item (i.e. physical instantiation of a book/record), rather on the first item that is going to be available.

So an item is never really requested. This state belongs more to the record or to the set of all the equivalent items. Unfortunately this complicates a bit the design, but is important to retain.

[mvesper]

@kaplun I see the wording might be a bit confusing here. It should actually be removed completely. The "requested" state of an item is related an inter library loan. Basically when the book is on its way. Requests on an item are handled by the "Loan Cycle".

Also I can see that a user might request a specific item or whatever becomes available first.

[agentilb]

Yes, in the case of CERN Library there are 2 possibilities:

• either the record has several volumes (each item corresponds to a specific volume), all attached to the same record, in this case the request will be on a specific volume/item.
• either all items of a record are "identical" (only 1 volume), in this case the request will be on any available item.

[nietzold]

Hi guys! TIND is continuously gaining more experience on different use cases. Here are a few comments from our side that I think are not yet (thoroughly) covered:

1. Acquisition

• Metadata batches of acquired books/ebooks/ejournals typically have purchase information attached to them (order information). Can this information be categorized so that one easily can track statistics and link vendors, order value, order time, deals/packages, subscriptions, etc.?
• @aw-bib and @martinkoehler: what do you currently do with (physical) acquisitions and e-acquisitions?

2. Multiple libraries

• Should be possible to track individual statistics based on internal libraries/branches. Lot's of libraries are organized in consortium, typically sharing a library catalogue between several library branches.
• Should be possible to add custom loan rules and provide custom email templates for library branches (already mentioned)

3. Item/copy details

• Currently, this is limited to a total of 8 fields
• Ideally, it should be possible to add an 'indefinite' number of fields, depending on the complexity needs of the library. Standard fields could be: Item ID, Bibrec ID, Call no, Barcode, Permanent location, Temporary location, Item type, Enumeration, Date created, Cataloger name. Then, more optional and customizable fields could be added.

4. Advanced loan rules

Advanced loan rules should be set using four variables:

• Item type
• Library branch
• Patrons (e.g. students have different rules than staff)

5. Optional barcode

• We've encountered several cases where the library does not have a barcode. Should this ideally be optional?

6. Patrons vs. users

• Are patrons/borrowers still treated separate from users in 2.0? I.e. loan rights should be a role rather than a separate database.

PS: KOHA and ALEPH have already been mentioned as examples. There's also currently being put a lot of efforts into the development of another open source library platform called Kuali OLE (http://www.kuali.org/ole/modules). Might be worth taking a look at.

[aw-bib]

1. Acquisition:

• Perfectly agreed that packages of (especially ebooks) are a commmon use case. Besides order information you usually get the Marc for those records so easy ingestion is quite imperative. However, this tackles more standard compliance with Marc.
• physical vs. ebooks: usually you have two records, one for the book and one for the ebook. In an ideal world those would be linked in some way. IRL, however, this is hardly possible especially if you consider packages for purchase. To come closer to the ideal world, FRBR would be the way to go, IMHO. FRBRization, however, is far from trivial.

2. Multiple libraries:

Please be careful with wording. Consortium triggers quite another context here than you intend. (E.g. a consortium would be if library A together with the libraries B, C, D agree on contracts with some publisher, where A..D are completely independent playsers.)

• I agree, that you have holdings not only in one location, and that it is quite common that even circulation is handled almost independently so getting a book from one location to another locatin is similar to ILL. You may even have this "intermediary location" like "on transport" (Marc 876__$l)
• Agreed, that loan peroids per location are common. In general I think you have to have loan periods depeding as "default" on the item which may depend itself on location, but also on the users role. This is addressed in your item 4.

3. Item/copy details

I'd suggest to check out Marc Holdings, especially 852 and 876 and use them as a model of necessary fields.
I do not think that cataloguer name is relevant on the item basis.

4. Advanced loan rules

I'd call them "standard loan rules", else I agree.

5. Optional barcode

Usually every library has a thing that is unique to the item. This can also be the shelfmark or an RFID Id. I think the name "barcode" is just a bit historic. But I think you always have some unique entity for an item as such. How would you track otherwise if it is missing or on loan?

6. Patrons vs. users

I think you are right if you keep in mind, that a patron might not have any additional rights on the system than just borrow books. E.g. we also use our "to be catalogue" as the publications database. Some of our patrons will not be allowed for submission e.g. But I believe that the current role model can accomodate for this. However, it might well be that those patrons only users can not validate by some external login (ldap or the like) as they just don't have any account valid on the system. So, there is a certain need to give them local accounts.

[Kennethhole]

Here is some additional comments from my side:

3. Item/copy details
I don't think we should try to add more data based on the 852/ 876 field. That data is perfectly stored in the bibliographic metadata. That's also why we have moved the call number from the item level to the bibliographic level. So in those cases where the data can be stored in the bibliographic metadata, we should aim to do so.

From my point of view, the main reason for having more fields is to not loose information when migrating from other systems. Today, libraries kind of have to choose which data they will keep and which data they will loose when migrating to Invenio, as they often have stored more info in the old system.

6. Patrons vs. users

In the regular Invenio-user database (both 1.x and 2.0), you can only store email address and nick name. Often more information is required when you borrow a book, such as phone number and address. Might this be the reason for why a second database for borrowers have been created? Ideally you should be able to add all data into a single database. If that is difficult, the data you enter in the access module should automatically generate an account in the borrower database in circulation.

Some limitations today, which will be solved by having a single list.

• It is not possible to delete a borrower though the bibcirc GUI.
• The borrower in bibcirc is linked to the users in WebAccess though the email address. If a user updates his/her email address, the user will not be able to request loans and see your loans/ requests/ proposals and historical overview. The user has to notify the administrators so that they update the email address in bibcirc as well. A regular user should not have to deal with that..

7. Efficiency

• If you would like to merge two records today, you first have to delete the copies from one record, and add them manually to the second record. There should be a function for moving all copies to another record.
• There should be an opportunity to delete all copies simultaneously from the item detailed view.
• As of today, it is only the patron who receive an email when a loan request is made. Smaller libraries, which do not have many loans, would benefit of having the same notification sent to the library by email as well. Then they don`t have to monitor the "loan request list" all the time.
• When the library register a purchase request, it should be possible to use that data to create a bibliographic record. Then they don`t have to register the same data twice.

8. API

• As it becomes more popular to use discovery services (DS), the opportunity to read the items availability, should be available for the DS though a API. Ideally, the users should also be able to request the book from the DS. I guess this will require some sort of authentication though the API as well?

9. Other

• Before you request an ILL, you are asked to search though the catalog to be sure it`s not there. This function is much appreciated and is requested for the register of purchase requests as well. Would it be possible to enable/disable such functions though the config file?

[aw-bib]

I don't think we should try to add more data based on the 852/876 field. That data is perfectly stored in the bibliographic metadata.

Ahm, from Invenios point of view this is bibliographic metadata. It's just the correct field.

In the regular Invenio-user database (both 1.x and 2.0), you can only store email address and nick name. Often more information is required when you borrow a book, such as phone number and address.

Agreed. It just works out in CERNish or HGFish setups as we only have patrons that are "on campus".

Might this be the reason for why a second database for borrowers have been created? Ideally you should be able to add all data into a single database.

Nagging you could even use authority like records for that within invenio and place them in a collection. Probably worth thinking about. E.g. in our upcoming migration from I'll have a lot of fun, I fear, to get this data out of some strange internal tables.

It is not possible to delete a borrower though the bibcirc GUI.

Do you really want to delete him or just mark him inactive? Probably the latter is the way to go.

If you would like to merge two records today, you first have to delete the copies from one record, and add them manually to the second record. There should be a function for moving all copies to another record.
There should be an opportunity to delete all copies simultaneously from the item detailed view.

These are very good arguments for using marc holdings in 852/876 of the bibliographic record as an interface to that.

When the library register a purchase request, it should be possible to use that data to create a bibliographic record. Then they don`t have to register the same data twice.

Again using 852/876 for the "in purchase" items to mark this status and you're done. (BTW: this is something I actually just did for our invenio 1.1, where I just go over the records and write the internal tables based on those fields. They have enough data to express everything and for the cataloguer it's in one go as she is in bibedit anyway.)

As it becomes more popular to use discovery services (DS), the opportunity to read the items availability, should be available for the DS though a API. Ideally, the users should also be able to request the book from the DS. I guess this will require some sort of authentication though the API as well?

Doesn't have invenio with hosted collections just all you need for these fancy things already? Why not build it the other way round?

[Kennethhole]

Do you really want to delete him or just mark him inactive? Probably the latter is the way to go.
We have actually been asked why there is no opportunity to delete a borrower. I guess that a library have little interest of knowing which borrowers that were active ten years ago.

These are very good arguments for using marc holdings in 852/876 of the bibliographic record as an interface to that.
Yes I think I agree that adding as much data as possible in the bibliographic level is a good solution. But you will still need the copies with some data in bibcirc to handle the circulation workflows, right? So it should still be possible to move them to another record, or delete all copies simultaneously.

If we are going in that direction of storing as much as possible in 852/ 876, we should have a standardized way of linking the 852/ 876- fields to the correct items. Two options is to either keeping the call number in the bibcirc item database or moving the barcode (or other ID) over to the bib.record. Any thought or other alternatives?

Doesn't have invenio with hosted collections just all you need for these fancy things already? Why not build it the other way round?
We have looked into this as we thought it might be a good solution ourselves. The main benefit of a DS is that you can search all journals (on an article level) that the organization subscribe for. This is not easily done in your ILS as you wont have access to the metadata for each single article. Therefore, institutions, and particular academic, which need to cover a broad field of subjects, uses DS. And when they first have it, they like to import their books and IR-items as well.

[aw-bib]

Do you really want to delete him or just mark him inactive? Probably the latter is the way to go.

We have actually been asked why there is no opportunity to delete a borrower. I guess that a library have little interest of knowing which borrowers that were active ten years ago.

A common point is that (depending on the enviroment) people come back. Probably one needs both?

Yes I think I agree that adding as much data as possible in the bibliographic level is a good solution. But you will still need the copies with some data in bibcirc to handle the circulation workflows, right? So it should still be possible to move them to another record, or delete all copies simultaneously.

What I did here is store the data in the 8xx fields consider bibedit as the GUI(tm) and then just write the other stuff right from there. So you have only one point where to add it and that's the bibliographic. As soon as this is done moving entries around is just the usual copy&paste&merge&... in bibedit.

If we are going in that direction of storing as much as possible in 852/ 876, we should have a standardized way of linking the 852/ 876- fields to the correct items.

Perfectly agree. LoC gives the standard I think. This should also ease up migration.

Two options is to either keeping the call number in the bibcirc item database or moving the barcode (or other ID) over to the bib.record. Any thought or other alternatives?

I admit I did it by "everything in Marc" and then (in 1.x) just feed the backend tables from there by means of a bibtaskletish approach. I think if one could do something like the icon generator which is triggered as soon as a record is touched it is seemless.