by Karen Coyle, https://kcoyle.net

Introduction

A previous Code4lib journal article (Coyle, 2022) and a book chapter before that (Coyle, 2016) described some ways that non-library metadata creators have incorporated the concepts of Work, Expression, Manifestation, and Item (WEMI), first described in Functional Requirements for Bibliographic Records (FRBR). The article described examples of communities using the WEMI concepts that they had discovered in FRBR. However, these communities were using WEMI for data unrelated to libraries with the result that some of their uses did not adhere to the model expounded in the FRBR report. The Code4lib article proposed that a version of WEMI could be developed that was more appropriate to non-library data by abstracting the base concepts from the library-specific design.

A vocabulary defined using the Resource Description Framework Schema (RDF/S) in the Dublin Core Metadata Initiative (DCMI) namespace is now available that implements this simple idea.

Part I: OpenWEMI Vocabulary

Key documents

• Specification
• HTML vocabulary display
• Vocabulary in turtle (Normative)
• The OpenWEMI Cookbook an ongoing gathering of use cases and examples.

Additional documents, including examples, are at the OpenWEMI github site.

The motivation

The library community produced a multi-layered conceptual model of its catalog metadata in 1998, in a report titled Functional Requirements for Bibliographic Records (FRBR) (IFLA 2009). This was later developed into the Library Reference Model (LRM) (Riva 2017). The FRBR report introduced a view of library catalog resources with a four-part structure at its base: Work, Expression, Manifestation, and Item (WEMI), and these were incorporated into the LRM. Although the FRBR and LRM models were defined only in relation to library catalog data, communities unrelated to libraries found utility in the WEMI concepts for the description of a variety of created resources. (See the OpenWEMI Bibliography for examples.) In many cases these reuses varied significantly from the library application model, and in ways that, at least in the RDF world, could result in inconsistencies in the semantics of the vocabulary terms.

OpenWEMI frees the WEMI concepts from the original library application to allow these to be adapted by other metadata communities where their use would contradict the semantics of the library-defined model. The changes to the WEMI model in OpenWEMI are subtle yet are designed to overcome the restrictions included in the library model. OpenWEMI can be used by communities adjacent to libraries, such as non-library archives, but can also be expanded to anyone using metadata to describe created resources in any domain: architecture, manufacturing, entertainment, and more, including less formal data practices.

The philosophy

It is to be expected that those creating metadata in the course of their work will be thinking only of their own application needs. It is less common that models are created with no specific application in mind, or with a goal of serving a wide variety of needs.(Gruber, 1993) A prime example of the latter is the Dublin Core Metadata Terms (DCMT). These minimally constrained terms have gained traction on the Web and elsewhere precisely because they have few constraints on their definitions. Each term in DCMT describes an aspect of a resource, any resource, and aside from term definitions and some suggestions for value types, the rest is unconstrained.

Similarly, OpenWEMI is also not limited to a particular application, but where DCMT is primarily made up of terms to be used in descriptive metadata, OpenWEMI consists mainly of concepts — in the form of RDF classes — that can provide the scaffolding for metadata and metadata vocabularies. A goal of OpenWEMI is to offer a possible way for metadata developers to think about their data with the least possible constraint on their modeling choice.

The OpenWEMI RDF Vocabulary

The OpenWEMI vocabulary is defined in RDF/S with use of Web Ontology Language (OWL) functions when a union of classes is needed.

Classes

The OpenWEMI classes are:

• openwemi:Endeavor: “A creation”
• openwemi:Work: “An abstract notion of an Endeavor.”
• openwemi:Expression: “A perceivable form of an Endeavor.”
• openwemi:Manifestation: “A realization of an Endeavor in physical, digital, or experiential form.”
• openwemi:Item: “An instantiation of an Endeavor.”

The class openwemi:Endeavor originated in the FRBR-based vocabulary created by Ian Davis, Richard Newman, Leigh Dodds, and Bruce D’Arcus.(Davis, 2005) This vocabulary was not sanctioned by IFLA, yet it resulted as the only RDF-defined vocabulary for FRBR and thus was included in projects wishing to use FRBR in their RDF instance.

Figure 1. OpenWEMI class diagram.

