...
BIBFRAME makes a distinction between Provision and Contribution activities through distinct class assertions, the former primarily applying to Instances and the latter to Works. While the Ontology Group understands the reasoning behind this distinction, we believe that because bf:Works, bf:Instance and bf:Item are not disjoint and an activity subclass could potentially apply to more than one Work, Instance, Item resource type, the distinction between Instance- and Work-related activities is unnecessary and overly complicates query patterns.
bibliotek-o defines a general Activity pattern that facilitates explicit roles through subclassing of the bib:Activity class, which links Agents to BIBFRAME core classes (Works, Instances and Items). This pattern eliminates the distinction between provisions and contributions, thus simplifying both querying and potential extension for additional relationships between agents and bibliographic resources. This design pattern is adopted in other ontologies, such as the Schema.org Action class and the CIDOC CRM Activity class.
Gains: simplified Simplified/flexible model, more closely aligned with Activity ontology design patterns. Straightforward extension to Item-related activities, such as those modeled in the rare materials and art ontology extensions.
Example: Without the bf:Contribution/Provision divide, a bf:Work, bf:Instance, and/or bf:Item can have a bib:AcquisitionActivity without questioning whether the Activity is a bf:Contribution or bf:Provision.
For the full Activities recommendation document, see: https://wiki.duraspace.org/display/LD4P/bibliotek-o?preview=/79795231/83237322/bibliotek-o_pattern_activities_201612.pdf
...
Rather than using the BIBFRAME multi-path pattern, bibliotek-o commits to modeling content types, carrier types and media types through subclasses of Work, Instance, and Item, alongside type assertions on individual resources. This pattern can be interpreted as RDA implementation because it expresses content/carrier/media information about library resources and thus supports cataloging according to the RDA content standard.
Gains: simplified Simplified/flexible model, more closely aligned with established classing of objects, ability to reuse existing classes.
Example: For cd’sCDs, one could reuse the Music Ontology ’s class mo:cd. The closest analogous terms in the MARC carriers or RDA carriers are skos:Concepts for “audio disc” or “computer disc”.
...
This deviation stems from a concern about directly attributing these data to the bibliographic resource; generally, these notes types are not necessarily intrinsically related to the resource but are asserted by the cataloger. By using the OA model, one can provide a target (i.e., the resource being described) and a motivation (e.g., summarizing) for the note, meanwhile providing an intermediate node to separate the note from data intrinsically connected to the resource. Rather than simple text strings, the OA model provides richer expressivity, such as annotation bodies that are resources, along with specification of type and format; making multiple atomic but related annotations on a specific resource; and ascribing purposes and motivations to annotations.
Gains: single Single pattern for notes, greater expressivity to describe the note.
...
The use of RDAU properties is primarily due to their much more granular nature than what is afforded in BIBFRAME, as well as being a well established descriptive standard in the library community. Please note that biblotek-o does not currently address part-whole relationships, accompanying material or sequential relationships as part of the framework (as of December 2016).
Gains: greater Greater expressivity of relationships between bf:Works, Instances, Items; explicit reuse/alignment with RDA.
Example: Currently in BIBFRAME there is no what way to say a work is "based on" (rdau: P60305 ).
...
Gains: Consistent recording of origins, ordering of title parts, designation of preferred titles is designated at a relationship.
Example: Titles with multiple subtitles can capture them be captured separately, in the proper order, and with a language tag; can confidently identify Instances with better control over Title origins.
...
Broadly, bibliotek-o defines ‘legacy literals’ to mean any existing textual metadata being migrated into RDF that does not conform to the desired model and/or application profile, and represents data as unstructured, unparsed, and unnormalized string literals.
The authors of BIBFRAME are legitimately concerned with preserving these legacy literals, and have defined a broad range of datatype properties to do so. Given bibliotek-o’s preference for structured, machine actionable data over note-like strings, bibliotek-o has defined , it instead defines object properties and classes where appropriate, to provide semantically rich models and promote the future creation of structured metadata. In order to preserve legacy metadata, it defines a custom datatype legacySourceData to flag this legacy data. This approach does not distort the desired data model for what is essentially a flag for later processing; legacy literal data can be migrated to the desired data model for future cleanupdata for future cleanup, thus achieveing both goals of an expressive data model and preservation of legacy literals.
Gains: Our The model can support use cases and ontology design best practices without being limited to by how legacy metadata is structuredformulated.
Example:
508##$aPhotographer, Richard Beymer.
The This 508 MARC note above could convert to the following RDF, which can later be enhanced to assert a the more specific bib:PhotographerActivity type and the foaf:name cleaned up and parsed.
ex:activity1 a bib:Activity ;
...
bib:hasAgent ex:agent1 .
ex:agent1 foaf:name “Photographer, Richard
...
Beymer”^^http://bibliotek-o.org/datatypes/legacySourceData .
For the full Legacy Literal recommendation, see: https://wiki.duraspace.org/display/LD4P/bibliotek-o?preview=/79795231/87468650/bibliotek-o_pattern_legacy_literals_201612.pdf
...