The session began with a question raised: is allowing arbitrary descriptive and administrative metadata formats inside METS documents a good idea? The obvious advantage is that it makes METS very versatile. But this could also limit its scope – does that make METS only for digitized versions of physical things, excluding born digital material? The group as a whole didn't believe this was an inherent limitation. The ability to add authorized extension schema over time seems to be a good thing, and necessary for the external schema allowance to work.
The flexibility of METS allows it to be used beyond its textual origins – to scores, sound recordings, images, etc. It could potentially be useful beyond libraries, especially to archives and museums. To balance this flexibility, is knowing some sort of structured metadata is being presented enough to ensure a reasonable level of interoperability?
The discussion then turned to the TYPE attribute on <div>, a topic much discussed in the METS community. How does a METS implementer know what values to use? An organization will presumably develop its own practice but the practices won’t be the same across institutions. A clever name for this was suggested: “plantation” metadata – each place can develop their own.
Are there lessons from library cataloging that could help with this problem? Institutions dealing with the same types of material could join together and harmonize practices. METS Profiles provide the means for documenting this, but they don’t really encourage collaboration. Perhaps the expectation is that the metadata marketplace will converge, and those going their own way will lose out some significant benefits, and see it in their best interest to collaborate.
This line of thought led to the question - How did OCLC/LC/the library community get standardized in the first place? Probably because individuals would write up their own rules, then share them. Eventually these rules became shared practice. Maybe this same shift will happen when sharing really becomes a priority. Diverse practices will converge when people really want them to.
A question was then raised about when METS should be used instead of MARC. When is MARC not enough? A participant made the analogy that this was like comparing a plantation to a video arcade. The two are for different purposes, and METS can include descriptive metadata in any format, including MARC. If you want to allow a certain type of searching, for example, a user wants to search for a recording by a certain group, saying METS is better than MARC doesn't make sense. The descriptive metadata schema used within METS is what is going to make the difference in this case, not the use of METS itself. An implementer will still need good descriptive information.
Participants then noted that we had been talking about systems, but we need to talk more about people. Conversations between communities with different practices will help improve interoperability. Can we standardize access points? To do this we would need to develop vocabularies collaboratively between communities, and talk more so that we understand each other’s point of view.
One participant made an extremely astute observation that the structure of METS makes it seem that it wasn't designed to be used directly by people. While metadata specialists often need to look at METS, and plan for what METS produced by an institution should look like, the commenter is correct that for the most part, METS is intended for machine consumption. A developer present noted that we could write an application that does a lot of what METS does without actually storing it in XML/METS – but the benefit of METS is abstracting out one more layer. Coming full circle to the flexibility issue from earlier in the discussion, it was noted that it is difficult to make standard METS tools (including parsers and generators) due to the almost infinite practices that must be accommodated. This led to the thought that perhaps METS could go much farther in being machine-friendly than it already is. That's a scary thought to metadata specialists who work with it!
No comments:
Post a Comment