Print

Print


Actually, having been on the "sort of vendor" side of that, what always 
kept us from indexing fixed fields was the inconsistency of their use. 
If you have a file of records and 50% have a fixed field filled in and 
50% do not, then any search on that field will miss a large number of 
records that should have been retrieved. You cannot accurately index 
what isn't there.

kc

On 3/10/15 6:38 AM, Cecilia M. Preston wrote:
> Ross,
>
> My first reaction to many of these questions about what MARC has not 
> or could not do, has been talk to your ILS vendor.  Much of the data 
> embedded in a MARC record was never indexed by the ILS folks because 
> ‘no one was interested in it’ or what was generally referred to in the 
> ancient days of Z39.50 ATS (Author, Title, Subject) was all the 
> patron/user/client is interested in.  When I asked the vendor for my 
> local system at ALA why I could not get access to some information I 
> knew was in a MARC record the answer was simply ‘we can index that if 
> they want to $$$ for it’  Not something I think many institutions have 
> the funding to do for me.
>
> -Cecilia
>
>
> On Mar 5, 2015, at 6:25 PM, Ross Singer <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>> 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.
>>
>> -Ross.
>>
>> On Thursday, March 5, 2015, J. McRee Elrod <[log in to unmask] 
>> <mailto:[log in to unmask]>> wrote:
>>
>>     Forwarded by permission of James Weinheimer:
>>
>>
>>
>>     There are some points to keep in mind when considering linked
>>     data/semantic web. The new formats (schema.org
>>     <http://schema.org/>, Bibframe) are *not*
>>     there for libraries to be able to do new and wonderful things
>>     with their
>>     own data. Why? Because libraries already understand and control
>>     all of
>>     that data. Right now, so long as we have XML formats (and we have
>>     that
>>     now with MARCXML) we can do *anything* we want with the data.
>>     MARCXML is
>>     not perfect, but it is still XML and that means: librarians can
>>     search
>>     that data however we want, manipulate it however we want,
>>     transform it
>>     however we want, sort it however we want and display it however
>>     we want.
>>     If we want to search by the fiction code in the fixed fields and
>>     sort by
>>     number of pages or by 100/700$q we can. We can print out reams of
>>     entire
>>     records, or any bits and pieces of them we could want, collate
>>     them in
>>     any number of ways (or not), and print them out on 3D printers in
>>     day-glow colors, display them with laser beams on the moon or
>>     work with
>>     them in the virtual reality "wearable technology". We can do all
>>     of that
>>     and more *right now* if we wanted. We've been able to do it for a
>>     long
>>     time. We don't needschema.org <http://schema.org/>or Bibframe to
>>     enhance our own
>>     capabilities because we can do anything with our own data now.
>>
>>     So, who isschema.org <http://schema.org/>and Bibframe for?
>>     Non-librarians, i.e. for people
>>     who neither understand nor control our data. Libraries will allow
>>     others
>>     to work with our data in ways that they can understand a bit more
>>     than
>>     MARC. Non-librarians cannot be expected to understand 240$k or 700$q,
>>     but withschema.org <http://schema.org/>or Bibframe, it is
>>     supposed to be easier for
>>     them--although it still won't be easy. Nevertheless, they will be
>>     able
>>     to take our data and do with it as they will as they cannot do
>>     now with
>>     our MARC/ISO2709 records.
>>
>>     With Bibframe andschema.org <http://schema.org/>people will be
>>     able to merge it with other
>>     parts of the linked data universe (oops! Not Freebase or dbpedia.
>>     They'll have to go to Wikidata! Wonder how long that will last!)
>>     or with
>>     all kinds of web APIs (seehttp://en.wikipedia.org/wiki/Web_API) that
>>     can create mashups. (I still think this video gives the best
>>     description
>>       of a mashup:What is a mashup? - ZDNet
>>     <https://www.youtube.com/watch?v=ZRcP2CZ8DS8>. Here too is a
>>       list of some of the web apis
>>     http://www.programmableweb.com/apis/directory) Web programmers
>>     can then
>>       put these things together to create something absolutely new,
>>     e.g. bring
>>       together library data with ebay so that people can see if
>>     something on
>>       ebay is available in the library or vice versa. But remember
>>     that those
>>       web programmers will also be able to manipulate our data as
>>     much as we
>>       can, so the final product they create may look and work completely
>>       differently than we would imagine, or that we would like. As a
>>     result,
>>       libraries and catalogers will lose the control of their data
>>     that they
>>       have always enjoyed. For better or worse, that is a necessary
>>       consequence of sharing your data.
>>
>>       Then comes what are--I think--the two major questions of linked
>>     data for
>>       libraries. First is: OK. We add the links, but what do we link
>>     *to*?
>>       Will linking intoid.loc.gov <http://id.loc.gov/>appeal to the
>>     public? I personally don't
>>       think so since there is so little there, other than the traditional
>>       syndetic structures found in our traditional catalogs (i.e. the
>>     UF, BT,
>>       NT, RT for subjects, the earlier/later names of corporate
>>     bodies and
>>       series, the other names of people). This is not what people
>>     think of
>>       when they think of the advantages of linked data. While those
>>     things may
>>       be nice for us, I don't know if that will be so appealing to
>>     the public.
>>       If it is to become appealing to the public, somebody somewhere
>>     will have
>>       to do a lot of work to make them appealing.
>>
>>       Concerning VIAF, it's nice to know the authorized forms in Hebrew,
>>       French, Italian, and so on, but again, is that so appealing to the
>>       *public*? It may be, but that remains to be proven.
>>
>>       Second, there is no guarantee at all that anyone will actually do
>>       anything with our data. While I certainly hope so, there are no
>>       guarantees that anybody will do anything with our data. It
>>     could just
>>       sit and go unused.
>>
>>       It's interesting to note that the LC book
>>       catalog in this format has been in the Internet Archive for
>>     awhile now
>>       (https://archive.org/details/marc_records_scriblio_net) but I
>>     haven't
>>       heard that any developers have used it.
>>
>>       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 [log in to unmask]
>>     <mailto:[log in to unmask]>First Thus
>>     http://blog.jweinheimer.net <http://blog.jweinheimer.net/>First
>>     Thus Facebook Page
>>     https://www.facebook.com/FirstThusCooperative Cataloging Rules
>>     opencatalogingrules
>>     <http://sites.google.com/site/opencatalogingrules/>Cataloging Matters
>>     Podcastshttp://blog.jweinheimer.net/cataloging-matters-podcasts[delay
>>     +30 days]
>>
>>       --
>>
>>     --
>>     James [log in to unmask]
>>     <mailto:[log in to unmask]>First Thus
>>     http://blog.jweinheimer.net <http://blog.jweinheimer.net/>First
>>     Thus Facebook Page
>>     https://www.facebook.com/FirstThusCooperative Cataloging Rules
>>     opencatalogingrules
>>     <http://sites.google.com/site/opencatalogingrules/>Cataloging Matters
>>     Podcastshttp://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