I have been looking round other people's transcriptions on the net
over the last few days and I'm getting reminded of a few missing
features of ABC that would make web-trawls for music more productive.
- universal identifiers, along the lines of the Message-IDs used with
email and Usenet postings. These tell you whether you've found another
copy of something you've already got, and (if they have some internal
structure, as Message-IDs usually do) can help direct you to the human
who did the transcription or made it available.
- checksums. These tell you whether you've got the tune or complete
file the way the transcriber or uploader originally had it.
- URLs. Not as useful as universal identifiers, because they're
relatively transient, but they would usually help in tracing
associated material for a few years after being disseminated.
- keywords. Currently there is no way to search for music by intended
instrument, genre, period, the performer it was associated with, range,
or intended function ("wedding march", "mobile ringtone"). Keywords
can support that.
This is the same sort of thing that HTML does with META tags. I suggest
that we now allocate a field to these web-related functions, and like
the META tag, specialize that field into subsidiary types later. These
fields could occur either on their own in a file or within a tune header.
A single file or tune could contain several of them. They would be one-
line fields, each containing only information of a single subsidiary type.
I suggest the subsidiary type information is represented in a similar way
to META tags:
< typetag = data >
where "typetag" is a case-independent string composed of alphameric
charcters or "_" and the spaces around the = sign and next to the <
and > signs are insignificant. The "data" field may have its own
syntax dependent on the typetag.
Examples:
E:<url = http://www.purr.demon.co.uk/jack/McLennan.abc>
or
E:<KEYWORD = accordion, musette, Viseur>
or
E:<ID = Evita/DontCryForMeArgentina/FullScore@TheReallyUsefulCompany>
where Sir Andrew would presumably have registered the part to the right of
the @ sign somewhere to guarantee global uniqueness of the ID, with the
part to the left being solely his responsibility (as with Message-IDs -
this generally means using locally-generated sequence numbers somehow).
As the E: field is not used by any currently supported software I propose
we reallocate that. "G" would be another possibility, handily standing
for "global", but I believe that does still get *some* use, albeit in
rather trivial ways. I've never seen either in a tune I've got off the
net.
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
