Simplification of XOBIS was possible in part due to identification of recurrent patterns crossing the emergent "boundaries" between Principal Elements and/or their parallel relationships.Due to their generality, we call them Generic Elements; they are defined independently, or coordinated for consistency.Generic Elements are ones that are needed as sub-elements of more than one Principal Element, or which serve as unifying container elements, although with varying substructures. Selected Generic Elements are discussed here and later in the context of related Principal Elements.
Description
Notation
XOBIS uses the divide and conquer approach for descriptive aspects of cataloging, fundamentally by not mixing description and entry (e.g. MARC 245). Such information is carried in tandem with the Entry when needed to justify, amplify, or describe in more detail the applicable Principal Element, a parallel relationship grouping, or the specific Relationship to which it refers.Notes could be omitted when redundant and may occur on blind relationships. Description is a container element for notes and other descriptive information. Each instance is a Notation. This example illustrates a transcribed title, with correction, for a Work:
<Work type="intellectual" role="instance">
<Entry class="individual">
<Title>Railroad Employees Pension Plan</Title>
<Qualifiers>
<Time>
<Year>1930</Year>
</Time>
</Qualifiers>
</Entry>
…
<Description>
<Notation class="transcription">
<Value>Railroad employes [sic] pension plan</Value>
</Notation>
</Description>
</Work>
Initially, a single pattern encompasses descriptive information because it is generally for display and use in keyword indexing.Is there justification for all the detailed and variable subfielding found in notes in MARC? The XOBIS Notation element consists of a Value and may have an optional Type to specify a collective/group value for a Concept and a specific value, another Concept. The generic Type element, covered below, provides a mechanism to control groups and values associated with another element, possibly:
<Type set="Physical
Description">Extent</Type>
<Type set="Physical
Description">Dimension</Type>
<Type
set="Notes">Application History</Type>
<Type
set="Notes">Scope</Type>
Notation has a 'class' attribute to cover broad categories shown below and may have a 'language' attribute for use when this differs from the 'language' attribute of Record. For example, an author abstract is transcription, while one written by the cataloger is annotation. All of these classes are defined for each "substantive" Principal Element and Relationship. Two do not apply to "notional" Principal Elements or Relationship: transcription and description.
| 'class' attribute | Working Definition |
| transcription | Designates transcribed information and may contain supplied data in brackets; could be quoted in display |
| annotation | Data supplied by the cataloger for public display |
| documentation | Data supplied by the cataloger typically not for public display |
| description | A transitional value when description cannot be parsed for association with the proper Principal Element or Relationship |
| unspecified | Just in case |
Because of XOBIS' emphasis on relationships between Principal Elements, the context of notes is clearer, and many cases may be superseded by Relationships themselves-- making the information more accessible.For example, the note "Sponsored by the Music Library Association" and an added entry for Music Library Association are more succinctly covered by a Relationship from a Work to an Organization: Sponsor:Music Library Association.Routine redundant description to justify an Entry is questioned; however, rules could be developed for targeted usage.Much more investigation and practical experience in applying XOBIS are needed before determining the need for additional patterns, realigned rules, and/or a better method of handling description.
Each Principal Element includes a container element, Entry, to delineate the composite sub-elements providing it with a relatively unique identity. Examples of entries occur at the beginning of their respective sections.An Entry may be undifferentiated from the Entry of another Record, since it may not always be desirable or possible to disambiguate entries readily. A small number of these duplicate "hits" is reasonable; a threshold in editing software could suggest needed disambiguation.The Qualifiers element below discusses routine preemptive disambiguation. Entry is repeated in Relationships to provide visual reinforcement (should a typographical error in a control number occur), to permit records to stand alone (not requiring related records for processing/display), and to permit blind links (optional creation of the indicated target record).Entry may be thought of as a concise disambiguated identity for each Principal Element.
While entries may vary in their substructural composition and attributes, they consist generally of two parts:
Simply stated, works are titled and other Principal Elements are named. The distinction between identification and disambiguation also supports sorting and differential display. Additionally, Type and Duration elements optionally allow entries to carry equivalence designations (cf. Varia below). Basic examples introduce the section for each Principal Element below.
Entry Names
Name
NameSegment
Title
TitleSegment
A designated Name provides an anchor for the Entry of most Principal Elements, while Title usually serves in this role for Work. Either would often have Qualifiers. Various patterns of substructures provide flexibility, since the complexity exhibited by names and titles is often underestimated. For traditional personal names, Forename, Surname, and Expansion (spelled out version) can be used as needed with a Qualifiers substructure to handle other parts; Name handles personal names that do not fit this structure. Similarly, Time has a special chronological substructure for dates, while named time periods may be entered as a Name.Repeatable NameSegment or TitleSegment elements may serve as alternates for Name or Title. The Title or first TitleSegment may have a 'type' attribute to indicate whether it is generic, e.g. "Transactions". The 'type' of any additional TitleSegment may be subtitle (for short subtitles which should be part of the entry), section (for section titles), or other (just in case).Section numbers are handled as a String in Qualifiers. NameSegment does not have a 'type' attribute at this time.The 'nonfiling' attribute applies to names and titles and their segments (initial or subsequent), adding more flexibility.See Figure 4 for how these elements interrelate, and the Attributes section and the sections on individual Principal Elements for details.
Figure 4. Names & Titles: Identification and Qualification
Entry Substitutes
Entry Substitute elements represent a kind of internal authority control¯shorthand versions of entries for Principal Elements, which may be used or referenced in place of the full Entry when conventionally or stylistically desirable, or per cataloging rules. The 'substitute' attribute on a Principal Element used in the context of Qualifiers or a Type value in a Relationship may have any one of these four element names as its value. The value of the chosen substitute, treated as just a text string, must then be used as a Name or Title instead of the Entry's full substructure. An 'id' attribute must accompany the Entry Substitute. Validation would rely on editing software.Individual entry substitutes are not repeatable, as editing software could be confused if more than one Code existed for the same Entry.If additional values are needed, using Varia or Relationships to indicate that a value is associated with an authoritative code list or catalog, i.e. another Work, supports these.
Qualifier and form/genre terms are frequently singular, while topics are generally plural. Rather than establishing separate authorities for the same Concept, substitution permits a single authority to serve various purposes. The resulting juxtaposition reveals interesting variations in practice, which may or may not be deliberate. This technique could potentially permit integration of values from separate code lists with their appropriate Principal Element authority. Such integration should aid improving and maintaining filing consistency.
A Code could be used on Concept as a data entry form to reduce keying. Code is also used in support of the 'scheme' attribute to indicate which Work controls the particular term. While languages could be represented by their Code value, we recommend using the spelled out form consistent with XML's favoring verboseness.Citation indicates a preferred form for citing a Work, useful in display. The following examples illustrate some possibilities for substitute entries. The technique will benefit from testing. Without greater knowledge of the works, it is difficult to know whether Work with 'role' attribute of authority or authority/instance would serve better in particular cases.
| Concept | ||
| Entry | Programming Languages (Electronic Computers) | [LCSH] |
| Singular | Computer Program Language | [LC qualifier] |
| Entry | Programming Languages | [MeSH] |
| Singular | Programming Language | |
| Language | ||
| Entry | Spanish | |
| Code | spa | |
| Organization | ||
| Entry | Lane Medical Library | |
| Code | CSt-L | |
| Place | ||
| Entry | Oklahoma | |
| Abbrev | Okla. | |
| Code | OK | |
| Work | ||
| Entry | Catalogue des Nébuleuses et Amas d'É´oiles … | [instance?] |
| Code | Messier | |
| Entry | Chronologisch-thematisches Verzeichnis sälicher … | [authority?] |
| Abbrev | K. | |
| Code | Köchel | |
| Entry | Medical Subject Headings | [authority?] |
| Code | MeSH | |
| Entry | Short Title Catalogue of Books Printed ... 1641-1700 … | [instance?] |
| Code | Wing |
Singular implies a categorical relationship (as one member of a collective Concept). This is reflected in its providing the preferred value for Type, cf. below, which should use Singular unless the value of Entry itself is suitable. Note that the 'substitute' attribute of Qualifiers must specify Singular if needed because they may be singular or plural.
A potential Entry Substitute, Relational, is under study.Often a collective Concept is similar or identical to a Relationship, particularly its Singular form, e.g. Translations/Translation and Translators/Translator.Contrast the abstract Translating as a third concept.Relationship currently may have a separate conceptual authority record for this purpose.There were too many unknowns to attempt to fold such relationships into the same Concept record at this early stage.In this example, note the similarities between the singular categories and the relational values of the same concept. The Relationships section elaborates.
| Work A | Relationship |
| Category: Translation (Singular of Concept) | |
| (Relational) | Translation [of?]: Work B [reciprocal: Translated as?] |
| (Relational) | Translator [Translated by?]: Being (Category: Translator) |
Qualifier (each Principal Element may serve in this capacity)
Identifier
<Work type="artistic" role="authority">
<Entry class="individual">
<Title>Mercury</Title>
</Entry>
<Qualifiers>
<Concept id="4567" substitute="Singular">
<Name>Choreographic Work</Name>
</Concept>
<Being id="7890" substitute="Code">
<Name>Ashton</Name>
</Being>
<Time>
<Year>1931</Year>
</Time>
</Qualifiers>
</Work>
Qualification is used extensively in bibliographic and authority records for contextual clarity and for conflict resolution of index entries using disambiguation. In MARC, such qualifiers are sometimes encoded and sometimes not (being considered "integral" parts of a heading). In XOBIS, Qualifiers offers an integrated, generalized solution with ample flexibility. This is key with our emphasis on title entry for Work, and extends to name entries for other Principal Elements. The technique, although verbose, provides the potential for tight integration, with homogeneous indexing of entries that lack matching authorities and simplified propagation of updates to qualifiers when entries are changed.
Although optional, routine inclusion of edition and/or date in qualifying an Entry amounts to preemptive disambiguation and simplifies display of names and titles. The same applies to distinguishing instances from authorities, cf. the 'role' attribute below, whereby a given qualifier can make the Entry for a particular instance unique from that of its otherwise identical authority.When an instance is subordinate to a qualified authority, the instance can be qualified separately; this maintains consistency by keeping the shared part of the Entry discrete from the part that varies by instance. This results in a double qualifier.
Another similar situation exists for some qualified Object entries. An additional special qualifier, Identifier, was defined for testing disambiguation using an Organization and String in such cases.Its use with Being is pending.For more information on these complexities, see the Object section below and the discussion of specimens in the Being section.Being also has a unique qualifier, Expansion, for spelled out initials (MARC's x00 ^q).Its use is limited to personal name structures.Entry above illustrates the structural placement of Qualifiers.
For any given Principal Element, a Qualifiers element serves as the container for one or more specific qualifiers used to amend the basic name or title. Each one of the Principal Elements may serve in the role of qualifier, although some rarely, e.g. Work. Duration is permitted as a container for repeated Time elements.Other than this, only Being, Organization, and String have been designated as repeatable in the same Qualifiers container at this time. The order of these may vary as needed, although it could be enforced once fully defined.Inclusion of the related Principal Element's ID as an 'id' attribute is desirable, but optional to permit ad hoc values. The substructure of each qualifier is identical to the related Entry's substructure, unless a substitute entry is used. In this case, the value of Name or Title should match the value of its parallel Principal Element's substitute entry, e.g. Abbrev, Code, or Singular, which serves to record the decision. An 'id' must be present to use a 'substitute'.To indicate the substitute entry used, the Principal Element used as a qualifier has a 'substitute' attribute matching the value chosen. The introductory example reflects that this is easier to grasp than this explanation sounds.When a qualifier itself has Qualifiers, these are retained in an embedded cascade.
Qualifiers itself is repeatable under certain conditions. When NameSegment or TitleSegment is used, each occurrence may be qualified.When an authority that has Qualifiers is used as the basis of the Entry for a derivative Work, it appears that an additional separate Qualifiers element referring to the derivative itself may be needed. The Work section addresses this issue, which might occur with other "substantive" elements.
The generalization of qualification bodes well for consistency. However, it also suggests that current rules for qualification need review.Because of routine title entry, some cases may not be automatically disambiguated via edition and date, especially for common or generic titles. For Work, the use of surname, especially one that is unique or well known in a field (e.g. Shostakovich in music) is viewed as most promising in such situations.Precedence for this is found in uniform titles for choreographic works, which may include surname, surname with initial, or a pair of surnames. XOBIS' Qualifiers provide a rich palette of options with a precise mechanism for providing greater control and flexibility than is presently available.These examples show Principal Elements' role in qualification:
1. Post-Qualification
Place (Concept) Mercury (Planet)
Concept (Concept) Mercury (Substance)
Work (Concept : Being : Time) Mercury (Choreographic Work : Ashton : 1931)
Work (Place, Place : Time-Time)
Medical world (London, England : 1969-1987).
Medical world (London, England : 1913-1968).
Event (String : Time : Place, Place)
International World Wide Web Conference
(10th : 2001 : Hong Kong, China).
(11th : 2002 : Honolulu, Hawaii).
The first triad of entries illustrates disambiguation in case of homography. In the second example, there actually is a short-lived intervening title; note the provision for using a range of dates rather than just the initial date.The third case illustrates the alternative possibility of elimination of repetition in indexing.When the associated authority record exists, Relationships to it are intended to take precedence over display of individual indexing entries. Further treatment of this topic appears in the Place section.
Traditionally, subordinate entry has been used for names implying subordination (Dept., Committee) and generic terms (Research Institute, Friends of). In XOBIS this has been recognized as pre-qualification to disambiguate the specific names:
2. Pre-Qualification
Place. Organization.
Alaska. Dept. of Education.
Michigan. Dept. of Education.
Organization. Organization.
University of Ibadan. Dept. of Education.
University of Oxford. Dept. of Education.
Treating these as pre-qualification provides a more comprehensive generic solution. Structurally, the only difference from post-qualification is order (i.e. before). Consult Figure 4 under Entry Names above, and the Place (particularly the Bartlesville example) and Organization sections below for details.We are continuing to study this area, as the possibility of using post-qualification solely is intriguing.Consider the following example:
Telephone directories consistently transpose subordinate entries, e.g. "Education Dept.", when displayed under a parent entry. Such subordinate entries then subfile under their initial substantive component.It also offers the potential of collocating such organizations as shown (or perhaps hierarchically) to provide an added dimension to an organization index. Qualifiers could display when the Entry stands alone and be dropped as redundant in subordinate display. There is precedence in AACR2 for transposing parts of a name to the end in rule 24.5C2 and for conventionalized subheadings for political parties in rule 24.16. Cross-references help, but current entry subordination rules are not always easy to follow or advocate:
XOBIS handles both pre- and post-qualification. In the second example below, it is interesting to note the embedded relationship (Lieutenant Governor of:) with a temporal duration. The structural approach used in XOBIS had made analysis of such intricacies easier.
XOBIS handles both pre- and post-qualification.In the second example below, it is interesting to note the embedded relationship (Lieutenant Governor of:) with a temporal duration. The structural approach used in XOBIS had made analysis of such intricacies easier.
3. Pre- and Post-Qualification Simultaneously
Using a group of elements to disambiguate the same elements is a challenging, yet worthwhile goal. XOBIS' use of atomism and recursion provides structural support for automated maintenance of qualifiers when related entries change.After attempting to define the substructure of each Principal Element's qualifier differently, we decided that a single, integrated Qualifiers element offered the most promise. While approximating the title qualification of current practice, it attempts the desirable harmonization of technique across the differing elements.More analysis is needed to determine the degree to which qualifiers can be honed to increase consistency and reduce complexity, and still accommodate needed distinctions and sequence of occurrence.Unification of the daunting array of related rules of current cataloging conventions holds potential for their needed simplification.
This pattern of qualification emerged slowly, in part due to the interplay with Relationships, where a separate Modifier acts in a similar, but less controlled way. For example, sequential position is commonly used for disambiguation, and such enumeration occurs throughout MARC, e.g. x00 ^b, x11 ^n, 245 ^n, 250 ^a, 4xx ^v, and 8xx ^v. While trying to distill enumeration as a separate element, we realized that some of these examples are Qualifiers, where the already defined String would function effectively, and the remaining ones are Relationships, where a Modifier "qualifies" the relationship. We elected not to distinguish instances of numeric values to support sorting in the belief that software should provide this without manual designation other than provision of the 'nonfiling' attribute in both cases. Double qualification (use of a qualified entry in Qualifiers) does not pose a problem.
Rather than establish multiple elements in the schema with predetermined attribute choices, XOBIS uses the Type element in many cases to provide a flexible mechanism to identify both the allowable categories and their allowable values. Type permits using a single value from category of mutually exclusive ones.This is in contrast to the 'type' attribute, cf. under Attributes below, for cases where limited, fixed choice categorizations are handled.
Type is structured to provide a built-in validation mechanism to permit software enforcement of values occurring in the database.The category, a named Concept, is added via a Relationship to each Concept record to make it allowable.Currently, the value of Type should match the Singular Entry Substitute of the related Concept, or else default to the Entry itself. At present, freetext values provide additional flexibility.Consult the Concept section for the differentiation of categories.
This recursive technique provides flexibility whenever controlled choice values are desirable, without prescribing the values as part of the schema. The schema is thus insulated from changes due to new and evolving terminology, the database serving to self-document allowable choices by category and their definitions.
The technique is used widely.The 'set' attribute of Type identifies a conceptual category.These two examples typify the structure and show how this works in regard to Varia, discussed below.
In ControlData it handles assigning proposed categories of Action Types and Record Types of a Record. Although out of context, these examples further illustrate the generic nature of Type:
Requirement, retention, or replacement of specific Record Types or Action Types in ControlData is left to editing software.Time and Notation elements are available to complement Type for each Action. To accommodate repeatability, the container elements Actions and Types were defined. These are the only places where Type is repeatable.This was necessary because ControlData is outside the purview of Relationships, which otherwise handles repeatable categorical values.
The example under Description above shows how Type works with Notation to accommodate a wide range of data that may be changed flexibly without changing the schema. See the Time section for how implicit relationships such as birth date are handled using the same technique. We considered using the technique to assign each Principal Element to a single broad category. However, attributes appeared to work better at the general level for mutually exclusive values (cf. 'type' and 'class' attributes). Since a single record may belong to multiple specific categories, Relationships worked better to accommodate unknown numbers of potentially repeatable categories. See the Relationships section and the 'degree' attribute below for how an individual Relationship is categorized, refined, and referenced.In the remaining cases where a single categorization was needed, Type suited the situation best.More examples are dispersed in the text.
Type generally acts as a "field" authority, allowing much flexibility and ease of maintenance for record parts that are not of fundamental structural significance. The various category sets and values could be established as "seed" records with new ones issued much as LC now issues updates to MARC and new values for code lists from time to time¯although it might be more desirable to make the new records available for downloading via FTP (File Transfer Protocol). Possible specific values have only been sketched since unilateral decisions would not be productive. However, we will have to make interim decisions in order to test mapping from MARC to XOBIS.Many values could be conscripted from MARC.An alternative would be to explicitly define separate elements, although this would make maintaining the schema more difficult.
Varia
Variant
<Entry
<Title>Data Structure Investigations</Title>
</Entry>
<Varia>
<Variant>
<Type set="Title Variant">Cover Title</Type>
<Duration>
<Time>
<Type set="Temporal Type">Beginning Date</Type>
<Year>2003</Year>
</Time>
</Duration>
<Title>Investigating Data Structures</Title>
</Variant>
</Varia>
Varia is a container element encompassing a special class of intra-Record relationships, unlike inter-Record ones which are handled as Relationships and discussed later.Each instance constitutes a separate Variant.They cover title variants (MARC 246) and "see" references for authorities (MARC 4xx), as both function identically and are integrated in XOBIS. They represent equivalence relationships to the Entry for the Principal Element within which they occur and create a recursive relationship. Their values would be controlled as Concepts designated via Type for this purpose.
Variant is also a container element.Its substructure incorporates that of Entry identically, including Qualifiers. Optionally, these are preceded by two separate elements expressing the nature of the equivalence:
Type may be freetext to allow unrestricted flexibility at this stage. Although not prominent in MARC, Duration does occur (e.g. 246 ^f). For pragmatic reasons, Varia includes relationships that are quasi-equivalent and subsumptive (deliberately forced equivalency, e.g. MARC 247), reflecting pragmatic library practice. The distinction between when successive or latest entry is appropriate needs to be clearer; both are important for different reasons.Successive seems best suited for periodicals, which are cited as published and maintain that identity in perpetuity.Latest appears more appropriate for serials with revised content, as generally the latest version is the one cited/sought and creating separate records for titles hovering around a single identity creates clutter. Equivalence has been extended to Entry in one case so far (Being), due to complexities relating to multiple identities of persons (e.g. pseudonyms); cf. Entry above and Being below for explanation.See also Entry Substitutes above for how special variants are defined to permit enhanced functionality.
These examples, although out of context, indicate a few of the kinds of equivalence relationships that span the range of Principal Elements and would be governed by Relationship authorities:
| Type | Variant(Name or Title) | |
| Work | Spine Title | Guia, Registros Hospitalarios |
| Being | Nickname | Parliament Joan |
| Organization | Acronym/initialism | ALA |
| Work | Variant | Warburton Anatomy Act of 1832 |
<Entry>
<Title>Academic Psychiatry</Title>
<Qualifiers>
<Time>
<Type set="Temporal Type">Beginning Date</Type>
<Year>1989</Year>
</Time>
</Qualifiers>
</Entry>
<Versions>
<Version>
<ID>7888</ID>
<Qualifiers>
<Concept id="44444"substitute="Code">
<Name >Digital</Name>
</Concept>
<Organization id="3333">
<Name>Highwire Press</Name>
</Organization>
</Qualifiers>
<Relationships>
<Relationship class="geographic" type="associative">
<Name>Fulltext</Name>
<Place>
<Name>http://ap.psychiatryonline.org</Name>
</Place>
</Relationship>
</Relationships>
</Version>
</Versions>
Controversy abounds regarding employment of single or multiple records to represent certain closely related types of bibliographic works, affectionately referred to as "multiple versions". The issue has continued to grow with advances in technology, escalating from various types of reprints and microforms to the nearly intractable situation with innumerable and volatile digital manifestations.The issue is central to FRBR (20).Lane Medical Library attempted to implement the separate records policy, but after a few months found that it created an excessive workload and the proliferation of records made it more difficult to quickly ascertain serial holdings. This colored our decision to define Version, which is, however, optional.
The approach in XOBIS reflects the similarity evident in this milieu:relatively constant content.Would a user, aware of format differences, consider the versions equivalent? In such cases the practicality of separate records is questioned. There is the economic aspect, both in terms of redundancy and wasted effort.In effect, the "same" work must be recataloged, and worse yet, multiple records maintained.Change in content, rather an author's use of version vs. edition, would be a better gauge of the need for separate records.Determining the degree of variation to distinguish a Version from a separate Work is beyond the scope of this paper; previous work may have delineated needed distinctions.XOBIS attempts to provide a practical framework to explore whether this approach might be adequate and effective as many works exhibit a single expression.
As we begin mapping data into XOBIS, we will explore difficulties in implementation of this model. In particular, the intricacies of adding a new Version to the Record for a work previously cataloged independently is of interest. Our current integrated library system allows recording version specific information on holdings. However, since holdings records are not indexed, we must map the data back to the bibliographic record for this purpose. This process is automated. Ideally, only data shared by all versions should remain in the "base" record. We hope to learn more by comparing XOBIS and FRBR in this regard.
Both Versions and Version are container elements. They could apply to any "substantive" Principal Element to allow different versions of these to share a Record.It is interesting to consider possible implications, e.g. treating different identities for a Being as Versions rather than separate records. However, initially they are defined only for Object and Work, where cases are more obvious. This will allow us to test the technique.Examples of each appear in those sections below.
Each Version has an ID and Qualifiers, and may have discrete Description, Varia, and Relationships. The IDs are embedded ones in addition to Record's own ID.All have equal status.The Qualifiers element functions as a qualifier to the Record's Entry, due to its inherently subordinate role here.Qualifiers provide consistency and considerable flexibility in extending the Entry, which may itself be qualified (resulting in double qualification). Each Version would need to be indexed indirectly as part of this extended title. However, a Version's Varia are identical to the Entry's Varia and would be indexed directly.
Commonly, form may constitute the distinction in Versions, but organization, edition (e.g. British and American simultaneous editions of the same work), or other distinctions may also fulfill this role. The Relationships element serves as a container for each Relationship, functioning identically to the regular structure, discussed in the Relationships section below. For example, a periodical might be held in three different versions:
Entry (Qualifier)
Relationship: Organization
Version (Digital: Highwire Press)
Aggregator: Highwire Press
Version (Digital: Ovid)
Aggregator: Ovid Technologies
Version (Microfilm)
Publisher: University Microfilms
A Holdings element uses the regular XOBIS linking mechanism to the ID(s) of one or more Holdings records of an envisioned separate schema.These may link directly to the Work or Object, or to a specific Version. (The Holdings element is also available to Place and Being instances.) It is difficult at this stage to identify all the ramifications of some features of XOBIS. Clearly, more work is needed. We expect that a beta version, benefiting from testing and wider input, will address this area more fully.