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:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  March 2015

BIBFRAME March 2015

Subject:

Re: Linked data

From:

Karen Coyle <[log in to unmask]>

Reply-To:

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

Date:

Mon, 30 Mar 2015 12:46:10 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (181 lines)

Interesting analogy, Ron. I think that the lack of flexibility in 
library data has a lot to do with sharing. Up until the time that 
libraries were using their data in a machine (computer) environment, 
what they shared was printed cards. Modifying those cards to customize 
them for a particular library was not easy (and I know this because one 
of my first jobs in a library involved much use of an electric eraser 
and white-out). So the question needs to focus on that later point in 
the 20th century when data was machine-modifiable, essentially from 
about 1975 onward. From that point onward, we were hindered by a 
combination of overly rigid systems and the MARC format.

In MARC, we have simultaneous definition of the meaning of data elements 
("245 $a" = Title proper), the constraints on those elements (mandatory, 
non-repeatable), and the serialization (ISO 2709). This is Henry Ford's 
assembly line - it can only produce one kind of product, and it only 
serves specifically compliant applications. (Note to JimW: Before you 
come back with some argument using MARCXML, please check the MARCXML 
documentation. MARCXML has NO flexibility compared to ISO 2709, and that 
is by design.)

In contrast, in Dublin Core you have data elements defined with a 
meaning, but their use is not constrained, and the serialization is 
open. This means that although one application may use DC term (dct) 
"title" in XML and another may use it in a tab-delimited list, these two 
applications have a good chance of being able to exchange data because 
they are working with the same meaning. One of these applications may 
consider "title" mandatory, the other may not, or they may vary in 
whether the application allows more than one dct:title.

Of course, applications do need to impose constraints on data. But 
having those constraints bundled with the meaning of the data elements 
greatly limits the flexibility of the metadata language. DC therefore 
has defined an "application profile" that is where the 
application-specific constraints (mandatory, repeatable) are defined. So 
you have maximum interoperability built into the definition of your 
metadata terms, and you still have the ability to customize the metadata 
"record" for your particular needs using an application profile.

