LIBR-281 Metadata Project - Collective Bargaining Agreements

Metadata Project: Dublin Core and Collective Bargaining Agreements

Home > Project Documentation > Conclusions-Lessons Learned

Conclusions-Lessons Learned

Did this project achieve its goals?  I think the answer is yes. Yet, it is worth some discussion of the nature of the goals themselves. Probably an unstated goal of any project performed for a class is to get a good grade and to get good feedback from the instructor. Whether that unstated goal was met is still to be determined.

A similar group of goals has to do with demonstrating knowledge and skills that were supposed to have been learned by taking the class. I think it is safe to say that the project was quite successful on this basis. It allowed me to create a product that demonstrated how to apply metadata to an appropriate mission.  It showed Dublin Core in action—organizing information about a collection of documents.  It required me to design specific rules for entering and using the various Dublin Core elements for cataloging the items in this collection.  The site, designed as the “product” required for the project, is capable of creating an interoperable set of Dublin Core records and exporting those in XML format. 

A larger goal was to demonstrate the feasibility of using a system, such as that designed here for meeting specific needs of labor unions or other involved in collective bargaining.  I would say that this goal has been met, in the sense that the product hints at a feasible solution for meeting these needs.  However, it is still very much in the initial stages—and to build a system that could actually meet these real-world needs would require much more time and probably more than the efforts of one individual.

A personal goal that I had was to learn about Omeka. I think I accomplished that one. I knew nothing about the program a month ago when I started. Now I have designed what I think is a nice site, using Omeka. I am not convinced that Omeka is the best of all possible solutions to the specific task I undertook here—organizing collective bargaining language.  I suspect it is better suited to use by museums, historical societies, cultural orgainzations and others who have artifacts or creative works that they wish to display.  I would enjoy a chance to use it for such a purpose myself someday.

I learned some “real-world” about metadata and Dublin Core by taking on this project. Metadata is more art than science, in spite of its formal and precise appearance.  An initial example of this I ran into was deciding what to use as a title element for my documents. Labor agreements do not exactly have titles in the same way that works of art or books do.  They are commonly referred to like this, for example: “Agreement between union x and employer y.”  Many would think of that as the title of the agreement.

Overlapping this issue is the issue of who is the creator?  There is no author. The document is the outcome of a process in which two sides negotiate over what it says. Perhaps it is safe to call both the employer and the union creators—and Dublin Core allows for multiple elements, so that can be done. However, that is also the information that I was considering using for the title.  In the end, I used the information in both places, though in slightly different format, and argued that this might be somewhat redundant, but it would have the advantage of improving findability—because users searching for the employer or union using either element would be successful.

I came to appreciate Dublin Core’s flexibility as I pursued this project. It was adaptable to my somewhat unusual task.  On the other hand, I cannot help but wonder if perhaps a custom solution designed only for my project would not be better in some ways.  A great deal of specificity could be gained with a custom solution. However, what would be gained in specificity would be lost in interoperability.  I suspect that any metadata project will face a tradeoff between being very specific and being broadly applicable or interoperable.

I discovered that Omeka is capable of using extended Dublin Core with the installation of an additional module. However, upon investigation, I decided that it would make the project a lot more complicated, would still not have the advantage of adding much in the way of the specific needs for labor agreements. It would make an already very long project take even longer.

Suppose I was not feeling the necessity of demonstrating my Dublin Core skills for purposes trying to impress the professor. Would that have changed how I approached the project? Maybe. It is possible that Dublin Core was not even necessary. Perhaps the same thing could have been accomplished with the built-in tagging capabilities that Omeka has. In addition, much of the searching could be done on a simple keyword basis. 

On the other hand, if the project were to be scaled-up, with many more contracts included and perhaps additional collections dealing with other types of language (e.g. language on family leave, work quotas, overtime pay, health and safety or the like), the Dublin Core capability might prove to be quite useful.  In a larger scale project, it might enhance search capabilities greatly.

Was Dublin Core the best scheme to apply for this project? I do not know.  To be honest the time pressures of the semester kept me from fully considering other alternatives. I suspect that among the dozens of available metadata schemes available today, there may be one more suited.

Overall, I am quite pleased with the product I have produced, and I feel that I have learned some highly valuable skills in the process.

<<==Previous Project Description

Next References ==>>