I've added my code just above the section of the XSL file that starts with:

<!–
************************************************
Javascript
************************************************
–>

Would you mind tell me where I can add the script in the fullnonmarcbib.xsl stylesheet ?

Thanks

http://www.daveyp.com/blog/index.php/archives/69

I have posted a couple of times recently about intentional data, data that records choices and behaviors. I mentioned holdings data, ILL records, circulation records, and database usage records. One could extend this list to any data which records an i…

If you've not seen what Amazon Web Services have to offer, then have a look at this sample XML output:

http://www.daveyp.com/blog/stuff/032112247X.xml

…down at the bottom, there's a section marked "SimilarProducts" - those are the ISBNs Amazon use for their "Customers who bought this book also bought".

All you need to do is to cross-reference the Amazon ISBNs with those in your database - if you get a match, display a link.

Casey's second suggestion would ideally suit an academic institution, as student borrowing trends at specific times in the year could partly depend upon the modules they were studying.

If you were to view the student's entire borrowing history (e.g. over 3 years), then it would contain (in part) an amalgamation of all of their module topics.

However, sample the data every 90 days and you get a clearer selection of which titles to suggest to another borrower that will (potentially) be the most relevant to them at that moment in time.

For example, if a student took a three year course in Java then you'd expect them to begin by borrowing books like "Dummies Guide to Java" and "Learn Java in 21 Days". By the end of the course, they might be on to "Advanced Agile Java Development using Scrum"***

Their entire borrowing history would be a mix of Java titles, whereas a 90 day sample will group together Java titles at a similar skill level.

*** - After graduation, they will of course be rounded up by a press gang led by Jack Blount (wearing an eye patch and a suspicious looking parrot on one shoulder squawking "Pieces of 8.0! Pieces of 8.0!")

I have two ideas on this subject:

1) You have a trusted 3rd party (preferably in a country with no extradition treaty) "launder" the data — encrypt the borrower#'s with an encryption key that you don't know, only they know. So borrower #123 will always get encrypted as "7xl3" or something. That way, you can keep circ history indefinitely without having it tied to the borrower at all. If you get visited by the feds, they have no way of decrypting the borrower#'s since you don't have the key.

2) Say you are allowed to keep circ history data for a relatively long period of time but not forever (90 days, say). Every 90 days, you encrypt the borrower#'s in the circ history with a one-time pad (basically, a completely random encryption key that is never reused so the only way to crack it is by brute force). So say 1st quarter of 2005, borrower #123 gets encrypted as "7xklj" and 2nd quarter of 2005, borrower #123 gets encrypted as "823w". You have no way of knowing that "823w" is the same person as "7xklj" but you can still know that borrower 7xklj checked out so and so books in a 90 day period. Basically it would make it so you could figure out "borrowers who checked out x also checked out y within 90 days of each other" but again, there's no way to decrypt any of the data older than 90 days — or make inferences between what happened 3-6 months ago and what happened 0-3 months ago.

If you only keep circ history for a few days like we do, the method is basically equivalent to what Davey describes but much messier.

Finally, you don't have to collect any data yourself to offer such a service. You could just use Amazon Web Services.

There are several methods of turning a borrower number into something else (e.g. a MD5 hash), but none really fully erase the trail back to the original borrower.

If you have a high circulation turnover, then the alternative would be to store each of the bibs of the items that a borrower checks out at the same time - e.g. if someone goes to the issue desk with 5 items, record those 5 bibs together. However, don't store anything about the borrower - just record the bib numbers:

1857,47265,901,11367,91375

As each borrower checks items out, you'll get strings of bibs to add to your database…

857,37562,9582,901,1857 (5 items checked out)
7464,1725 (2 items checked out)
3874,58948,857 (3 items checked out)

Then, to generate suggested items for bib# 901, you'd need to:

1) search though all your strings of bibs and collate all the ones that contain a "901":

1857,47265,901,11367,91375
857,37562,9582,901,1857

2) count how many times each bib occurs in the collated list

Then present the ones that occured the most as the suggested items (e.g. 1857).

Think of it more as a "people who borrowed this item, also borrowed these items at the same time…"

At the very worse, all you could deduce from the database would be that at some point in the past, someone borrowed these specific books at the same time. There would be nothing to help to work out who they were, when they borrowed those items, or if they ever borrowed again.