[MEI-L] halfmRpt and @rend

Mon Aug 12 20:44:43 CEST 2013

I'm sorry, I accidentally hit Ctrl+Return, which made the Google
webmail interface send my last mail before I was finished.

Anyway, I wrote most of what I wanted to write.  I guess I should
write on ODD modification and provide that on mei-incubator to discuss
this further.

2013/8/12 TW <zupftom at googlemail.com>:
> This is interesting, we were about to bring up a similar problem with
> the Corpus monodicum encoding.  In my understanding, @altsym was meant
> to provide rendering information, not to describe the appearance of a
> source.  But, as I understand it, the suggested use of @altsym for the
> Freischütz would first and foremost encode the symbol found in the
> source.
>
> That's very similar to some requirements we have for Corpus monodicum,
> where editors want to encode certain symbols that scribes are using in
> the source (specifically: different variants of symbols with the same
> melodic meaning).
>
> Currently, we do this with annotations.  However, we would like to
> also encode a table of all those variants that are used.  In the
> printed edition, tables like this will be included and it would be
> sensible to also encode them in MEI.  <symbolTable> would come close
> to our requirements.  However, rather than artificially recreating
> them with the vector elements available inside <symbol>, we'd want to
> provide a scanned instance of each symbol.
>
> We have two suggestions to make:
>
> 1) Introduce another attribute that would serve as a complement to
> @altsym, but is intended for specifying that a certain symbol was used
> in the source.  This pair would work exactly like the @style/@rend
> pair, one being for describing what's found, one indicating how it
> should be rendered.
>
> 2) Officially make <symbolTable> multi-purpose (or introduce a similar
> structure, which however I don't favour).  We'd need to provide a
> facsimile snippet with something like <graphic>.  Either this should
> be allowed inside <symbolDef>, or we should be able to use the @facs
> mechanism, although this wouldn't be preferable in our case as we
> don't provide facsimiles
>
>
>
> 2013/8/12 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> Hmmm, forgot about that!
>>
>>
>>
>> If we proceed with plans to make @rend and @style available on more elements
>> but with generic typographic meaning, existing @rend attributes will have to
>> be replaced by some other attribute that carries element-specific
>> renditional information, possibly @form.  For now, @altsym is the only other
>> option.  Remember, however, that the value of @altsym must be a URI that
>> points to a symbolDef element.
>>
>>
>>
>> Considering the potential of SMuFL, I've been thinking a character-oriented
>> method for indicating an exact or alternate rendition might be another way
>> to go.  We could, like TEI, provide for defining a character in the header
>> which is then pointed to using an attribute, similar to the way <symbolDef>
>> and @altsym work), or we could allow text content of elements to contain
>> Unicode character references to codepoints defined by SMuFL. Another
>> possibility is to re-work <symbolDef> so that it can hold the Unicode
>> reference (making it similar to TEI's <charDecl>) which is pointed to using
>> @altsym as before.  This is going to take a while to discuss and implement,
>> though.
>>
>>
>>
>> --
>>
>> p.
>>
>>
>>
>>
>> __________________________
>> Perry Roland
>> Music Library
>>
>> University of Virginia
>> P. O. Box 400175
>> Charlottesville, VA 22904
>> 434-982-2702 (w)
>> pdr4h (at) virginia (dot) edu
>> ________________________________
>> From: mei-l-bounces at lists.uni-paderborn.de
>> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Benjamin Wolff Bohl
>> [bohl at edirom.de]
>> Sent: Monday, August 12, 2013 10:44 AM
>>
>> To: Music Encoding Initiative
>> Subject: Re: [MEI-L] halfmRpt and @rend
>>
>> I just checked on mRpt and mRpt2, both of which don't allow @rend either.
>> Anyhow, all of the rpt elements allow @altsym.
>>
>> Considering this in combination with googlecode isuue 144
>> (http://code.google.com/p/music-encoding/issues/detail?id=144) "reserve
>> @rend and @style for CSS-like renditional information", is it the right way
>> to go, or should we stick with @altsym and maybe disallow @rend on beatRpt?
>>
>> Best,
>> Benjamin
>>
>> ***********************************************************
>> Musikwissenschaftliches Seminar Detmold/Paderborn
>> BMBF-Projekt "Freischütz Digital"
>> Benjamin Wolff Bohl
>> Gartenstraße 20
>> D–32756 Detmold
>>
>> Tel. +49 (0) 5231 / 975-669
>> Fax: +49 (0) 5231 / 975-668
>> E-Mail: bohl at edirom.de
>>
>> http://www.freischuetz-digital.de
>> ***********************************************************
>>
>> Am 12.08.2013 15:20, schrieb Roland, Perry (pdr4h):
>>
>> Pretty sure that's an oversight.  Please submit a ticket.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> --
>>
>> p.
>>
>>
>>
>>
>> __________________________
>> Perry Roland
>> Music Library
>> University of Virginia
>> P. O. Box 400175
>> Charlottesville, VA 22904
>> 434-982-2702 (w)
>> pdr4h (at) virginia (dot) edu
>> ________________________________
>> From: mei-l-bounces at lists.uni-paderborn.de
>> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti
>> [raffaeleviglianti at gmail.com]
>> Sent: Monday, August 12, 2013 8:44 AM
>> To: Music Encoding Initiative
>> Subject: Re: [MEI-L] halfmRpt and @rend
>>
>> FWIW, having looked at the same material, I also think a @rend would be very
>> useful there.
>>
>> Raf
>>
>>
>> On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl <bohl at edirom.de> wrote:
>>>
>>> Hi all,
>>>
>>> proofreading our data in Freischütz-Digital I came across repeat symbols.
>>> First case I was wondering whether to go with beatRpt but then I realized
>>> there was halmRpt, as well.
>>> As Weber writes his repeats as double slashes (not the common %) we're in
>>> eager need of @rend to indicate this circumstance. While @rend is available
>>> on beatRpt, it isn't on halfmRpt.
>>>
>>> Is there any reason for that, am I missing something?
>>>
>>> Best,
>>> Benjamin
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>