Print

Print


EnumerationAndChronology sounds like a bad name to me, no matter what it
means.

On Mon, 14 Dec 2015 at 22:16, Hess, Kirk <[log in to unmask]> wrote:

> 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]
> *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] <[log in to unmask]>]
> *Sent:* Monday, December 14, 2015 1:44 PM
> *To:* [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] <[log in to unmask]>] *On Behalf
> Of *Karen Coyle
> *Sent:* Monday, December 14, 2015 10:21 AM
> *To:* [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] http://kcoyle.net
>
> m: +1-510-435-8234
>
> skype: kcoylenet/+1-510-984-3600
>
>