OpenWEMI includes openwemi:Endeavor as an umbrella class to the WEMI classes. Each of the WEMI classes is subclassed to openwemi:Endeavor, and each class is defined in its relation to openwemi:Endeavor. openwemi:Endeavor can allow reference and searching in situations where the precise usage of the OpenWEMI classes is unknown. It also will support the addition of other classes at the level of the OpenWEMI “stack” if needed. Like other high-level classes such as owl:Thing, openwemi:Endeavor is in the background of OpenWEMI and is not likely to be used explicitly in metadata, although there is no prohibition against this.

Properties

The properties of OpenWEMI define only the essential relationships between the classes. There are no properties for descriptive metadata. That latter is left entirely to the metadata efforts that make use of the OpenWEMI vocabulary.

The properties are designed to reflect the general semantics of WEMI, maintaining the logical direction from the most concrete (Item) to the most abstract (Work). Within that one constraint, however, the ranges and domains of the properties allow the properties to be used with any classes of a more abstract definition. Thus, openwemi:Instantiates has a domain of openwemi:Item and a range of openwemi:Manifestation, openwemi:Expression, or openwemi:Work, or any combination of those.

The primary properties of the model are:

• openwemi:expresses (domain: Expression | range: Work)
• openwemi:expressedBy (domain: Work | range: Expression)
• openwemi:manifests (domain: Manifestation | range: Work or Expression)
• openwemi:manifestedBy (domain: Work or Expression | range: Manifestation)
• openwemi:instantiates (domain: Item | range: Work or Expression or Manifestation)
• openwemi:instantiatedBy (domain: Work or Expression or Manifestation | range: Item)

Note that each property has two options, one that takes a bottom-up view (openwemi:manifests, openwemi:instantiates) and a parallel property that takes a top-down approach (openwemi:manifestedBy, openwemi:instantiatedBy).

Figure 2. OpenWEMI class relationships.

“Related” Properties

Another set of properties supports statements of relationships between like classes:

• openwemi:relatedWork (domain:Work | range: Work)
• openwemi:relatedExpression</code (domain:Expressio>n | range: Expression)
• openwemi:relatedManifestation (domain:Manifestation | range: Manifestation)
• openwemi:relatedItem (domain:Item | range: Item)

A property such as openwemi:relatedExpression could be the superclass to a property expressing the relationship between an original text and a translation, both of which are defined as expressions in this :

myMD:translationOf rdfs:subpropertyOf openwemi:relatedExpression .

After which all uses of myMD:translationOf will be inferred to be between two openwemi:Expressions.

“Common” Properties

Most communities work with data that are not defined in terms of the WEMI concepts. Data managers may still wish to make use of some of the WEMI concepts to express relationships between two resources that may or may not be modeled as WEMI. With these properties, originally defined by Ross Singer of Talis at open.vocab.org, it is possible to state that any two entities share a common Work, common Expression, common Manifestation and/or common Item. For example, one can make a statement that two metadata instances, one in a library catalog in MARC format and one in Amazon in their proprietary format, do indeed represent the same Work, the same Expression, and/or the same Manifestation.

These properties differ from the OpenWEMI “related” in that there is no definition of domain or range. While not interrelated with the OpenWEMI-defined properties we included these as in the spirit of OpenWEMI and of RDF, allowing anyone to make connections between metadata instances with these useful concepts.

• openwemi:commonEndeavor
• openwemi:commonWork
• openwemi:commonExpression
• openwemi:commonManifestation
• openwemi:commonItem

How OpenWEMI might be used

You can use OpenWEMI directly without creating subclasses or properties, but keep in mind that OpenWEMI as defined has very loose semantics. If that fits your use case, then by all means use the defined OpenWEMI vocabulary. If you wish to “make it your own” then you will want to create a resource-specific version that is more expressive of your metadata by subclassing your model components to OpenWEMI. This provides a WEMI-based vocabulary that is compatible with your semantics. For example, if you are creating metadata for music materials (prefixed “mu:” here), you can create music-defined subclasses to openWEMI classes:

mu:MusicWork rdfs:subclassOf openwemi:Work . 
mu:MusicExpression rdfs:subclassOf openwemi:Expression.

etc.

And you would give your classes definitions that make sense in your data environment:

