WorldCat ontology primer

1.4.1 The ontology reflects the state of our field

OCLC has invested in structuring the ontology and using language to support a more inclusive range of experiences and worldviews. However, there is a tension between inclusive description and the legacy of knowledge systems and data that reflect Western-centric worldviews that, at times, uphold racist and colonialist viewpoints. To scaffold a transition toward a more inclusive future, it may be necessary to diverge from legacy practices. As the WorldCat ontology matures, additional scope notes will be provided that guide inclusive descriptions of WorldCat Entities. The WorldCat ontology properties, labels, and definitions should not confer legitimacy on acts of enslavement, violence, theft, and other injustices; nor fail to recognize the harms they caused. The information recorded in properties is not intended to confer legitimacy among conflicting claims of ownership or creation.

1.4.2 Properties related to Person entities

WorldCat Entities is an authoritative, but not biographical, resource. In keeping with the values and practices of the library cataloging community, properties which describe sex, gender, religion, race, ethnicity, sexual orientation, national identity, and/or citizenship status have been purposefully omitted from the WorldCat ontology. Properties which convey places of birth, death, and/or residence are intended only as statements of fact, not as an expression of national identity or citizenship status. Properties that describe common agent roles use gender-inclusive terms to the greatest extent possible. In some cases, these property labels may reflect terms which have become more gender-neutral in common usage.

1.4.3 Enslaved persons

Inspired by the work of the Enslaved project, special consideration has been given to properties that make statements about enslaved persons. It is morally and semantically incorrect to model the exchange of human lives using the same concepts that apply to the buying and selling of Works, Places, and Organizations. To avoid misinterpretation, the ontology distinctly defines wco:enslaved and wco:enslavedBy to represent these relationships in contexts where it may be the only record available for the entities involved. Any data in WorldCat Entities regarding enslaved persons is included to recognize and recover their contributions within the bibliographic universe.

1.4.4 This work is ongoing

OCLC has sought community consultation in creating and revising the WorldCat ontology but this work is ongoing. We invite feedback that will help us continue to improve our language and structures by sending an email to askqc@oclc.org.

3.2.1 Frequency

The wco:Frequency class is intended to take the form of a blank node to which multiple descriptive properties may be attached. For example, a wco:ContinuingResource may have multiple frequencies during its publication lifespan. The blank node construct allows for multiple frequencies to be applied, with applicable start and end dates.

Diagram 3.2.1a: The basic structure of the Frequency model - Image

Diagram 3.2.1b: The structure can be repeated as necessary. In this case, the Series publication was issued bimonthly from 1995-2004, then monthly after 2005 - Image

3.2.2 Measurement

The wco:Measurement class is a blank node intended to aggregate two required elements: a measurement’s value and unit. The wco:hasValue property includes SHACL constraints sh:minCount 1 and sh:maxCount 1 which require a single integer value. Each wco:Measurement node should include a wco:unit to be comprehensible. The only case in which a unit is not required is with the wco:population property, for which the unit of “persons” may be inferred. wco:Measurement nodes may also include wco:startDate and wco:endDate properties, to allow for recording changes in measurements over time.

Diagram 3.2.2a: The basic structure of the model - Image

Diagram 3.2.2b: Example - Image

Properties with expected value of wco:Measurement:

• wco:spatialArea
• wco:population
• wco:duration
• wco:elevation

Note that properties such as wco:dimensions and wco:extent are defined as datatype properties, which expect a literal value as an object. This is to accommodate significant variance in cataloging practices.

3.2.3 Performance Medium

The wco:PerformanceMedium class is designed to provide structured meaning to describe both the type and quantity of instrumentation required for musical works. This structure can be applied to instances of wco:Music (i.e., performances captured as sound) and wco:NotatedMusic (i.e., those intended to be studied or performed). Note that instrumentation in this context also includes the concept of vocalization(s).

The basic structure shows:

• A wco:Music or wco:NotatedMusic entity is linked to the wco:PerformanceMedium node.
• wco:PerformanceMedium is a blank node which fulfills the functional purpose of describing the “what” and the “how many” required for a performance.
• wco:PerformanceMedium requires two properties:
  1. wco:performedBy links to a skos:Concept which describes what is required for the performance. The use of skos:Concept facilitates linking to external vocabularies.
  2. wco:hasValue is an integer which describes how many of the “what” are required for the performance.

Diagram 3.2.3a: The basic structure - Image

