Making concrete in writing an object that exists only in the memory of people seems impossible, yet that is the intention of our schema. We hope to capture the experience of a performance by including, not only the managerial contributors, but also the individuals in the ensemble, corps de pas, or technical team. This schema encourages the cataloguer to capture every contributor, constructing a more complete memory of the performance.
Rather than extending an existing metadata schema, such as CDWAlite, we have created a new schema, intended to capture the memory of the performance through every contributor. Schemas used for cataloguing cultural heritage are, such as CDWAlite, are not inclusive of non-material art objects. Furthermore, we believe that it is vital for the schema to be usable for non-cataloguers and those not familiar with the huge umbrella that is the performing arts. Our hope is that this schema could be filled by any individual after attending a live-performance, so that elements of the performance that might otherwise be lost will be captured. For example, if the recording for a live performance of a ballet does have a credits list, many if not every individual of the corps de pas will be lost from the memory of the performance. Likewise, if a dramatic performance is not recorded, but an announcement is made at the beginning of the performance, noting the change the lead, the full record of that performance will be lost. By capturing the individual performance in a metadata record, the creative contributors of performances will have the opportunity to be captured.
That being stated, this schema also takes into account our efforts to retain our memories in some form. In this case, we make references to objects such as moving image formats that serve that very purpose.
To group like-elements together, we have used wrappers and semantic arrangement of the elements. The elements are distinguished from each other in the data dictionary provided. For elements that wrap other elements, we have included “wrap” in the element name (e.g., contributorWrap).
Our schema’s order is not terribly stringent. We want it to be understandable to the average person, given that our schema will be filled by anyone willing. Filling in the fields out of order shouldn't give the user an error. Changing the order of fields shouldn’t give an error either, although for consistency’s sake the “suggested” order we've written the fields in could be considered a best practice.