Replies: 3 comments 1 reply
-
Not to be a rainy cloud, but I would caution against large-scale restructuring efforts. I am only one voice here, so please weigh my comments accordingly. But I think it's important to understand why these are the way they are before we commit to doing a full-scale re-work [1]. So if you'll permit me to comment on this proposal... TEI, and by extension those parts of MEI that are based on TEI, is not a 'traditional' metadata scheme as you might expect if you're thinking about metadata from the MARC / Dublin Core tradition, or even the 3x5 catalogue card and ISBD tradition. In these metadata schemes, you have a field and a value with fairly precise, and concise, contents. So if you're thinking about metadata with a view towards making it align with these formats, you might expect an element like However, if you read the TEI guidelines and observe how TEI is used "in the real world" you will see that the contents of elements like <foliation>
A pencil foliation (s. xx) assigns the flyleaf the number ii with the frontispiece
attached to it (see below) as fol. i; for the main body, two pen foliation in upper right
corners, the chronologically earlier being that provided by Sir Walter Cope, and the
second added by the time of binding for Robert Cotton (on both these collectors,
see <hi rend="smallcaps">provenance</hi>). The earlier foliation runs fols 9–362,
but with the last leaves, from fol. 355, having been originally 1–8; fol. 289–93 precede
the folios Cope numbered 286–88, which the Cottonian foliation renumbers as 294–96,
with the original 294–96 also renumbered 297–99; there are also errors, with fol. 197
repeated, 203 omitted and an unnumbered leaf after fol. 218.
</foliation> In these cases, you can begin to see how elements such as To give an example of what I mean more broadly, here are two pages from the 19th/20th century Summary Catalogue of Manuscripts in the Bodleian describing MSS. Hatton 113-14. I give this as a sort of "origin story" for where this tradition comes from: https://medieval.bodleian.ox.ac.uk/images/ms/aaq/aaq0326.gif This entry is designed as a brief scholarly description, in prose, of the manuscript in question. What it is not, though, is a simple "bibliographic" record, as we might expect from a later library catalogue. [2] Looking at the newer electronic record of the same: https://medieval.bodleian.ox.ac.uk/catalog/manuscript_6027 and the corresponding TEI file: https://github.com/bodleian/medieval-mss/blob/master/collections/Hatton/MSS_Hatton_113-14.xml We can see that this still follows the tradition of the 19th century catalogues, despite being translated into a digital context. Again, these are highly descriptive, but fundamentally prose-formatted, catalogues. Accordingly, these records are meant to be processed more like a highly-descriptive HTML markup, rather than as atomic metadata values. Perhaps the next question, however, is that if we're MEI, why are we following the TEI at all? We have a collective decision as a community that MEI is not TEI, and so we can diverge from that specification where we need to. To be clear: I agree with the fundamentals of this sentiment. Music has needs that are different than text, and we need to have freedom to diverge when we see fit. But I think this is tempered by three factors:
I say all of this in the hopes that I am not discouraging the work of the IG, nor trivializing their discussions, but also in the spirit of providing some context to "why things are the way they are" and potentially filling some gaps in the community knowledge base. Nor am I saying that things are perfect -- I think there are likely areas that can be improved. So I have three basic concerns with this proposal:
To close, I want to say "Thank you" for posting this note and making it a discussion well in advance of the change. This is a very useful and open way of making sure a wide range of voices are heard, and so that we can arrive at a solution that benefits everyone. [1] Some may wonder why I have opinions about this stuff. My experience in the metadata section of the TEI is based on how it is being used in institutions in the UK to create large manuscript catalogues. I was the system architect for the Fihrist Union Catalogue of Islamic Manuscripts (https://www.fihrist.org.uk), the Medieval Manuscripts at Oxford (https://medieval.bodleian.ox.ac.uk) and six other catalogues at Oxford. I also worked closely with colleagues who were framing and publishing the Encoding Guidelines for Manuscript Description (https://msdesc.github.io/consolidated-tei-schema/msdesc.html) and consulted on data processing and discoverability of the TEI records. I say this not to boast, but to provide some background in my experience with this particular section of the TEI. [2] As a side note, it is interesting to consider these traditions in terms of the ability to access the materials and their intended use. A catalogue card is, fundamentally, about finding mass-produced books on a shelf; I believe MARC, Dublin Core, METS, etc. are extensions of this use-case. A descriptive catalogue is more aligned towards scholarship where access to the material is restricted, either because it is in a distant place, or because it is rare or fragile that only certain people can access it. In these cases, having prose descriptions that are widely distributed are much more useful since they serve as a surrogate to the material, and a summary of the history and scholarship of the item to date in a way that does not translate easily to breaking it down into atomic fields and values. To take the |
Beta Was this translation helpful? Give feedback.
-
An other thing that I can imagine is to bring up an official mei customization for encoding structured metadata maintained by the @music-encoding/ig-metadata |
Beta Was this translation helpful? Give feedback.
-
This is a very important discussion, important way beyond the issue at hand. I don't want to go into details here, but would like to emphasize some of the arguments in here. First, and most importantly: work on standards is mostly a communication thing. Having a good technical solution for a problem at hand is certainly important, but explaining it to others involved is at least as important. The bigger the proposal – be it something new or a revision of existing parts – the bigger the need for communication – within any given IG, but also beyond. |
Beta Was this translation helpful? Give feedback.
-
The unsatisfying fact that the content of multiple header elements ha too many elements must be solved some time. In the IG-meeting on April 14th we agreed to work on this topic after the MEC 2022.
The goal is to define models that contain a senseful group of elements that can be proposed as element content for several metadata elements. (e.g., it is unsatisfying that
<foliation>
may contain<watermark>
)The ODD-Team should be included right from the beginning!
Beta Was this translation helpful? Give feedback.
All reactions