Re: Semantics and Music Notation

Hi Joe, Jan, all,

I agree with you both that this is a rabbit-hole that we should avoid. 
But I don't think that looking the other way is going to help us do 
that. Some problems simply go away if one looks at them closely enough...

You both seem primarily concerned with CWMN (it is, of course, extremely 
important), but I'm trying to ensure that other notations don't get 
locked out.

Reading Jan's post, its clear to me that he is referring to semantic 
representations /inside MusicXML/.
MusicXML is an interchange format shared by CWMN AUTHORING_APPs.

If there is a standard way to represent (say) Harp pedal positions 
abstractly in MusicXML, then the CWMN APP's Developer can decide to 
allow the User various alternative ways of displaying the pedals. In 
this case, the User would be creating a concrete, personalised INSTANCE 
that no longer contains abstract semantic information.

In other words, MusicXML can, of course, include abstract semantic 
representations -- but that does not affect the Global Architecture that 
I'm proposing.
Its up to MusicXML's Developers to decide which abstract semantic 
representations they are going to support. As far as I'm concerned, they 
have a completely free hand.

Hope that helps.

All the best,
James
-- 
http://james-ingram-act-two.de
https://github.com/notator


Am 21.04.2016 um 08:14 schrieb Jan Rosseel:
>
> Joe,
>
> Yes, let’s not go down that rabbit hole. Except…
>
> Before going to the exceptions: I find it amusing if people want to 
> have a standard cover a situation where “composers define the meaning 
> of a symbol in the foreword to a score”. That’s as opposite to a 
> standard as there can be. As I’ve stated before: there’s a standard 
> for that, it’s called PDF.
>
> No to get to the “except…”. You can leave glyphs to be as what they 
> are – glyphs. But then, PDF already covers that. I’d expect MusicXML 
> to be beyond that and at least cover tried and tested CWMN practices.
>
> Which brings me back to semantics of annotations. MusicXML – or at 
> least a “annotation profile” – should cover common, semantic 
> annotations, and leave it to the renderer to display those, possibly 
> to the liking of the individual musician.
>
> Just two examples:
>
> ·Harp pedals: these are not even annotations, but form a part of the 
> score, but nobody engraves them because harpists like to have them 
> notated in ten-ish different ways.
>
> ·Fingerings: in SCORA we render those in the “classical” way – above 
> staff, rather small – yet I hear musicans that want to have it larger, 
> below staff when the notes are in the lower half, other font, …
>
> For me, it’s all about making scores customised to the user. MusicXML 
> should be semantic enough (and the profiles should force the 
> applications/engravers to use those semantics) to allow exactly that.
>
> Regards,
>
> JanR
>
> *From:*Joe Berkovitz [mailto:joe@noteflight.com]
> *Sent:* woensdag 20 april 2016 23:08
> *To:* James Ingram
> *Cc:* public-music-notation-contrib@w3.org; Jim DeLaHunt
> *Subject:* Re: Semantics and Music Notation
>
> Hi James,
>
>     As I said at the recent face-to-face in Frankfurt, I don't think
>     one can legislate on the meaning of a particular glyph. The
>     simplest glyphs (for example the dot '.', plus '+', or zero '0')
>     are particularly often overloaded to mean different things in
>     different contexts: Dots are used for augmentation of durations,
>     staccato, as noteheads etc. A plus glyph (+) can mean simple
>     addition in a mathematical text, hand-stopping in horn parts, be
>     part of a complex time-signature etc.
>
> Within the confines of an accepted corpus of notation and performance 
> practice (e.g. the bulk of CWMN works), one absolutely *can* agree on 
> the meanings of a glyph -- in fact, such legislation is one of the 
> advantages of any notational system that has a substantial body of 
> practitioners in the world. Even overloaded glyphs can be understood 
> in one way or another, and these distinctions can be captured in an 
> encoding ("+" in a time signature is not encoded the same way as "+" 
> as an articulation on a note).
>
> I fear that this thread is headed down a meta-rabbit-hole of extreme 
> abstraction, in its effort to support open-ended definitions of any 
> musical language. There will then be a need for a musical 
> meta-language as well (for describing the structure and musical 
> meaning of the arbitrary language).
>
> Such a meta-language is a very interesting problem, but if we take it 
> on, I do not envision this group making meaningful progress with 
> respect to our charter to develop a useful encoding for the very large 
> body of existing works. Perhaps a separate group would like to break 
> off and develop such a meta-notation-language as a separate effort. If 
> successful -- a big if -- it could possibly serve as a separate 
> document that supplies semantic definitions for glyphs used in a 
> score, supplementing the work done in this group.
>
> This stance doesn't mean we can't support graphical scores, or include 
> arbitrary, non-canonical glyphs and notations in scores. But I believe 
> that it's best *within our encoding system* to allow these to act as 
> opaque, literal glyphs for which there is no particular 
> interpretation. In the future a separate effort -- perhaps yours -- to 
> describe arbitrary notational systems may succeed in supplying those 
> interpretations. In the meantime, the real world of musical practice 
> supplies a very effective set of interpretations for widely accepted 
> notation systems.
>
> ...Joe
>