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)
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 <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.
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:
(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
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.
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 Coylem: +1-510-435-8234skype: kcoylenet/+1-510-984-3600