LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  December 2015

BIBFRAME December 2015

Subject:

Re: bf:enumerationAndChronology

From:

Bill Dueber <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Mon, 14 Dec 2015 22:13:05 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (204 lines)

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

>Hi,
>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.
>
>Thanks!
>Bob Sandiford | Principal Engineer | SirsiDynix
>P: 800.288.8020 X6943 |
[log in to unmask]<mailto:[log in to unmask]>
>www.sirsidynix.com<http://www.sirsidynix.com/>
>
>Join the conversation: Like us on Facebook!<http://www.facebook.com/SirsiDynix>
Follow us on Twitter!<http://twitter.com/SirsiDynix>
>
>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: http://catalog.hathitrust.org/Record/100166115
>So with the first issue available chronlogically v.3: no.1 (1894)
<http://hdl.handle.net/2027/uiuc.1751155v3i1>
>If the handle was serving RDF the item would be something like...
><http://hdl.handle.net/2027/uiuc.1751155v3i1>
> a bf:Item ;
> rdfs:label "v.3: no.1 (1894)" ;
> bf:enumerationAndChronology "v.3: no.1 (1894)";
> bf:itemOf <http://bibframe.org/resources/TXz1450123897> .
>
>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
BF.
>
>- 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"
>OR
><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
>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.
>Joe
>
>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.
>
>kc
>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]> http://kcoyle.net
>
>m: +1-510-435-8234
>
>skype: kcoylenet/+1-510-984-3600
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager