On Mon, 14 Dec 2015 21:27:35 +0000, Bob Sandiford <[log in to unmask]> 

>Parsing a label or the enumerationAndChronology as suggested in the example is a non-
trivial event.

+1 to this. Dealing with the easy 60-70% is, well, easy. The number of edge cases, though, 
is enormous. I've been working off-and-on on a PEG parser to try to deal with the 
normalish stuff, but any text parser is going to have loads of ambiguous parses. (e.g., "no 
1-4" is a range, "no 1-93994" is a single identifier). 

Going forward, explicit listing of every issue, abstract, index, summary, etc. is clearly the 
way to go (at the machine level) with the display logic turning that into summary holdings.  
Looking backwards, well, we're just going to have to live with what we have. The truth is 
that a lot of what's recorded in MARC records is the result of someone saying, "Hey, 
someone make a pile that's about 2-3 inches tall of whatever's laying loose on that shelf 
and send it to the bindery for a hard green cover."

And you'd like to think that the year is pretty easy to pull out, but at least some people (I'm 
looking at you, govdocs) chose to use three digits for the year (leaving off the initial '1') for 
a while. 

  For example:
>-          Different labels for the enumeration, (v. vol., no., #, etc)
>-          Different languages for the enum labels.
>-          Different enumeration - Arabic numerals, roman numerals, etc.
>-          Special editions - indexes, and such.
>-          While year is usually fairly easy to pull, the chronology will often include months - 
abbreviations, multi-lingual, etc, as wel as potentially day of month, and varying formats of 
displaying that chronology.
>Being able to understand all of this is a requirement if one is to collapse multiple 
consecutive issues (Items) into a condensed display format (e.g. "Vol. 1 No. 2 - Vol. 3 No. 6 
(Feb 2012 - Jun 2014)" or something comparable...
>All this to say - if there were some way that the enum levels and the chron date could be 
kept in a more 'program friendly' manner, that would be helpful.  If not, we'll do the best we 
can with the extensive variation of an enum / chron statement.
>Bob Sandiford | Principal Engineer | SirsiDynix
>P: 800.288.8020 X6943 | 
[log in to unmask]<mailto:[log in to unmask]>
>Join the conversation: Like us on Facebook!<> 
Follow us on Twitter!<>
>From: Bibliographic Framework Transition Initiative Forum 
[mailto:[log in to unmask]] On Behalf Of Hess, Kirk
>Sent: Monday, December 14, 2015 3:57 PM
>To: [log in to unmask]
>Subject: Re: [BIBFRAME] bf:enumerationAndChronology
>Thanks for your comments - I thought bf:EnumerationAndChronology was supposed to 
be used similar to how HathiTrust models enumcron as local field 974$z in the bib api 
(955$v at ingest).
>For example:
>So with the first issue available chronlogically v.3: no.1 (1894)
>If the handle was serving RDF the item would be something like...
>          a                                           bf:Item ;
>          rdfs:label                            "v.3: no.1 (1894)" ;
>          bf:enumerationAndChronology "v.3: no.1 (1894)";
>          bf:itemOf  <> .
>You could write programs to separate out the parts of these statements for indexing or 
display in a discovery system. The statement text in the thread's examples are all pretty 
consistent so you could regex the dates/children from the statement and put the editorial 
comments in a note.  I thought it would be nice if the chronology was separated from the 
enumeration but dates are usually pretty easy to programmatically extract. Ideally, you'd 
add this generated data as local properties which would help us improve future versions of 
>- Kirk
>From: Bibliographic Framework Transition Initiative Forum 
[mailto:[log in to unmask]] On Behalf Of Fallgren, Nancy (NIH/NLM) [E]
>Sent: Monday, December 14, 2015 2:56 PM
>To: [log in to unmask]<mailto:[log in to unmask]>
>Subject: Re: [BIBFRAME] bf:enumerationAndChronology
>Going forward, I would like to see summary holdings statements created 
programmatically from item data.  Do the examples Joe offered need to be manually 
created strings in a summary holdings statement?
>>1-86 (1941-1987) Some issues missing
>Would it be more useful for a program to read the volume nos. of the individual items, 
stop when the sequence is incorrect to insert a comma, pick up at the next number, and so 
on.  Then a user could actually see the missing volumes/breaks in sequence, e.g. if vol 3 is 
missing, the statement might display the holdings summary like this:
>  1-2, 4-86
>1941-1942, 1944-1987
>(note that I'm also advocating splitting enumeration and chronology into two properties - 
there is no place for "and" in predicates)
>>Supplements 1910-1916 Bound with other issues for the year
>Is this really holdings info or is it shelving info? Does it belong in a holdings summary 
telling the user what we have in our collection or does it belong with the individual item as 
a help toward finding it on the shelf?  They are different functions.  As Item data, this could 
actually be stated as a relationship with URIs rather than with strings, e.g., <URI for 
Supplement 1910> <bound with> <URI for X>?
>>1937-1942, 1946-1968, plus 1969/1978 cumulative vol.
>This might be handled similarly to first example above, where an item that falls outside 
the regular chronology or enumeration pattern or has a different predicate is added to the 
summary per library provided program specs, e.g., volumes/issues with a different 
sequencing pattern could be added to the end of the regular enumeration or chronology 
pattern:  1937-1942, 1946-1968; cumulative volume 1969-1978.  The triple for the 
cumulative volume might look like
><Item URI> <chronology> "cumulative volume 1969-1978"
><Item URI> <seriesSequence> "cumulative volume 1969-1978"
>I'd really like to see programs do more of this heavy lifting for us and for us to think more 
about formulating data so they can.
>Nancy J. Fallgren
>Metadata Specialist Librarian
>Cataloging and Metadata Management Section
>Technical Services Division
>National Library of Medicine
>From: Joseph Kiegel [mailto:[log in to unmask]]
>Sent: Monday, December 14, 2015 1:44 PM
>To: [log in to unmask]<mailto:[log in to unmask]>
>Subject: Re: [BIBFRAME] bf:enumerationAndChronology
>BIBFRAME does not, and should not, support all library management functions.  In the 
area of holdings, which is related to circulation, there is a lot of detail that should remain in 
the ILS.  That said, there is crucial user-facing information, available now in library 
catalogs, that must be part of BIBFRAME.  In order to support the user task "obtain", we 
need to give users basic information about our holdings.  This is as true in a linked-data 
environment as in the current one.
>In my comments on the Item proposal, I have focused on information needed by users.  
Usable summary holdings statements for serials and multivolume monographs is some of 
that crucial information needed in BIBFRAME.
>From: Bibliographic Framework Transition Initiative Forum 
[mailto:[log in to unmask]] On Behalf Of Karen Coyle
>Sent: Monday, December 14, 2015 10:21 AM
>To: [log in to unmask]<mailto:[log in to unmask]>
>Subject: Re: [BIBFRAME] bf:enumerationAndChronology
>Joseph, this brings up a niggling question that continues to bother me, which is the scope 
of BF. The detail that is needed to feed a serials control system is... well, very detailed. It's 
also something internal to systems and, although shared among libraries (sharing 
publishing patterns, for example), it's at a whole different level from, say, identifying 
authors or describing works. It's supply chain information, not KOS-type information. So is 
there one BF that is expected to cover bibliographic description, KO, and all library 
managements functions? Or would it make sense to have interlocking parts that can be 
used as needed? The MARC bib vs. holdings is starting to look good to me.
>On 12/10/15 11:00 AM, Joseph Kiegel wrote:
>The Item proposal does not provide detail on how the property 
bf:enumerationAndChronology is meant to be used.  A single property with a literal value in 
BIBFRAME is a much simpler approach to holdings information than the current data 
structure in MARC.
>The name of the property may lead one to think that the property is equivalent to fields 
863-865 in the MARC holdings format, but this must not be the case because numeric, 
alphabetic or date designations alone without captions (fields 853-855) are useless.
>A more reasonable approach is to assume that bf:enumerationAndChronology is the 
equivalent of textual holdings (fields 866-868).  Examples would be strings such as:
>1-86 (1941-1987) Some issues missing
>Supplements 1910-1916 Bound with other issues for the year
>1937-1942, 1946-1968, plus 1969/1978 cumulative vol.
>One problem is that there is no distinction between three types of holdings information 
that are currently differentiated:  the basic bib unit, supplementary material, and indexes.  
The examples above are the basic unit, supplementary material, and indexes, respectively.  
It seems that additional text should be added to differentiate these cases, in the interest of 
clarity for users.
>Another problem is that literal statements are not machine actionable; the obvious use 
case is ILL.  In most situations this will not matter because component items are readily 
available for machine action.  This is not always true, however; for example, for analyzed 
serials and multipart monographs.  In this case a textual statement of summary holdings 
will be found on the main instance while items are on the analyzed instances, which will 
take more processing to gather and analyze.  For performance reasons, this analysis is not 
likely to be done.
>Further, expandability of a textual statement by algorithm cannot be assumed.  While true 
some of the time, it will not always be true, such as the first example above (which issues 
are missing?).  There is no way in the proposal to mark which statements are expandable, 
if you wanted to rely on this approach.
>Karen Coyle
>[log in to unmask]<mailto:[log in to unmask]>
>m: +1-510-435-8234
>skype: kcoylenet/+1-510-984-3600