lcnetdev / bibframe-ontology Goto Github PK

Justification: By removing range of bf:place, objects that are not typed bf:Place will not have undesirable entailments. E.g. We want to use bf:place to link to GeoNames entities, but not have those entities entailed as type bf:Place.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: The Sample Data section in https://github.com/LD4P/arm/blob/master/modeling_recommendations/pagination_foliation.md provides numerous pagination and foliation examples that provide fuller details of the extent, which currently cannot be accommodated fully by bf:extent/Extent, bf:unit/Unit, bf:count. The pagination and foliation requires understanding the sequence of various counts of pages, foliation, etc., and while one option is to turn each count into a bf:Unit, there is currently no way to order the various bf:Units and unlikely that it would be sustainable to maintain these a separate resources.

If not using separate bf:Unit resources to capture information (and rather than introducing a new datatype property for pagination and foliation), creating :PaginationFoliation as a subclass of bf:Extent allows the property query path to remain the same as the more general bf:Extent pattern, while still saying this particular extent is speaking specifically to the pagination and foliation of a bibliographic resource.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: Many notes can be attached to the appropriate node and then note type is therefore implied. That limits the cases where a noteType has to be defined. Using subclasses would provide a higher level of standardization. See also the related proposal #33

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Remove “Used with Work, Instance, or Item” on bf:title, to allow use with events and other resources, e.g. ExhibitionEvents.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: While an rdfs:comment does not mean that bf:colorContent can only be used with Work or Instance, the ArtFrame working group nevertheless feels that it would avoid confusion to remove this recommendation altogether. There are a number of use cases, where we feel that colorContent should be more appropriately associated with the Item (e.g. a published print was hand colored after the fact)

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

In bflc there is a property and Class for encodingLevel. Being able to grade descriptions is useful in many dealings with metadata. However a suggestion if it moves into the regular Bibframe vocabulary would be to instead add descriptionLevel (objectProperty) and DescriptionLevel (Class). Justification for this would be following the naming conventions of other properties used with the AdminMetadata Class. Also make it open for more broader use focusing on the descriptive content, not like the term encoding which I think for many implies something more technical oriented. SubClasses like EncodingLevel could of course still be used, if found useful to cater for different schemas like the MARC encoding level: http://id.loc.gov/vocabulary/menclvl.html

"Resouce" instead of "Resource"

Justification: The class and predicate pairs are redundant; specifically, a work covers an object, and the type of object does not need to be repeated in the predicate. We recommend a single predicate, bf:covers, and inverse bf:coveredIn.

Also, we recommend removing the domain Work, since other types of resources, such as ExhibitionEvents, can have coverage.

