0. The Relationships Element and its Substructure
<Work type="intellectual"> <Entry class="individual"> <TitleSegment>XOBIS</TitleSegment> <TitleSegment type="subtitle" nonfiling="The ">XML Organic Bibliographic Information Schema</TitleSegment> <Qualifiers> <Time id="77735> <Year>2002</Year> </Time> </Qualifiers> </Entry> </Work> <Relationships> <Relationship class="compositional" type="associative" degree="primary"> <Name>Subject</Name> <Work id="1234"> <Title>XOBIS</Title> <Qualifiers> <Concept id="5678" substitute="Singular"> <Name>Schema</Name> </Concept> <String> <Name nonfiling="Version ">1.0a</Name> </String> <Time id="56635"> <Year>2002</Year> </Time> </Qualifiers> </Work> </Relationship> </Relationships>
The Relationships element is one of the core structural features of XOBIS.It serves as a container for individual inter-Record relationships. Each of these may be represented by special type of Concept (Relationship Authority), indicated by a Relationship element, or established on an ad hoc basis, on any given Record (the Source). The Relationship identifies the Record for another Principal Element (the Target) and carries information unique to the Relationship. This contrasts with the special type of intra-Record relationship that handles equivalence (Varia). Relationships also occur under the Versions element to permit delineating version-specific relationships to other records.Both of these aspects are discussed in the Generic Elements section. Following an overview of the substructure of Relationships, their broader integrative role and functional implications are treated in sections providing three perspectives: Source-Target, Navigational, and General. The overall arrangement provides consistency and versatility with the intention of unifying a wider variety of linkages, both within and beyond a particular XOBIS implementation, than is found in existing structures.
The substructure of Relationships is shown in the outline below.Each Relationship has a required 'class' attribute with values parallel to each Principal Element:conceptual, lexical, linguistic, organizational, episodic, chronological, geographic, vital, material, or compositional. These would be useful in organizing the display of record content. It also has a currently optional 'type' attribute to indicate the Navigational Type, discussed below, with values: subordinate, superordinate, preordinate, postordinate, associative, dissociative, and unspecified. An optional 'degree' attribute has values to indicate the relative strength of the relationship to a given Target, usually primary or secondary (similar to MARC 650 1st indicator); conceptual relationships have the additional values of broad (e.g. to indicate broad topics for a serials list) and tertiary (for routine links such as NLM's check tags) at present.
Name intends to duplicate the Entry of a related authority Concept, which constitutes a Relationship Authority (also a Concept), discussed below. Modifier permits adding a parenthetic String to the Name to indicate a limitation, restriction, or nuance of the relationship. Commonly, this will be labeled enumeration, e.g. "pt. 3"; the 'nonfiling' attribute applies here. The Duration of the relationship uses the identical structure defined in the Time section. Duration and Modifier deserve wider attention to provide improved accuracy. The implications are broader than are immediately apparent. For example, when the subject emphasis of an organization changes, but its name remains the same, false "hits" on an "old" topic that is still valid can appear peculiar. By indicating, for example, that the Boston University School of Medicine's Relationship to Homeopathy was during the initial part of its history eliminates the anachronism. The same applies to serials which change subject emphasis while retaining the same title.
Next, the Target is identified by incorporation of a Principal Element matching the Relationship's 'class' attribute. The Target's Entry carries its 'scheme', 'language', and 'transliteration' attributes in the Relationship to avoid having to reference the related record for this information useful to display/processing.
Optionally, a Subdivision element may reference a Principal Element that has a'usage' attribute with value subdivision to indicate this is allowable. The kind of Subdivision is inherent in the Principal Element for chronological, geographic, and linguistic, while Concept specifies a 'subtype' attribute with values general, form, topical, or unspecified. Subdivision was defined primarily to accommodate a single topical subheading for simplicity and homogeneity of the Concept element.However, making it repeatable and including chronological, form, topical, and geographic attributes may accommodate the precoordinate approach as a transitional device. (Note that subdivisions of organizations and events are treated differently.)To permit descriptive or explanatory information Description, cf. Generic Elements above, completes the substructure of Relationships.
The introductory example illustrates how this documentation (a Work) has XOBIS (Schema : Version 1.0a : 2002) (also a Work) as its "Subject" (a Relationship). The Name "Subject" should be under authority control to indicate when it is applicable, provide Varia, etc. Similarly, an Organization could be linked simply by this Relationship on the Record for an Event (Source):
Other sponsors at different times could be added as necessary.The Relationships structure in XOBIS accommodates many types of information not currently recorded.Whether or not cataloging rules should be changed to require or option various possibilities is a separate question.The following discussion attempts to illustrate how XOBIS' simple technique serves as a vehicle for integration for all types of information defined.
Definition of the values of the 'class' attribute of a Relationship to parallel each Principal Element serves to organize Relationships as Source-Target pairs (aka Principal Relationship Classes). This arrangement contributes to XOBIS' symmetrical structure and also supports organization and display of these ubiquitous, binary relationships by Target category. These corresponding "hard-wired" choices enforce structural integrity:
|Relationship 'class'||Parallel Principal Element|
The 100 possible Source-Target pairs are shown in Figure 5.
Figure 5. XOBIS Source-Target Relationships
Each of the 100 Principal Relationship Classes used is envisioned to have a Concept authority to manage specific values belonging to that class.Each value would also be established as a Relationship Authority (also a Concept). The class would not be assigned when using the specific values, as the 'class' attribute of the Relationship is required to carry this information. Legitimate examples of most of the possible combinations are known to exist.Some are likely rare. Source-Target pairs provide convenient names:
|Compositional-Compositional Relationship||(Work to Work)|
|Compositional-Geographic Relationship||(Work to Place)|
|Geographic-Compositional Relationship||(Place to Work)|
|Conceptual-Chronological Relationship||(Concept to Time)|
|Lexical-Vital Relationship||(String to Being)|
|Vital-Organizational Relationship||(Being to Organization)|
Counting bi-directional pairs as one (as the second/third examples illustrate), the number of Principal Relationship Classes is reduced to 55. In either case, this provides a rich palette of structurally inherent categories of relationships without becoming too unwieldy. Source-Target Relationship Classes are integral to the structure of XOBIS and are useful for determining context when establishing new specific Relationship values. They also are intended for use by editing software to control allowable values.
A specific, individual Relationship serves as the representation of the link between one Record and another, each reflecting a primary categorization by one of the Principal Elements. The ID of the Target should be included when known to provide a concrete link, with the Entry and its attributes serving as visual backup and convenience for display. Ad hoc values are permissible, but they must be categorized.
Using XLink technology to extend this linkage outside a given implementation of XOBIS is tantalizing to consider.Any linking 'id' could be converted to an 'xlink' during an export process to identify its source. This would allow the recipient to link directly back to the originating XOBIS implementation if desired. There is the potential for individual implementations to have the choice of carrying a particular Record or referring to a national or other external resource's Record. It may not be necessary to carry an authority for every instance that may occur in a given system. Interested parties could create domain-specific national or international resource files to serve in this capacity.We hope to test this idea after converting test data.
Relationships are multi-dimensional.While Source-Target Relationship Classes are most useful for control and presentation, enhanced management of relationships holds even greater potential for online navigation.XOBIS incorporates a set of Navigational Relationship Types to provide for directional (up/down/back/forth) and coordinate relationships. In this regard, it is useful to think of a link's destination as the referential record, and the record a user is viewing as the focal record. Navigational Relationship Types are intended to permit offering users a choice of referential record sets relative to their focal record.For example, if chapter 3 is a Work represented by the focal record, a user should be able to navigate up to the book containing the chapter, back to records cited or back to chapter 2, forward to records citing the chapter or forward to chapter 4, as well as to any other content-based linked works. Likewise, all the other Principal Relationships would be "hotlinked," to contextualize the work. Some of these relationships are covered in current library systems, some in various fulltext digital resources. XOBIS endeavors to unify all relationships into a single, integrated structure.Consult Bean and Green (56) for an excellent compilation of the many types of relationships in the bibliographic milieu.
XOBIS provides for six mutually exclusive Navigational Relationship Types, recorded as 'type' attributes of Relationship: subordinate, superordinate, preordinate, postordinate, associative, and dissociative. An additional value, unspecified, was added for mapping convenience.Many of the values could be determined algorithmically in mapping, but since other may not be, we elected to make this attribute optional for now. The Navigational Types are grouped below in super-categories to make their organization more apparent. The specific examples indicated are illustrative only, and not prescriptive. Note how these also fall into various Source-Target Relationship Classes.They may exhibit all the characteristics of any authority, for example, "Preceded by" as a Variant of "Continues".Complex relationships can be broken into binary form, with subtleties recorded as Description as necessary.
Note that the special Subdivision element discussed above represents a precoordinated subordinate Navigational Relationship.The subdivision attribute value of various Principal Elements indicate its applicability Each Subdivision is just another Concept designated as being eligible to serve in this capacity. This seemed compatible with XOBIS' structure when we analyzed topical subheadings with topical headings in MeSH and was envisioned as only occurring in Relationships, where two 'id' values could link the extended Entry to two Concept authorities.Essentially, it still works this way, but we realized that the technique could be extended to other Principal Elements because LCSH terms would be dispersed in XOBIS. Since Lane Medical Library does not use LCSH, we are ill-equipped to test whether this late addition can handle the great variety of LCSH non-topical subheadings. Subdivision itself may be questioned once we have experience in testing subordinate MeSH topical subheadings as alternative Subdivision Relationships.
The third kind of Relationships in XOBIS is designated General Relationship Types. These may be defined as needed and are not restricted to single Source-Target Relationship Classes or Navigational Relationship Types. They are idea-oriented and represent collective Concept classes, with individual values belonging to a class reflecting instantiation or "isness" in relationship to it. This represents a broader interpretation of form/genre (MARC 655).In examples throughout this text, these have been illustrated with the label "Category:". General Relationships Types might also be called Categorical Relationships.At Lane Medical Library we have found the working definition or litmus test of "is, includes, or represents" helpful in determining applicability.This provides flexibility in applying a specific value by considering the Record a surrogate for the real thing, considering subsumption equivalence (discussed under Varia in the Generic Elements section), etc. A whole book could be written on this (56).
Because General Relationships are content, only a few possibilities in one area are sketched. Various Web sites have recognized the importance more tenuous relationships, especially in historic contexts, and emphasize them via hotlinks, e.g. who influenced another's work. These should be incorporated in the more comprehensive environment of libraries and museums. Below are a few Types that might be established to apply to Being (vital); note that they may overlap. The various Principal Elements to which they point is left to the imagination.
|Relationship Type||Potential Relationship Values|
|Ecclesiastical||Priest, archbishop, postulant, metropolitan, etc.|
|Educational||Faculty, student, teacher, praeses, course director, etc.|
|Genealogical||Cousin, mother, brother, spouse, grandniece, etc.|
|Printer's widows were covered in a recent LC rule interpretation.|
|Legal||Plaintiff, witness, contestee-appellant, etc.|
|Military||Corporal, general, admiral, sergeant, etc.|
|Reciprocal||Sibling, spouse, colleague, etc.|
|Note that cousin is not reciprocal in French (cousin/cousine).|
|Responsibility||Artist, author, composer, illustrator, printer, etc.|
|Recently in the news: Artist: Ramona (Elephant), 1995-|
|Royal||Empress, king, suzeraine, infanta, maharani, etc.|
|Cf. Being and Organization regarding establishing corporate headings for president's, etc.|
Some Relationships are sufficiently inherent that they are not always thought of as such. Uniform Resource Identifiers (MARC 856) present a twist in representing the link between metadata (a Record serving as a surrogate for a Work) and the Place where the fulltext, database, online version, etc. resides. The American Psychiatry Version example, under Generic Elements above, illustrates how XOBIS treats URLs like any other relationship.We chose the Name of the General Relationship to be Fulltext and the Name of the Place to be the URL.This is also a compositional-geographic Source-Target Relationship.An implementation issue might involve whether to display the URL or not; the Name value could serve as the hotlink.
This technique of dealing with URLs raises interesting possibilities. The Relationship may be blind in the sense that an authority record for a URL as Place is unlikely. However, XOBIS' hierarchical structure and the URL's (domain, machine, institution, path, and fragment) imply that authorities for selected upper level components of the URL might be useful in improving management of these, particularly in case of name changes. Individual URLs would be instantiations of a collective Place. Contrast this with the role of XLinks discussed under Source-Targets Relationships above.
Another case took us awhile to realize."Fictional" appears to be a universal General Relationship, reflecting illusory membership in a class (Fictional whatever).This Relationship applies to all Principal Elements as shown in earlier examples. Shades of meaning, such as legendary, mythical, imaginary, projected (especially in futurism), spurious, satirical, etc. (LCSH usage varies), suggest the need for establishing additional relationships.Whether the deception is intentional or not, such as when ideas do not pan out (e.g. Phlogiston, Cold Fusion), may make a difference in delineating such relationships. Even fictitious, versus fictional, reflects a subtle dishonesty.In contrast, "fictitious" business names (dba/doing business as) actually occur in the real world.Specific Principal Elements sections above expand on the general relationships indicated by these examples:
|Organization||San Serriffe Publishing Company|
|Event||World War III|
|Time||1026 FE [Refers to First Empire in Asimov's Foundation series]|
|Being||Jabba, the Hutt|
Fictional relationships are analogous to the categorical and topical relationships discussed under Concept.Minnie Mouse is a member of the category Fictional Characters, whereas she has a fictional relationship to the topic Mice.Both are concepts, but her not being an actual mouse is an important distinction to avoid adulterating the Concept Mice. This is closely akin to the depictional relationship, made famous by Magritte's noting "Ceci n'est pas une Pipe." on a painting of a pipe, and recently added to MARC relator codes (58). Fiction itself, benefiting from the recent emphasis on both topical and categorical access, may also exhibit fictional relationships, e.g. Wilde's Picture of Dorian Gray.
Whether it is necessary to qualify names routinely to indicate their fictive nature is debatable. Relationships alone may suffice in cases where qualification is not necessary for disambiguation or clarification when a name or title does not convey the idea of membership in its given class. At least, such information should assist in policy development.
A few other factors will help round out the treatment of Relationships in XOBIS and indicate potential mapping ideas from MARC.Explicit Relationships in MARC can be mapped directly in many cases. Implicit Relationships have been discussed in the context of being embedded in some entries, cf. Being and Organization. However, many other ones have the potential of being derived algorithmically from MARC. Some examples of this are: next/previous in sequence of volumes in a series, the subordinate relationship of instances of uniform titles series relating to their parent authorities, component part siblings, etc.
While making many Relationships explicit in XOBIS improves navigation and accessibility, it is not practicable or desirable to do this in all cases. We envision a third group of "one to many" Virtual Relationships, which would be displayed, but calculated "on the fly" to give the appearance of being explicit. Examples of this are links to subordinate levels of topics with many exemplars, contents of a periodical, components of a book, etc. This extends to bibliographies at the end of works, although these are considered part of the work; one of the successes of the Web has been linking these.Further analysis of which Relationships should be Explicit or Virtual is needed.
Integration of Relationships into a Web-oriented "bibliographic" apparatus revealed certain repeating themes or principles during our protracted exercise of schema development.Although the ideas are simple, teasing out all the details was tedious. The most interesting themes involved instantiation, recursion, and integration of Authorities, particularly our projected Relationship Authorities.
Instantiation, or distinguishing a specific instance from a category, became the primary method of delineating Principal Elements in XOBIS.In the discussion under Concept, we began with everything as abstract, recognized categories of the abstract as collective, and from these separated the "atomic" instance, refined by notion versus substance.Each of these decisions prescribed a now structurally implicit, hierarchically subordinate, "isness" relationship.The result produced cascades of Concepts, a specific Concept, or a class of specifics¯ the other Principal Elements. Despite the complexities of the real world, this seemed to provide a reasonable framework.One example for each Principal Element recaps the overall effect:
|Hospitals||Bethlem Royal Hospital||Organization|
|War||World War II||Event|
At the outset, we recognized Relationships as "special" and treated them accordingly. However, as the schema unfolded, this partitioning created somewhat of a dilemma.Their use was extended to Versions, cf. Generic Elements section above, to provide more flexibility.Many relationships, depending on how they are named, are identical or very similar to the Concept from which they are obviously derived. Consider this example of a Navigational Relationship Type with a potential specific Relationship for each Principal Element. Note that many relationships can cross the "boundaries" between Principal Elements, permitting a very flexible framework for describing and controlling them (e.g. both an Organization and a Work may be "Continued by" another, if so defined).
As a working solution to resolve the tension, the Relationship element was integrated as a special kind of Concept, e.g. the collective Associate Relationships (Concept) has specific instances, e.g. Synonym (Concept). Three other concepts signify this the special role of Relationships as categorical relationships to three suggested authorities:Relationship Classes (for source-target), Relationship Types (for navigational), and Relationship Authority (for specifics). Currently, this is the only distinction from other concepts. There are implementation issues, such as whether to include such records in Concept retrievals or to segregate them.Distinctions from "regular" concepts with the same or similar names might be necessary, e.g. "Synonyms" vs. "Synonym" perhaps displayed with a colon.See also the discussion of Singular under Entry Substitutes.Display issues may be likened to incorporating some "display constants" suggested in MARC or typical OPAC display labels (e.g. Subject:) as part of a Relationship Authority.Adding punctuation, deduping repeated label values, etc. are in the purview of XSL. In a later version of XOBIS, we plan to explore the issue of Relationships sharing the same Concept authority as its parallel topic.
The implicit degree of control and flexibility in dealing with Relationships in this manner is fascinating, although the implications have not been fully digested. In a presentation to the 2000 MARBI/CC:DA joint meeting, Miller asked the rhetorical question: "Have relationship authorities been considered?" (1). Efforts to get a handle on Relationships are gaining momentum.An excellent example is the delineations made in dealing with graphical material's depiction versus subject (57).MARC's growing relator codes list is a natural fit (58). These and other explicit relationships in MARC, e.g. subject fielding (6xx), linking entries (67x-68x), authority links (5xx), and some specific fields and indicators provide a rich resource on which to build. It is important to aggregate this key information, which is often obscured in coding, relegated to documentation, and/or left to OPAC display vagaries. Determining the most appropriate specific relationship values and their references is a necessary, yet challenging endeavor that will occupy us for some time.XOBIS illustrates the value of formalizing Relationships as fundamental building blocks of a comprehensive informational apparatus.
Recursion (self-referencing) is almost as prominent in XOBIS as are Relationships. In an effort to balance complexity and simplicity, we erred on the side of simplicity, perhaps due to the siren song of elegance.As Generic Elements surfaced (cf. that section), we realized that key ones mirrored the 10 Principal Elements, e.g. qualifying an Event with a Place. Rather than dealing with them repeatedly in various contexts, we elected to reuse core structures. The dogged elimination of redundancy resulted in a more tightly unified and symmetrical structure than would have been possible otherwise.While greatly simplifying the schema, recursion does introduce its own complexity. It is necessary to consider the context of a core structure due to subtle differences, e.g. applying different attributes in Relationships vs. Qualifiers for a given Entry. With experience these may appear to be common sense, but trying to describe them abstractly requires mental agility.
The delineation of the Principal Elements above illustrates recursion, but Entry provides a more accessible example.A coordinated Entry substructure for each Principal Element is used in all cases where the Entry is referenced, e.g. as the Entry for an authority, as a Variant of the authority, as one of the Qualifiers as part of another Entry, or as the target of a Relationship. This is mirrored in the ID structure, whereby its value is included in the 'id' attribute in each of these capacities. To achieve this degree of synthesis implied that some rules or conventions would need adjustment. The design reflects an emphasis on postcoordination, although there is some provision for precoordination. NLM's recent change in cataloging policy in this direction is encouraging.It is hoped that some adjustment to cataloging rules will be considered more reasonable than building idiosyncratic structures to handle relatively minor departures. An added benefit is that some data not previously coded, e.g. qualifiers in titles, is accommodated seamlessly. Propagation of authority changes should be easier as well.
Another method of allowing variation without prescribing specific structures is manifest in Entry Substitutes, cf. the Generic Elements section. Abbrev, Citation, Code, and Singular elements provide alternative or substitute versions of an Entry, which can be referenced wherever the 'substitute' attribute is defined. These were segregated from Varia expressly in order to be individually addressable and to build some give into the structure.
A last example of recursion is a self-documenting technique of relying on database content rather than building everything into the schema.In this manner software may control values according to criteria defined outside of the schema, while valid values occur as data in the schema. This way it is easy to update choices without changing the schema.See the Type element in the Generic Elements section as the chief exemplar.
XOBIS' crisp uniform entries, tightly woven structuring of relationships, and other recursive features aim to balance rigor with flexibility.Much as XML separates content from display to maximize flexibility and information reuse, XOBIS strives to keep its framework separate from changeable data values, while permitting external software to use these to control what can be entered as data.