LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


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:

Thomas Berger <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Wed, 11 Mar 2015 10:21:29 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (159 lines)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 11.03.2015 um 05:55 schrieb Michael Ayres:
> That's fine—but when data  is incorrectly linked to records through computer manipulation (whether by string 'mis'-matching or by faulty programming) as opposed to human judgment, then it follows that the inferred links such as you listed will clutter the record or search results with more incorrectly matched data.
> 
> In the examples below, I would want verification that the place of recording was actually at that particular location at the particular time of the recording (assumption being that such businesses often move locations over time or may have other recording facilities in various cities).

thanks to the links provided I could easily consult

< https://en.wikipedia.org/wiki/Avatar_Studios >

and < https://en.wikipedia.org/wiki/Like_a_Virgin >

Thus: It was the exact building in Manhattan, although the name of the studio
at the time of production was "The Power Station".

It can be expected in the long run that wikidata or dbpedia or whoever
will state the "variant" names and the corresponding dates (the name change
occurred in May 1996 according to the wikipedia article (July 1996 according
to the studio's home page, however they refer to "open[ing] its doors") i.e.
the information is already there but still has to be converted from "text"
into "data").

It will be the responsibility of every data provider to decide whether
"Avatar Studios" is a firm (and "The power plant" was another firm, mandating
two entities) or a building housing renowned individual recording studios
(rooms). As we all know, reality is slightly more complex than these two
options, obviously the studios (firm) is responsible for keeping the studios
(facilities in the building) up to their standards...

Now, the librarians responsibility is to keep the libraries records up to
standard. Others already have stressed that the focus is shifting from
giving perfect /descriptions/ to reliably providing /relations/. This can
only be based on "Authority Control" which - properly understood - does
/not/ consist of bricolaging "headings" disambiguating at text level but
in performing intellectually sound identifications and discriminations
which then are recorded. In consequence this means authority records which
/represent/ their corresponding entities even when they are still uncomplete,
authority records which can serve as accretion points for /data/ and
not just are a bag for collecting "variant forms", *and* stable relations
between bib records and authority records, i.e. proper linking obliviating
the practice of being forced to match and re-match strings ever and ever.

Personally I see a continuing (if not eternal) demand for a profession
performing identifications as above: Any bookseller, publisher, record label
or IP agency may have an absolutely consistent (and sometimes even public)
database of the objects important for their operation, but it is the
librarians main task to make the connections when these objects (books,
authors, ...) or evidence of them are found in the wild...

The standards of library records and of librarian's professional authority
would be watered down if "information found on the internet" would be
blindly /incorporated/ into library records, be it by automated techniques
like "inference" or good old "copy & paste": Sometimes the source would not
be reliable enough, in other cases it may evolve too rapidly and leave
the libraries records with incomplete or outdated information. Shifting
information from bib records to authority records already constitutes a
certain kind of "decoupling" which seems necessary here.

Assuming that information literacy is not only a lip service, the librarians'
professional task then is assessing and selecting those external sources
which should be ~connected~ to their services (most prominently the
catalogue). This connection may express itself by merely providing links
in the OPAC, inserting content by mashups, indexing harvested metadata
or even indexing full texts or original art. Certainly there are technical
economic and legal impediments and in most cases one will not be able
to implement an additional service just because it can be thought of. But
to my impression big ILS companies have long since begun to invest into
content databases which then at a calculaded cost and with less technical
hassle be licensed and accessed by users of appropriate ILSes...

As for the initial examples: No, we probably will never investigate the
history of the recording studios when some madonna album enters our
stacks. And our "agent" definitely is the studios-as-a-firm and not the
studios-as-a-facility. But a closer look at our resources could show
that they allow differentiation between "place of operation" (of the
pruduction company: Manhattan) and "place of recording" (the physical
studios: Manhattan) and the records we produce shouldn't mess this up.
And that (collaboratively!) subduing these kinds of entities under
"Authority Control" is worth the effort. /Other/ communities will build
up more detailed data (wrt individual tracks, or which facilities have
been when operated by what company, all individual producers or sound
engineers involved &c..., of course geolocation information for whatever
can be tagged with coordinates) and the requirement for library data
is to be able to connect with that as soon as librarians assess this
as "reliable".

So, actually we are not talking "bibframe" here but about organizing
librarians work (more "authority control" would be a start) and organizing
librarians work: the output is not some static "record" enduring until
the end of civilization but must be adapted to reliably record the outcome
of the processes *actually* performed by the librarian, not more and
most eminently not less: I claim that most of the many, highly intellectual
identification processes performed by librarians never make their way
into library data. This is a shame (we *are* better than that) and a
waste (since it is not recorded the next person is forced to do the
same work again).

viele Gruesse
Thomas Berger


> Michael
> 
> From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Ross Singer
> Sent: Tuesday, March 10, 2015 5:52 PM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Linked data
> 
> To be clear, that's that not inference.  That's string matching.
> Inference is:
> 
> <http://dbpedia.org/resource/Material_Girl>
> is an album on
> <http://dbpedia.org/resource/Like_a_Virgin>
> which was recorded at
> <http://dbpedia.org/resource/Avatar_Studios>
> which is located at
> lat/lon: 40.76638888888889 -73.98944444444444
> so we can infer that
> <http://dbpedia.org/resource/Material_Girl>
> was recorded in
> <http://dbpedia.org/resource/Manhattan>
> -Ross.
> On Tue, Mar 10, 2015 at 5:25 PM Michael Ayres <[log in to unmask]<mailto:[log in to unmask]>> wrote:
> Catalog records deal with 'facts' of description substantiated by a trained cataloger examining the physical item in hand—'inferences' should never come into play other than perhaps in a note indicated as such.  It takes people power (time/money) to fill in data fields/codes using human expertise and judgment.  Links and inferences  can be misleading and outright wrong.   (I remember a few instances when catalog records were 'mutilated' by bad authority control links, such as the time Madonna (rock singer) was substituted for the Virgin Mary.  Wrong inference!)
> 
> Yes, many records have Fixed Field data or other data/tags missing for a variety of reasons.  In the early days it wasn't always seen as critically important by some folks either because it sometimes duplicated what was already stated in the 'important part' of the record, or time and work quotas didn't allow that level of detail, etc.  And some would ignore its importance if it didn't affect what printed on the cards—not thinking about the possibilities that computer applications might bring (for better or worse) in the future.  And the fact that it is next to impossible to get ILS vendors to incorporate the use of so much potentially helpful data in our MARC records certainly played a role in which data was viewed as important or unimportant.  One thing I know for sure:  no matter what the framework, the usefulness of a catalog record is only as good and complete as the human thought and effort that went into its creation; and attempts to change or expand upon that through ext
raneous means should be viewed with a critical eye.
> 
> Michael Ayres | Technical Services Manager
> City of Irving  l  Irving Public Library System
> 801 W. Irving Blvd., Irving, TX  75060
> P:  (972) 721-2764   F:  (972) 721-2329
> [log in to unmask]<mailto:[log in to unmask]> | CityofIrving.org<http://cityofirving.org>
> From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]<mailto:[log in to unmask]>] On Behalf Of Ross Singer
> Sent: Tuesday, March 10, 2015 10:35 AM
> 
> To: [log in to unmask]<mailto:[log in to unmask]>
> Subject: Re: [BIBFRAME] Linked data
> 
> It doesn't have to be there if it links to other things.
> The problem is with MARC is that that record (and each copy of it in each place) would need to be updated with every enhancement.  How would the records incrementally improve?
> With BIBFRAME and RDF, the data *doesn't* have to be there.  That's the whole point of it.  But by identifying it and the resources in it, we can make inferences from other data.  And since this is the design from the start, it's not shoehorning onto a data format that isn't particularly well suited for it.
> -Ross.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iJwEAQECAAYFAlUACRgACgkQYhMlmJ6W47MVSQQAiibQkr5G0mSXVVrPSxJGqAdJ
eLR/Uerz4QRd1+oG+juB79W2Ix7fK/qpYDdZ+4Vpg3WTZ5ATbLh0yQq6e4ZgiwCf
o03vfMHTOTu66BYlDqv9GL+JIeUIY9HPue3L2IuOy6AzsRUjqNG6o6GwQFXmLEJS
IJlEquwEeT1Eo42Ulhw=
=F2OF
-----END PGP SIGNATURE-----

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

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
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