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 !
On 26/10/2007, Christopher Sutton <chris.sut...@elec.qmul.ac.uk> wrote:
> 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.
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.
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 :-)
> 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.
This looks good. Re suggested future extensions, I think most of them belong outside the chord ontology. Specifically:
- 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.
- Explicitly specify whether chords are descriptive or prescriptive (ie. transcription vs. score)
This is a function of the context in which the chord description is used, not the chord description 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 ?
This risks blurring the distinctions between levels of description that we seek to clarify by 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)
Totally agree with this, but again, at the risk of stating the obvious, it belongs in the time ontology 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.
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.
cheers, Samer
On 10/26/07, Christopher Sutton <chris.sut...@elec.qmul.ac.uk> wrote:
> 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 !
Danny Ayers wrote: > 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 !
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 :)
>> 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...
On 26/10/2007, Danny Ayers <danny.ay...@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.
Is it possible to specify multiple sharps or flats? 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:
Just to clarify on a couple of your points (need to think more about some of the others !)
seventy3inc...@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 ?
> 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 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.
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.
seventy3inc...@googlemail.com wrote: > Is it possible to specify multiple sharps or flats? > 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:
> 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:
> 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.... :) )
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
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.sut...@elec.qmul.ac.uk> Sent by: music-ontology-specification-group@googlegroups.com 26/10/2007 17:54 Please respond to music-ontology-specification-group@googlegroups.com
To music-ontology-specification-group@googlegroups.com cc
Subject "absolute" note pitches (was "The OMRAS2 Chord Ontology, first draft")
Hi Samer,
Just to clarify on a couple of your points (need to think more about some of the others !)
seventy3inc...@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 ?
> 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 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 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
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
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
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-specification-group@googlegroups.com 29/10/2007 09:48 Please respond to music-ontology-specification-group@googlegroups.com
To music-ontology-specification-group@googlegroups.com cc
Subject Re: "absolute" note pitches (was "The OMRAS2 Chord Ontology, first draft")
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
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.sut...@elec.qmul.ac.uk> Sent by: music-ontology-specification-group@googlegroups.com 26/10/2007 17:54
Please respond to music-ontology-specification-group@googlegroups.com
To music-ontology-specification-group@googlegroups.com cc
Subject "absolute" note pitches (was "The OMRAS2 Chord Ontology, first draft")
Hi Samer,
Just to clarify on a couple of your points (need to think more about some of the others !)
seventy3inc...@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 ?
> 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 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 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
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
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
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:
> Just to clarify on a couple of your points (need to think more about > some of the others !)
> seventy3inc...@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.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 > > 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.
|
