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:

"Young,Jeff (OR)" <[log in to unmask]>

Reply-To:

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

Date:

Wed, 24 Feb 2016 20:44:47 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

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-google-
> 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