[MEI-L] feature request list (long)

[Roland, Perry (pdr4h)]

> Hello all,
> 
> 2. add "within" in data.PLACE
> 
> I like the new datatypes.

Thanks.

I forgot to mention yesterday that these changes necessitated a change to the place attribute on some elements.  In fact, there is no longer a place attribute on bend, phrase, slur, or tie.  It has been replaced by an attribute called "curvedir" that takes the same values as before, i.e., "above" and "below".  For those of you with existing MEI files, this change of attribute name should be easily fixed with a search-and-replace operation.

> 
> 
> 3. create "non-sung text" element in order to accommodate spoken dialog
> 
> I wonder if it would be possible to create a sort of "placeholder" element for the first release? Even though there will be discussion for its role and behaviour in the future, it could work as an element where to embed TEI markup. I'm suggesting something not unlikely <tei:musicNotation>, which is only a phrase level element, but might be modified to contain MEI markup.
>
> So what about a <mei:spoken> element? (I'm sure someone in the list could propose a more appropriate name for non-sung text) For now, it could be in the text module and could live between measures (i.e. in model.sectionPart or model.measureLike) and just contain <p>. What do people think?

Actually, I'd be more inclined to create a specialized form of the <dir> element.  It would be in the controleventLike class and could occur anywhere other elements in that class, such as dir, dynam, phrase, tempo, hairpin, octave, reh, slur, tie, etc., could occur.  In other words, <spoken> would be attached to a staff and it's time location would be specified just like these other elements, i.e., with @tstamp or @startid.


> 4. allow app in tuplet (beam too)
> 5. allow value "unknown" for @grace
> 
> Great news!
> 
> 8. create history element containing a list of events
> 
> I like the solution presented, but I'm wondering whether this information is better stored in an MEI file or in an ontology? It seems to me that this encoding brings into the textual representation concepts of ontological classes (events, persons, relationships); however, I see how this could be useful to a small-scale project.

Yes, the point here, I think, is to provide something relatively uncomplicated, yet still useful for small-scale projects, not unlike the approach already taken in the <classification> element.  If a project needs a more heavy-duty solution, the better option would be to use some other markup standard, like RDF, etc.  The general principle of providing "good enough" metadata applies here and everywhere in the MEI header.

> 
> Thank you very much for this update!
> 
> 
> Best wishes,
> Raffaele

--
p.

__________________________
Perry Roland
Digital Curation Services
University of Virginia Library
P. O. Box 400155
Charlottesville, VA 22904-4155
434-982-2702 (w)
pdr4h at virginia.edu