LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


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:

Fri, 6 Mar 2015 11:11:13 -0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (163 lines)

Yes, and that's why it was done. But it did not allow any changes in the 
content of library records, and therefore did not move us forward in any 
way. A mere serialization of an out-of-date format is like nailing good 
wood onto rotten - you don't gain much.

kc

On 3/6/15 7:25 AM, Martynas Jusevičius wrote:
> There is one big difference: the whole stack of XML technologies can
> now be used to access, manage, and transform the data.
>
> On Fri, Mar 6, 2015 at 4:21 PM, Karen Coyle <[log in to unmask]> wrote:
>> EXACTLY. To act as if MARCXML is anything different from ISO 2709 MARC is
>> nonsense. MARCXML is a pure serialization of the 2709 format into XML. It
>> allows for no modification of content compared to the MARC record. MARCXML
>> is not allowed to vary from MARC, it must be totally  backward compatible,
>> so it is essentially the same thing as MARC. Anyone using MARCXML as an
>> argument that we have "moved on" is very wrong.
>>
>> kc
>>
>>
>> On 3/6/15 6:13 AM, Bowers, Kate A. wrote:
>>> MARCXML might have been a step in the right direction if the scope of
>>> MARCXML was transformation of MARC rather than a verbatim "XML-izing" within
>>> the limitations of MARC.
>>>
>>> For example, MARCXML does nothing useful with fixed field data except to
>>> put it into a new bottle. It could have been made verbose and infinitely
>>> flexible, but that wasn't done.
>>>
>>> Kate Bowers
>>> Collections Services Archivist for Metadata, Systems, and Standards
>>> Harvard University Archives
>>> Cambridge, Massachusetts, USA
>>> voice: (617) 384-7787
>>> fax: (617) 495-8011
>>> [log in to unmask]
>>>
>>>
>>>
>>>
>>> ________________________________________
>>> From: Bibliographic Framework Transition Initiative Forum
>>> <[log in to unmask]> on behalf of James Weinheimer
>>> <[log in to unmask]>
>>> Sent: Friday, March 6, 2015 8:44 AM
>>> To: [log in to unmask]
>>> Subject: Re: [BIBFRAME] Linked data
>>>
>>> Ross Singer wrote:
>>> <snip>
>>> Counterpoint: if libraries can do "anything they want" with their data and
>>> have had 40+ years to do so, why haven't they done anything new or
>>> interesting with it for the past 20?
>>>
>>> How, with my MARC records alone, do I let people know that they might be
>>> interested in "Clueless" if they're looking at "Sense and Sensibility"?
>>> How
>>> do I find every Raymond Carver short story in the collection? The albums
>>> that Levon Helm contributed to? How can I find every introduction by Carl
>>> Sagan?  What do we have that cites them?
>>>
>>> How, with my MARC records alone, can I definitively limit only to ebooks?
>>> What has been published in the West Midlands?
>>>
>>> You *could* make a 3-D day-glo print of a MARC record, I suppose - but
>>> that
>>> seems like exactly the sort of tone deaf navel gazing that has rendered
>>> our
>>> systems and interfaces more and more irrelevant to our users.
>>> </snip>
>>>
>>> Why haven't libraries done anything new or interesting with our data for
>>> the past 20 years? Is it because it has been *impossible* due to our
>>> formats, even though we now have XML? You ask an excellent and important
>>> question that I was hoping somebody would bring up. It deserves a
>>> separate discussion. But first I want to emphasize: I am not saying that
>>> we need to work with MARC records alone--never said that at all. What I
>>> am saying is that for the library community, that is, the people who
>>> already know and understand--and even control--MARC format, changing the
>>> format they already control to Bibframe will not give them any new
>>> capabilities over what they have been able to do with MARCXML.
>>> *Librarians* understand the MARC codes and that means they can work with
>>> MARCXML to fold in their records with what else exists on the Internet;
>>> they can do that now, and they've been able to do it for awhile.
>>> Changing to Bibframe/RDF will not change anything for librarians, but it
>>> will change matters for non-librarians who may want to use our data for
>>> their purposes. Nevertheless, a *lot* of work will remain to be done. It
>>> isn't like after we change to Bibframe, we can fly onto the deck of the
>>> aircraft carrier festooned with banners that proclaim "Mission
>>> Accomplished". It will only be the beginning of a vast amount of work
>>> and expense. It seems to me to make sense to talk about that now.
>>>
>>> So, if we can already do anything and haven't, the obvious question is:
>>> why will anything change with Bibframe/RDF? again, I stress: this
>>> concerns *the library community*. Non-librarians will have new options
>>> but there will not be any new capabilities for the library community.
>>> Perhaps Bibframe will be a catalyst for change among librarians,
>>> providing a needed kick-in-the-pants to get them to do something they
>>> haven't until now. OK, I'd go along with that. But let's be fair and say
>>> that it is just as possible that it won't. Going back to the reason why
>>> we haven't done anything interesting in the last 20 years: maybe it's
>>> money, maybe it's imagination, maybe it's proprietary catalogs, maybe
>>> it's power.... I don't know, but there may be a whole host of other
>>> reasons.
>>>
>>> Perhaps with Bibframe the non-librarian community will come riding to
>>> the rescue and they will figure out what to do. We can hope.
>>>
>>> I wrote that message on Autocat to combat the popular idea that the
>>> reason libraries haven't done anything new or interesting is because of
>>> the limitations of the format. That was true until MARCXML arrived and
>>> then it became possible to do all sorts of new things. MARCXML may be
>>> nasty and difficult to work with, but no matter: if somebody wants to,
>>> it *can* be worked with *within the library community*. And people have
>>> worked with it, such as we see in catalogs that utilize Lucene indexing
>>> (which is based on MARCXML) to create the facets we see in different
>>> library catalogs. (That is one thing that has been done in the last 20
>>> years, and it is due to XML)
>>>
>>> I gave the example of printing day-glo colors merely to emphasize that
>>> we can currently do anything we want right now, but of course, I was not
>>> suggesting we should waste our time on that. I want to try to open
>>> people's minds to what *can* be possible. *Anything* is a tremendous
>>> concept that is difficult to grasp. Once we accept and begin to
>>> comprehend the idea that "anything can be done" the question of what
>>> would be better, or worse, uses of our labor and resources becomes far
>>> more complex and takes on different subtleties. Those who believe that
>>> the problems we have faced are because of the *format* so therefore, the
>>> solution is to get a "better format" and things will then be solved,
>>> will be sadly disillusioned.
>>>
>>> Finally, in answer to some other posts, I repeat once again that I am
>>> FOR the library community's implementation of linked data but we need to
>>> do it with our eyes open. I'll copy that part of my original message:
>>> "I want again to emphasize that libraries should go into linked data,
>>> but when we do so, there will probably be more question marks than
>>> exclamation points. Just as when a couple is expecting a baby and they
>>> experience pregnancy: at least when I experienced it, I imagined that
>>> the birth of my son would be an end of the pregnancy. But suddenly, I
>>> had a crying baby on my hands! Linked data will be similar: it will be a
>>> beginning and not an end."
>>>
>>> James Weinheimer [log in to unmask] First Thus
>>> http://blog.jweinheimer.net First Thus Facebook Page
>>> https://www.facebook.com/FirstThus Cooperative Cataloging Rules
>>> http://sites.google.com/site/opencatalogingrules/ Cataloging Matters
>>> Podcasts http://blog.jweinheimer.net/cataloging-matters-podcasts [delay
>>> +30 days]
>>
>> --
>> 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

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

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
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