[OPEN-ILS-GENERAL] RE: Serials Management

[Stuart Miller]

"Olga" is a table. Don't ask--you don't want to know, believe me.

As far as I know, any exported pattern will have the same data--I've attached a few more examples if you'd like to take a look.

Stuart Miller

-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of David Fiander
Sent: Tuesday, September 16, 2008 6:55 PM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] RE: Serials Management

Stuart,

Thanks. It's just a CSV spreadsheet with several different tables
glued together, by the looks of it. They were at least kind enough to
include headings for the columns, but you are right: it is pretty
inscrutable.

Interestingly enough, the "note" field in the first table
(affectionately referred to by Horizon developers as "Olga" for some
reason) is actually a MFHD caption & pattern field:

    $83$a[v.]$b[no.]$u4$vr$i(year)$j(season)$wq$x21

First level enumeration is volume # (not printed on the item),
Second level enumeration is issue # (not printed on item),
There are four issues in a volume,
Issue numbering resets every volume (that is, issues are not
continuously numbered)
Alternative chronological enumeration is year and season
It's published quarterly
New volumes begin with the Spring issue

Is that note field something that all of the export files have, or is
it coming from somewhere else, do you know?

- David

On Tue, Sep 16, 2008 at 4:58 PM, Stuart Miller <stuartwm at uchicago.edu> wrote:
> You can export a pattern from Horizon--I've attached the one for the journal Ballet Review (a very simple one) and the users have developed a repository of patterns as there is an import function as well.
>
> I opened the attached using Notepad and I can make sense out of it (with a lot of squinting and looking at the Horizon client), but I don't know if it will make sense to anyone who doesn't know Horizon. If you can discern it, I can always send you some of our real stinkers.
>
> Stuart Miller
>
> -----Original Message-----
> From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of David Fiander
> Sent: Tuesday, September 16, 2008 3:40 PM
> To: Evergreen Discussion Group
> Subject: Re: [OPEN-ILS-GENERAL] RE: Serials Management
>
> Stuart,
>
> I have just started working on code to read MFHD records, and I can
> tell you that the pattern stuff in the standard is pretty expressive.
> But the more real-world examples we can get our hands on, the better.
>
> Does Horizon provide some other format for exporting / importing
> holdings data, even if it's only for sharing with other Horizon
> systems?
>
> I have started to think that serials issuance patterns are something
> that should be shared: it's not like I get different issues of the
> Economist or Lancet than you do, so why should we duplicate the effort
> of describing the pattern?
>
> That is, of course, a completely different project from
> exporting/importing holdings data and making predictions about when
> the next issue should arrive.
>
> On Tue, Sep 16, 2008 at 3:19 PM, Stuart Miller <stuartwm at uchicago.edu> wrote:
>> Dan,
>>
>> This may be an issue of semantics. When I hear someone say that they are going to use MFHD to express pub patterns to generate predictions, I think "records of variable length fields are NOT good candidates for something like prediction." If you're talking about Evergreen being able to import pattern data from an MFHD file, that's something else. And yes, we can probably export our pattern data in MFHD but that will be a custom program we'll need someone to write. Horizon never supported MFHD, and now never will. Unicorn and other ILS products may indeed be a different story.
>>
>> But of course getting patterns is only half the battle. The other one is writing the prediction algorithms to interpret the plethora of patterns represented by 20,000+ serial titles. We have patterns of the "every other alternate month when the moon is the 7th house, the 3rd issue of the then current volume combines with the 4th issue and that issue has only mm/yyyy, not mm/d/yyyy as usual and we only have 3 issues per volume instead of 4" type. [I'm only half-joking, unfortunately.]
>>
>> Stuart Miller
>>
>> -----Original Message-----
>> From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Dan Scott
>> Sent: Monday, September 15, 2008 10:08 AM
>> To: Evergreen Discussion Group
>> Subject: Re: [OPEN-ILS-GENERAL] RE: Serials Management
>>
>> 2008/9/15 Stuart Miller <stuartwm at uchicago.edu>:
>>> I know that 1.4 and 2.0 will introduce support for MARCH Holdings format. I had not heard that anyone was looking at using it for claims or predictions and if that's true, I am very dubious--the only system that I know of that actually built serials management on MARC holdings was the old NOTIS LMS--and even the product manager who designed it admitted that basing it on MARC was, in the end, a bad idea. I believe all other ILS products just constructed their own algorithms and I don't think most of them even got around to exporting the data in MARC (except some did export summary holdings, I think--we can, but only with a custom program from a consultant; the vendor never supplied one, presumably due to lack of demand??).
>>>
>>
>> Stuart - wow, that's a pretty negative set of statements.
>>
>> Just to ensure that we're talking about the same thing here, the idea
>> was to use MFHD primarily to express publication patterns
>> (enumerations and chronology), so that one can generate predictions.
>> We were also planning on being able to export MFHD and to generate
>> compressed or uncompressed holdings displays.
>>
>> One assumption is that those using serials management today will be
>> able to export publication patterns in MFHD from their legacy system
>> that we can then migrate into Evergreen without painfully recoding
>> every pattern. Unicorn, for one, does support MFHD export for serials
>> patterns (at least I _think_ it does; now you've got me wanting to go
>> back and see whether it's simply regurgitating whatever is in the
>> 85x/86x fields in the bib record - curse you!). I'm sure you wouldn't
>> want to recode 20,000 publication patterns for your serials; is there
>> a better alternative than MFHD for serials patterns and holdings
>> information that you have in mind for an intermediate format? Maybe
>> sets of cron patterns are the answer for a lingua franca
>> (http://open-ils.org/dokuwiki/doku.php?id=acq:serials:patterns - he
>> says, half jokingly).
>>
>> Another assumption is that staff would be shielded from most of the
>> complexity of manipulating MFHD patterns by a nice user interface.
>>
>> Also, MFHD support isn't planned until 2.0. We don't want to get hopes
>> up too high for the 1.4 release!
>>
>> Of course, all of this is subject to actually getting some code on the
>> ground and running through some real data.
>>
>>> I really can't, in an email, detail the complexities of managing thousands of print serials that run the gamut from very vanilla to very complex enum/chron patterns. I've attached a statement of baseline acq/serials requirements that we developed inhouse for use in evaluating systems. It doesn't get into a lot of details, but it may be of some interest.
>>
>> Yep, it's certainly of interest. If you can generate a list of the
>> serial patterns in use at your institution to contribute to the data
>> that we have collected from Laurentian and Windsor, that would be
>> useful information too.
>>
>> --
>> Dan Scott
>> Laurentian University
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: United_States_code.hzp
Type: application/octet-stream
Size: 838 bytes
Desc: United_States_code.hzp
Url : http://list.georgialibraries.org/pipermail/open-ils-general/attachments/20080917/a4e4e651/United_States_code.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Physical_review__A_.hzp
Type: application/octet-stream
Size: 1403 bytes
Desc: Physical_review__A_.hzp
Url : http://list.georgialibraries.org/pipermail/open-ils-general/attachments/20080917/a4e4e651/Physical_review__A_.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: United_States_coast_pilot__2__.hzp
Type: application/octet-stream
Size: 1139 bytes
Desc: United_States_coast_pilot__2__.hzp
Url : http://list.georgialibraries.org/pipermail/open-ils-general/attachments/20080917/a4e4e651/United_States_coast_pilot__2__.obj