[MEI-L] typable events

Johannes Kepper kepper at edirom.de
Wed Aug 7 23:37:17 CEST 2013 

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

More information about the mei-l mailing list