Print

Print


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).

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

-Ross.

On Tue, Mar 10, 2015 at 5:25 PM Michael Ayres <[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 extraneous 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] | CityofIrving.org

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Ross Singer
Sent: Tuesday, March 10, 2015 10:35 AM


To: [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.