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  February 2016

BIBFRAME February 2016

Subject:

Re: creating/writing bibframe data

From:

"Folsom, Steven" <[log in to unmask]>

Reply-To:

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

Date:

Thu, 25 Feb 2016 04:26:15 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (227 lines)

[returning to some of the earlier parts of this thread]

If it is at all helpful for folks who are faced with justifying resource
allocations for LOD techniques/experimentation (I don¹t know anyone who
isn¹t)‹ While at Cornell I worked with colleagues (Chew Chiat Naun and
Jason Kovari) to write a position paper to outline our motivations for
exploring the role of linked data in technical services workflows,
http://hdl.handle.net/1813/41481.

The goal of the document was to describe the production incentives and
increased ability to network beyond the walls (and http:domain) of the
library that is potentially afforded us by being ³of the web, not on the
web² (as Tod and others have pointed out). I deliberately use the word
³potentially² because we need to hold ourselves to assessing the value of
these endeavors, not just not in terms of metadata production, but also
the impact on our users wherever they/we/it might be.

Trying not to be just a ³why linked data is good² position paper, towards
the end we list some of the tangible projects we intended to be involved
with that would help us evaluate the theoretical gains, ground our
conversations, and iterate on our findings.

Yours,
Steven

‹‹‹‹
Steven Folsom
Metadata Technologies Program Manager
Harvard Library
http://orcid.org/0000-0003-3427-5769







On 2/24/16, 9:31 PM, "Bibliographic Framework Transition Initiative Forum
on behalf of Matola,Tod" <[log in to unmask] on behalf of
[log in to unmask]> wrote:

