bf:Note recent changes

[kirkhess]

We all know the note modeling approach has taken a lot of turns yet the current approach still matches the original whitepaper for the most part: https://www.loc.gov/bibframe/docs/pdf/bf2-notes-march2017.pdf

It looks like the conversion specs tell you to create notes like this:

rdf:type, no bf:noteType (example 2)

    <bf:note>
      <bf:Note>
        <rdf:type rdf:resource="http://id.loc.gov/vocabulary/mnotetype/metaentry"/>
        <rdfs:label>0 - successive</rdfs:label>
      </bf:Note>
    </bf:note>

Or just a label (example 1)

    <bf:note>
      <bf:Note>
        <rdfs:label>0 - successive</rdfs:label>
      </bf:Note>
    </bf:note>

First, the mnotetype is a skos:Concept, not a bf:Note, despite what is in the ontology comments on Note“ Any entry from the Note Types vocabulary at ID may be used; all have been defined as a bf:Note”. That should be easy to update in id.loc.gov.

I think in each of these types if there are multiple choices I think you really meant something like this:

    <bf:note>
      <bf:Note>
        <rdf:type rdf:resource="http://id.loc.gov/vocabulary/mnotetype/metaentry/successive"/>
        <rdfs:label>0 - successive</rdfs:label>
      </bf:Note>
    </bf:note>

Which you could reduce to:

Also, if a note is really a byte in a fixed field, consider adding the code (not really in the whitepaper as well...)

    <bf:note>
      <bf:Note>
        <rdf:type rdf:resource="http://id.loc.gov/vocabulary/mnotetype/metaentry/successive"/>
        <rdfs:label>successive</rdfs:label>
        <bf:code>0</bf:code>
      </bf:Note>
    </bf:note>

Finally, if you aren't using noteType any more than perhaps it needs to be explained when it should be used? (Example 3)

And I don't think example 4 is an option any more, please consider publishing an updated whitepaper with the current thinking. Thanks!

[kefo]

First, the mnotetype is a skos:Concept, not a bf:Note, despite what is in the ontology comments on Note“ Any entry from the Note Types vocabulary at ID may be used; all have been defined as a bf:Note”. That should be easy to update in id.loc.gov.

Agreed. When written, that statement was true. It keeps getting wiped out. I'll talk to someone about it.

I think in each of these types if there are multiple choices I think you really meant something like this:

No, we meant what we mean in this case. It's a generic note type for "metadata entry convention" (whatever that is!). You use the generic note type and then the rdfs:label is the specific note. (What you raise - that this is essentially a controlled list of values - is valid but tangential to the note issues you are posting about.)

Also, if a note is really a byte in a fixed field, consider adding the code

Mostly the same as previous comment. (If converted to a controlled list, then, yes, perhaps the label is the label and the code the code.)

I'm thinking at this point we should review some of these as fodder for (more) controlled lists. @jodiw01 ?

Example/option 3. The text reads "The note type may be known, but there may be no known class for that type, internal or external. In that case the type may be expressed by the property bf:noteType." Doesn't that make it clear it should be used when there is "no known class for that type, internal or external?"

Example/Option 4: I don't think anything we're doing or what you have described invalidates option 4. It still seems viable to me. It's just a bf:note property that references an anonymous resource that does not have a specific note type.

[kirkhess]

Thanks! Your comments make sense - I think I was indirectly suggesting a way to reduce the number of blank nodes that are generated from notes. it would require more lists as you mentioned and some data crunching (looking forward to the latest bulk download...)

I get what you are saying about 3 and 4 as theoretically ok but in practice I think LC doesn't use them so it might be nice to indicate there's a preferred way vs. a non-preferred way 5 years later?

Without usage instructions in the ontology my team looks at data from LC and if the property bf:noteType is never used, no one has any idea how to use it and wonders if they need to support it. Also, I doubt anyone would do example 4 - the ontology has a range of bf:Note on bf:note and I think we know in practice processing XML is harder when the class is missing or rdfs:Resource.

[ntra00]

I think at a minimum we need to expand the definition of bf:noteType, but it helps we now have examples pulled from actual data for the other kind; I put in a handmade example for notetype that will go live as soon as we next update to production.

https://id.loc.gov/ontologies/bibframe.html#p_noteType 

Notetype was defined: "Type of note." Change to "Type of note if not found in a controlled list such as https://id.loc.gov/vocabulary/mnotetype" ?