Print

Print


Karen,

The questions you pose are great. We know that URIs will identify entities in linked data, but we haven't really nailed down the roles strings have played in MARC that entity labels and data values will need to continue to perform. 

For example, in my last email I posed the possibility of adding a bf:nonSort property for what has been handled in MARC with non-filing characters. It's unclear (at least to me) how long we need to bother with recording this information. There are sophisticated methods for building index sort values, but different languages seem to present different challenges. Not to mention, you could get a children's book titled and about the letter "A".

-Steven

On Jul 23, 2015, at 9:26 PM, Karen Coyle <[log in to unmask]> wrote:

Joe, as stated, the RDA rules are "technology neutral." I don't think that they say that a string can't be represented by an identifier so that one doesn't have to write "Penguin Classics" over and over again when recording the series, any more than it would state that one couldn't select a series title from a list of existing series titles. Any string that is likely to be repeated could be assigned an identifier. In fact, this is often what happens inside a database management system for repeated strings, especially those that are indexed, so it is already a fact of our existing systems.

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. If the cataloging rules require "recording series information", does that mean that the information is intended for display? for search? what kind of search? "Recording" doesn't answer those questions, but they do need to be answered. A lot happens, or should happen, after the cataloging data is created, and we don't seem to have a clear specification of what that is.

kc

On 7/22/15 8:34 AM, Joseph Kiegel wrote:
[log in to unmask]" type="cite">

There is a need for both.  Cataloging codes, like RDA, require recording series information, and that is why bb:seriesStatement is needed.  Some libraries (but not all) additionally provide a link to a related series work, and that is best done, of course, with an identifier.  Neither of these two mechanisms replaces the other:  both are necessary.

 

Joe

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Wednesday, July 22, 2015 8:00 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal for treatment of series in BIBFRAME

 

Nate, I buy that as long as there are only two options:

1. series statement that is a plain string
2. series entity with an identifier

It makes little sense to create a blank node when an identity can be created. True, there will not be authoritative identifiers for all (or even most?) series, but merging can take place over time until most series have a useful identifier.

The bottom line is that there is no reason not to identify series where one can.

kc

On 7/22/15 6:35 AM, Trail, Nate wrote:

Itís pretty clear that sometimes a series is just a statement and sometimes it can be a work in itsí own right, so we need both bf:seriesStatement and bf:series/bf:Work to accommodate both.

 

Nate

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Tuesday, July 21, 2015 11:39 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Proposal for treatment of series in BIBFRAME

 

Joe and Theo,

This is clearly a well-thought out bit of work. I assume that the blank node solution is viable, but I wonder if you contemplated another possibility: that the series is a bibliographic entity on its own that has a relationship with monograph? This would make sense given that:
 - a series is a work in its own right
 - there can be catalog entries for the series itself
 - some series have authority records

The advantage of this solution is that it identifies a series with a persistent identifier that would allow one to link all members of the series, e.g. to show a list of monographs in the series. The disadvantage is that it has to solve these problems:
1. what to do with series that usually do not get authority control (e.g. the publishers' series) (my take: treat them as entities and give them an ID)
2. at what "level" to link a series to a bf:Instance (the bf:Work for the series?)

The #2 question there is one that is even more complex with FRBR, but is true for all multi-entity bibliographic models, which is that bibliographic relationships need to be made between entities and it isn't always clear which entities are appropriate for the relationship. In this case, the series as a bf:Work is manifested as a group of bf:Instance's with a "partOf" relationship. There's no single publication that is the bf:Instance of the series. Perhaps this has already been resolved in how serials are handled in BIBFRAME, though. Hopefully someone can weigh in on that.

kc

On 7/20/15 10:33 AM, Joseph Kiegel wrote:

Series are complex and need a more detailed treatment than has been provided to date.  Theo Gerontakos and I have written a proposal with a way to handle them.  It is attached, and also available at:

 

http://www.lib.washington.edu/msd/pubcat/ld/uw-series-proposal

 

 

Joe Kiegel

 

 




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



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

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