[MEI-L] typable events

[Johannes Kepper]

Hi Andrew,

my actual example is

<space xml:id="d6d3e1117" type="sharesLayer1" subtype="rest" corresp="#d1e2682" dur="4"/>

which could be encoded as 

<supplied reason="Finale is sh…" resp="#jk">
	<space dur="4" corresp="#ID_of_rest_in_Layer1"/>
</supplied>


While this is absolutely possible, it complicates intermediate steps a bit, since I already have to deal with editorial markup then. Remember, this is only temporary data that I won't publish, and that I don't regard as ready yet. However, it is a state that will be submitted to my repository, and will thus be visible to others. If it was a more stable state, I would certainly take the <supplied> approach, but in the end, this will just result in a couple of sentences in the documentation. For now, all I want to achieve is to get an indicator where I have to look during proofreading. The benefit of the attribute-only solution is that I can just strip the attribute when I'm done, assuming I have made my changes where necessary beforehand. 

But again, you're discussing my example, which I already announced as being questionable. I'm deeply sorry that I didn't come up with a better one, but I had none in mind. Without having a better one by now, I suspect that in most situations where one would add @type to events, MEI would allow an alternative using editorial markup. But still, I wonder if we shouldn't allow @type on events. 

It would be easier for me to follow your arguments if you would address this question as well, not just my ill-considered example…

Thanks,
jo





Am 07.08.2013 um 13:46 schrieb Andrew Hankinson <andrew.hankinson at mail.mcgill.ca>:

> The only thing I have to add here is from an old discussion Perry and I had a while back. I just remembered it when reading through Johannes' e-mail, so I'll reproduce it here:
> 
>> … I think it's good practice to use @type to indicate the *classification of the element itself, not its contents.*  For example, <name type="personal">Perry Roland</name> as opposed to <name type="composer">Perry Roland</name>.  The first seems to me like a good use of @type -- it classifies the name, not Perry Roland.  Down the second path is ruin and death. :)
> 
> In the case of the example Johannes provided, I'm unclear what the problem is. Is it that you can't do "<rest type='supplied' />"? This seems a strange way of marking it up, especially since we have quite extensive functionality for editorial additions.
> 
> Couldn't it be:
> 
> <measure>
> …
> <supplied reason="missing" resp="$POINTER_TO_AUTHOR_DEF_IN_HEADER">
>   <rest />
> </supplied>
> </measure>
> 
> -Andrew
> 
> On 2013-08-07, at 1:07 PM, Johannes Kepper <kepper at edirom.de>
> wrote:
> 
>> Hi Thomas,
>> 
>> thanks for pointing that out. This solution seems to be too temporary to me, I would like to have something more stable. Also, I'm actually using both @type and @subtype. But this is just about my example – what's your take on the availability of @type on events in general?
>> 
>> jo
>> 
>> 
>> 
>> Am 07.08.2013 um 13:03 schrieb TW <zupftom at googlemail.com>:
>> 
>>> My favourite attribute to abuse for temporary solutions that should
>>> not result in invalid MEI is @label as it's available almost
>>> everywhere.  (Kristina can tell you a thing or two about that.)
>>> 
>>> 2013/8/7 Johannes Kepper <kepper at edirom.de>:
>>>> Dear List,
>>>> 
>>>> I have some issues I've found recently that I would like to discuss. Let's start with a question about typable events. In current MEI, it is not possible to use @type (att.tybable) on all events (model.eventLike), such as notes, rests, chords, spaces, tuplets, bTrems etc.
>>>> I wonder if this is intention, or if we just missed to add that class. Even if it was our intention (though I haven't found a former discussion on this), what were the arguments, and do we still think this is a necessary restriction?
>>>> 
>>>> The following sample may be skipped for brevity…
>>>>> My example for this is somewhat questionable in itself, so let me explain it a bit. For our Freischütz edition, we're heading off with Finale data converted to MEI via MusicXML. In the case of multiple layers on one staff, Finale clips shared events at the end of the second (and any subsequent) layer: If both layers share a rest at the end, only the first layer holds this rest, while the second is just incomplete.
>>>>> 
>>>>> For several reasons, I think this is faulty behavior, and therefore add corresponding spaces by XSLT. However, I would like to keep track which spaces were contained in the original file, and which spaces were added by me. A simple @type on the latter would be perfect for me.
>>>>> 
>>>>> I am fully aware that MEI offers a whole plethora of elements to indicate added, normalized, or otherwise changed content. But since this is just an intermediate step in the process of generating my data, I regard this additional markup as too complicated. I'm not sure if I will keep this information after the next step of proofreading. On the other hand, I don't want to operate on invalid data, even if it is only a temporary state.
>>>> 
>>>> I'm pretty sure there are simpler examples and better arguments at hand, but I hope my example makes the point. So, what do others say – should events like notes and rests be typable?
>>>> 
>>>> Best,
>>>> Johannes
>>>> _______________________________________________
>>>> 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
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l