Print

Print


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]>
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 <http://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.
>
>
>