Having a bf:Note class makes sense to me. The current approach seems
exhaustive enough to be cumbersome, but probably not exhaustive enough to
capture the full range of possibilities in the source data. Not all notes
come from 5XX fields. Here is a sample marc2bibframe conversion of a record
for a serial:


Here, bf:frequencyNote maps to the 310 field (Current Publication
Frequency). Unfortunately, it also maps to the 321 field (Former
Publication Frequency). This would seem to be a not insignificant loss of
information. 5XX fields that are distinct in MARC are mapped to generic
bf:note properties (515, 588). bf:frequency doesn't appear, but maybe it
was meant to correspond to the 008 fix field for continuing resources,
which also has a value for frequency (position 18). The need for two
distinct properties remains unclear.

In short, a bf:Note class with bf:noteType values might provide greater
flexibility and preserve more of the original semantics.


Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

On Tue, Sep 9, 2014 at 5:38 PM, Robert Sanderson <[log in to unmask]>

> Y'all ready for this? ;) [1]
> When is a literal property a 'somethingNote' and when is it just a
> 'something'?
> I assume (lacking previously mentioned MARC to BibFrame mapping document)
> that all of the Notes come from 5XX fields, which seems like something that
> could easily be rationalized along with some of the other properties, again
> assuming they're not 5XX and hence didn't get the Note moniker.
> For example, these two look ... well ... identical:
> frequency: Intervals at which the issues or parts of a serial or the
> updates to an integrating resource are issued.
> frequencyNote: Current or former publication frequency of a resource.
> Current notes are:
>   copyNote
>   awardNote
>   contentsNote
>   graphicScaleNote
>   illustrationNote
>   supplementaryContentNote
>   dissertationNote
>   geographicCoverageNote
>   languageNote
>   temporalCoverageNote
>   creditsNote
>   performerNote
>   frequencyNote
>   note (!)
>   musicMediumNote
>   findingAidNote
> And the following seem like they're intended to be "notes" in the more
> generic sense of added description by a cataloguer or other:
>   frequency
>   custodialHistory
>   immediateAcquisition
>   notation
>   responsibilityStatement
>   providerStatement -- or are "Statements" transcriptions from the
> Instance?
>   editionResponsibility
>   contentAccessibility  (though c.f.
> Given the discussion regarding assigners of URIs being important, it seems
> that creators of notes would be also important?  And thus Notes could be
> their own class, bf:Note, with properties including value, assigner, type
> and so forth.
> Rob
> [1]  Warning: seizure
> inducing flashing, terrible animation, poppy 90s music, ...
> --
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305