It looks to me like BIBFRAME is taking this latter approach, and that is 
a good thing. We do need to have an agreement on the meaning of our 
terms, but that hardly means that everyone has to produce identical 
bibliographic descriptions. As long as the terms mean the same thing, we 
can understand each other's data. Note that BIBFRAME does not require 
that everyone make the same division of the elements into bf:Work and 
bf:Instance graphs -- it is not an "error" (at least, based on 
BIBFRAME's vocabulary as defined) to create a single graph for a 
bibliographic description, or to create graphs using BIBFRAME properties 
that match FRBR's work, expression and manifestation. The BIBFRAME 
vocabulary, in keeping with the vision of data sharing on the open web, 
does not dictate cardinality of properties (cardinality being whether a 
term is mandatory and repeatable) in its property definitions, since it 
is not aimed at a single application.

Unfortunately, we don't know how much hope we should have for the 
development of systems that can work in this more flexible way, rather 
than the "lock-step" Henry-Fordian model that is the norm today. Systems 
based on triple stores should be able to be more flexible, but it isn't 
clear that the reality of the library market is going to make this 
possible. It would be great to get folks together for a good 
brainstorming question to see what ideas we can generate for 
post-Fordian (Henry, not Kevin!) library systems.

kc



On 3/30/15 10:54 AM, Murray, Ronald wrote:
> Well:
>
> First there was Henry Ford, and then there were the Dodge Brothers - and
> how they manufactured automobiles has everything to do with this thread.A
> quick skim of Simpn Headıs ³The New Ruthless Economy*² will point out that
> the initial stages of mass production were characterized by assembly lines
> designed to create specific products. Ford perfected this strategy,
> thinking that variety of product lines was not required.
>
> This is the mode of production that library luminaries admired and
> adopted, because thatıs what was available - efficient generation of a
> uniform product.
>
> It was only when the Dodge Brothers (using money they got for suing Henry
> Ford) started General Motors that the idea of *deliberately* varying model
> output in an assembly line architecture took root. Their solution was to
> design a common underlying production substrate into which manufacturing
> elements designed to produce new models could be plugged. Mass product of
> products that could be varied periodically.
>
> Libraries did not adopt this method (whether they knew about the
> distinction or not). They did not have a physical infrastructure that
> could support that kind of resource description strategy. We are only
> reaching that point (as a promissory note), with W3C techıs RDF playing
> the underlying infrastructure role. But whereıs the
> theory/experiment/design mechanism that would provide guidance for
> evolutionary/revolutionary changes in IT system design?
>
> I think that the 19th-century industrialization of the library squeezed
> out most of what could have become a theory/experiment/design
>   mechanism in the search for Ford-like mass production perfection.
> Competitors mostly wanted to swap out the main classification scheme for
> their preferred one, but rearchitecting the bibliographic description &
> access substructure was out of reach.
>
> But today is different.
>
> Goodreads, BIBFRAME ­ you name it ­ are all part of an unrecognized,
> W3C-implemented, General Motors-like strategy for building variant
> resource description schemes on a common substrate. Lots of resource
> description schemes out there now. The important question for me is
> whether the W3C XML/RDF substrate has sufficient capability to enable
> resource description structures that genuinely improve on existing ones.
> Sperberg & McQueen warned about XML's limitations in representing
> nonhierarchical structures. Its not clear to me that RDF addressed all of
> S&Qıs concerns.
>
>
> Ron Murray
>
> *http://www.amazon.com/New-Ruthless-Economy-Power-Digital/dp/0195179838/
>
> --------------
>
> Ronald J, Murray
> Digital Conversion Specialist
> Preservation Reformatting Division
> Library of Congress
> Washington DC 20540
>
> email:[log in to unmask]
> phone: (202) 707-9610
>
>
>
>
> On 3/29/15, 1:32 PM, "James Weinheimer"<[log in to unmask]>  wrote:
>
>> On 3/27/2015 5:46 PM, Kelley McGrath wrote:
>>> I strongly disagree with the statement that  someone who understands
>> MARCXML can do whatever they want with the data. I think I have a pretty
>> good grasp of MARC and I have spent countless frustrating hours trying
>> to get information out of MARC records (and not always succeeding).
>>> Granted, I'm not a developer, but I've worked with people who are
>> good developers so I don't think that's the bottleneck.
>>> That said, I'm not sure that Bibframe is going to fix my problems.
>> [sorry, my cat walked on my keyboard and sent the message too soon!]
>>
>> MARCXML is not particularly friendly to extracting some of the
>> information, but it can be done nevertheless. Certainly it can be made
>> easier but that doesn't mean that it can't be done. A lot of that
>> information is buried in the fixed fields which are crazy, but much of
>> that information is less important for the public. Besides, relatively
>> few need the width of the tape is 1/4 in. (which equals value "m" in
>> 007/07 when 007/00 is "s"). Such information can still be extracted.
>> There has been ample time (20 years or so?), plus there used to be
>> money, but there is much less now.
>>
>> In conjunction with the basic statement that libraries could have
>> created lots of things and they haven't. Look at the other sites on the
>> web, for instance, Goodreads really should have been made by libraries.
>> We aleady have all the information. That was a missed opportunity.
>>
>> The problems have not been format. Obviously, the problems are elsewhere.
>>
>> James [log in to unmask]
>> First Thushttp://blog.jweinheimer.net
>> First Thus Facebook Pagehttps://www.facebook.com/FirstThus
>> Personal Facebook Pagehttps://www.facebook.com/james.weinheimer.35
>> Google+https://plus.google.com/u/0/+JamesWeinheimer
>> Cooperative Cataloging Rules
>> http://sites.google.com/site/opencatalogingrules/
>> Cataloging Matters Podcasts
>> http://blog.jweinheimer.net/cataloging-matters-podcasts
>> The Library Heraldhttp://libnews.jweinheimer.net/
>>
>> [delay +30 days]

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

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

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