The OMRAS2 Chord Ontology, first draft
Christopher Sutton
A few of us at C4DM have been working on an RDFS chord ontology for use
in our lab and are keen now to invite feedback and discussion from a
wider community.
The current specification is at http://purl.org/ontology/chord/ - this
is only a first draft and there are some known issues. However we have
found it useful so far, and hopefully it can act as a basis for
discussion and improvement.
There are some python scripts demonstrating use of the ontology in the
motools package on sourceforge
(http://www.sourceforge.net/projects/motools/) and there will shortly be
some Java code there also.
There are a number of issues listed at the bottom of the specification
document - feel free to pick one and start a discussion here on list !
Many thanks,
Christopher Sutton
Danny Ayers
> A few of us at C4DM have been working on an RDFS chord ontology for use
> in our lab and are keen now to invite feedback and discussion from a
> wider community.
>
> The current specification is at http://purl.org/ontology/chord/
Marvellous!
I was wondering about something like this not long ago (am learning
guitar - again), but it looked a huge job, so - nice work, thanks!
I've a vague recollection of Sean B. Palmer doing something with
chords in n3, will try and locate a link.
> There are some python scripts demonstrating use of the ontology in the
> motools package on sourceforge
> (http://www.sourceforge.net/projects/motools/) and there will shortly be
> some Java code there also.
There may be some reusable Java around here somewhere:
http://www.idi.ntnu.no/~heggland/ontolog/
> There are a number of issues listed at the bottom of the specification
> document - feel free to pick one and start a discussion here on list !
I notice a reference to midi - if anyone's got a little spare time
(heh) there's another little midi job described here:
http://dannyayers.com/2007/03/30/instruments
Incidentally, it's very well presented - what tools did you use to
prepare the doc?
Cheers,
Danny.
--
Yves Raimond
First: great job Chris :-)
> There may be some reusable Java around here somewhere:
> http://www.idi.ntnu.no/~heggland/ontolog/
This looks great! I'll give it a try right now.
> > There are a number of issues listed at the bottom of the specification
> > document - feel free to pick one and start a discussion here on list !
>
> I notice a reference to midi - if anyone's got a little spare time
> (heh) there's another little midi job described here:
> http://dannyayers.com/2007/03/30/instruments
Oh - I actually missed that post :-) It is definitely really interesting stuff!
Actually, I recently went through the work of Jurgen Reuter presented
at the Linux Audio Conference last year [1], and I think he already
has something. I have been in touch with him recently, but haven't yet
had access to the actual rdf.
>
> Incidentally, it's very well presented - what tools did you use to
> prepare the doc?
>
Heh - Chris is a great CSS hacker! He succeeded to get something nice
out of ontospec (the small prolog script we use to generate the MO
specification), which is nearly impossible :-)
All the scripts/tools/etc. to generate the documentation are available
on the motools SVN:
http://sourceforge.net/projects/motools/
Cheers!
Yves
[1] http://lac.zkm.de/2006/papers/lac2006_juergen_reuter.pdf
Yves Raimond
> chords in n3, will try and locate a link.
I just found the link:
http://infomesh.net/2001/05/sw/
There is a whole guitar chord dictionary in N3 (using a tablature-like
schema) - that's great!
Cheers,
y
Danny Ayers
> > http://dannyayers.com/2007/03/30/instruments
>
>
> Oh - I actually missed that post :-) It is definitely really interesting stuff!
> Actually, I recently went through the work of Jurgen Reuter presented
> at the Linux Audio Conference last year [1], and I think he already
> has something. I have been in touch with him recently, but haven't yet
> had access to the actual rdf.
It'll be cool if he's already covered this - it is the kind of thing
better done by someone closer to the, er...beeps?
btw, Steve Harris (who may be on this list) is another Linux
Audio/SemWeb hacker - on the audio side I think mostly around Ardour
and LADSPA.
> All the scripts/tools/etc. to generate the documentation are available
> on the motools SVN:
> http://sourceforge.net/projects/motools/
Great, thanks.
seventy...@googlemail.com
Re suggested future extensions, I think most of them belong outside the chord ontology.
Specifically:
- Allow absolute pitch specification - by MIDI note number
structure - there could be a separate ontological 'module' devoted to defining the mapping between
the symbols of pitch notation and specific numeric encodings.
- Explicitly specify whether chords are descriptive or prescriptive (ie. transcription vs. score)
itself. For example, if the chord exists in the context of an annotation of some sort, it would be the
job of the annotation to specify whether the chord was descriptive or prescriptive.
- Specify voicing
- Fully ? (eg. intervals are ordered and include octave information)
- Just whether a chord is played in open, closed or mixed position ?
making an ontology. For the phenomenon of 'a set of simultaneously sounding musical
pitches', we have several possible levels of representation ranging from 'a set of fundamental
frequencies' through 'a set MIDI numbers', 'a set of (symbolic) musical pitches', eg {C2, G3, E4,A4},
'a chord' such as C6, to functional harmonic descriptions like 'dominant 7th'.
The purpose of moving up the levels of representation is deliberately to throw away information
available at the lower level and to make explicit information that can only be inferred from the
lower level (eg to decide if a set of pitches is intended as a Minor 7th or a Major 6th).
Including voicing information takes the present representation (which is in the middle of the
list I gave above, about the level of 'C6') and mixes it with the 'set of pitches' representation.
I think we would have to be careful about making each level fuzzier by mixing in information from
other levels, and err on the side of defining distinct representations for distinct task, eg for voicing
or for functional harmony. I don't know much about voicing or what terms people use when they
describe voicings - is it a clearly distinct concept from just giving set of pitches?
- Representation of metrical time. Currently the TimeLine ontology doesn't cover this case, but it would be useful (eg. for translating from MMA chord files or scores)
not the chord ontology.
- Fix the requirement to specify a named root note. This would be partly solved by allowing Notes to be specified by absolute pitch.
the physical fundamental frequency? If the latter, then I would disagree, as I don't think it makes
sense to specify the root as frequency but then to describe all the intervals in symbolic, diatonic
terms.
cheers,
Samer
Hi,
A few of us at C4DM have been working on an RDFS chord ontology for use
in our lab and are keen now to invite feedback and discussion from a
wider community.
The current specification is at http://purl.org/ontology/chord/ - this
is only a first draft and there are some known issues. However we have
found it useful so far, and hopefully it can act as a basis for
discussion and improvement.
There are some python scripts demonstrating use of the ontology in the
motools package on sourceforge
(http://www.sourceforge.net/projects/motools/ ) and there will shortly be
Christopher Sutton
> I've a vague recollection of Sean B. Palmer doing something with
> chords in n3, will try and locate a link.
Just followed Yves' link on this - very cool, will have to see about
incorporating the guitar fingerings into our descriptions of chords. I'd
like one day to link to chord box diagrams from the chord descriptions
and this is certainly a useful step in that direction :) Thanks !
> There may be some reusable Java around here somewhere:
> http://www.idi.ntnu.no/~heggland/ontolog/
Looks interesting, will try it out, thanks. The java code I had in mind
was just the basic parsing of RDF chord transcriptions, pulling out the
info into Java variables. I just have to strip down some code we have
already.
> Incidentally, it's very well presented - what tools did you use to
> prepare the doc?
Thankyou ! The diagrams were created using OmniGraffle (of which I am a
big fan) and as Yves mentioned, the rest was just some modifications to
the scripts used for generating the music ontology spec. The doc's
generated by running chord/ontospec/spec.sh from the motools SVN
checkout. So most credit goes to the MO and FOAF spec authors for
setting a good example and CC licensing their stuff :)
Cheers,
c
Danny Ayers
<seventy...@googlemail.com> wrote:
[great stuff]
>> Fix the requirement to specify a named root note. This would be partly
>> solved by allowing Notes to be specified by absolute pitch.
> Not sure what you
> mean by this. By absolute pitch, do you mean symbolic pitch (C2, A3 etc) or
> the physical fundamental frequency? If the latter, then I would disagree, as
> I don't think it makes
> sense to specify the root as frequency but then to describe all the
> intervals in symbolic, diatonic
> terms.
When I read this I wondered how you would get a concrete (audio)
representation from the information without having a physical
fundamental... I defer to folks more knowledgeable about music
notation/representation on this specific question, but it does suggest
a meta point - Use Cases!
The optimal spec style that seems to be emerging elsewhere (whether in
one doc or many) is to cover a) spec proper; b) tests; c) use cases;
d) primer. The spec here seems to do a pretty good job of covering
spec and primer, tests probably aren't necessary in this context
(unless you want to dig deep into OWL), which leaves use cases...
Danny Ayers
On 26/10/2007, Danny Ayers <danny...@gmail.com> wrote:
but it does suggest
> a meta point - Use Cases!
I'd better ask - how might you use the ontology (and whatever else was
necessary) to :
* transcribe chordal music ?
* play it back ?
These are naive questions, and any response would probably need a fair
bit of handwaving implementation-wise, but I reckon the ont does cover
at least most of what is needed.
--
seventy...@googlemail.com
I think that would be appropriate at this level of description,
but I don't know if it would cause implementation difficulties.
The direct approach would be a recursive definition like:
Note ::= Natural | Modifier Note
Modifier ::= Sharp | Flat
this would allow, eg 'Sharp Sharp F' but would not enforce
the exclusion of, eg 'Sharp Flat Sharp C'.
How could you render this in Owl/RDF?
samer
Christopher Sutton
Just to clarify on a couple of your points (need to think more about
some of the others !)
seventy...@googlemail.com wrote:
> * Allow absolute pitch specification - by MIDI note number
>
> MIDI, being a particular encoding note information, belongs outside the
> logical specification of chord
> structure - there could be a separate ontological 'module' devoted to
> defining the mapping between
> the symbols of pitch notation and specific numeric encodings.
I was looking to allow specification of pitch including octave, without
requiring a note name to be given. MIDI note numbers seemed the obvious
existing numbering system. Is there a more appropriate system ?
> * Fix the requirement to specify a named root note. This would be
> partly solved by allowing Notes to be specified by absolute pitch.
>
> Not sure what you mean by this. By absolute pitch, do you mean symbolic
> pitch (C2, A3 etc) or
> the physical fundamental frequency? If the latter, then I would
> disagree, as I don't think it makes
> sense to specify the root as frequency but then to describe all the
> intervals in symbolic, diatonic
> terms.
I wasn't suggesting frequency, no. Instead of "absolute pitch" here I
should perhaps have said "pitch class including octave".
The use case which led to this comment was :
- I have a set of concurrent, unnamed notes (eg. from a MIDI file) and
I'd like to specify them as a chord without deciding on note names.
Currently you can do this in part by specifying the chord's intervals as
SemitoneIntervals but you still need to assign a name to the root note,
which I think is a problem.
One solution seems to be to allow a Note resource to be specified by
"pitch class including octave" and allow Chord resources to be made up
of a set of Notes rather than one root Note and a set of Intervals.
I need to think some more about your comment about levels of abstraction
(which I think ties in with Danny's comment about use cases), because
perhaps consideration of octave and voicing should be kept separate from
ideas like "a C major 7 chord".
And on a quick point :
> * Representation of metrical time. Currently the TimeLine ontology
> doesn't cover this case, but it would be useful (eg. for
> translating from MMA chord files or scores)
>
> Totally agree with this, but again, at the risk of stating the
> obvious, it belongs in the time ontology not the chord ontology.
Very much agree, it's listed here just because it tends to come up when
discussing uses of the chord ontology. Is there a TimeLine ontology
mailing list ?
Thanks,
c
> On 10/26/07, * Christopher Sutton* <chris....@elec.qmul.ac.uk
Christopher Sutton
The ontology currently allows one or more Modifiers to be attached to a
Note, and defines four instances of the Modifier class, corresponding to
single and double sharps and flats.
There aren't any restrictions on how many Modifiers may be applied to a
Note. I suspect the ontology could really benefit from some additional
OWL constraints to help ensure sensible usage.
c
Yves Raimond
[I totally agree with all your comments in the previous email]
> Is it possible to specify multiple sharps or flats?
Yes, it is. For example, you can try the following URI:
http://purl.org/ontology/chord/symbol/Ds:dim7
> I think that would be appropriate at this level of description,
> but I don't know if it would cause implementation difficulties.
> The direct approach would be a recursive definition like:
>
> Note ::= Natural | Modifier Note
> Modifier ::= Sharp | Flat
>
> this would allow, eg 'Sharp Sharp F' but would not enforce
> the exclusion of, eg 'Sharp Flat Sharp C'.
> How could you render this in Owl/RDF?
As Chris said, the ontology does not restrict this, and you can
cumulate modifiers (although I guess the order may be important in the
S/S/F case? how could that be handled?).
Although the DCG running behind the symbol service does not handle the
grammar rule you mention for now :-(
(I am a bit too affraid someone would send a request for
Dsssssssssssssssss.... :) )
Cheers!
y
John Ibbotson
Hi Chris,
To elaborate on a couple of points:
Certainly there is a need for MIDI or some equivalent numbering of notes. Alternatives would include pitch class + octave which can always be calculated from the MIDI number. Another numbering system (which relies on the correct naming of a note) is Hewlett's base 40 numbering system see http://www.ccarh.org/publications/reprints/base40/ which allows correct intervals to be assigned between two notes. The example used in the paper is C#/Db to Bb. The same number of semitones exist between the notes, but C# to Bb is a diminished 7th whereas Db to Bb is a major sixth. It is fairly trivial to write inferencing rules to correctly name intervals using Jena to correctly name intervals given the correct base-40 numbers.
Regarding the comments on timelines, I used Allen's paper (Allen, J. F. (1983). "Maintaining knowledge about temporal intervals." Communications of the ACM 26(11): 832 - 843) as a starting point for the proof of concept idea I presented the other week. This gives a set of temporal relationships between events that can be applied to musical keys, chords and notes
Relation Symbol Symbol Pictoral
X before Y < > XXX YYY
X equal Y = = XXX
YYY
X meets Y M Mi XXXYYY
X overlaps Y O Oi XXX
YYY
X during Y D Di XXX
YYYYYYY
X starts Y S Si XXX
YYYYY
X finishes Y F Fi XXX
YYYY
I combined the last three relationships into a single "during" relationship with an inverse "contains" relationship so that chord "contains" note and inverse "note" during "chord". A more detailed look at this way of expressing temporal relationships may address Samer's comment.
Regards,
John
John Ibbotson CEng FIET
Senior Inventor
ITA and Provenance Projects, Emerging Technology Services
Hursley Park, MP137, Winchester, Hants. SO21 2JN, UK
Tel: +44 1962 815188
Mobile: +44 7739 876 196
Email: john_i...@uk.ibm.com
ITA: http://www.usukita.org
Provenance: http://www.gridprovenance.org
Technical Solutions to business problems that require innovation across IBM knowledge portfolio.
"If you torture data sufficiently it will confess to almost anything" Prof. Fred Menger
| Christopher Sutton <chris....@elec.qmul.ac.uk>
Sent by: music-ontology-sp...@googlegroups.com 26/10/2007 17:54
|
|
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
John Ibbotson
Attempted to correct the "graphics"
Relation Symbol Symbol Pictoral
X before Y < > XXX YYY
X equal Y = = XXX
YYY
X meets Y M Mi XXXYYY
X overlaps Y O Oi XXX
YYY
X during Y D Di XXX
YYYYYYY
X starts Y S Si XXX
YYYYY
X finishes Y F Fi XXX
YYYY
Regards,
John
John Ibbotson CEng FIET
Senior Inventor
ITA and Provenance Projects, Emerging Technology Services
Hursley Park, MP137, Winchester, Hants. SO21 2JN, UK
Tel: +44 1962 815188
Mobile: +44 7739 876 196
Email: john_i...@uk.ibm.com
ITA: http://www.usukita.org
Provenance: http://www.gridprovenance.org
Technical Solutions to business problems that require innovation across IBM knowledge portfolio.
"If you torture data sufficiently it will confess to almost anything" Prof. Fred Menger
| John Ibbotson/UK/IBM@IBMGB
Sent by: music-ontology-sp...@googlegroups.com 29/10/2007 09:48
|
|
marklevy
There are various traditional ways of describing chords. The ones I
know about are:
- functional harmony (IIb V I etc.), used from around 1800 to the
present
- figured bass, used from around 1600 to the present
Others that I know of are:
- jazz chord symobls, used from ? to the present
- guitar tab, used from ? to the present
No doubt there are lots more.
And there are broader notation systems which you can also use:
- MIDI
- western score notation
- anything else that can describe individual notes
It might be useful to relate the chord ontology to some of these, not
least because there is a mass of existing data in these formats.
Specifically, if we can't express chord sequences written in any of
the first four of these systems using the chord ontology then maybe we
have a problem. Arguably this should be stronger: we ought to be able
to convert chord sequences from these notations into rdf with an
automatic translation tool. Any thoughts on this?
Is there any pressing need for the ontology to go beyond traditional
chord notation systems - or is that the realm of notes and not chords
(I think this is Samer's point)?
Cheers,
Mark
On Oct 26, 4:54 pm, Christopher Sutton <chris.sut...@elec.qmul.ac.uk>
wrote:
> Hi Samer,
>
> Just to clarify on a couple of your points (need to think more about
> some of the others !)
>
> > On 10/26/07, * Christopher Sutton* <chris.sut...@elec.qmul.ac.uk
> > <mailto:chris.sut...@elec.qmul.ac.uk>> wrote:
>
> > Hi,
>
> > A few of us at C4DM have been working on an RDFS chord ontology for use
> > in our lab and are keen now to invite feedback and discussion from a
> > wider community.
>
> > The current specification is athttp://purl.org/ontology/chord/- this