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:

Martynas Jusevičius <[log in to unmask]>

Reply-To:

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

Date:

Sun, 8 Mar 2015 20:44:24 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (147 lines)

You write "About catalog data, it isn't that it is special, but it is
different from the other types of data that you point out." and then "
I am very skeptical about the usefulness of mixing content data with
our directional data. Nevertheless, we should try it, to find out what
happens".

You have a problem with mixed content, but you are skeptical about
solving it? Definitions of, and the distinction between, "content
data" and "directional data" are not so clear to me.

I can better talk standards. RDF is exactly for that, mixing the
content until you see the big picture. And people have already tried,
even in libraries, with good results.

Here's a project our company made for the danish State and University
library: http://dedanskeaviser.dk
The source is not a real catalog, but structured data and rich text
are available as Linked Data.

And still, what makes you think proteins can be cataloged as Linked
Data but books can't?


Martynas

On Sun, Mar 8, 2015 at 8:07 PM, James Weinheimer
<[log in to unmask]> wrote:
> On 3/7/2015 9:37 PM, Martynas Jusevičius wrote:
>>
>> I find these statements hard to believe. Data is just data. Data,
>> metadata - there is no difference.
>>
>> People are using RDF to describe proteins, semiconductor products,
>> horoscope signs, antique coins and who knows what else. What makes you
>> think libraries are special? Again, I mean real technical limitations
>> -- all the history and the "traditional ways of doing things" are
>> irrelevant here.
>
>
> There are different types of data, and we experience it in all kinds of ways
> every day. I have gone into greater detail in those podcasts and
> presentations I mentioned, but I'll try to redo a little of it here. The
> differences are subtle, but clear.
>
> Before I begin however, what you have claimed to be history, and traditional
> ways of doing things, is not history at all. Whether we like it or not, what
> I described is the way libraries still work. It is what users are supposed
> to do when they use a library, and if people don't do it, they will get bad
> results. Of course, few people do it and this explains a lot of the
> frustration that people currently have with library catalogs.
>
> The solution that libraries have tried is called "information literacy" and
> "bibliographic instruction" which, instead of fixing library tools to work
> in a modern environment, means to teach everybody how to use our tools the
> way they are. In my own opinion, this hasn't worked and everything needs to
> be rethought, but what I described is not history--unfortunately it is still
> happening today.
>
> About catalog data, it isn't that it is special, but it is different from
> the other types of data that you point out. When someone comes to a library,
> they don't come specifically to search the catalog (or at least, those that
> do are exceedingly rare). Instead, the vast majority are there because they
> have a question and want information. My example has been "What were the
> causes of the War of the Spanish Succession". The catalog does not contain
> the information I want--the information that can answer my question is
> contained in the books, journal articles, and other materials in the
> collection--but if I use the catalog correctly, it can direct me to the
> resources that have the information I want. In this way, the information
> found in a catalog is similar to information found on ... traffic signs.
>
> If you want to drive from Rome to Paris, you need signs to help you get
> there. The better the signs, the better, the easier, and the more enjoyable
> the trip. Poor signs, or the absence of them (which happens in Italy all the
> time), can lead to frustration, anger or even disasters.
>
> So, people want and need decent and reliable road signs, but they are very
> rarely interested in the signs themselves: who made them, where and when,
> what materials they are composed of and so on. Still, those in charge of the
> road signs need to know that information, so that they can replace them,
> update them, add to them, etc.
>
> Using this same reasoning with catalogs and how things are changing, compare
> this with the person who is interested in the "War of the Spanish
> Succession" and searches the library catalog. They can sit there quite
> literally, all day long and not have learned anything about the War. All
> they see are *catalog records* and if they are to learn about the war
> itself, they need to get into the books of the collection. But when they
> search Google, in just a half-an-hour they have gotten some real
> information. This leads them to expect that library tools will work similar
> to what works (apparently) so easily and simply on Google, which seems
> logical but is completely wrong.
>
> Google works with a different type of information: content; library catalogs
> work by giving people directional information: so even when the searcher
> does everything correctly, all they see are directions: for general books on
> the War, look here, For books on the politics look there, For battles, look
> here, etc.
>
> For those who use catalogs incorrectly, they are practically doomed to
> disaster and for them it is similar to a driver who hasn't seen a road sign
> for hours, and ends up at the end of a road in the middle of a field at
> midnight.
>
> Believe me, this happens to students all the time when they are researching
> their papers at the last minute! Both end up in tears and/or almost
> screaming.
>
> Catalogers see this difference in information clearly because they work with
> the actual materials that people want: the books, the recordings, the maps,
> etc. all go through their hands. The mistake that many catalogers make
> (again in my opinion) is that they believe people, who care about the
> information in the collection (i.e. who want to learn about The War of the
> Spanish Succession), also care about the catalog records they make. Of
> course for the public, these records are the equivalent of road signs that
> help them get where they want to go. They don't care about the road signs
> and once they reach their destination, they completely forget about all the
> helpful road signs. I confess I remember only the frustrations and anger
> during the trips that had lousy signs. I think the same thing happens with
> catalog records.
>
> While our methods still "work" in a sense, they are strange for people in
> the 21st century. They need to be, in a sense, translated so that they work
> in today's environment.
>
> So, all data is definitely not equal. I think there is still a need for our
> type of data but it needs to be reconsidered. Tools that work well for
> content data, don't work so well with directional data. And with linked
> data, I am very skeptical about the usefulness of mixing content data with
> our directional data. Nevertheless, we should try it, to find out what
> happens. I would be very happy to be proven wrong.
>
> There are other options, too.
>
>
> 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

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
https://listserv.loc.gov/cgi-bin/wa?A2=ind1503&amp;L=BIBFRAME&amp;P=23640
listserv.loc.gov
crawl=CC-MAIN-2019-26
56465
application/http; msgtype=response
sha1:DNERMIXFJVFKJC52XOAJFKPT4C332ZCY
<urn:uuid:69ad6d3f-f291-4eb2-a28d-efa89560585c>
2019-06-26T19:15:55Z
140.147.55.47
text/html
sha1:JUJSUM2HU6KY2W56K2JPB7TOTTPQHLAY
<urn:uuid:8f4ac780-590a-4118-920c-0b454ebd7b1e>
https://listserv.loc.gov/cgi-bin/wa?A2=ind1503&amp;L=BIBFRAME&amp;P=23640
response
<urn:uuid:a39df956-2103-491c-a7f8-8e4c55065cce>
isPartOf: CC-MAIN-2019-26
publisher: Common Crawl
description: Wide crawl of the web for June 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-154-230-119.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/