Print

Print


Tim, Adam,

I would personally prefer subclasses as then additional note types beyond
the main specification are using the constructs of the language, rather
than relying on string uniqueness in a (doubtless not URI) noteType.

Yes, there's a choice between subclasses of bf:Note, and sub-properties of
bf:hasNote ... and I'm not religious as to which ... but it can't be both.
In this regard see the identifier decision regarding sub-properties and
scheme.  My preference for sub-classes is the same as Adam's -- easier
machine inferencing and human understanding.

Rob


On Wed, Sep 10, 2014 at 12:45 PM, [log in to unmask] <[log in to unmask]>
wrote:

> I'm not too familiar with the full range of possibilities here, so this
> may be a very naive question:
>
> Would it be better to have a type attribute on a hypothetical bf:Note
> class, or would it be better to build out a hierarchy of subtypes to that
> class? The type attribute has the advantage of tremendous flexibility at
> low cost. The class hierarchy has a little more "readability" and makes
> many kinds of automated facilities operate more efficiently (e.g.
> inferencing, some kinds of querying…).
>
> ---
> A. Soroka
> The University of Virginia Library
>
> On Sep 10, 2014, at 12:51 PM, Tim Thompson <[log in to unmask]> wrote:
>
> > 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
> >
>



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