Work relationships and ONIX codelists issue 59

The following post was featured in the international ONIX implementation group — a mailing list that you really should follow for ONIX announcements and discussion. Want to stay on top of ONIX implementation issues in a global discussion led by EDItEUR? Join the group here and continue reading.

What are work relations in ONIX? @EDItEUR_org's Graham Bell explains it all in this blog post.
CLICK TO TWEET

Those of you that have looked at the latest ONIX codelists — issued earlier this week — will have noticed the large number of new codes added in list 164. (Click the Show/Hide button at the bottom right of the blue table to see which of the codes have been added. All the others have updated notes with improved explanations of how they should be used.)

List 164 is used for “work relations” — that is, between the product being described in the ONIX product record and a “work.” What’s a “work”? It’s a distinct intellectual or artistic creation to which a set of intellectual property rights are attached. In effect, a work is content, in the abstract sense, independent of any product that contains that content. And while the work is abstract, it’s “manifested” in one or more products — products are manifestations of works.¹ Works can have many manifestations (for example, as a hardback, as a paperback, as one or more ebooks, and so on) but products generally only manifest one work.

So by identifying the work that’s manifested in a particular product, you can easily find all products that have the same content — work identifiers can provide clear and unambiguous links between products that have the same content.

Now, works can also be modified to create other works — for example, a work can be translated, abridged, and adapted to create three different derived works which can then themselves be manifested in new products. Prior to the latest release of the codelists, ONIX could link a product to its parent work, and to a “grandparent” work (from which the parent was derived). But it could not say how the parent was derived from the grandparent. With new codes in list 164, the nature of this work-to-work derivation can be expressed.

The ONIX Implementation and Best Practice Guide has been updated — as it is with every new release of the codelists — to include an explanation of how the extended list of work relation codes can be used, with an example showing their use. Find the explanation below. Download the full guide here.

Notes:

The diagram illustrates the relationship between the product (which is the subject of the Product record) and various works.

Image description: The diagram shows the relationship between Works W, X, Y, Z and Products A and B. A is the product being described in the Product record, and is a manifestation of Work X. Work X is also manifested as Product B. Work X is derived from Work W. Work Y is then derived from Work X. Work X also has a looser link to Work Z. Each work other than X may also have its own manifestations.

The work relationships that can be specified using Work relation code always relate the product (Product A in the diagram) to a work — either directly to Work X, or indirectly to W, Y or Z via X.

The simplest code, 01, states that Product A — the subject of the Product record — is a manifestation of Work X. There may of course be many other manifestations of Work X — if Product A is a hardback, there may be paperback, e-book and unabridged audio manifestations too. One of these other manifestations is shown as Product B. The work identifier for X is shared across all those manifestations, and may be used to group them together unambiguously. Note that Products A and B may also be directly linked using
Product relation code 06 (Alternative format).

Work relation codes 02 and 03 allow identification of works W or Y — each being related indirectly to Product A via X, either as a parent or child of X (thus work W is often termed the ‘grandparent’ work of Product A). Work X was derived from W in some way — for example, W could be a novel in its original language and X a translated version, or W may be a third edition and X the fourth, or W may be complete and X abridged. Similarly, Y could be a fifth edition, or be adapted from X into a playscript.

Note that use of codes 02 and 03 do not require a Work identifier for X. The common case is for Product A — which is an abridged product — to be linked to W, the unabridged grandparent, thus implying the existence of but not explicitly identifying the abridged work X.

But codes 02 and 03 do not specify the method of derivation. For this, there is a range of codes (20 and above) which can be used both to identify W and specify the method of derivation of X from W. By translation, by revision, by abridgement, and so on. Similar codes (40 and above) relate Product A to Work Y, via X.

Work Z represents works with a much looser connection to Work X and Product A, for example using Work relation code 04, where Work X and Work Z are in the same collection, or code 05, where Work X and Work Z have at least one contributor in common.

A, W, X, Y and Z are used in the notes attached to each of the codes in List 164.

I hope this makes the changes to list 164 clearer — though bear in mind that the new codes are very much an “advanced feature of ONIX, and the well-established work relation codes 01 and 02 remain the most important to include in Product records if you can.

It should be said that there's no strong standard identifier for works, in the way that ISBN identifies manifestations (products). The former ISTC identifier standard has been withdrawn. So proprietary identifiers are common. All products that manifest the same content should share a proprietary ID, like this:

<RelatedWork>

    <WorkRelationCode>01</WorkRelationCode>        <!-- product is manifestation of -->

    <WorkIdentifier>

        <WorkIDType>01</WorkIDType>                <!-- proprietary work identifier -->

        <IDTypeName>Perfect Publishing Work ID</IDTypeName>

        <IDValue>69f1533f-3305-4d11-a3c8-ddf946780173</IDValue>     <!– type 4 UUID -->

    </WorkIdentifier>

</RelatedWork>

Quite a few publishers also use the ISBN of the first manifestation of a work as a proxy work identifier, which would use an ID type code 15, instead of 01 for a proprietary identifier.

Graham Bell is Executive Director of EDItEUR, responsible for the overall development of EDItEUR’s standards and the management services it provides on behalf of other standards agencies (including the International ISNI agency and the International DOI Foundation).

He joined EDItEUR as its Chief Data Architect in 2010, focused on the continuing development and application of ONIX for Books, and on other EDItEUR standards for both the book and serials sectors. Graham will be back, teaching Canadian stakeholders about ONIX and its practical applications in multi-day educational workshops in March 2023. To receive news about upcoming events, sign up for the Tech Forum newsletter.

---

¹ “Work” may mean something slightly different if you have a background as a librarian. A work in ONIX is more like an “expression” in a librarian’s LRM terminology, and the modifications that create new works in ONIX (e.g., translation, abridgement, adaptation, revision, and so on) create new LRM expressions.