• mu:MusicWork - “A distinct musical creation”
• mu:MusicExpression - “The work as expression in musical notation”
• mu:MusicManifestation - “A produced or published realization of the music.”
• mu:MusicItem – “A single exemplar of the realized music.”

Additional levels of subclasses can be used to describe types of resources in your collection, such as:

Class	SubClass
mu:MusicWork	mu:Symphony mu:Contata mu:Serenade
mu:MusicExpression	mu:Score mu:Libretto mu:PerformedMusic
mu:MusicManifestation	mu:CD mu:Streaming</code
mu:MusicItem	mu:ArchivalCopy mu:LendingCopy

Because OpenWEMI has few constraints of its own, additional constraints can be added to the locally subclassed elements. For example, the classes subclassed to OpenWEMI classes can be defined as disjoint, and domains and ranges can be defined as more limited than in OpenWEMI proper.

mu:Item rdfs:subclassOf openwemi:Item
	owl:disjointWith mu:MusicManifestation ;
	owl:disjointWith mu:MusicExpression ;
	owl:disjointWith mu:MusicWork .

mu:item rdfs:range mu:MusicManifestation .

If you already have a vocabulary that you are using but you wish to include OpenWEMI concepts in your instance data you can use the the OpenWEMI class directly in the instance data you are creating. Using the music classes above and Dublin Core Terms, in RDF this could look like:

ml:Z1234 a mu:Serenade ;
  dct:creator "Dvořák, Antonín" ;
  dct:title "Serenade in E major" .

ml:Z345 a mu:PerformedMusic ;
  openwemi:expresses ml:Z1234 ;
  dct:Type "Serenade" .

ml:Z897 a mu:CD ;
  openwemi:manifests ml:Z345 ;
  dct:title "Serenade in E major for string orchestra" ;
  dct:description "Program notes by Yoshiyuki Fujita in English, French and German translation" ;
  dct:identifier "CO-78919 Denon" .

ml:abcd a mu:LendingCopy ;
  openwemi:instantiates ml:Z897 ;
  dct:identifier "CD 12757" .

This example uses the language of WEMI (mu:MusicWork) but there are no restrictions on the names of classes or properties derived from OpenWEMI.

Part II: OpenWEMI vs FRBR/LRM

OpenWEMI is purposely not the same as the WEMI concepts in FRBR and the LRM. This section describes the primary differences.

OpenWEMI is not specific to any application or community

FRBR and LRM are explicitly in support of the library catalog application. As the LRM document states: “IFLA LRM, as its name indicates, remains a model issuing from the library community for library data.” (Riva 2017 p. 12) Both base their analysis on a set of user tasks that mirror the actions of library users who approach the catalog for the purpose of finding library materials to use: Find, Identify, Select, Obtain, Explore.

OpenWEMI aspires to be useful in the description of anything that can be considered “created.” (While “created” can be contrasted to “natural” it is not forbidden for anyone to make use of OpenWEMI to describe something in the natural realm.) Our goal in developing OpenWEMI was to create a vocabulary that makes use of the general concepts in FRBR and LRM’s WEMI but to remove any aspects that would favor any one application. This meant broadening the definitions of the WEMI classes beyond those in the library models and eliminating any elements of the model that would define the classes and properties as being limited to a specific application or community of practice.

OpenWEMI is an RDF vocabulary

IFLA has designated both FRBR and LRM as “conceptual models.” Both are defined using terms from an entity-relation model. No coded vocabulary was provided for FRBR; LRM has an RDF vocabulary defined in the IFLA Standards namespace which, however, is not mentioned in the LRM documentation and does not appear to be in use. OpenWEMI is first and foremost an RDF vocabulary. FRBR and LRM can in theory be implemented in any data model, while OpenWEMI serves best those that support the RDF framework, such as JSON Linked Data (JSON-LD).

OpenWEMI does not enforce interoperability… but neither do FRBR/LRM

OpenWEMI classes and properties are semantically broad. Any metadata models based on OpenWEMI are not guaranteed to be interoperable. That metadata functionality must be instilled at a more detailed level than OpenWEMI and must be built into community agreement on the metadata model being used.

