[MEI-L] TEI Members Meeting report and a feature request

[Roland, Perry (pdr4h)]

Raffaele,

I think you mean "syntactic sugar"; that is, the substitution of a (hopefully) simpler way of saying something for another, (usually more complex) method.  But successful uses of "syntactic sugar" involve changing the syntax without changing the meaning.  It seems to me that this is not the case here.  Personally, I don't find anything particularly difficult with using <figure> so I fail to see the need for something simpler.  Without a need for simplication, another element that allows encoding of the same meaning is superfluous and causes confusion.

<music> should indeed be thought of as figure-like for technical reasons that have to do with where it can occur, but that doesn't mean it's the same thing as a figure.  To me, the use of <music> instead of <figure>, implies a desire to say something different and more meaningful (or at least at a different level of detail).  The approach to "syntactic sugar" you suggest only serves to obscure the difference that the two tags can indicate.

The intent behind the creation of <binaryObject> may very well have been to allow the insertion of any kind of base-64 encoded object.  What I was trying to say before is that I think it's unfortunate that it's in the model.graphicLike class.  This means that anywhere <binaryObject> can be used, <formula> and <graphic> *must* also be allowed.  I can see the usefulness of <binaryObject> within <music>, but not <graphic> (for the reasons above) and certainly not <formula>.

I agree that generic content models are often better than specific ones, but they shouldn't be more generic than necessary.  Too much "generosity" in a content model is just as bad as too many strictures.

So, I re- reiterate my call for a <music> element with a content model that makes it clear that its purpose is *not* for simply inserting a graphic (<figure type="music"> can be used for that), but for marking the content as something else; that is, *MUSIC*.

How about 

   ELEMENT music (model.labelLike|model.ptrLike|binaryObject)*

where other XML notations can be inserted via customization?

This clearly indicates that we're not just inserting a graphic, but a generic identifier for the concept called "music", which potentially consists of any combination of textual descriptions, labels, references to external graphic, audio/video or other binary files, base-64 encoded binary files, or (after customization) music markup.  The intent is to allow the content to define the encoder's concept of "music".

This model is in keeping with the generally-accepted idea (proposed first by Babbitt and later taken up by SMDL) that the somewhat difficult-to-define thing we call "music" exists in several "domains", e.g., logical, visual, and gestural.  A graphic as content of <music> indicates an existence in the visual domain, while a reference to an external file or a base-64 encoded file containing a sounded performance indicates existence in the gestural domain, and markup (XML or otherwise) of musical concepts indicates existence in the logical domain.  I believe this model is generic enough to cover all these domains without introducing unnecessary complexity or confusion.

Am I missing something in my analysis?  Is something *absolutely necessary* missing from this model?  If nothing is truly missing, then we don't need anything else.

I rest my case,

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h at virginia.edu
________________________________________
Date:    Sun, 5 Dec 2010 10:43:44 +0000
From:    Raffaele Viglianti <raffaele.viglianti at KCL.AC.UK>
Subject: Re: TEI Members Meeting report and a feature request


Hi Perry,

Sorry for this late reply.
> TEI already provides a method for including graphics, including music; that is, <figure>.

This is true, and it sounds to me that Peter would agree, so we have
this as one side of the argument. The other is that <music> provides
semantic sugar for <figure> in this case.

I'd like to quote what James Cummings wrote on the feature request page:
http://bit.ly/akUxld

"Yes, as we've discussed a proposed tei:music element is a figureLike
element so should indeed have the ability to have a graphic in it. I feel
that a tei:music/@type='notation' with a graphic element inside it would be
a form of syntatic sugar for embedding a figure with a graphic pointing to
a score. It would just be a more precise way of doing so and also allows
for instead embedding MEI or something else, or indeed tei:binaryObject
with a recording.

This makes it a much more general purpose element for denoting that some
bit of the original here had music in some sense, which I think is a much
more flexible approach. But I tend to fall into the if in doubt make it
more general purpose and flexible camp rather than the if in doubt make it
as tight as possible camp.

-james"

And I agree. I think I like the idea of having one element in TEI that
very generically refers to "music" and the medium and format of whatever
has been called music is deferred to other representations (either
embedded with a customization or pointed).

> In the interest of keeping things simple, may I suggest that:
>
> 1. We request a new <audio>  element,
>
> The <audio> element may be useful for non-musical situations, e.g., spoken renditions; therefore, it might be useful to create a model.audioLike class.

This is an interesting suggestion, and we might want to liaise with the
Linguistics SIG. They are wondering how to handle annotation of binary
files (i.e. speech corpora).

> It appears that <binaryObject>  was conceived as a substitute for <graphic>.  It might also be a substitute for <audio>, but as long as <graphic> and <binaryObject> are part of the same class, it could be used incorrectly; that is, allowing one to insert a sound where a graphic is appropriate or vice versa.
This is already possible in principle. As far as I know, binaryObject
was created to embed a binary object ("graphic or other object") in
character data, similarly to what svg does with the <image> element.

<image y="198.14789" x="-1.7857151" id="image4015"
xlink:href="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABA.... etc.

> 2. Instead of model.glossLike,<music>  should allow the model.labelLike class as content. This would provide just<desc>  and<label>  elements, without the "baggage" of altIdent, equiv, and gloss.

I think the extra baggage doesn't hurt in this case.

> 4. We can side-step the issue of disagreement between the @type value and the contents of<music>  by returning to an open value list for @type on<music>.
The current proposal keeps the value of @type open, but with "notation"
and "sound" as recommended values. I think this idea can stand, even if
the TEI later produces an <audio> element.

Best,
Raffaele

--
Raffaele Viglianti
PhD candidate and PGRA
Centre for Computing in the Humanities
King's College London