LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  July 2014

BIBFRAME July 2014

Subject:

Re: BF vocabulary and RDA

From:

"Willan, Terry (CSS)" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Tue, 29 Jul 2014 13:17:11 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

Bibframe seems to be conceived as a kind of universal adapter for bibliographic data. That comes across from the introduction on the initiative home page: 'a general model for expressing and connecting bibliographic data', and from the Introduction to Bibframe Profiles: 'The BIBFRAME metamodel is designed to be lightweight, flexible and able to accommodate the declarative needs of both existing (RDA, DACS, VRA, etc..) and yet-to-be-developed community vocabularies.'

But I haven't seen anything that explains clearly why a metamodel is necessary or the best option. What kind of environment is envisaged where this is so?

I'm not a technical expert, but I think there are ways of exchanging RDF without need of a metamodel; indeed, RDF is designed to support diversity. RDA, and I guess some other metadata schemes that Bibframe hopes to represent, can be expressed directly in RDF.

Bibframe claims to 'accommodate the declarative needs' of various schemes but it has its own data model and vocabulary, so it looks like just another model. If specific models are going to be used locally, then it must be worth questioning the value of the extra complexity and possible semantic degradation of having to map into and out of Bibframe to share data. I wonder whether the mainstream library infrastructure would end up creating, managing and storing Bibframe 'records', as they have done with MARC. This doesn't seem to be making the best of the opportunities offered by linked data concepts and technologies.

Furthermore, whilst the note in the Introduction to Bibframe Profiles that defines a 'BIBFRAME Record' tries to undo the traditional, MARC sense of a record, the fact that the notion of a BIBFRAME Record is used at all makes me wonder whether a vision for a bibliographic linked data environment has not been fully explored.


Terry Willan
Business Analyst

Software services
Capita, Knights Court, Solihull Parkway
Birmingham Business Park, B37 7YB

Office: 0870 400 5038
Email: [log in to unmask]

www.capita.co.uk/software


-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Philip Evan Schreur
Sent: 26 July 2014 00:38
To: [log in to unmask]
Subject: Re: [BIBFRAME] BF vocabulary and RDA

Just adding my pennies as well. The amount of resources we are responsible for is far outstripping our capacity for full RDA metadata creation. We are already reinventing our processing streams. I don't see why Bibframe shouldn't communicate data created according to RDA but it shouldn't be dependent on RDA for its structure. Structure and data needs come first. Once that's settled, we look to see how RDA can be expressed in that structure.

Philip

Sent from my iPhone

> On Jul 25, 2014, at 4:20 PM, "[log in to unmask]" <[log in to unmask]> wrote:
>
> I'll see that +2 and add my own to the pot.
>
> In all seriousness, it's not totally clear to me what the purpose is of doing Linked Data based on cataloging rules that do not invest in either the RDF metamodel or the Web, or even what it means to do Linked Data in that way.
>
> For me, a Bibframe bound to RDA is of much less interest than a Bibframe that can act as an interchange and point of commonality amongst different models of description, especially from the point of view of a research institution. That's because the portion of resources in the responsibility of such institutions that is carefully described by professional catalogers (the only audience for RDA) is shrinking. At my institution, and I think this is common, the remainder now more and more consists of the intermediate products of research, often described by the researcher or scholar who created them, or of digitized representations of archival material with original cataloging that is concerned with SAA (or entirely local) standards. If Bibframe is limited to being an RDF format for RDA cataloging, it's of no use at all for the fastest growing segments of descriptive work at my institution.
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On Jul 25, 2014, at 6:23 PM, Karen Coyle <[log in to unmask]> wrote:
>>
>> +1 and +1 again - kc
>>
>>> On 7/25/14, 1:15 PM, Fallgren, Nancy (NIH/NLM) [E] wrote:
>>> Hi Sally,
>>>
>>> I was under the impression that BIBFRAME was to be rule agnostic in order to appeal to a wider community than MARC/AACR2/RDA users and to avoid the interdependence we had with MARC/AACR. While that’s probably not entirely realistic, shouldn’t the effort be to minimalize the influence of MARC/AACR2/RDA on the BF vocab to the extent possible? When we someday move away from RDA will we need to completely overhaul or throw out BF too?
>>>
>>> -Nancy
>>>
>>>
>>> Nancy J. Fallgren
>>> Metadata Specialist Librarian
>>> Cataloging and Metadata Management Section Technical Services
>>> Division National Library of Medicine
>>>
>>>
>>> From: McCallum, Sally [mailto:[log in to unmask]]
>>> Sent: Friday, July 25, 2014 2:10 PM
>>> To: [log in to unmask]
>>> Subject: [BIBFRAME] BF vocabulary and RDA
>>>
>>> Hi all,
>>> There are often references to MARC on this list but the real influence on the BF vocabulary has been RDA, which we are not in a position to ignore in the bibliographic environment. With RDA you record the attributes of an entity and then an institution can make the Work title or label for that entity as long or short as is needed for the situation. But we are not yet in that environment so we must carry our strings in addition to the pieces. The pieces look a lot like MARC because the pieces called out by RDA look that way, but not entirely: RDA has more, and there is a tendency to want each element in RDA separately identified for manipulation purposes. As RDA matures, BF will follow the progress and adapt as appropriate.
>>>
>>> Sally
>>>
>>> ***********************************
>>> Sally H. McCallum
>>> Chief, Network Development and MARC Standards Office Library of
>>> Congress, 101 Independence Ave., SE Washington, DC 20540 USA
>>> [log in to unmask]
>>> Tel: 1-202-707-5119 – Fax 1-202-707-0115
>>> ***********************************
>>
>> --
>> Karen Coyle
>>
>> [log in to unmask] http://kcoyle.net
>>
>> m: 1-510-435-8234
>> skype: kcoylenet
>>


This email and any attachment to it are confidential. Unless you are the intended recipient, you may not use, copy or disclose either the message or any information contained in the message. If you are not the intended recipient, you should delete this email and notify the sender immediately.

Any views or opinions expressed in this email are those of the sender only, unless otherwise stated. All copyright in any Capita material in this email is reserved.

All emails, incoming and outgoing, may be recorded by Capita and monitored for legitimate business purposes.

Capita exclude all liability for any loss or damage arising or resulting from the receipt, use or transmission of this email to the fullest extent permitted by law.

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager