5JSC/Restricted/ALA rep/1/Editor follow-up
Draft 2007-06-09
1
Designations of Roles and Relationships
Editor’s Comments
Principle of Flexibility
The principle of flexibility, as articulated in the RDA Objectives and Principles, states that RDA
data “should function independently of the format, medium, or system used to store or
communicate the data”. It is therefore important to avoid making assumptions about how
RDA data designating roles and relationships will be encoded, and to provide for as much
flexibility in the encoding of designations as possible.
In the proposals that have been put forward, as well as in the comments on the proposals,
there is a tendency to assume that designations of roles and relationships will be encoded as
“add-ons” (i.e., using encoding devices such as the subfields for relator terms and codes and
indicator values in MARC 21). However, if RDA data are encoded in a syntax that is compliant
with both RDF specifications and the DCMI Abstract Model, designations of roles and
relationships will be treated not as “add-ons” but as sub-properties of the properties defined
as elements in chapters 6 and 7. For example, the role designation translator will be treated
as a sub-property (or element sub-type) of the contributor element.
Taxonomy
If RDA data are encoded in an RDF/DCMI-compliant syntax, and designations of roles and
relationships are treated as sub-properties of higher-level properties such as contributor or
equivalent manifestation, the designations of roles and relationships must be designed so as
to conform to the requirements of sub-properties, as defined by the RDF syntax and the DCMI
Abstract Model. In other words, each designation of role or relationship must be defined in
such a way that it can function as an element sub-type of one of the higher-level elements
defined in chapters 6 and 7. In practical terms, it also means that each designation of role or
relationship must be defined as an element sub-type of only one of the higher-level elements
defined in chapters 6 and 7.
That requirement raises an issue insofar as the proposed lists of designations of roles and
relationships assume that certain of the designations can be used with more than one of the
higher-level elements defined in chapters 6 and 7. Such designations have been proposed
both as designations of role (e.g., compiler as a designation that can be used either with
creator or with contributor) and as designations of relationships (e.g., facsimile as a
designation that can be used either with equivalent manifestation or with equivalent item). If
designations are used in that way, the “rules” of the RDF syntax and the DCMI Abstract Model
would require that every instance of the sub-property would also be valid instance of both of
the higher-level properties for which that sub-property has been defined. That would mean
that every instance of compiler would have to qualify both as an instance of creator and an
instance of contributor, and that every instance of facsimile would have to qualify both as an
instance of equivalent manifestation and an instance of equivalent item. However, that is not
what is intended by the proposed designations. The intention is that an instance of compiler
will qualify either as an instance of creator or as an instance of contributor, and that an
instance of facsimile will qualify either as an instance of equivalent manifestation or as an
instance of equivalent item.
In order to satisfy the “rules” of the RDF syntax and the DCMI Abstract Model, it will be
necessary to define separate designations in cases such as those described above where a
particular instance of a role or relationship may qualify as a sub-property of either one or the
other of two higher-level properties. In other words, it will be necessary to define a
designation for compiler as a sub-property of creator and a separate designation for compiler
5JSC/Restricted/ALA rep/1/Editor follow-up
Draft 2007-06-09
2
as a sub-property of contributor, and to define a designation for facsimile as a sub-property of
equivalent manifestation and a separate designation for facsimile as a sub-property of
equivalent item.
Redundancy
The proposed designations of roles and relationships include a number of designations that
operate at the same level as the elements defined in chapters 6 and 7 (e.g., creator,
contributor, accompanies, describes). From an encoding perspective, those designations are
redundant. That is to say that those roles and relationships are already covered by the
elements that are defined in chapters 6 and 7. Regardless of whether the RDA data are
encoded in an RDF/DCMI-compliant syntax, in a MARC 21 syntax, or in some other syntax, it
is assumed that the role or relationship at that level will be identified explicitly as part of the
encoding syntax, and there would be no need for a designation of role that simply repeats
what has already been identified through the identification of the element.
A question has been raised as to whether designations of role need to be defined for the
various roles associated with legal proceedings. If it is determined that such roles should be
differentiated, consideration should be given to defining separate elements for those roles and
others associated with legal and religious works (as listed in the RDA Element Analysis table)
as an alternative to differentiating them through designations of role. From the perspective of
an RDF/DCMI-compliant syntax, that would effectively mean treating those roles as properties
at the top level of the hierarchy rather than treating them as sub-properties.
Levels of hierarchy
The proposed designations of roles and relationships generally reflect either two or three
levels of hierarchy. In some cases, the designation of role or relationship functions as a subproperty (or element sub-type) of the property that is defined as an element in chapter 6 or 7
(e.g., translator as a sub-property of contributor, or revision of as a sub-property of source
work (or expression)). In other cases, the designation of role or relationship functions as a
sub-property of a designation of role or relationship that is defined as a sub-property of an
element defined in chapter 6 or 7, making it a sub-sub-property of that element (e.g., dancer
as a sub-property of performer, which in turn is a sub-property of contributor, or facsimile as
a sub-property of reproduction, which in turn is a sub-property of equivalent manifestation).
In order to support the treatment of RDA designations of roles and relationships as subproperties and sub-sub-properties of elements defined in chapters 6 and 7 when they are
encoded in an RDF/DCMI-compliant syntax, it will be essential to make those hierarchical
relationships explicit in the taxonomy of the designations.
It should also be noted that extending the taxonomy of RDA designations of roles and
relationships to include additional levels of hierarchy would not be problematic, as long as the
structure of the taxonomy observes the RDF/DCMI sub-property “rules”.
Faceting
It has been suggested that a faceted approach might be used to make the list of designations
of roles extensible (for example, by allowing terms such as “dubious”, “erroneous”, “former”,
or “current” to be combined with various terms in the list, as applicable. While that approach
may seem to have some advantages in terms of reducing the number of designations listed, it
has been noted in comments on the proposal that it could be problematic with respect to
providing a controlled vocabulary for RDA designations of roles that is comprehensive in the
sense of enumerating all valid terms.
5JSC/Restricted/ALA rep/1/Editor follow-up
Draft 2007-06-09
3
Using facets of that type would also add another level of complexity when encoding RDA data
in an RDF/DCMI-compliant syntax. Effectively, another node in the RDF graph would be
required in order to link the designation of role with the value for the added facet.
Granularity
It has been suggested that a faceted approach might also be used to allow the combining of a
designation of role with a term for the specific part or aspect of a resource, in order to
construct designations similar to those in the MARC 21 list for “author of introduction”, etc.
But again, that approach could be problematic with respect to providing a controlled
vocabulary that is comprehensive, as well as adding another level of complexity when
encoding RDA data in an RDF/DCMI-compliant syntax. As has been noted in comments on the
proposal, it might be more effective to handle that level of specificity by creating a separate
description for the part and using a higher-level designation of role (e.g., author) in
conjunction with an access point associated with that specific part.
Complex relationships
When encoding RDA data in an RDF/DCMI-compliant syntax, all n-ary relationships (i.e., all
relationships involving more than two entities) are encoded as a linked set of binary
relationships.
Encoding complex relationships will also facilitate the automatic generation of reciprocal
relationships. For example, if the merger of two resources (A and B) to produce a third new
resource (C) is recorded as A merged with B, A merged to form C, and B merged to form C, it
is possible to automatically generate the reciprocals B merged with A, C formed from merger
of A, and C formed from merger of B.
While the encoding of a complex relationship as a set of binary relationships will facilitate
machine processing of the data (e.g., generating reciprocal links), RDA also provides for
recording complex relationships in the form of an unstructured description that can be used to
display the relationship information in a natural language form (e.g., “A merged with B to form
C”). To facilitate both machine processing and the display of relationship information in a
natural language form, a complex relationship can be recorded using both conventions.
MARC 21 relator codes
It has been suggested that the MARC 21 list of relator codes might be used as an alternative
list of values for designating roles. However, as noted above in the section on levels of
hierarchy, it will be essential to make the hierarchical relationships between designations of
roles and relationships explicit in order to support the treatment of those designations as subproperties and sub-sub-properties of elements defined in chapters 6 and 7 when they are
encoded in an RDF/DCMI-compliant syntax. Because the hierarchical relationships between
codes in the MARC 21 list of relator codes are not made explicit, using the MARC 21 list of
values as an alternative to the RDA designations would introduce an added level of complexity
when exporting RDA data in an RDF/DCMI-compliant syntax. In order to do so, roles coded
using values from the MARC 21 list would first have to be mapped back to the corresponding
RDA designations, so that the hierarchical relationships could be reinstated. Given the current
lack of semantic integrity in the MARC 21 list, that mapping could prove to be problematic in a
number of instances.
Definitions
If the intent is to develop a DC-RDA application profile, with vocabulary encoding schemes for
all RDA-defined controlled vocabularies, it will be necessary to define the terms used in those
vocabularies. In that context, definitions will be required for all terms used in the RDA
5JSC/Restricted/ALA rep/1/Editor follow-up
Draft 2007-06-09
4
controlled vocabularies for designations of roles and relationships. Applying the principles
established for the RDA glossary (i.e., defining only terms that are not used in the ordinary
dictionary meaning) to terms used in RDA controlled vocabularies would not be appropriate.