[MEI-L] typable events

Wed Aug 7 23:54:41 CEST 2013

Thanks, Johannes, for the summary.

The discussion so far notwithstanding, I have been considering the addition of @type and @subtype (or perhaps @analog) to control events, especially <dir>, since <dir> is a generic container for "stuff" associated with events.  As such, in a conversion from some other music representation scheme with more specific elements for this kind of "stuff", it would be helpful to be able to associate the MEI <dir> element with the element in the source representation from which it is derived.

For example, MEI has no element specifically for fingerings, so that kind of info. has to go in a <dir>.  In order to facilitate conversion of the MEI back to the original form, it is necessary to know that this particular <dir> translates back to a <fingering> element, not some other.  Or perhaps I should follow my own advice and create a new <fingering> element in MEI.  :-)

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Wednesday, August 07, 2013 5:37 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] typable events

Ok, let me summarize the discussion so far:

* we all agree that making events typable invites abuse more than it solves actual problems. As long as no one speaks up with better arguments, we won't make this available

* I'll think over my bad behavior in the past and try harder next time ;-) (probably doing the private namespace thing then…)

Thanks for the discussion :-)
Jo

Am 07.08.2013 um 23:31 schrieb "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu>:

>
> Don's comment +1
>
> --
> 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 Byrd,  Donald A. [donbyrd at indiana.edu]
> Sent: Wednesday, August 07, 2013 10:35 AM
> To: Music Encoding Initiative; Johannes Kepper
> Subject: Re: [MEI-L] typable events
>
> Disclaimer: this is a hasty comment from someone who hasn't been
> following the details of the discussion :-| . Ahem. Using an attribute
> in a private namespace seems like exactly what you want. If anything,
> breaking validity unless you change your def. of MEI sounds like an
> advantage, since then if you fail to clean up your intermediate code
> properly, anyone running against standard MEI would likely find that
> out very quickly.
>
> --Don
>
>
> On Wed, 7 Aug 2013 16:19:16 +0200, Johannes Kepper <kepper at edirom.de> wrote:
>> Hi Andrew,
>>
>> I wasn't complaining about your argumentation, not at all :-)
>>
>> Actually, when I set that up, I didn't think about it much. It was
>> just today when I noticed that it doesn't validate, and I wondered
>> why that is. I totally agree that the current state is, say, less
>> than ideal... I see your point about inviting abuse when making @type
>> more general available, and I guess I'm willing to follow that
>> argument. However, I'm less convinced that @label is actually a
>> better solution for my needs. Since I'm saying something _about_ my
>> MEI, I wonder if an attribute in a private namespace might be an
>> option? This would break validity (unless I change my MEI
>> accordingly), but it would be clearly something said from "outside",
>> without pretending to be my final MEI...
>>
>> Opinions?
>> jo
>>
>>
>> Am 07.08.2013 um 16:08 schrieb Andrew Hankinson
>> <andrew.hankinson at mail.mcgill.ca>:
>>
>>> Oh, I wasn't making any particular argument -- just trying to
>>> understand your need.
>>>
>>> The phrase that I copied from Perry seemed to suggest that @type
>>> should be used to typify the element, not the use or context. So
>>> "<space type='non-breaking' />" (to make up an example) might be OK,
>>> whereas '<space type='sharesLayer1' subtype="rest" />' seems weird,
>>> since you're typifying the use and context of the element, not the
>>> element itself.
>>>
>>> I have no problem with @type on events, per se, but since "type" is
>>> such a loose concept I think that would open it up for abuse for
>>> people trying to do "quick and dirty" encoding. Should we consider
>>> <note type="quaver" /> or <clef type="treble" /> to be "good" MEI?
>>> Hopefully not, but I think it would be the kind of thing that would
>>> be a tempting solution when you're not an expert encoder.
>>>
>>> Leaving @type off of them may indeed be an oversight, but maybe we
>>> don't want to go too crazy with @type in favour of more expressive
>>> markup.
>>>
>>> If it's just temporary, and you just want an attribute that you can
>>> abuse for a transitional file, why not do as Thomas suggested and
>>> put it in @label, perhaps with a fixed formatting that you can
>>> process later:
>>>
>>> <space label="layer1-rest-finalefix" corresp="#d1e2682" />
>>>
>>> You could then split on the hyphens in any @label and have your
>>> layer, event, and reason all in one easy-to-chew package. :)
>>>
>>> Alternately, you can do it another way and store a list of IDs in a
>>> separate plain text file or CSV, which you can then use later when
>>> processing it.
>>>
>>> -Andrew
>>>
>>> On 2013-08-07, at 3:39 PM, Johannes Kepper <kepper at edirom.de>
>>> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
> Donald Byrd
> Woodrow Wilson Indiana Teaching Fellow
> Adjunct Associate Professor of Informatics
> Visiting Scientist, Research Technologies
> Indiana University Bloomington
>
>
> _______________________________________________
> 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