[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,
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.
Metadata Technologies Program Manager
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
>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).
>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:
>>Search results link to a full page description as opposed to the "card"
>>they present in their regular search results. For example:
>>They don't provide access to their underlying graph, but this makes it
>>easier to imagine the possibilities.
>>> -----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
>>> > 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
>>> > 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
>>> very few times when the public wants or needs to navigate
>>> works/expressions/manifestations/items. 99% of the time, people simply
>>> 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
>>> 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
>>> we see it is in their "knowledge graphs". So, if I do a search for
>>> (https://www.google.com/search?q=albrecht+durer) in the right-hand
>>> see a "card" (their word for it!) that is Durer's "Google Knowledge
>>> has a few of his paintings and engravings, basic info stolen from
>>> some quotes, more artwork, and finally, I discover that people also
>>> for "Raphael, Jan van Eyck, Leonardo da Vinci, Titian and
>>> their advertising, Google of course says that this is *absolutely
>>> (https://www.youtube.com/watch?v=mmQl6VGvX-c) but we shouldn't believe
>>> promo. Is this really so amazing? In fact, I find it practically
>>> information we see in the Google knowledge graphs may be useful to a 5
>>> 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
>>> send that will interoperate with Google to provide people with extra
>>> information. (See
>>> The reason Google search works so much better for me than Bing or
>>> not because it uses linked data because it doesn't. It works better
>>> (fortunately or unfortunately) it has a huge database of my own
>>> habits going back years, and Google's super-secret algorithms work on
>>> trove of my personal browsing history. For this convenience, I gave up
>>> 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
>>> 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
>>> 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
>>> data in ways they want. In that way, they can create things that you
>>> never dream of.
>>> Of course, that is linked *open* data. Linked *closed* data (or
>>> linked data) is another matter entirely.
>>> James Weinheimer [log in to unmask] First Thus
>>> http://blog.jweinheimer.net First Thus Facebook Page
>>> Personal Facebook Page https://www.facebook.com/james.weinheimer.35
>>> Google+ https://plus.google.com/u/0/+JamesWeinheimer
>>> Cooperative Cataloging Rules
>>> Cataloging Matters Podcasts
>>> The Library Herald http://libnews.jweinheimer.net/
>>> [delay +30 days]