Print

Print


Jeff, I don't think that John's reply had to do with consistency. I think it had more to do with being able to propagate additions and corrections throughout the bibliographic space. This is exactly what some of us hope linked data will facilitate.

I remembered, reading John's post, of studies I read while in library school where researchers were trying to figure out how to link newer scientific articles to older articles where the terminology was different. The idea was that you could use citation indexing to link newer terms to the older articles that were cited many citations deep. It had problems, of course, but I think those researchers were anticipating linked data -- which is, after all, what citation indexing is about.

kc


On 5/28/13 7:41 PM, Young,Jeff (OR) wrote:
[log in to unmask]" type="cite">
In some ways, I think we worry too much about consistency and normal forms. It's almost like the MARC record community has been shooting spit-wads at relational databases for decades because they didn't scale. Suddenly Linked Data comes along and looks like a globally-scalable relational database that needs us MARC folks to either a) sort out into a global 3rd normal form or else b) pat each other on the back because graphs are ultimately just records, which means we were right all along anyway.

Jeff

Sent from my iPad

On May 28, 2013, at 9:23 PM, "Myers, John F." <[log in to unmask]> wrote:

The work I did was over a decade and a half ago.  I'm not certain the OPACs of my then employer had migrated from dumb terminals to workstations yet.  The web was just catching our notice, so no, URIs were not part of the work.  It was even long before OCLC's Expert Community initiative, so the edits were all restricted to the local database even, more's the pity.

The project though dealt with adding fictitious character subject headings where needed.  And each character typically had a cluster of associated headings for their class of people, etc.  A lot of this effort involved distinct works -- e.g. adding "Kinsey Millhone (Fictitious character)" to _A is for Alibi_, _B is for Burglar_, etc., so not much help from a WEMI tree/cascade there.  But there were enough occasions where the library held multiple frbr:manifestations -- lots of regular- and large-print couplings, but also multiple editions for older works.

I have been mindful in the ensuing years of this dynamic when cataloging later editions of older titles of all varieties of literature and non-fiction.  If a new edition of a literary classic has subject analysis provided, is it not reasonable that all editions should be similarly enhanced?  If a new edition of a non-fiction title benefits by subsequent development of a subject area, shouldn't older editions be updated?  All of this would provide some improvement in the degree of consistency for the user's experience.  It would also expose all editions to a given subject search, thereby offering alternatives should the most recent (formerly the only one so exposed) not be not available.  To restate my previous argument, just as links from a name authority record today can allow changes in the name formulation to be populated throughout all associated bibliographic records (where such linking is supported) rather than requiring each to be individually updated, so would a linked tree from Work to Expression to Manifestation allow subject relationships to populate through the tree when the subject relationships at the Work level were modified.

As to "equivalent entities," I see that my entire sentence is not clear.  It is not in reference to project of enhancing bibliographic records but to a desire for the future.  I am advocating that we treat all of the FR entities on an equivalent basis. Rather than privileging bibliographic records over authority records and rather than privileging manifestations over works, expressions, and items, we need a structure that allows each of the FR entities to be fully, "equivalently" developed with respect to their attributes and relationships.  Developing such an articulation, that is "re-articulating" MARC to support such an articulation, is not possible because of the deficit in available characters to serve the necessary number of record types.

John F. Myers, Catalog Librarian
Schaffer Library, Union College
807 Union St.
Schenectady NY 12308

518-388-6623
[log in to unmask]

Jeff Young (OR) wrote:
John,

I think you're asking great questions, but I also have some doubts.

Could you share some of the raw data you spent a great deal of time in retrospectively populating? For example, did you assign resolvable HTTP URIs to those entities so other systems on the Web could reference and reuse them? On a similar note, you mention "equivalent entities", which sounds a bit scruffy. How did you represent those equivalent entities in your data? Did you use an existing standard, or did you have to roll your own?

I also get uncomfortable when I think I hear people talking about a record as-if it was a "surrogate" for some thing in one breath, but then argue about whether various copies and forms of records are the same things in the next breath. Records are evil in that way.

Jeff

Sent from my iPad

On May 26, 2013, at 10:25 PM, "Myers, John F." <[log in to unmask]> wrote:

As someone who once spent a great deal of time in retrospectively populating bibliographic records of the same title (records for frbr:manifestion associated with the same frbr:work) with consistent subject headings, the significant appeal of FRBR’s WEMI structure is the potential for inheritance of such relationships down the WEMI tree (cascade as Stephen puts it).

 

With apologies for being contrarian, if BibFrame is not going to support such inheritance, but instead will require the repetition of identical relationships in separate BibFrame:Work records representing frbr:expression entities in the same frbr:work family, then it seems hardly be worth the investment being poured into BibFrame -- this implied functionality of the inherent WEMI relationships under FRBR was one of the few labor offsets to be found in the model, and a huge boon in terms of reliably and consistently populating subject terminology throughout a WEMI tree, both at the inception of the tree and for subsequent maintenance in the event subject terminology refined at a later point.

 

