Data Fields–A Tentative List
Our initial project will build on an existing database compiled at the CESR for the French chanson of the 16th century. This data set will provide the foundation for our “search” tool. But of course we will want to think about other fields that will be useful when our scope expands. Consider:
- Composer: a regularized list, or as they appear in the original books? And if the former, how will we handle questions of conflicting attributions?
- Text incipit: Regular spellings, as the CESR database currently uses, or to follow original spellings?
- Number of Voices: In the Du Chemin set, all but one of the works is for 4 voices. But clearly we will need a field for this as the project expands.
- Musical source: Title of book where this image can be found
- Publisher: Name of printer
- Date:
- Standard reference: RISM or other standard reference to the source?
- Location: which copy of the source?
- Fields identifying the exact reference of the image
- Superius This will be the number of our image
- Altus This will be the number of our image
- Tenor This will be the number of our image
- Bassus This will be the number of our image
- Quintus, etc.
- Folios: We might need this for manuscript sources
- Clefs: All four, or just superius?
- Final: Lowest note of bassus. Or some other indication of ‘mode’?
- System: hard/soft
- Language:
- Poet: (when known)
- Literary Source : (when known)
- Verse form:
- Meter:
- Image type:
- Resolution :
- Modern edition of composition:
- Commentary in this Resource: This will be a link.
- Transcription in this Resource Sib and scorch.htm file
- Settings of same text by other composers:
- Composition on same page: [In the case of books where adjacent pieces might bear relationship to each other]
February 5th, 2009 at 5:26 pm
In my motet database, I have retained the names of composers and textual incipits in both the original form (as they occur in sources) and in standardized form. You have to standardize if you want to search with any degree of effectiveness, but you don’t want to lose the original information of spelling, attribution, word order, etc.
In the expanded version of my database (not yet online), I am including both RISM and Census Catalog style sigla. I have also included a separate field for the name of the source.
February 16th, 2009 at 8:38 am
I agree with Jennifer; the transliteration and the normalized versions of composer ID and of text incipit would both be helpful.
Another thought; in the La Trobe medieval music database, the full text is included in searchable form. I had no idea how helpful that would be until I started using it. It’s a text-only aspect, which makes it not too difficult to code, and it pops up an extremely helpful array of clues as to what might be related to what.
So I recommend a “full text” box somewhere with search capabilities, separate from the text incipit column.
February 16th, 2009 at 9:25 am
What about a field for concordances and/or musical models/musical progeny (aka “related compositions”)? That’s slightly off topic at this stage, but I can see that being useful at a later stage. I’m thinking here of the old Howard Mayer Brown approach for the late 15th century repertoire.
It may be that the primary objective is to work through the book itself (as in: what does THIS material object tell us about this piece in the repertoire). I think we get in a rut of focusing on the print as SOURCE and not as OBJECT, but we have a long history of taking that source-based approach. So I’m of two minds: in one version, the indexing (”data fields”) is akin to one of those Musica Disciplina source articles, with all of the columns of data that requires; in the other version, I’m advocating for a “clean” version which sticks to the basics.
February 20th, 2009 at 5:18 pm
I agree with Cynthia that full texts are very important. I am in the process of adding that data to my cataog, and I receive many queries from users asking for that information (easier wished for than done!). Here again, you have the problem of a standardized version vs. the version in the source, and again, ideally, you would like to have both. A quick solution, though, might be to use as the standardized text the version that appears in the most scholarly modern edition (recognizing that these could also be problematic, or not as “standard” as you would like).
March 6th, 2009 at 10:04 am
Some random thoughts: are there cases where the author of the text is known and/or different from the composer? I would suggest having the flexibility of including additional names associated with the work other than just the composer. Perhaps a name is referenced in the text even. Do you want to have traditional subject fields, either for musical form (which might be different from verse form?) or for topics, such as what is being described by the text, or for a known historical event that might have been associated with the work. You may want to consider technical metadata beyond the image type and resolution. What equipment was used for image capture, who was the technician who did the work, etc. Finally, I would suggest that you consider how your various fields might map to standard metadata schemes, most notably Dublin Core or Qualified Dublin Core. This will ultimately allow your data to be combined with other data and will set the stage for possible harvesting by the Open Archives Initiative–Protocol for Metadata Harvesting (OAI-PMH).
March 14th, 2009 at 2:52 pm
A field for recorded versions would be useful!