The LRM model itself is at least one level more abstract than the cataloging rules that libraries follow and is not itself designed for interoperability. The LRM documentation explains that “[a] wide range of decisions made in cataloging rules can be accommodated by the model” (Riva 9999, p.9) and that neither FRBR nor LRM include decisions regarding the nature of works, expressions, etc. Those decisions are defined (to the extent that they are) in the cataloging rules. Different communities could implement these differently in their metadata practices. In theory there could be a multitude of different bibliographic metadata practices based on FRBR or LRM; in practice, the library community adheres to one metadata model through the cataloging rules which are specifically designed to enforce interoperability of library metadata.

OpenWEMI does not include descriptive properties

Both FRBR and LRM are vocabularies for bibliographic description. Although having many fewer data elements than the bibliographic vocabularies like the Machine Readable Cataloging format (MARC) and the more recent Bibliographic Framework (BIBFRAME), the properties (called “attributes” in the LRM entity-relation model) in these vocabularies are specific to the library catalog application.

OpenWEMI is a kind of empty vessel. It does not specify any properties beyond those that are necessary to create fundamental semantic relationships between the OpenWEMI classes. This means that there are no assumptions about the context within which OpenWEMI will be used, or what type of resource can be described.

OpenWEMI classes are not disjoint

The library model defined in FRBR and LRM treats the entities of WEMI as disjoint. This means that the attributes defined for each entity are distinct. This creates a solid model but it also limits the possibility of variants and of interoperating with variant models such as with the BIBFRAME Work, which combines the WEMI concepts of Work and Expression in a single class.(Baker, 2014)

A consequence of defining the classes as disjoint is that no attribute can be can be defined for use with more than one class. It is for this reason that LRM needs three different data elements for “language”:

LRM-E3-A6 Language (Expression)
LRM-E6-A3 Language (Agent)
LRM-E9-A7 Language (Nomen)

and six for “Category.”

RDA, which follows the LRM, must have separate elements for each entity, resulting in properties such as “has title of expression”, “has title of manifestation”. This results in a large vocabulary with little reuse of data elements, which may not be suitable for some communities.

OpenWEMI does not define the WEMI classes as disjoint which is reflected in the OpenWEMI property definitions. This particular openness means that classes may be defined as disjoint in vocabularies whose classes are subordinate to OpenWEMI. The general rule for subclassing is that you can further constrain the class definition but you cannot contradict the constraints that are there. If OpenWEMI classes were disjoint there would be no possibility of using them as non-disjoint in consequent metadata schemas.

OpenWEMI defines multiple relationships between its classes

The LRM WEMI has a single relationship between each class that defines a linear model from Work to Expression to Manifestation to Item. This requires that all entities exist in the metadata model based on FRBR and LRM, and only certain patterns of relationships are valid in the instance data. For example, an LRM Work can only be “realized” by an LRM Expression, but not an LRM Manifestation.

Figure 3. LRM class relationships.

OpenWEMI defines multiple relationships between its classes that however retain the semantics of abstract-to-specific that is fundamental to OpenWEMI. It does not limit those relationships to a linear connection between classes. Each OpenWEMI class can have properties that link directly or from any of the other classes as long as the general semantics of “abstract-to-concrete” are maintained. In OpenWEMI an openwemi:Item can instantiate an openwemi:Manifestation or an openwemi:Expression or an openwemi:Work. An openwemi:Manifestation can manifest an openwemi:Expression or an openwemi:Work.

There are two important reasons why OpenWEMI defines multiple possible relationships between classes. The Open World Assumption in RDF allows for the case in which not all data is present at a particular moment in time. It is easy to imagine various situations in which a “full” description does not (yet) exist, or the information is not available when the data is first created. The other reason is that some communities may determine that their metadata model does not require all of the WEMI classes. (Others, of course, may find they need to add more classes and relationships to meet their requirements.) If a metadata model does not make use of, say, the Expression class, creating a local subproperty to openwemi:manifests with a domain of openwemi:Manifestation and a range of openwemi:Work creates no inconsistencies with the OpenWEMI vocabulary definition. Properties that are subproperties of OpenWEMI properties can be defined such that their ranges are any or all of the classes defined as ranges in the OpenWEMI vocabulary. Because the ranges in OpenWEMI are a union of the OpenWEMI classes, any or all of those classes may be used without contradicting the OpenWEMI vocabulary definition.

