[MEI-L] halfmRpt and @rend

[TW]

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
>