On 7/25/15 8:01 PM, Stephen Hearn wrote:
[log in to unmask]" type="cite">
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. 
The odd thing about this statement is that there is nothing in the act of cataloging that creates "access." Cataloging creates display strings. Display strings were once ALSO the technology of access in the physical alphabetical catalog. Access today is a system design function that is not one-to-one with display.

In other words, the decisions that are being made in the process of cataloging are not necessarily informing actual access. I know that this frustrates the heck out of catalogers, but if we want cataloging and access to be somehow cohesive then cataloging needs to address the technology that provides access.

[log in to unmask]" type="cite">
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?
If it has a name, then in real life it is an entity. You may consider "Discworld series" to be a string, but there is an actual series with that name, and although catalogers deem it to be lesser than a numbered series, it is still real. So the identifier is for the entity.

More could be said about FRBR and aggregates, but that's a can of worms that we won't come to any conclusions here.

<snip>
[log in to unmask]" type="cite">

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.

This is an interesting aspect of numbered series that I hadn't considered before -- that the series name and number identify a publication. I can see how this has value in an inventory, similar to the enumeration in serials. However, it is probably rare that any publication is known to users solely or even mainly by its series and enumeration, any more than journal articles would be known by their serial title and enumeration rather than by the author and title of the article. So I understand this distinction, but I do think we have to ask: what does it mean functionally for the user? Is it truly an access point? Or... is it a bibliographic relationship that can be used for identification and collocation? Bibliographic relationships were treated in the past the same as access points because that was the only way to have collocation, but we can now collocate via links, so it may be useful to consider that navigation between bibliographic entities using links is not the same as access via searchable headings. In fact, what FRBR provides is not a record model but a model of collocation based on bibliographic relationships that can be used in a computerized catalog, something that we were not able to achieve with flat records stored in database management systems. I think this is the key take-away from FRBR and linked data, which is that linking provides a richer form of collocation than we had in the physical catalog, and some of the practices in that catalog were kludges to create some crude collocation through alphabetical order.

kc
[log in to unmask]" type="cite">

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

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600