Figure 4. OpenWEMI class relationships.

openwemi:Endeavor is not LRM-E1 Res

The LRM defines a high-level class, Res, which is defined as “Everything considered relevant to the bibliographic universe, which is the universe of discourse in this case…. “(Riva, 2017, p.19 ) OpenWEMI has also defined a class, Endeavor, that is a superclass to the four OpenWEMI classes and that provides a unifying class relationship for those four classes. The primary difference between lrm:Res and openwemi:Endeavor is that openwemi:Endeavor is open-ended, where lrm:Res is in the context of the bibliographic universe that the LRM is defining.

OpenWEMI is only WEMI

The original FRBR model was made up of three different “groups”:

• Group 1 had entities Work, Expression, Manifestation, and Item and their attributes
• Group 2 had entities Person and Corporate Body and their attributes
• Group 3 had entities Concept, Object, Event, Place, which are to be used only as subjects of a Work.

The LRM combined the conceptual models that defined groups 1 and 2. It also added concepts for time and place.

OpenWEMI is only WEMI. Other elements like agents, subjects, etc., are left to the implementations based on OpenWEMI that communities choose to develop. As stated above, this makes OpenWEMI non-aligned with any particular application or community use case, providing an unrestricted, but supported, structure for describing creative endeavors.

Conclusion

There is a need in the area of metadata development for general vocabularies that adhere to the maxim that “less is more” and that facilitate the creation of application-specific models. As Gruber states, sharing is best facilitated by the creation of vocabularies that follow the philosophy of “minimum ontological commitment.”

“An ontology should make as few claims as possible about the world being modeled allowing the parties committed to the ontology freedom to specialize and instantiate the ontology as needed.” (Gruber 1993, p910)

With OpenWEMI we have aimed to provide a model that is flexible and extensible.

Acknowledgments

The Dublin Core Metadata Initiative provided the technical framework for the development of OpenWEMI and is committed to maintaining the vocabulary in the namespace “https://ns.dublincore.org/openwemi/“.

The following members of the OpenWEMI Community Group were key to the development of this vocabulary:

• Phil Barker, Cetis LLP
• Sean Petiya, Adjunct Professor, Kent State University
• Ross Singer, Talis
• Graeme Williams

And thank you to all who commented on our work throughout the months of development.

About the Author

Karen has decades of experience with metadata use and development. She has published articles and books on the topic, and has participated in a number of standards efforts with libraries, NISO, W3C, and Dublin Core. She has been a speaker at many events and conferences. Her writings and presentations are available on her web site: https://kcoyle.net

email: kcoyle@kcoyle.net

References

Baker, T., Coyle, K. and Petiya, S. (2014), “Multi-entity models of resource description in the Semantic Web: A comparison of FRBR, RDA and BIBFRAME”, Library Hi Tech, Vol. 32 No. 4, pp. 562-582. https://doi.org/10.1108/LHT-08-2014-0081

Coyle, Karen. (2022) Works, Expressions, Manifestations, Items: An Ontology. Code4lib Journal, Issue 53. https://journal.code4lib.org/articles/16491

Coyle, Karen. (2016) “Chapter 10: Bibliographic Description and the Semantic Web.” in:FRBR, before and after: a look at our bibliographic models. Chicago : ALA Editions, an imprint of the American Library Association.

Davis I, Newman, R. (2005) Expression of Core FRBR Concepts in RDF. http://vocab.org/frbr/core.html.

Gruber Thomas R. (1993). Toward Principles for the Design of Ontologies Used for Knowledge Sharing. In: International Journal Human-Computer Studies 43. p.907-928.

IFLA Study Group on the Functional Requirements for Bibliographic Records. (2009). Functional Requirements for Bibliographic Records. Den Haag. http://archive.ifla.org/VII/s13/frbr/frbr_2008.pdf.

Library of Congress. BIBFRAME 2 Ontology. Version 2.4.0. https://id.loc.gov/ontologies/bibframe-2-4-0.html

Riva P, Le Boeuf P, Žumer M. (2017). IFLA Library Reference Model: A Conceptual Model for Bibliographic Information. Den Haag, IFLA. https://repository.ifla.org/handle/20.500.14598/40