[MEI-L] Antw.: symbol/symbolDef

[Benjamin W. Bohl]

Hi all!
I don't think that you're off track Perry ;-)

Thomas, what you're describing sounds to me like the occasion for a critical note (annotation); @plist could refer to the occurrences of the uninterpreted neume or even the user defined symbol.
I don't see any necessity or use in describing the fact that the neume is unknown or or occurs in other places directly in the music body.

Benjamin

----- Reply message -----
Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>
An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de>
Betreff: [MEI-L] symbol/symbolDef
Datum: Di., Mär. 20, 2012 20:13


> When talking with the Corpus monodicum people from Würzburg about
> encoding their data in MEI, the problem occured that occansionally
> they find neumes that they cannot interpret (yet).  However, those
> neumes aren't just sloppily written, they clearly manifest a certain
> kind of symbol as it is found repeatedly (for example within the works
> of a certain scribe).  @facs doesn't express this, while @altsym could
> do.

Please forgive me, but I don't understand what you're trying to say.  @facs doesn't express what?  The fact that they can't / don't want to say what a certain symbol is / means?  What does @altsym do in this case that @facs doesn't?

Whatever "it" is, @facs points to a region of an image and says "there it is", while @altsym points to a vector graphic and says "this is how you draw it".  Neither of these attributes has anything to do with interpretation.

Both of these require the encoder to make a decision about what "it" is by choosing an MEI element.  So, for a neume one can say

<neume @facs="d1" altsym="us1"/> 
<!-- This is a neume, it's there at "d1", and instructions for rendering it are at "us1" -->

Are you wanting <symbol> to function as a generic marker for an unknown sign?  That is, if a symbol's meaning is unknown, then are you looking for markup like --

<symbol @facs="d1 d2 d3 d4 d5"/>

saying, in effect, "I don't know what this thing is, but it occurs 5 times"?

This doesn't sound right to me because you already said they have *neumes* that can't yet be interpreted.  But at the very least they can be called "neumes", right?  So what's wrong with calling them neumes by using the <neume> element?

Am I completely off the track here?

--
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 TW [zupftom at googlemail.com]
Sent: Tuesday, March 20, 2012 2:23 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] symbol/symbolDef

2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>
> The purpose behind the symbolDef/symbol pair is to encode *user-defined* shapes/signs/symbols so that they can be rendered.
>
> This is distinctly different from classifying/identifying shapes/signs/symbols in a facsimile, which  can/should be handled using @facs on MEI elements.
>
> Just a reminder:
>
> Don't forget about @altsym which can be used to link an MEI element directly to a <symbolDef>.
>

When talking with the Corpus monodicum people from Würzburg about
encoding their data in MEI, the problem occured that occansionally
they find neumes that they cannot interpret (yet).  However, those
neumes aren't just sloppily written, they clearly manifest a certain
kind of symbol as it is found repeatedly (for example within the works
of a certain scribe).  @facs doesn't express this, while @altsym could
do.

Would this be misuse as this would not be targeting rendering?  If
not, why force them by means of the Schema to draw a vector version of
a symbol?  Just the classification and one or more facsimile
references would pretty much say everything that can be said, I think.

Thomas

_______________________________________________
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
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120321/fe7a2278/attachment.html>