This recommendation helps address current inconsistencies with the way the two existing coverage properties behave. The range of bf:geographicCoverage is bf:GeographicCoverage, even though bf:Place should be sufficient. bf:temporalCoverage is a datatype property even though bf:Temporal exists as an entity. If bf:covers is created, the range should be open to allow for use with bf:Place (bf:GeographicCoverage isn't needed) and bf:Temporal.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

derivedFrom in AdminMetadata is defined as a literal but says it should contain a "Link to the metadata that was the source of the data." For it to be usable as a proper link it needs to be an ObjectProperty.

http://id.loc.gov/ontologies/bibframe.html#p_derivedFrom

Justification: inverses are critical to linked data environments, allowing automatic bi-directional linking from any dereferenced resource. Also, some linked data tools (e.g. Vitro) require assertions in both directions to navigate back and forth from resources.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

The labels for originDate (Associated title date) and originPlace (Associated title place) suggest they are only used in association with a title. However the definition and domain states that they are both used with the work entity. Updating the labels to simply "Origin date" and "Origin place" would make these properties less ambiguous and not locked down in context.

Another way forward could be to instead use something like a single origin objectProperty and class to be able to make more expressive statements with for example date and place. Comparable to the possibilities with the capture property.

Justification: It produces an undesirable entailment when linking directly to a skos:Concept vocabulary.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: bf:part and bf:Mount are sufficient, allowing a single pattern for parts.

We believe that a Mount is a part of a resource, similar to Frame, Binding, etc. We therefore propose defining a Mount class (note the semantics differ from bf:Mount, which is a material) alongside these other classes, using bf:part to link the bibliographic resource to its part.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: The ARM Awards Ontology (https://ld4p.github.io/arm/award/ontology/0.1/award.html), though a relatively simple model, provides greater machine actionable expressivity over the current bf:awards.

• In the ARM Awards Ontology awards are treated as RDF resources so that one can confidently query resources related to a particular award, e.g. given me all the resources related to http://dbpedia.org/resource/Caldecott_Medal.
• The ARM Awards Ontology also provides an AwardReceipt class to allow one to assert when the award was received and the nature of the receipt (e.g. honorary mention, nominee).

By deprecating bf:awards and using the ARM Award Ontology, the BIBFRAME community would have a single expressive pattern to link BIBFRAME resources to Awards.

Note: The ARM Award Ontology uses an Activity Pattern rather than the bf:Contribution, but the bf:Contribution pattern could easily replace the bf:Activity class.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

http://www.w3.org/2002/07/owl#ontologyIRI does not exist, which leads to an accusation of namespace hijacking in tools like http://oops.linkeddata.es/

While the functional-style specification for OWL 2 does include an ontologyIRI property, the OWL2 serialization at http://www.w3.org/2002/07/owl explicitly states that it is only a partial description of OWL2.

Perhaps the ontologyIRI property is available from a different namespace, but as it cannot be resolved at the given URI, I would recommend removing it from the BIBFRAME vocab definition.

Open up the domain of bf:extent so that extents that may vary from the “ideal Instance” can be captured on bf:Items. E.g. pages may be missing from a specific copy.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

The label for bf:identifies should probably be "Resource identified".

<owl:ObjectProperty rdf:about="http://id.loc.gov/ontologies/bibframe/identifies">
  <rdfs:domain rdf:resource="http://id.loc.gov/ontologies/bibframe/Identifier"/>
  <skos:definition>Resource that is associated with a character string that serves to differentiate one resource from another.</skos:definition>
  <rdfs:label>Resouce identified</rdfs:label>
  <owl:inverseOf rdf:resource="http://id.loc.gov/ontologies/bibframe/identifiedBy"/>
  <dcterms:modified>2017-02-03 (New inverse)</dcterms:modified>
</owl:ObjectProperty>

bf:Urn is currently defined as "Uniform Resource Number", but (per RFC 8141 https://datatracker.ietf.org/doc/rfc8141/), it should be "Uniform Resource Name".

Justification: The ARM Measurement Ontology (https://ld4p.github.io/arm/measurement/ontology/0.1/measurement.html), though a relatively simple model, provides greater machine actionable expressivity over the current bf:dimensions. In current MARC cataloging practice dimensions are recorded in one single subfield (300 $c) even if the content standard or domain specific cataloging practice direct the cataloger to record the measurements in much more detail. BIBFRAME has carried this forward by defining the datatype property bf:dimensions. However, there are number of domain specific ontologies (such as QUDT, VRA RDF and CIDOC CRM) that do provide more granularity and in 2015 a discussion paper was submitted to the Committee on Cataloging: Description & Access to expand RDA instructions in this area. This ARM Measurement Ontology provisions for pairing measurements and their units in such a way that sizes, durations, etc. can be computed and compared.

By deprecating bf:dimensions and using the ARM Measurement Ontology, the BIBFRAME community would have a single expressive pattern to describe measurements with BIBFRAME implementations.

Note: For more information on the recommended implementation of the ARM Measurement Ontology (including the reuse of QUDT terms), see: https://github.com/LD4P/arm/blob/master/modeling_recommendations/measurements.md

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Create as inverse of bf:agent, bf:isAgentOf to link from an Agent. This is particularly important in a linked data environment, when only the Agent URI is known/dereferenced.

From hbz/swib18-workshop#33 (comment).

There are redundancies between classes in the MADS and Bibframe vocabularies which both are used: bf:GenreForm and mads:GenreForm, bf:Temporal and mads:Temporal, bf:Topic and mads:Topic

This is a test issue.

Justification: inverses are critical to linked data environments, allowing automatic bi-directional linking from any dereferenced resource. Also, some linked data tools (e.g. Vitro) require assertions in both directions to navigate back and forth from resources. For example, from a Person URI, we would want to link to the Works about them.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: Current definitions reference only the organization and arrangement of a collection of objects. We recommend the extension of the terms to include individual objects, so that for example, during exhibitions the arrangement of a book (opened to plate 10) can be noted.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: inverses are critical to linked data environments, allowing automatic bi-directional linking from any dereferenced resource. Also, some linked data tools (e.g. Vitro) require assertions in both directions to navigate back and forth from resources.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: Removing the domain bf:Instance will allow the possibility to assert on bf:Items materials that that are not the same as an "ideal" bf:Instance. The ranges should remain unspecified to allow for use with materials vocabularies (e.g. Getty AAT) that do not declare their terms to be of type Material.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: inverses are critical to linked data environments, allowing automatic bi-directional linking from any dereferenced resource. Also, some linked data tools (e.g. Vitro) require assertions in both directions to navigate back and forth from resources.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Bibliographic field 510 in MARC is mapped to bflc:indexedIn (http://id.loc.gov/ontologies/bflc/indexedIn) but it is not RDF dereferencable, which either indicates an incorrect mapping or a future prospect for something which not yet exists in the bf/bflc RDF?

Justification: Attributions are generally applicable across all domains.
In the MARC 21 standard this has so far been handled by adding subfield j (attribution qualifier) to the 1xx field in the bibliographic record. The MARC Relator Terms contain “Attributed name” (http://id.loc.gov/vocabulary/relators/att) for use in this subfield. However, the ArtFrame group felt that attributions behaves somewhat differently from other relators such as artist or author.
Background: https://github.com/LD4P/arm/blob/master/modeling_recommendations/attributions.md
Note: The attribution modeling recommendation doc includes references to the arm activities model. The activities could be reformulated as contributions.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Change definition bf:Mount to be a mount object rather than a mount material, or remove the class and leave it to be defined by ArtFrame/RareMat groups along with other resource parts such as Binding, Frame, etc. This will allow a more consistent approach to both materials and parts.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Because limitation statements capture string values, rather than creating a distinct predicate, the proposal is to create a subclass of bf:Note, http://example.org/LimitationNote.

For more context on the recommendation, see: https://github.com/LD4P/arm/blob/master/modeling_recommendations/limitation_statements.md

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: A super property bf:material/bf:materialOf pair would be useful for situations where it's not applicable or clear how to decide whether a material is the base or applied.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

From hbz/swib18-workshop#33 (comment). There are at least four bflc properties used in the Bibframe works dataset where the URIs do not resolve:

http://id.loc.gov/ontologies/bflc/consolidates, http://id.loc.gov/ontologies/bflc/relatorMatchKey, http://id.loc.gov/ontologies/bflc/procInfo, http://id.loc.gov/ontologies/bflc/profile

Extend definition beyond geographic locations to physical and electronic locations, as well as locators such as entries in a source and cell coordinates in a table. Electronic locations are relevant to online exhibitions, and it is good practice to define terms broadly for general use. Subclasses can be defined either in BIBFRAME or extensions for specific types of locations.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

The definition for both these properties states "For use to relate/connect Works under FRBR/RDA rules" (one property uses "relate"; the other uses "connect"). PMO would like to be able to use this property for modeling works, but not restrict it to either FRBR or RDA. Perhaps the sentence could be changed to read: "For use to relate Works under LRM/RDA guidelines or similar implementations".

bf:hasPart/bf:partOf says is 1. Used with: Work, Instance, Item; and 2. has Expected Value: Work, Instance, Item. This listing should include Event in both cases.

Create as inverse of bf:contribution (bf:isContributionOf) to link from an Agent to the Work. This is particularly important in a linked data environment, if only the Agent URI is known/dereferenced, rather than coming from the point of view of the Work. See also: #3

Expand definition of bf:GenreForm (The definition only refers to moving images in its examples. Some literary or art examples would be good, or just reusing the bf:genreForm definition which is simply "Form category or genre to which a resource belongs" which makes it much broader.)

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: This would allow bf:Events to be applied in contexts other than as the event content of a work, e.g. exhibitions, auctions, theft.

We recommend removing "used with Work, Instance, or Item" from the bf:subject definition, so that it can apply to other types of entities, e.g. ExhibitionEvents.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

It seems that PublisherNumber (http://id.loc.gov/ontologies/bibframe.html#c_PublisherNumber) has inherited the rather vague label "Other publisher number" from 028 i1=5 in MARC21, which in that context makes more sense because of its more "list-like" nature. I suggest it would be more aligned with the BF2/RDF model to just use "Publisher number" allowing it to be a more general Class and let the definition clarify usage.

Possibly this is also a reflection of the more specialized publisher numbers for music and video and it could make sense that these were instead subClasses of PublisherNumber.

Identifier has several useful subClasses. A suggestion to add some widely used coordinating identifiers for Agents like Orcid and Viaf would be useful complementing the already included Isni subClass.

Following the Linked Open Vocabulary best practices, there are a few statements that would be useful additions to the owl:Ontology element:

• dc:description to describe the purpose of the vocabulary
• dc:issued to track the first issuance of the vocabulary
• rdfs:comment to include a changelog for the major revisions
• all of the rights & property statements (dc:rights, cc:license, dc:publisher, dc:contributor)

Also we should indicate that the language is xml:lang="en" throughout, to better support translation efforts.

Justification: The ARM Custodial History Ontology (https://ld4p.github.io/arm/custodial_history/ontology/0.1/custodial_history.html), though a relatively simple model, provides greater machine actionable expressivity over the current bf:custodialHistory. In the ARM Custodial History Ontology, custodial histories can have distinct related events that link to agents at a particular time an place. Together this allows to query when, where, and who has been involved with a particular item, and track the sequence of events.

By deprecating bf:custodialHistory and using the ARM Custodial History Ontology, the BIBFRAME community would have a single expressive pattern to link BIBFRAME resources to custodial histories.

Note: The ARM Custodial History Ontology uses an Activity Pattern rather than the bf:Contribution, but the bf:Contribution pattern could easily replace the arm:Activity class.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

bf:relatedTo has the definition: Any relationship between Work, Instance, and Item resources. Could it be expanded to include Event as well?

Justification: Accession numbers are an important identifier for cultural heritage institutions to record and track an object in their collections. These numbers are also useful in the provenance of an object. BF2 does not explicit way to record accession numbers that are currently being recorded in MARC 541 $e. This issue was discussed during the Rare Material and ArtFrame Ontology Spring on March 2-3, 2017, and it was determined that accession numbers are an essential identifier and must have some way recording this information in a linked data ontology for cultural heritage and rare materials. See: https://github.com/LD4P/arm/blob/master/modeling_recommendations/accession_numbers.md.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

The mapping of MARC field 777 says bf2:issuedWith should be on a Work entity, but the RDF says issuedWith is restricted to Instances. Either issuedWith needs a a broader domain and range to allow for more entities or the mapping needs to be revised.

777 - ISSUED WITH ENTRY (R) | W - issuedWith

<owl:SymmetricProperty rdf:about="http://id.loc.gov/ontologies/bibframe/issuedWith">
<rdfs:domain rdf:resource="http://id.loc.gov/ontologies/bibframe/Instance"/>
<rdfs:range rdf:resource="http://id.loc.gov/ontologies/bibframe/Instance"/>
skos:definitionResource that is issued on the same carrier as the resource being described.</skos:definition>
<rdfs:subPropertyOf rdf:resource="http://id.loc.gov/ontologies/bibframe/accompanies"/>
rdfs:labelIssued with</rdfs:label>
dcterms:modified2016-04-21 (New)</dcterms:modified>
</owl:SymmetricProperty>

Justification: bf:appliedMaterial and bf:baseMaterial are sufficient.

We do not believe that BaseMaterial and AppliedMaterial are types of things. A material instance (e.g. brass) is simply a Material, and it may be used as the base material or the applied material in specific cases. A material which is a base material to one resource may be the applied material of another.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: inverses are critical to linked data environments, allowing automatic bi-directional linking from any dereferenced resource. Also, some linked data tools (e.g. Vitro) require assertions in both directions to navigate back and forth from resources.

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

Justification: BF is right to separate font from the other types of “notation,” since font refers to the style in which symbols are printed rather than to the symbol systems themselves. However, typeface is semantically related more to font size than to these symbol systems. Further, BF would include in addition to font size, other properties of a font - typeface and style.

The ARM Core Ontology (https://ld4p.github.io/arm/core/ontology/0.1/core.html), includes the patterns to allow Fonts and Handwriting to be handled distinctly from Notations. For more information on the recommendation see: https://github.com/LD4P/arm/blob/master/modeling_recommendations/fonts_handwriting_notations.md

By deprecating bf:FontSize and predicate bf:fontSize and using the related terms from the ARM Core Ontology, the BIBFRAME community would have a single expressive pattern to describe Fonts, Handwriting, and Notations within BIBFRAME implementations.

The following two minor changes to notation related term definitions would complete the distinction between Notations and style elements capture in Fonts and Handwriting:

• Remove “typescript” from existing notation-related definitions.
• Change “alphabet” in notation-related definitions to “writing system,”

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]