Initial Reflection on Element Set Creation
This exercise has allowed me to follow through, in much greater detail, with a project that I have been working on for several years now. I had hoped that this exercise would be easy given the spreadsheets and guides that I already had created on this subject, but that false comfort pushed me to take an ambitious approach to the project, and I got carried away. However, in the long run I think it is worth it: not only have I learned a great deal in this process, but I have a draft of a specification that I can share with my team for HistoricDress.org to develop a “Costume Core” specification that has great potential to be shared with the national costume history community.
With this “Costume Core” in mind, I gave my new elements a prefix of “cc.” CDWA Lite was very well matched to my desired elements. However, there were several desired elements of the CDWA guidelines that are not in CDWA Lite. For the most part, I created new elements for these, but in some cases VRA or DC elements were a good match, or it was possible to add refinements to CDWA Lite elements. Some elements listed in my original set were actually attributes, and others were wrappers for bundling dependent elements.
My most significant additions are specific measurements and structural details. I am exploring defining these at a more specific level to enable research through large datasets to target these details, in ways that are not currently possible with more general description fields. Each specific measurement could be defined as a “type” attribute of a measurementSet in the existing CDWA Lite or VRA core specifications, but I wanted to be more clear about the desired measurements, and to set them apart.
It was a comprehensive learning experience to pore over the specifications for DC, CDWA Lite, and VRA core, through the CDWA and CCO guidelines. While the crosswalk provided by the Getty to navigate between them all (http://www.getty.edu/research/publications/electronic_publications/intrometadata/crosswalks.html) was very helpful, I found that I had to make numerous revisions to apply to my specific application.
Final Reflection
When I began to adapt an XML schema for my element set, I regretted my decision to focus on CDWALite as my base schema. Comparing the CDWALite and VRA Core 4.0 schemas, I found that the structure of the VRA schema was much more adaptable and re-useable. That meant that I had to go back and change my element definitions to reflect the use of VRA instead of CDWALite.
I experimented with several different approaches to nesting different elements. I considered describing each component of a garment separately, with structural descriptions and measurements nested within, but it quickly became apparent that that would not be as efficient as nesting all the measurements together, all the structural details together, etc., and using the <extent> attribute to indicate which component was being described. I think much more work and testing needs to be done with this specification, to see how end users can interact with the metadata. Transforming the metadata with XSL will likely require more changes in the schema to make it more usable. It is important that this specification is not intended merely for discovery, but for specific research with larger datasets of costume objects. That is why so many more indexing fields are required.
I also experimented with the order of the elements, both in XML and in ContentDM. Currently, both are in order for the cataloger, not for the end user. A blank cataloging worksheet has been included to show the logical order for recording data while examining an object, to help the cataloger distinguish between information that is in the object itself (intrinsic) versus external information, such as information from the donor or from research (extrinsic). To make it easier to input data from this worksheet, the XML schema has been changed from the order of VRA Core 4.0. It may make more sense to change this back to alphabetical moving forward; user practice will indicate which is more efficient. Better systems for data entry will need to be created to transform the data from the easiest format for the cataloger to a more appropriate format for the end user, perhaps with a different format for data entry in between the two, depending on the workflows that are developed.
For this project I chose to work both with XML instances and with a ContentDM collection, to compare how the schema could be applied to both a hierarchical, nested structure in XML and to the flat database structure of ContentDM. The XML structure allows for the inclusion of much more detail, but many institutions collecting historic costume are already tied to flat database systems like ContentDM. One avenue to pursue moving forward will be to create web-based forms to augment the metadata already included in local contributor’s systems, perhaps creating an XML output.
I hope that through my involvement with HistoricDress.org, I will be able to test this specification more widely, and aim for wider community adoption among historic costume collections around the country. There is also still much to be learned from other institutions working with historic costume. The most detailed costume metadata available online is currently coming from the Australian Dress Register, and I look forward to contacting members of the team from that project and finding out more about their workflow and specifications for metadata.