Re: Unique ids in MusicXML 3.1 and beyond

An EMA measure points to a 'musical' measure, not an 'XML' measure. So if I read "The fugue in Work X starts on measure Y" then I can translate that to an EMA request, and it will return a pointer to that measure, independent of whether it's captured in MEI or **kern or MusicXML. If you modify the document the EMA address would remain the same, since the underlying musical work does not change.

It only addresses a measure by index insofar as musicians themselves address it by index ("We're starting from Measure 13"). If you remove a measure from a work, then (arguably) it's not the same work. :)

Think of it more as providing musical interoperability across heterogenous systems, rather than representational or processing compatibility across software.

-Andrew

> On 8 Sep 2017, at 18:33, James Sutton <jsutton@dolphin-com.co.uk> wrote:
> 
> Hi Andrew,
> 
> I think you misunderstand my point.
> 
> The ema address, as I understand it, addresses a measure by index. If I remove a measure before the addressed one then the same address points to a different measure. This is a problem. I want an address to stay valid however I modify the document. For this I need an invariant uid for each measure
> 
> Apropos:
> If an application would change my IDs without being instructed to do so, that would be the last time for me to use that application… 
> 
> If we all use the same convention then we can use the same ids. If not then we cannot since the id is a limited resource (only one is permittted per item), 
> We have come back to my original point.
> 
> with best regards
> James Sutton
> Dolphin Computing
> http://www.dolphin-com.co.uk
> http://www.seescore.co.uk
> http://www.playscore.co
> 
> 
> 
> 
> 
>> On 8 Sep 2017, at 18:13, Andrew Hankinson <andrew.hankinson@gmail.com> wrote:
>> 
>> This is precisely the problem that EMA addresses: how to provide musical addressability independent of the underlying XML representation.
>> 
>> On Sep 8, 2017, at 6:09 PM, James Sutton <jsutton@dolphin-com.co.uk> wrote:
>> 
>>> Hi Adrian,
>>> 
>>> To clarify the original point, the uid is just like a unique address for each item in a score, so any document external to the MusicXML can unambiguously refer to any item in the score, even when the score is changed, until the item is deleted
>>> 
>>> The problem with bars[B].parts[P]... as an address is that it is not robust in the face of modifications to the XML. ie if you add a part or a bar then indices B and P do not point to the same place, and you normally cannot detect the failure!
>>> However if you use global uids they remain valid until the target object is deleted, and then you can detect when it has failed, as long as ids are never reallocated. (An interesting problem is how to ensure that.)
>>> 
>>> James Sutton
>>> Dolphin Computing
>>> http://www.dolphin-com.co.uk
>>> http://www.seescore.co.uk
>>> http://www.playscore.co
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 8 Sep 2017, at 15:28, Adrian Holovaty <adrian@holovaty.com> wrote:
>>>> 
>>>> On Fri, Sep 8, 2017 at 4:01 PM, James Sutton <jsutton@dolphin-com.co.uk> wrote:
>>>> Here is a couple of cases:
>>>> 
>>>> 1. If any program (eg OMR engine) needs to output non-MusicXML information (eg bounding-boxes of items)  then it could be passed via another channel (XML, JSON, text, ..), cross-referencing by uid
>>>> 
>>>> 2. a) If a conductor taps a note on her tablet, the note could be highlighted on all the players' tablets by passing a uid. The MusicXML might be generated by a completely independent program which outputs uids.
>>>> 
>>>>  b)  the note might be changed, or a notation might be removed or corrected
>>>> 
>>>> This does open a general way of referring to elements in a MusicXML file and for passing any information about elements which is not catered for in the MusicXML format.
>>>> 
>>>> For these use cases, it would be nice to have a general "selector" API for music notation in general — not just MusicXML, but any symbolic common Western notation across any app.
>>>> 
>>>> Joe has brought up this idea in the past, and I think it's a great one. Imagine something like this, to select the second beat of the first voice in the first bar of the first part:
>>>> 
>>>>     bars[0].parts[0].voices[0].beats[1]
>>>> 
>>>> It seems inelegant to shoehorn such a thing into MusicXML via a change to the way IDs work, but I admit I don't understand your original proposal, despite having read it a few times. :-/
>>>> 
>>>> Adrian
>>>> 
>>>> --
>>>> Adrian Holovaty
>>>> Soundslice: https://www.soundslice.com/
>>>> Personal: http://www.holovaty.com/
>>> 
>

Received on Friday, 8 September 2017 17:39:49 UTC