Print

Print


A few latecomer thoughts on this already thoughtful discussion--

The difference between series represented by series statements only and those provided with standard access is better understood in terms of local decisions about access than some inherent property of different series.  I agree with Karen's comment that series statements should be purely descriptive and not beholden to access requirements.  The use of an identifier for a string to simplify repetitive data entry for series statements makes some sense, but is it really an identifier if it's only for a string, not an entity? 

The FRBR solution to the relation between work and series is hiding in the concept of the aggregate work.  A given text may appear within a series-designated volume in one publication and without the series in another publication.  For FRBR, the text is an expression of a work, but the two publications are also works--aggregate works combining the text's work with other components.  So the series has a work-to-work relationship with the aggregate work which contains the text work, and not with the text work itself.  The exception would be cases where the series relationship is really a part relationship involving the text work, as between a book and the trilogy it belongs to.  In such cases, the text work could have a part relationship to a larger text work while the publication work where it appears might have a series relationship to a particular edition of the trilogy, which would not be a true relationship between the text work and the series work.

I prefer models which treat series entities as separate entities with a relationship to items in the series and make the series entity description the locus for some of the series data elements that Joe and Theo discuss. The issues for implementing that model are as much organizational as structural.  The ability to create community-level series authorities is limited to a subset of NACO members in our community, as the ability to create community-level serial records is limited to CONSER.  There would need to be a way to extend the ability to create such community-level work to a larger pool of contributors if creating series entity descriptions becomes part of cataloging expectations generally.     

Lastly, regarding numbered series.  The relationship between a publication work and a numbered series is really different from that for an unnumbered series.  The latter relationship is fairly simple, while the former is better understood as not just a relationship but an alternate designation of the publication work.  Numbered series might better be modelled on the coding of standard numbering systems, with the series identifier specifying the system within which the number has significance, as "isbn" specifies the system for a specific number string. The way series numbers have been treated as appendages to the series title may read easily, but it's a case of a tail that needs to wag its dog in terms of data.

Stephen

  

On Fri, Jul 24, 2015 at 3:29 AM, Bernhard Eversberg <[log in to unmask]> wrote:
 24.07.2015 03:25,  Karen Coyle:

One thing I think that we have failed to do (as a profession) is to
bridge the gap between the intent of the cataloging rules and the actual
functioning of the technology that will manage the data that is created
in the cataloging workflow.

That's not exactly a new observation.
As I recall, back in 1984, there was an extended thread in AUTOCAT on
the subject of the OPAC interface, and the complete lack of guidelines
for its search and display features. The subject headline was "Face the
Interface". Subsequently, years later, Martha Yee (on behalf of IFLA)
published a study on OPAC design guidelines.
All of that was of no effect, and now RDA (cherished "New International
Standard") does even less to support standardization of search and
display and navigation features. So you can rightly call it a failure
of our profession, and not a small one.
Well, here's a challenge for the up and coming Generation BIBFRAME!

B.Eversberg



--
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID:  0000-0002-3590-1242
https://listserv.loc.gov/cgi-bin/wa?A3=ind1507&L=BIBFRAME&E=quoted-printable&P=752656&B=--001a114e7990142991051bbe755a&T=text%2Fhtml;%20charset=UTF-8&XSS=3&header=1
listserv.loc.gov
crawl=CC-MAIN-2021-49
6479
application/http; msgtype=response
sha1:VJV2SGKEK2WWDAH2AUJEKMI6UNNGCQ64
<urn:uuid:6922ec2a-8e72-4ba8-a8dc-540879e9c861>
2021-12-05T18:23:48Z
140.147.239.86
text/html
sha1:OW76HJJJ7VGBLSFCQYWZZ7Q2UKRRNL4I
<urn:uuid:216779f3-65a6-44cd-a578-8e375eb7584e>
https://listserv.loc.gov/cgi-bin/wa?A3=ind1507&L=BIBFRAME&E=quoted-printable&P=752656&B=--001a114e7990142991051bbe755a&T=text%2Fhtml;%20charset=UTF-8&XSS=3&header=1
response
<urn:uuid:a6b3c812-7d5b-4ce1-b94e-1cd01ae91c81>
isPartOf: CC-MAIN-2021-49
publisher: Common Crawl
description: Wide crawl of the web for November/December 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-203
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.3-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/