Day 1 - FROM THE MOUSE'S LAIR
Day 2 - INTO THE RAT'S NEST
Day 3 - AND ON INTO THE LIGHT
Despite the suggested order of discussion, we jumped rapidly into the rat's nest of serials. Call us masochists.
idea: scan UPC's to simplify receiving workflow ;)
Manufacturing module in OFBiz is a good model for interacting with scheduler. Talk to calendar server.
Maybe Evergreen serials acquisitions could use a SerialsThing algorithm? Traditional serials acquisitions systems have been built around the notion that there is a calendar-like model that drives a report of issues that should have arrived when a particular issue should be claimed. Instead, a collaborative model would allow libraries to reuse patterns, claim periods / policies for given serials, find out how many other libraries have already received a given issue and trigger claiming accordingly…
o Theoretically publishers will actually start publishing information using this standard
The ISSN is the standardized international code which allows the identification of any serial publication, including electronic serials, independently of its country of publication, of its language or alphabet, of its frequency, medium, etc. The ISSN number,therefore, preceded by these letters, and appears as two groups of four digits, separated by a hyphen , has no signification in itself and does not contain in itself any information referring to the origin or contents of the publication.
(quote from http://www.issn.org/en/node/60)
ISSN numbers are assigned by the ISSN national Centres coordinated in a network. All ISSN are accessible via the ISSN Register. The ISSN is not "just another administrative number". The ISSN should be as basic a part of a serial as the title.
http://www.lcweb.loc.gov/issn/ – LC is the US national center under the NSDP - National Serials Data Program
|687||Every 3 months, on the 1st day of the month|
|579||Every 3 months, on the 31st day of the month|
|471||Annually on the 31st day of December|
|443||Annually on the 2nd day of January|
|400||Monthly, on the 31st day of the month|
|238||Every 2 months, on the 1st day of the month|
|215||Every 6 months, on the 31st day of the month|
|211||Monthly, on the 1st day of the month|
|200||Every 2 months, on the 31st day of the month|
|161||Annually on the 31st day of January and the 31st day of July|
|125||Every 4 months, on the 1st day of the month|
|124||Weekly, on the 4th day of the month|
|Count||Claim period (days)|
Action: to determine the most common serials patterns to present in an interface, Dan, Art, GPLS(?), BCPL(?) will extract the patterns for all of their serials.
Rather than step into the extremely messy world of writing code for scheduling recurring events, let's consider reusing the existing solutions for that problem–CalDAV calendar servers–that have happily sprung up in the last five years. Therefore, we started looking at CalDAV clients and servers for scheduling user interfaces and date/time logic. Using an existing standard opens up possibilities for:
Having a calendar server would also help solve other Evergreen needs, such as room & equipment booking, displaying library days + hours of operation, importing institutional / state / provincial / federal holiday schedules.
So we could pick a CalDAV server, and maybe plug-in the Lightning extension for Thunderbird (probably not, as it sounds like it truly requires Tbird) or some pure Web UI client into the staff client for scheduling purposes. Some calendar servers:
A Subscription object:
Assumption that end-to-end request tracking will be part of acquisitions. Possible workflow:
Please consider being able to set various types of limits on the requests, like number of outstanding requests. Number of requests in a 30 day period, etc. This might be useful for organizations that want to reign in users that abuse the request feature, forcing the user to choose their items carefully. Also, it might be usefull to link certain users requests to a certain funding source. For example, if Professor X, Professor Y, and Professor Z used this to acquire new research materials, and they are all in the same department, they would all be linked to that departments book budget, and wouldn't be able to request materials with a total cost 10% over their budget.... or something like that. Josh -- Lake Agassiz Regional Library - Moorhead MN larl.org Josh Stompro | Office 218.233.3757 EXT-139 LARL Network Administrator | Cell 218.790.2110
Ideally Evergreen will implement vendor discovery APIs that enable a person placing an order for an item to submit a search from within the staff client that will query one or more vendors and enable the person placing the order to choose the preferred vendor (based on item cost, or ship time, or format).
No effort will be placed on screen-scraping vendor Web sites for this kind of information. Only vendors that expose a discovery API will be supported. The reference implementation would probably be Amazon. Hopefully vendors will realize the benefits of enabling a customer to search for items from within the Evergreen staff client and minimize the current copy and paste drudgery required between Web browser and ILS outweigh the increased competition vendors will face if these cross-vendor search results can easily be compared.
A simple discovery API could be built on OpenSearch with result enrichment for price / estimated ship date by shipping method / format. Some authentication may be required to enable the vendor to calculate discounts for customers.
No attempt is made at Laurentian to find the best price or best ship time estimate.
Of course, not all orders will be able to be submitted via the integrated vendor discovery; so Evergreen will still have to support manual order placement.
Order requests could be fed in directly from the entirely theoretical requests functionality of Evergreen; depending on the amount of bibliographic information in the request, search could be fired off automatically or augmented by the human.
For LU, collection librarian requests might simply be placed directly as an order by the librarian themselves, rather than the current paper loop of librarian → acq office → technician.
Mike gave a nice walk through of the current reporting interface in the staff client. To generate a report, you start by creating a report template and then create a report based on that template. The reporting interface enables you to browse through the database schema, defaulting to the most commonly required views but giving you the ability to access any field from any table. You can choose fields from various views, apply transforms to those fields, filter output based on those fields or other fields. Output formats are CSV, Excel, HTML, as well as basic line and bar charts.
More complex reporting could be performed by exporting data in CSV format and pulling the data into Eclipse BIRT. Enhancements