Diagram 3.2.3b: Example showing an instance wco:Music which requires two violins to perform - Image

Diagram 3.2.3c: The structure is repeatable as necessary - Image

3.2.4 Postal Address

The wco:PostalAddress class is intended to take the form of a blank node which provides a common connection for the separate data elements common in postal addresses. It acts as an aggregation mechanism intended to allow the presentation of those elements as a coherent whole. The expected range of wco:addressCountry, wco:addressRegion, and wco:addressLocality are all wco:AdministrativeArea, which is designed to provide flexibility to account for variations in administrative organizations globally. While not enforced, the user is encouraged to regard wco:addressCountry, wco:addressRegion, and wco:addressLocality as an ordered hierarchy wherein:

• wco:addressCountry represents the largest wco:AdministrativeArea within which a wco:PostalAddress exists (e.g., a nation, kingdom, or other sovereign state).
• wco:addressRegion represents a subdivision of the wco:AdministrativeArea indicated by wco:addressCountry (e.g., a state, province, or territory).
• wco:addressLocality represents a subdivision of the wco:AdministrativeArea indicated by addressRegion (e.g., a city, town, or village).

Diagram 3.2.4a: The basic structure - Image

Diagram 3.2.4b: Example - Image

3.2.5 Role

3.4.1 Transactional Events

The wco:TransactionalEvent class is utilized with properties that imply a transactional or transformative context. The wco:TransactionalEvent class is designed to supply data that is specifically and uniquely relevant to the event of the transaction, such as a wco:date, wco:relatedPlace, or wco:relatedAgent.

The entities engaged in the transaction are thereby related indirectly via a wco:TransactionalEvent node to which each entity is connected by a property that expresses the nature of the transaction. Those properties are listed in table 3.4.1 with their respective domain(s). The range of each property is wco:TransactionalEvent.

The model also requires using the wco:resultedIn and wco:resultedFrom properties which express a comprehensible, linear origination and outcome of the transaction. Diagram A illustrates:

• Entity A was succeeded by Entity B.
• Entity B was preceded by Entity A.
• A wco:TransactionalEvent occurred which resulted in Entity B.
• The same wco:TransactionalEvent resulted from Entity A.
• A linear, unidirectional path can be traced from Entity A (the predecessor) to the wco:TransactionalEvent and then to Entity B (the successor), which constructs a comprehensible and chronological chain of events.
• A linear, unidirectional path can be traced from Entity B (the successor) to the Transactional Event and then to Entity A (the predecessor), which constructs a comprehensible and chronological chain of events.

Diagram 3.4.1a: The basic structure - Image

The model can be expanded to express more complex transactions. Diagram 3.4.1b illustrates the merger of two organizations.

• Organization A and Organization B merged to form Organization C.
• Organization C represents the merger of both Organization A and Organization B.
• The merger of Organization A and Organization B resulted in the creation of Organization C.

Diagram 3.4.1b: The merger of two organizations - Image

Diagram 3.4.1c: Illustrates how this structure can be expanded to show a chronology of Transactional Events - Image

3.6.1 Fictional entities

The WorldCat ontology includes wco:FictionalEntity as a subclass of wco:Work. In this way, fictional entities inherit properties which can represent their “work-ness” such as wco:creator or wco:creationDate. Any entity may be multi-classed as both an instance of wco:FictionalEntity and any other class. For example, a fictional place would be declared as an instance of both wco:Place and wco:FictionalEntity.

3.6.2 Representative work

The WorldCat ontology does not utilize the LRM notion of a “Work” as a mechanism for grouping like entities. Instead, the idea of a "Representative WorldCat Work" is proposed to act as a common connection that fulfills the purpose of aggregation. The "Representative WorldCat Work" is currently defined as the first instantiation of a WorldCat Work or that which is considered the canonical resource. Note that the "Representative WorldCat Work" is not a class type. The "representative" Work is identified by derivative Works using the wco:hasRepresentativeWork property in addition to the property which expresses a transformative relationship between the works.

Diagram 3.6.2a: Work B is both a translation of Work A, and Work A is the representative work of Work B - Image

Expanding on this diagram, "Work C" is added below showing that it is a wco:readingOf Work B, and that Work A is the wco:representativeWork of Work C. In this way, the model can express how derivative works relate to one another while still directly relating them back to the "representative" Work.

Diagram 3.6.2b: How derivative works relate to one another and to the “representative” work - Image