Re: Notation References and Addressability

Hi Andrew,

I agree. Let's discuss those very use cases. 

We already have a use case for addressability. It could be improved.  Please build it out with the detail that you feel will make it more useful. In particular let's draw on whatever use cases have informed  EMA's design. 

I am not arguing in favor of a simple dumb atomic fragment ID. The only thing I am saying is that I don't want to dive into comparing technical approaches to addressability with each other at this point. Let's identify problems not solutions at this stage. 

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC
+1 978 314 6271
www.noteflight.com
"Your music, everywhere."

> On Nov 25, 2015, at 4:01 PM, Andrew Hankinson <andrew.hankinson@gmail.com> wrote:
> 
> Full disclosure: I've worked on the EMA project, so my knowledge of it is a bit privileged.
> 
> I would step in to defend bringing the idea of addressability, and EMA specifically, to the table. There is a very, very common use case among musicians and music scholars of 'addressing' bits of music: "Alright, let's take it from measure 3, second beat." Or "the theme arrives in the second voice on measure 42." Or "there is an error on the second staff, third measure, third beat." These are, perhaps, *the* most fundamental use case when working with symbolic music.
> 
> Simple fragment pointers are wholly insufficient for dealing with this kind of addressability. In all XML-based music encodings, a musical 'addresses' such as those given above must hit multiple points of the tree simultaneously -- you can't simply point to a single XML element and be done with it.
> 
> There are no existing solutions to this problem that are satisfactory for a music-specific context. XPath is perhaps the closest XML-native way of referencing specific parts of a document, but again you're querying the tree structure, not the musical structure. Writing a 'pointer' to specific musical 'addresses' as expressed by musicians means that a single 'addressable unit' must be extracted with multiple XPath queries, and these cannot be URL-encoded such that they serve a meaningful purpose in a Linked Data context.
> 
> The EMA project was conceived as a spec, inspired by existing efforts at image addressability with the International Image Interoperability Framework (IIIF), and is a first effort at establishing use cases for addressability by allowing musical fragments to be encoded and addressed in a musically-meaningful manner. While OMAS (the actual software implementation of EMA) is written to work with MEI-encoded files, the EMA specification is format-agnostic.
> 
> So rather than being a 'specific' API, the efforts of the EMA project may serve to help this community in establishing use cases on this point.
> 
> Cheers,
> -Andrew
> 
> 
>> On Nov 25, 2015, at 8:31 PM, Joe Berkovitz <joe@noteflight.com> wrote:
>> 
>> Hi Raff,
>> 
>> While I see a clear relationship between this work and the use case in question, I wonder if it's best not to get too involved in comparing the merits of specific APIs at this point.
>> 
>> There could be many APIs that support addressability. Some might be web services like yours; others might be DOM APIs that operate locally. What is interesting is the nature of the "pointer" that is being dereferenced.
>> 
>> When I think of addressability and the Web, I tend to think in terms of pointers (stable references from one document to another, for example the #fragment notation used in HTML documents). There are many possible APIs that can be used to dereference such pointers, but I think deciding the nature and structure of a "pointer" is a bigger question than the API mechanism. We can figure it out better once we understand all the things people want to do with pointers.
>> 
>> .            .       .    .  . ...Joe
>> 
>> Joe Berkovitz
>> President
>> 
>> Noteflight LLC
>> 49R Day Street / Somerville, MA 02144 / USA
>> phone: +1 978 314 6271
>> www.noteflight.com
>> "Your music, everywhere"
>> 
>>> On Wed, Nov 25, 2015 at 3:11 PM, Raffaele Viglianti <raffaeleviglianti@gmail.com> wrote:
>>> Hello all.
>>> 
>>>> On Wed, Nov 25, 2015 at 2:56 PM, Joe Berkovitz <joe@noteflight.com> wrote:
>>>> 
>>>> Musicologist, within one document, wants to reference a specific element, range or position of a work in the same or a different document using some kind of anchor construct. 
>>>> 
>>>> By the way, the fact that this case is "Musicologist" doesn't mean that no other roles would want to do this same thing -- just that the use case came up while thinking about musicological tasks.
>>> 
>>> Related to this point, I wanted to mention that the Enhancing Music notation Addressability (EMA) project has defined a URL scheme and API to "address" (or reference) a specific portion of music notation based on the notions of measure, staff, and beat (with the aim of making the scheme independent of a specific representation format).
>>> 
>>> We have a first draft of the API here: https://github.com/umd-mith/ema/blob/master/docs/api.md
>>> And we have an example implementation that works on MEI documents (demo: http://mith.us/ema/omas )
>>> The API aims at being format-independent, so implementations can also be written for MusicXML and the new format that will result from this working group.
>>> 
>>> Since referencing a specific portion of music notation seems to be an interest of this group, I would be curious to hear what you think of this approach.
>>> 
>>> All the best,
>>> Raff Viglianti
>