10

←	Oct 2006	→
S	M	T	W	T	F	S
1	2 Music Computability	3	4	5	6	7
8	9 Pycoon Selectors	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

I've just been looking at the research interests of staff in LLT at UEA and I've found someone who's interested in computational linguistics. Yay!

Though his research interests paragraph got me thinking. He talks about looking at computational systems underlying language - the actual language itself, the abstract concept of words and syntax. This is different to encoding texts using computational (or rather computer-based) techniques. It implies searching for algorithms for - and models of - language as an abstract concept.

Does this relate to what I want to do with music? I think it probably doesn't directly. A closer analogy would be the "computability of music" but I don't think thats what I'm after (or at least not at this stage; or it shouldn't be an influential factor in assessing/designing encoding methods for music scores, anyway). I'm not searching for algorithms which describe the grammar or syntax of music - just attempting to preserve (manuscript) music scores/information in a digital format. The use of that information is not a current concern.

I read an interesting abstract from the Extreme Markup 2002 conference the other day and it got me thinking about information encoding. I realised that, despite my post about the difficulty of near-binary representations of music information, I have been assuming the use of a markup-based encoding and ignoring other possibilities. This is especially relevant in light of this abstract as conflicting hierarchies are one of the important features of music encoding.

I foresee at least four different hierarchies working within a score: the note/bar/movement structural hierarchy; the analytical structural hierarchy; the marked phrasing, tying features; and the visual manuscript hierarchy. I think that it will be important to investigate other possible encoding methods which may be better suited to representing all this information.

Markup would have some advantages, however. If I use any other system, I will likely have to manage my own tokenization of the data in processing applications - while XML parsers (along with the markup concept) have that available for free. Also, that idea of stand-off markup may come into play for the specific problem of conflicting hierarchies: instead of messing up the data with milestone-like tags, you encode other hierarchies in separate files and then design ways of dynamically aggregating them into single views.

Of course, all this depends on being able to make use of UEA fully. I still haven't got the login details for my user account and there's a massive queue at the ITCS helpdesk every time I check. Sometimes I've gone and stood at the back of it but given up after a few minutes... I just don't think I can face it.

Posted Mon 02 Oct 2006 17:04:00 BST

Spent the weekend hacking and I now have selectors in Pycoon (my Cocoon rip-off).

Its amazing how adding just one little feature seems to make the whole framework appear more usable. You can now do things like this:

</when>

</when>

</select>

</match>

Or, even better, return NOT_ACCEPTABLE errors to MSIE users just for giggles:

</when>

</when>

</select>

</match>

And I added selectors for "resource exists" and "request parameter" which are quite nifty (in fact, they were ideas stolen from Cocoon).

I also added an http_generator which allows you to get your XML source streams using HTTP requests:

</generate>

</aggregate>

</match>

Now I'm looking forward to the 0.0.1 release ;-)

Posted Mon 09 Oct 2006 14:10:00 BST