>Couple of cases I would like to add to the discussion.
>
>1) Of the web, not on the web. The web has clearly become the information
>space of our time (and maybe many more to come). It is where network
>native citizen are for a large part of the day. Linked data allows your
>information to be constructed from the same web fabric. So that it can be
>leveraged regardless of the systems that it is contained in (the web is
>distributed by nature). MARC is not of the web, it can be transformed at
>the last minute to look like a web resource but not without loss or
>confusion. Libraries won¹t compete on the  popular resources (Amazon or
>Wikipedia or IMDB have that scale), but there is a lot of local or
>special knowledge that could adding to the context if we follow some
>basic rules (https://www.w3.org/DesignIssues/LinkedData.html or
>https://www.w3.org/2013/data/).
>
>2) Not all consumers are humans. Software reads this data if it
>available, for example web crawlers (googlebot, or bingbot). Big data is
>another example, libraries may not have these things running, but many
>projects could benefit from the knowledge that has been curated by
>libraries. Catalogers catalog resource so they can be discovered, we need
>to assume software agents play a part in this discovery process and need
>to consume the knowledge just as efficiently as a human would. IMO
>software plays a bigger part in the spread of information at much higher
>rate (going viral, is not because a human told another human).
>
>Tod.
>
>
>
>
>On 2/24/16, 3:44 PM, "Bibliographic Framework Transition Initiative Forum
>on behalf of Young,Jeff (OR)" <[log in to unmask] on behalf of
>[log in to unmask]> wrote:
>
>>Another place we see Google using their Linked Data is in their
>>Knowledge Graph Search API:
>>
>>https://developers.google.com/knowledge-graph/
>>
>>Search results link to a full page description as opposed to the "card"
>>they present in their regular search results. For example:
>>
>>http://g.co/kg/m/0dl567
>>
>>They don't provide access to their underlying graph, but this makes it
>>easier to imagine the possibilities.
>>
>>Jeff
>>
>>> -----Original Message-----
>>> From: Bibliographic Framework Transition Initiative Forum
>>> [mailto:[log in to unmask]] On Behalf Of James Weinheimer
>>> Sent: Wednesday, February 24, 2016 1:30 PM
>>> To: [log in to unmask]
>>> Subject: Re: [BIBFRAME] creating/writing bibframe data
>>> 
>>> On 2/24/2016 4:54 PM, Joy Nelson wrote:
>>> > When I look at Bibframe and linked data in general, I believe there
>>> > will be various uses for it.  In a public library setting, there may
>>> > not be a huge need for linking to external sources (like youtube,
>>> > etc).  However, linking the data we already have to one another would
>>> > be very useful.  As a public library user I am frustrated with the
>>> > limitations of the catalog just as you mentioned James.   And the
>>> > inflexibility of MARC is what I see as a major obstacle to improving
>>> > the catalog experience.  With linked data the catalog becomes
>>> > FRBRized.  This I believe is more in line with what patrons want - a
>>> > list of the items organized in a way that doesn't involve jumping
>>>from
>>> > one bibliographic record to another.
>>> >
>>> > For academic (and some special public libraries with special
>>> > collections) the benefits are much greater in the area of research.
>>> > Instead of helping a patron find just one item that's cataloged, we
>>> > help them find a broader breadth of materials across collections that
>>> > will assist them in their research endeavors.  Instead of searching
>>> > silo after silo after silo...we search once and find the many.
>>> >
>>> > The reason we all love Google so much is that they are using linked
>>> > data!  And if you use it and love it (and i do too) then it's not a
>>> > far stretch to think about how much better a library ILS can be using
>>> > those same concepts.
>>> >
>>> > It's an incredibly hard thing to do, but I think we need to resist
>>>the
>>> > urge to get up and personal with the trees right now.   As we move
>>> > towards a world of linked data the specifics of workflow will
>>> > inevitably work themselves out....they always do in every system.
>>> > There will be plenty of resistance as well, there always is.  The
>>> > hardest part of any transition is generally the people themselves.
>>> > :-D
>>> 
>>> Well, I am a heretic. I am not nearly so enamored of FRBR as is the
>>>rest of the
>>> library community. I have done quite a bit of reference work, and I
>>>have found
>>> very few times when the public wants or needs to navigate
>>> works/expressions/manifestations/items. 99% of the time, people simply
>>>want
>>> a copy of Huck Finn or the Divine Comedy, and they don't care which
>>> expression/manifestation it is, so long as it is in the language they
>>>want. The
>>> public has other, far more serious problems with our catalogs, but
>>>this is not
>>> the forum for that discussion.
>>> 
>>> Also, while Google does use linked data, it is not in their search
>>>results. Where
>>> we see it is in their "knowledge graphs". So, if I do a search for
>>>"Albrecht
>>> Durer"
>>> (https://www.google.com/search?q=albrecht+durer) in the right-hand
>>>column, I
>>> see a "card" (their word for it!) that is Durer's "Google Knowledge
>>>Graph". It
>>> has a few of his paintings and engravings, basic info stolen from
>>>Wikipedia,
>>> some quotes, more artwork, and finally, I discover that people also
>>>searched
>>> for "Raphael, Jan van Eyck, Leonardo da Vinci, Titian and
>>>Michelangelo". In
>>> their advertising, Google of course says that this is *absolutely
>>>amazing!!!!*
>>> (https://www.youtube.com/watch?v=mmQl6VGvX-c) but we shouldn't believe
>>>a
>>> promo. Is this really so amazing? In fact, I find it practically
>>>useless. The
>>> information we see in the Google knowledge graphs may be useful to a 5
>>>or 6
>>> year old, but to few other people.
>>> 
>>> Another place we see Google use linked data is with email. When someone
>>> books a hotel room or has a flight, the company can markup the email
>>>they
>>> send that will interoperate with Google to provide people with extra
>>> information. (See
>>> 
>>>http://googlesystem.blogspot.com/2013/08/sites-that-integrate-with-googl
>>>e-
>>> now.html)
>>> 
>>> 
>>> The reason Google search works so much better for me than Bing or
>>>Yahoo, is
>>> not because it uses linked data because it doesn't. It works better
>>>because
>>> (fortunately or unfortunately) it has a huge database of my own
>>>browsing
>>> habits going back years, and Google's super-secret algorithms work on
>>>that
>>> trove of my personal browsing history. For this convenience, I gave up
>>>my
>>> privacy. I don't know if I like it but there it is....
>>> 
>>> In any case, linked data does not allow *you* to work with *your own
>>> data* in any ways you couldn't already. After all, you have complete
>>>control
>>> over your own data and can convert it, search it, manipulate it, or
>>>display it in
>>> any ways you could possibly want right now, and you already understand
>>>all of
>>> its semantics. Linked data allows *others* to use your data--people
>>>who do not
>>> understand the structures of your own data--and then they can
>>>manipulate your
>>> data in ways they want. In that way, they can create things that you
>>>might
>>> never dream of.
>>> 
>>> Of course, that is linked *open* data. Linked *closed* data (or
>>>proprietary
>>> linked data) is another matter entirely.
>>> 
>>> James Weinheimer [log in to unmask] First Thus
>>> http://blog.jweinheimer.net First Thus Facebook Page
>>> https://www.facebook.com/FirstThus
>>> Personal Facebook Page https://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 Herald http://libnews.jweinheimer.net/
>>> 
>>> [delay +30 days]

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

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