I will go further to state that BibFrame, as articulated from its earliest presentation, has shortsightedly been shackled far too tightly to the Bibliographic vs. Authority record dichotomy we have in our current MARC environment.  The articulation of an expanded set of attributes and relationships for frbr:Works, frbr:Expressions, frad:Person, frad:Corporate_Body, and frad:Family; the subsequent expansion of corresponding elements in RDA; and the further subsequent expansion of fields in the MARC21 formats (accompanied by numerous instances of tensions between formats to record similar information) all indicate that all of the entities put forth in the Functional Requirements (FR) family of models need to be fully articulated in the next generation communication framework, and be done so on a level playing field.  The differentiation between Instances and Works, and between Instances and Authorities, along with the implicit privileging of Instance at the center of the BibFrame model is significantly problematic in this regard, as is the merger of frbr:work and frbr:expression under the BibFrame:work. 

 

We are hamstrung in MARC from re-articulating a structure of equivalent entities, since the LDR/06 byte that holds record type has had too many of the available alphabetic characters consumed in designating various bibliographic format record types (while all the authority records are glommed under ‘z’).  While there are some few vestigial structural differences indicated by the current breakdown of bibliographic types, it is a questionable arrangement post-format integration.  A new structure could entail four for Group 1 types, three for Group 2 types, a minimum of four for Group 3 types (subject to prospective expansion of the Group 3 types as noised about in some quarters), and an unknown number for various genre aspects that remain unaddressed in the FR Family but are being actively explored and developed by an ALA/ALCTS/CaMMS/SAC working group.  With only eight characters left unused in MARC21, we would have to break the format to realize this -- more's the pity, but we would not be so constricted in a new framework such as BibFrame is offering.

 

There was a discussion paper presented to MARBI a year or so back addressing the designation of bibliographic (and possibly authority) records for use as any of the WEMI entity “types.”  There were significant structural issues with respect to expanding employment of the formats along such flexible lines, so the proposal was dropped.  But it was my sense also that NDMSO didn’t “get” the data architecture being proposed.  If that sense was accurate, it appears to be symptomatic in how BibFrame has been developed.


It should be possible for BibFrame to be conceived and implemented at a higher level of generality, while still accommodating legacy data as a special restricted subset with its dichotomous bibliographic/authority structure.  Gordon Dunsire was able to provide a preliminary reconciliation of the widely divergent FRSAD model with the previous two FRBR and FRAD models, by articulating the latter two as subsets of the former (don't ask me how: FRSAD makes my head hurt, but I understood Dunsire enough at the time to see that it is possible).  If such a reconciliation and nesting of concepts can be done in that context, it can be done for MARC in a BibFrame environment.  And BibFrame would be well served by looking at the FR reconciliation process so as not to be caught a generation behind at the starting gun.

 

John F. Myers, Catalog Librarian

Schaffer Library, Union College

Schenectady NY 12308

 

[log in to unmask]

518-388-6623

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Ford, Kevin
Sent: Friday, May 24, 2013 10:51 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Holds and ILL with Bibframe

 

Dear Stephen,

 

Frankly, we've not really addressed this (though we're aware of the idea of inheritance in this sense).  It’s not the we won't, it's more to do with seeing where the data goes and what is practical.

 

The nice thing - as I see it - about BIBFRAME Works that double as RDA/FRBR Expressions is that, when the information is repeated, the BIBFRAME Work can stand alone without reference to another BIBFRAME Work (what would be the RDA/FRBR Expression).  Mind you - it's not that there is no link to a BIBFRAME Work that is representative of an RDA/FRBR Work (there is), it's just that you do not also need that other BIBFRAME Work to make sense of the one that is representative of the RDA/FRBR Expression.

 

Yours,

Kevin

 

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Friday, May 24, 2013 10:09 AM
To:
[log in to unmask]
Subject: Re: [BIBFRAME] Holds and ILL with Bibframe

 

There was an idea in FRBR that elements of description could cascade down the WEMI structure--things specific the Work (e.g., date of creation, form, context, relationships to creators, relationships to Work-level subject terms and classification) could be done once for the Work description and linked to from descriptions of Expressions of that Work; things specific to an Expression (e.g., relationships to translators, date of translation, language, relationships to Expression-level subjects) could be done once for the Expression description and linked to from descriptions of Manifestations of that Expression, and so on. Does BIBFRAME have a way to do this? or does collapsing the FRBR Work and Expression entities into the BF Work mean that the FRBR Work-specific elements must be repeated (and maintained) in each BF Work description (i.e., for each FRBR Expression)? 

 

On Fri, May 24, 2013 at 8:58 AM, Trail, Nate <[log in to unmask]> wrote:

The bf:Work does not contain the FRBR:Expression, it links to it. The FRBR:Expression is another BF:Work with a few extra properties like language that make it a FRBR:Expression.

 


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet