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:

MARC: http://bibframe.org/resources/Jqc1410365115/marcxml.xml
BF: http://bibframe.org/resources/Jqc1410365115/bibframe.rdf

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

--
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]> wrote:

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. schema.org/accessibilityFeature)

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] https://www.youtube.com/watch?v=avcS0aYJ2a8  Warning: seizure inducing flashing, terrible animation, poppy 90s music, ...

--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305