Editorial changes to bf:Work subclasses

[jodiw01]

As part of a review of the bf:Work subclasses, a few editorial changes are needed to existing types.

http://id.loc.gov/ontologies/bibframe/Collection
Add
SubClass Of: Work

http://id.loc.gov/ontologies/bibframe/Manuscript
Add
SubClass Of: Work
Remove
SubClass Of: Instance

http://id.loc.gov/ontologies/bibframe/MixedMaterial
Replace definition
Resource comprised of multiple types which is not driven by software. For instance, an archival collection of text, photographs and sound recordings.

http://id.loc.gov/ontologies/bibframe/Multimedia
Replace definition
Electronic resource that is a computer program or which consists of multiple media types that are software driven, such as videogames.

[kefo]

https://id.loc.gov/ontologies/bibframe.html#c_Collection
https://id.loc.gov/ontologies/bibframe.html#c_Manuscript
https://id.loc.gov/ontologies/bibframe.html#c_MixedMaterial
https://id.loc.gov/ontologies/bibframe.html#c_Multimedia

[niklasl]

This appears to be more than an editorial change. Changing the base class of a type can have unintended consequences for users of BIBFRAME, since class semantics are important for interoperability.

For example, the definition of Manuscript now diverges from common definitions such as this from the Merriam-Webster dictionary (emphasis added):

a written or typewritten composition or document as distinguished from a printed copy

Since Manuscript and Print are no longer both subclasses of Instance, we lose this clarity. Furthermore, we can no longer use Manuscript as the instance type of a Cartography or NotatedMusic work.

Would you instead recommend combining these as multiple types on a work? What would the type of the instance be (presumably just Instance)?

[kefo]

Yes, @niklasl , you are correct. The change regarding Collection and Manuscript should have been described as an ontological change, not an editorial one. We'll be more careful next time.

As for your questions:

Would you instead recommend combining these as multiple types on a work?

Yes. If i were to say more, I would add that this change was the result of confusing, contradictory description resulting from the uneven splitting of information in MARC Leader. In some cases, types were going to Work, in some cases Instance, in some cases no type was being added. After considerable study, splitting important information - like StillImage and Collection - across Work and Instance (StillImage was the Work type; Collection was the Instance type) was losing crucial meaning, namely that it was a Collection of Still Images. (It appeared to be a single StillImage with a Collection as an Instance, which was patently not the intent.) I speak presently of converting from MARC, which is a tad narrow in thinking, but catalogers working directly in Bibframe found the splitting confusing too. Your comment might suggest making Manuscript independent of Work and Instance altogether. In any event, with respect to Manuscript specifically, it was our thinking that the fact that something is a Manuscript is inherent to the Work itself (in some ways a form of the Work), despite it being defined as a physical thing defined as distinct from printed material.

What would the type of the instance be (presumably just Instance)?

We're wondering about Instance types ourselves. The four now - Print, Archival, Tactile, and Electronic - can be seen as woefully inadequate to the great breadth of types that could be applied to Instances. This would suggest adding a lot more Instance types, and that feels like a rabbit hole. Personally, I am wondering whether Instance typing is even necessary since the combination of carrier, contentType, and mediaType covers the particulars. When I do start to feel like some typing is necessary, I wonder if the distinction is merely between Physical and Electronic. Thoughts welcome.

[niklasl]

Thank you @kefo for the clarification, we suspected this was the reason and certainly sympathize with the hardships of MARC conversion.

Especially the “collection of still images” is familiar, and we have went back and forth about conceptualizing aggregation in another dimension than along the “instance/work” axis. (Some collections are of works, some are of instances.) Maybe “aggregation” is a better notion than the quite publishing-oriented “issuance”. Perhaps that will eventually go away considering these recent changes?

A while ago, we thought about “folding” media/carrier into subclasses of the concrete Instance class, and similarly turning content into subclasses of Work (and drew up a rough mapping which is in no way final, and quite insufficient for concrete cases). We’re about to revisit these kinds of slicings and normalizations, and will share thoughts as they become clearer!

[kirkhess]

BIBFRAME is kind of WEM locked right now which is another reason there's not a lot of push for instance types - the work type is the instance type.

Another issue I see is there's no easy way to convert into a bf:Tactile or bf:Archival in m2bf. You used to be able to map the LDR types to archival but it was removed in Aug. So really, the only two instance types are Print and Electronic. Maybe I missed something on Archival and I would really like to see a bf:Tactile in the wild - hoping LC can talk to the NLS and get some Braille into id.loc.gov.

That rough mapping seems promising - I've always though the 008 formats are a good choice too but they've sort of achieve this with this particular change to the Work types. Your mapping achieves a more granular set of types, esp. with the addition of microform and this might allow BF to be a little less WEM locked and better 007s.