kirkhess
commented
6 years ago AdminMetadata was a compromise to maintain a portion of the data in the fixed fields which would have been lost if we didn't invent a new entity or used an existing Linked Data ontologies (e.g. VOID).
The AdminMetadata generated from the conversion is implied to be related to the Work, Instances, and Items created by the conversion but because the conversion uses blank nodes we only have a single AdminMetadata. When we push the RDF into our semantic store we copy the AdminMetadata to the other entities, but it is still a blank node. We'll also review the properties if they as you mentioned might not apply to all three kinds of entities.
Administrative metadata needs a serious examination in light of needs for recording provenance and for maintaining linked data in a distributed library environment. This issue, however, is beyond the scope of a post here. These comments are on the administrative metadata produced by the converter.
Administrative metadata (bf:adminMetadata) is currently associated with Works, although in the ontology the property is not specified for use with a particular entity. While a MARC record contains information about many entity types (Work, Instance, Item, Topic, Agent, etc.), bibliographic description is essentially at the Instance level. Administrative metadata in the MARC record is thus about the description of Instances, at the very least. Arguably administrative metadata currently associated with a Work should instead be with the Instance in a converted MARC record. In particular, the record number in field 001 is an Instance (manifestation) identifier, not a Work identifier. bf:descriptionConventions contains information about rules used for descriptive content, which is about Instance information. For a Work, it makes sense to use creation and change dates, generation process, source and status. Everything else should probably be in the Instance.