Thoughts about the concepts of the MO, and mapping ID3 tags to MO data
Antoine Zimmermann
trying very hard to map ID3 tags to a RDF representation. I wish I
could use the Music Ontology, but I am stuck by several problems in
the conceptualisation of MO.
1) The concepts of Track and Album
In my opinion, there is a concept which encompasses Albums, EPs, Live
albums, Singles, Soundtracks, Compilation, Audiobooks. (which usually
can be bought as a single object, be it a CD, a 12" LP, a cassette, a
bunch of MP3 files, etc.)
In terms of ID3 tags, an instance of this concept has its name put in
the ALBUM tag.
In the MO, it roughly corresponds to a Record with a specific
ReleaseType (like album, live, soundtrack, audiobook).
This concept is not equivalent to Record because Record is any thing
that is the product of a Recording, e.g., a Track in an Album, or the
first half of a recorded Live.
To me, this concept (which I will subsequently call "Album") is a
distinct thing. It is clearly a subclass of a Record. But in addition,
it is characterised by other properties. In particular, it is named,
i.e., it can be identified by common people. And most importantly, it
is subdivided into Tracks. Tracks are Records too, and are
identifiable by their names too. But Tracks are not Albums. I would
even say that they are disjoint, even though a track length can
coincide with the album length. Albums are not temporal, nor physical.
They shall not be confused with the performance which leads to their
production (e.g., studio recording happening in a limited portion of
space and time), nor with the physical objects which contain them
(e.g., a CD album, which lasts until it is destroyed). An instance of
this concept exists from the time of its recording, and cannot be
undone.
So my view of the classification is the following:
The so-called concept "Album" (for lack of a better name) is a
subclass of a Record which has an "albumName" and which "has tracks".
Track is a subclass of a Record and it has a "trackTitle".
Note that there are "Untitled" albums and tracks. But they are usually
named anyway (like "the black album" by Metalica, the "Nothing Song"
by Sigur Rós, etc).
A Track is not necessarily part of an Album.
Albums and Tracks are disjoint classes.
Moreover, an album can be physically represented by an objet, while a
track cannot. Even if there is only one track on a CD, the CD does not
represent the track, but the album or the single. The CD cover is
attached to the album or single, not to the track. (it could be argued
that an MP3 file physically represents a track. Well, in some sense
yes, but I would consider Track and Album disjoint anyway).
2) The concept of "Song"
I was trying to figure out how to connect the lyrics of a song to the
given song, when I realised that there is no concept for Songs. In
fact, there is a need for a new concept, which is not temporal, not
physical and not a Record. Something which specifies how instruments,
voice, musical notes, lyrics must be arranged in order to produce a
Performance for a Track. Its serves as a specification to make a track
or to make a live performance of the track.
This concept allows recognising the song "Sunday Bloody Sunday" by U2
as one entity, although there exist several tracks on several albums
for this song. The lyrics of Sunday Bloody Sunday should be attached
to that entity, not to the specific tracks. Let us call this concept
"Song" (for lack of a better name).
A Song is a MusicalExpression. But not any musical expression. Usually
(but not always) Tracks are the manifestation of a Song. It is
difficult to define the concept of Song well because they are
sometimes very loosely specified (no lyrics, no score).
3) The concept of Release
A Release is distinct from an album, and distinct from the physical
object representing the album. A Release is always a "release of" an
album, but is has a specific physical form (it can be a CD release, or
a cassette release, etc). A Release has also a release date and a
label. It is not, however, a physical objects, because it does not
have a physical location and lifetime. It is not temporal.
It is probably a subclass of a MusicalManifestation (perhaps a
Record), but it is disjoint with Tracks and Albums.
4) dates
There are several dates that can be attached to these concepts. An
Album is recorded at a given time, in a given time interval. This is
perfectly rendered by the MO thanks to the Event "Recording". It can
have several dates of release (release as a CD Album, as a 12" album,
re-release), so the release date should be attached to the concept
Release. Sometimes, albums are re-released, but this should be, I
believe, another Release.
5) Summary
This is a summary of how to map ID3 tags to RDF, using a modified
music ontology with the concepts described above:
ARTIST is mapped into an instance of mo:MusicArtist
ALBUM is mapped into an instance of Album described above; the Album
and Artist are connected with properties "foaf:made/maker"
TITLE is mapped into an instance of Track described above; the Album
and Track are connected with property "has_track"
YEAR is mapped into the dc:date of an anonymous Release (if more
information can determine the exact release, e.g., first CD release,
the release could be identified); a Release could also have a special
property "releaseDate"
GENRE is mapped into an instance of mo:Genre, which is connected to
the Track via mo:genre
if there are lyrics in the ID3 tags, then they are mapped to an
instance of mo:Lyrics, and it is connected to an instance of a Song,
connected to the Track.
COMPOSER is mapped into an instance of mo:MusicArtist, and connected
to the Track with mo:composer
COMMENT is mapped into rdf:comment attached to the tags.
There are cases when the this mapping is not appropriate. If the album
is a compilation, then the artist is not the album artist, but the
track artist. If the track is precisely tagged, it can be mentionned
with a tag called "ALBUMARTIST", which can differ from the ARTIST tag.
Many other tags can be set with version 2 of ID3. They could be used
to make the translation more precise.
---
Final words: although I sometime peremptorily say "this is that", I am
not opposed to diverging points of view. It is just easier for me to
write things like that.
Yves Raimond
> trying very hard to map ID3 tags to a RDF representation. I wish I
> could use the Music Ontology, but I am stuck by several problems in
> the conceptualisation of MO.
>
>
> 1) The concepts of Track and Album
>
>
> In my opinion, there is a concept which encompasses Albums, EPs, Live
> albums, Singles, Soundtracks, Compilation, Audiobooks. (which usually
> can be bought as a single object, be it a CD, a 12" LP, a cassette, a
> bunch of MP3 files, etc.)
> In terms of ID3 tags, an instance of this concept has its name put in
> the ALBUM tag.
>
> In the MO, it roughly corresponds to a Record with a specific
> ReleaseType (like album, live, soundtrack, audiobook).
>
> This concept is not equivalent to Record because Record is any thing
> that is the product of a Recording, e.g., a Track in an Album, or the
> first half of a recorded Live.
Not really. I agree the chosen terminology is confusing here. But a
mo:Record is a frbr:Manifestion - an edited version of a particular
master signal, if you want. The mo:Recording you mention produces a
signal (see flowchart in the spec). A particular record can have a
particular release-type.
So your notion of an album is the same as mo:Record.
Just to sum up this particular bit of MO, in the most common case:
mo:Signal ----mo:published_as---> mo:Record (eg. LP of white album)
---mo:available_as---> <my LP> or <my MP3 rip>.
The Recording bit is before the Signal.
>
> To me, this concept (which I will subsequently call "Album") is a
> distinct thing. It is clearly a subclass of a Record. But in addition,
> it is characterised by other properties. In particular, it is named,
> i.e., it can be identified by common people. And most importantly, it
Again, a Record is named as well.
<http://zitgist.com/music/record/c7465f57-1908-4b72-88e6-0d1d87992453>
dc:title "Like a Virgin".
I think you think ( :-) ) that a mo:Record is what in fact is a mo:Signal.
Again, I agree the terminology is confusing, and we definitely need to
make a better documentation for that side of things.
> is subdivided into Tracks. Tracks are Records too, and are
> identifiable by their names too. But Tracks are not Albums. I would
> even say that they are disjoint, even though a track length can
> coincide with the album length. Albums are not temporal, nor physical.
> They shall not be confused with the performance which leads to their
> production (e.g., studio recording happening in a limited portion of
> space and time), nor with the physical objects which contain them
> (e.g., a CD album, which lasts until it is destroyed). An instance of
> this concept exists from the time of its recording, and cannot be
> undone.
So if I translate it in the terms above, I think you mean that the statement:
mo:Track rdfs:subClassOf mo:Record.
is wrong. (I don't remember if it still there, btw). I don't have
particularly strong opinions on that.
Am I right?
>
> So my view of the classification is the following:
> The so-called concept "Album" (for lack of a better name) is a
> subclass of a Record which has an "albumName" and which "has tracks".
> Track is a subclass of a Record and it has a "trackTitle".
Hmm... So what is the difference with what is currently in MO? It is
true that we rely on external vocabulary for titles (DC), do you mean
we should put some equivalentProperty in MO?
Again, a mo:Record is what you mean by :Album. Example instances are
"J. S. Bach's Six suites for unaccompanied cello performed by Yo-Yo
Ma, released on 33 1/3 rpm sound discs in 1983 by CBS Records"
or
"J. S. Bach's Six suites for unaccompanied cello performed by Yo-Yo
Ma, re-released on compact disc in 1992 by CBS Records"
Both corresponds to the same mo:Signal.
>
> Note that there are "Untitled" albums and tracks. But they are usually
> named anyway (like "the black album" by Metalica, the "Nothing Song"
> by Sigur Rós, etc).
>
> A Track is not necessarily part of an Album.
In this case, you mean a mo:Signal. True, a mo:Signal is not
necessarily part of an album. However, a mo:Track is defined as such.
A mo:Track is a particular track on a particular album.
>
> Albums and Tracks are disjoint classes.
>
> Moreover, an album can be physically represented by an objet, while a
> track cannot. Even if there is only one track on a CD, the CD does not
> represent the track, but the album or the single. The CD cover is
> attached to the album or single, not to the track. (it could be argued
> that an MP3 file physically represents a track. Well, in some sense
> yes, but I would consider Track and Album disjoint anyway).
>
A Track can be related to a particular item (in FRBR terminology) -
for example your MP3 file. Or this particular part of your magnetic
tape.
>
> 2) The concept of "Song"
>
>
> I was trying to figure out how to connect the lyrics of a song to the
> given song, when I realised that there is no concept for Songs. In
> fact, there is a need for a new concept, which is not temporal, not
> physical and not a Record. Something which specifies how instruments,
> voice, musical notes, lyrics must be arranged in order to produce a
> Performance for a Track. Its serves as a specification to make a track
> or to make a live performance of the track.
There is. It is called mo:MusicalWork (again, related to the concept
of Work in FRBR). There is even a work-in-progress extension of MO to
describe musical works in a symbolic fashion
(http://purl.org/ontology/mo/symbolic-music).
>
> This concept allows recognising the song "Sunday Bloody Sunday" by U2
> as one entity, although there exist several tracks on several albums
> for this song. The lyrics of Sunday Bloody Sunday should be attached
> to that entity, not to the specific tracks. Let us call this concept
> "Song" (for lack of a better name).
>
Yep, you definitely mean mo:MusicalWork here :-)
> A Song is a MusicalExpression. But not any musical expression. Usually
> (but not always) Tracks are the manifestation of a Song. It is
> difficult to define the concept of Song well because they are
> sometimes very loosely specified (no lyrics, no score).
>
No, a song is a MusicalWork. Why would it be a mo:MusicalExpression?
(see the examples in the spec, or in FRBR).
>
> 3) The concept of Release
>
>
> A Release is distinct from an album, and distinct from the physical
> object representing the album. A Release is always a "release of" an
> album, but is has a specific physical form (it can be a CD release, or
> a cassette release, etc). A Release has also a release date and a
> label. It is not, however, a physical objects, because it does not
> have a physical location and lifetime. It is not temporal.
> It is probably a subclass of a MusicalManifestation (perhaps a
> Record), but it is disjoint with Tracks and Albums.
Agreed. We need to do something for that. This is added to the todo list.
>
>
> 4) dates
>
>
> There are several dates that can be attached to these concepts. An
> Album is recorded at a given time, in a given time interval. This is
> perfectly rendered by the MO thanks to the Event "Recording". It can
> have several dates of release (release as a CD Album, as a 12" album,
> re-release), so the release date should be attached to the concept
> Release. Sometimes, albums are re-released, but this should be, I
> believe, another Release.
Same.
>
>
> 5) Summary
>
>
> This is a summary of how to map ID3 tags to RDF, using a modified
> music ontology with the concepts described above:
> ARTIST is mapped into an instance of mo:MusicArtist
> ALBUM is mapped into an instance of Album described above; the Album
> and Artist are connected with properties "foaf:made/maker"
> TITLE is mapped into an instance of Track described above; the Album
> and Track are connected with property "has_track"
> YEAR is mapped into the dc:date of an anonymous Release (if more
> information can determine the exact release, e.g., first CD release,
> the release could be identified); a Release could also have a special
> property "releaseDate"
> GENRE is mapped into an instance of mo:Genre, which is connected to
> the Track via mo:genre
> if there are lyrics in the ID3 tags, then they are mapped to an
> instance of mo:Lyrics, and it is connected to an instance of a Song,
> connected to the Track.
> COMPOSER is mapped into an instance of mo:MusicArtist, and connected
> to the Track with mo:composer
You may want to put that as the maker of a particular work. Track is
not in the range/domain of composer.
Cheers, and thanks for all that! Btw, could you add a summary of your
comments to the Wiki http://wiki.musicontology.com/ ?
y
Antoine Zimmermann
mo:Signal, not a mo:Record.
And what I called Release is in fact a mo:Record.
1) The concepts
a) Albums
Informally, we have the word album which designates 3 different
notions.
The album as the result of a recording of a music performance (or
rather, several performances put together). This is independent from
the medium (CD, cassette, MP3).
Its characteristics are its recording time, its name, the artists and/
or technicians who participated in its making. It is independant from
any commercial attributes, it is intemporal, nor physical.
So, it is a mo:Signal. But what I wanted to say from the beginning is
that there is no such concept in the MO. mo:Signal is too general. Let
us call it the AlbumSignal
There is also the album as a release, which characteristics are the
AlbumSignal which it contains, the medium (CD, cassette, etc), the
release date, the pictures of the folder, the technicians and artists
who designed the booklet, etc. This is equivalent to mo:Record, as far
as I understand now. It is not temporal or physical. An instance of it
cannot be hold in one's hands.
There is the physical album as an object that can be purchased and
hold, characteristics of which are the mo:Record which it
materializes, the price, the physical location, the owner, the
condition, etc. It is a mo:MusicItem. This cannot be sold in smaller
part in the physical world (as opposed to the digital world, see
below).
b) Tracks
Then, there is three corresponding concepts for the informal notion of
tracks.
The abstract track as a part of the SignalAlbum. This concept is
distinct from the concept of SignalAlbum, but it is also a mo:Signal.
SignalAlbums contain tracks, but tracks can exist independently from
albums. Let us call it SignalTrack.
There is the release track, identifying the exact encoding of the
track in a mo:Record, and the index of the track (for instance track 9
on a CD, or track B4 on a 12" LP). This may be equivalent to mo:Track,
but I still argue that it should be disjoint from mo:Record. It should
be a subclass of mo:MusicalManifestation.
There is the physical track, present on a part of a mo:MusicItem, or
in a particular audio file on some hard disk or portable media player.
This is the smallest portion of music that can be sold digitally. It
cannot be sold in the physical world alone, i.e., without a physical
album release, i.e., out of a mo:Record.
Remark: a mo:Record of an AlbumSignal can contain tracks which are not
parts of the SignalTrack of the original SignalAlbum. This happens
when albums are re-released.
c) What corresponds to id3:ALBUM?
My concern is about how to map ID3 tags to the MO. The question is
what id3:ALBUM should be mapped to? My hypothesis is that it should be
the abstract Album concept I described above. An MP3 file usually does
not come from an MP3 release. It is most often the product of a CD
ripping. But the problem is that it is very frequent that you cannot
identify whether it was ripped, bought online, downloaded, etc. So,
finally, you cannot identify the actual release associated to an MP3
file. Moreover, when it comes to sharing the audio file information,
you do not want to tell that "Sunday Bloody Sunday" is a track from a
vinyl record.
However, you need to have a RDF resource for a Release associated with
this abstract Album, when the release date is present in the id3 tags.
Same for the tracks: the ID3 tags identify an abstract track,
independent from the support. There can be an additional resource for
the released track in order to tell the index of the track on the
particular release.
d) Lyrics and songs
Now, the Lyrics. They are not a characteristic of a track. They are a
characteristic of a Song, which can be recorded as many different
tracks, from different performances.
What I call a Song also includes the Score of instrumental music. The
score, the lyrics, the arrangement of instruments etc, that can are
used to reproduce several performance of the same title. The recording
of a performance of a song, leads to a Track. In some sense, tracks
instantiate songs. But a track can also be independent from a song
(e.g., improvisation or random noise). The Song is a product of
artists, not of technicians (contrary to Tracks).
Songs are probably mo:MusicalWork. Probably it is equivalent.
e) Summary
This how I would reorganise the concepts (in fact, not much change to
the MO)
Class AlbumSignal subClassOf mo:Signal
Class TrackSignal subClassOf mo:Signal
AlbumSignal disjoint TrackSignal
Property has_track (domain AlbumSignal; range TrackSignal)
Property has_album (domain mo:Record; range AlbumSignal) subPropertyOf
mo:publication_of, functionalProperty
mo:Track subClassOf mo:MusicalManifestation
mo:Track disjoint mo:Record
Property indexed_track (domain mo:Track; range TrackSignal)
subPropertyOf mo:publication_of
2) My view of the work flow
There are several mo:MusicalWorks. They are used to make
mo:Performances which are recorded into TrackSignal(1), ...,
TrackSignal(n). These signals can be already commercialised as
AudioFiles on the Web. These TrackSignals are wrapped up in an
AlbumSignal. This AlbumSignal is commercialised as a mo:Record on a
particular medium at a particular time. It can be released several
times on several media.
What do you think? Does it make sense?
3) The mapping
Accroding to that, the ID3 tags are mapped to (my version of) MO like
this:
Each MP3 file creates an anonymous mo:MusicalWork
ARTIST --> mo:MusicArtist attached to the mo:MusicalWork
ALBUM --> AlbumSignal
TITLE --> TrackSignal, connected to the AlbumSignal and the
mo:MusicalWork
GENRE --> Genre (of the MusicalWork? or SignalTrack?)
YEAR --> a date associated with an anonymous resource of type
mo:Record (can possibly be desanonymised with additional information)
TRACKNUMBER --> a number attached to an anonymous mo:Track which
refers to the TrackSignal
LYRICS --> mo:Lyrics connected to the mo:MusicalWork
COMPOSER --> mo:Composer
Remark2: mo:track_number must be an integer. What are we supposed to
do with vinyl with A sides and B sides? The tags TRACKNUMBER can
contain any character string like A3 or even 09/12.
Yves Raimond
> Ok, so in fact, I believe that what I called Album is in fact a
> mo:Signal, not a mo:Record.
> And what I called Release is in fact a mo:Record.
>
>
> 1) The concepts
>
>
> a) Albums
>
> Informally, we have the word album which designates 3 different
> notions.
>
> The album as the result of a recording of a music performance (or
> rather, several performances put together). This is independent from
> the medium (CD, cassette, MP3).
> Its characteristics are its recording time, its name, the artists and/
> or technicians who participated in its making. It is independant from
> any commercial attributes, it is intemporal, nor physical.
> So, it is a mo:Signal. But what I wanted to say from the beginning is
> that there is no such concept in the MO. mo:Signal is too general. Let
> us call it the AlbumSignal
Ok! I was thinking of MasterSignal for this concept, to be more
aligned with the in-progress Musicbrainz schema. What do you think?
>
> There is also the album as a release, which characteristics are the
> AlbumSignal which it contains, the medium (CD, cassette, etc), the
> release date, the pictures of the folder, the technicians and artists
> who designed the booklet, etc. This is equivalent to mo:Record, as far
> as I understand now. It is not temporal or physical. An instance of it
> cannot be hold in one's hands.
>
> There is the physical album as an object that can be purchased and
> hold, characteristics of which are the mo:Record which it
> materializes, the price, the physical location, the owner, the
> condition, etc. It is a mo:MusicItem. This cannot be sold in smaller
> part in the physical world (as opposed to the digital world, see
> below).
>
>
> b) Tracks
>
> Then, there is three corresponding concepts for the informal notion of
> tracks.
>
> The abstract track as a part of the SignalAlbum. This concept is
> distinct from the concept of SignalAlbum, but it is also a mo:Signal.
> SignalAlbums contain tracks, but tracks can exist independently from
> albums. Let us call it SignalTrack.
>
> There is the release track, identifying the exact encoding of the
> track in a mo:Record, and the index of the track (for instance track 9
> on a CD, or track B4 on a 12" LP). This may be equivalent to mo:Track,
> but I still argue that it should be disjoint from mo:Record. It should
> be a subclass of mo:MusicalManifestation.
Subclassing of MusicalManifestation is inherited from the current
axiom mo:Track subClassOf mo:Record.
I agree it doesn't make any particular sense (and is weird from an
ontoclean point of vue), so I suggest, as you say, that we delete this
subClass axiom and we add:
mo:Track rdfs:subClassOf mo:MusicalManifestation.
In that case, disjointness would be ok (we do have to explicit quite a
lot of other disjoint subclassing in MO, as well).
>
> There is the physical track, present on a part of a mo:MusicItem, or
> in a particular audio file on some hard disk or portable media player.
> This is the smallest portion of music that can be sold digitally. It
> cannot be sold in the physical world alone, i.e., without a physical
> album release, i.e., out of a mo:Record.
>
> Remark: a mo:Record of an AlbumSignal can contain tracks which are not
> parts of the SignalTrack of the original SignalAlbum. This happens
> when albums are re-released.
>
Indeed. It is also true for simultaneous releases in different
countries, with different track lists etc.
>
> c) What corresponds to id3:ALBUM?
>
> My concern is about how to map ID3 tags to the MO. The question is
> what id3:ALBUM should be mapped to? My hypothesis is that it should be
> the abstract Album concept I described above. An MP3 file usually does
> not come from an MP3 release. It is most often the product of a CD
> ripping. But the problem is that it is very frequent that you cannot
> identify whether it was ripped, bought online, downloaded, etc. So,
> finally, you cannot identify the actual release associated to an MP3
> file. Moreover, when it comes to sharing the audio file information,
> you do not want to tell that "Sunday Bloody Sunday" is a track from a
> vinyl record.
> However, you need to have a RDF resource for a Release associated with
> this abstract Album, when the release date is present in the id3 tags.
As you say, most mp3s have been ripped from actual releases, or bought
on iTunes and the such. With that in mind, I think it would be ok
(this is what we do in GNAT, for example) to make it quite simply,
just focusing on the purely editorial part. Here is an example:
$ eyeD3 01\ -\ Lie\ To\ Me.mp3
01 - Lie To Me.mp3 [ 4.96 MB ]
--------------------------------------------------------------------------------
Time: 2:10 MPEG1, Layer III [ 320 kb/s @ 44100 Hz - Stereo ]
--------------------------------------------------------------------------------
ID3 v2.2:
title: Lie To Me artist: Tom Waits
album: Orphans: Brawlers, Bawlers & Bastards [disc one {Brawlers}] year: 2006
track: 1/16 genre: Alternative (id 20)
would be translated as:
:lie_to_me a mo:Track; dc:title "Lie To Me"; mo:available_as
<file:///Music/01\ -\ Lie\ To\ Me.mp3 >; mo:track_number "1".
:brawlers a mo:Record; dc:title "Orphans: Brawlers, Bawlers & Bastards
[disc one {Brawlers}]"; mo:track :lie_to_me; dc:date
"2006"^^xsd:gYear; mo:genre <http://example.org/id3genre/20>.
:tom a mo:MusicArtist; dc:title "Tom Waits"; foaf:maker :brawlers.
Notice the voluntary "mistake" for the disc number. Indeed, we need
more properties to "locate" tracks on records, as the record should
probably be the set of 3 CDs. (This relates to the concept of
"Package" in the new Musicbrainz schema, as well). But in ID3, can you
actually access such information (apart from encoding it in the album
tag)?
So I guess my main comment would be: keep it simple :-) I don't think
it is necessary to go into distinctions that can't be handled
completely in ID3 for this mapping.
>
> Same for the tracks: the ID3 tags identify an abstract track,
> independent from the support. There can be an additional resource for
> the released track in order to tell the index of the track on the
> particular release.
I would argue as above. Keep it simple :-)
>
>
> d) Lyrics and songs
>
> Now, the Lyrics. They are not a characteristic of a track. They are a
> characteristic of a Song, which can be recorded as many different
> tracks, from different performances.
> What I call a Song also includes the Score of instrumental music. The
> score, the lyrics, the arrangement of instruments etc, that can are
> used to reproduce several performance of the same title. The recording
> of a performance of a song, leads to a Track. In some sense, tracks
> instantiate songs. But a track can also be independent from a song
> (e.g., improvisation or random noise). The Song is a product of
> artists, not of technicians (contrary to Tracks).
> Songs are probably mo:MusicalWork. Probably it is equivalent.
>
Indeed. To go to the ID3v2 tags such as performer and composer, you
need to go one step further. I guess you need two things: Performance
and MusicalWork. composer is attached to the musical work, performer
to the performance. It therefore precise what we mean by "foaf:maker"
in the above example.
>
> e) Summary
>
> This how I would reorganise the concepts (in fact, not much change to
> the MO)
>
> Class AlbumSignal subClassOf mo:Signal
Ok - what about MasterSignal here?
> Class TrackSignal subClassOf mo:Signal
> AlbumSignal disjoint TrackSignal
> Property has_track (domain AlbumSignal; range TrackSignal)
Can't we reuse mo:track for that?
> Property has_album (domain mo:Record; range AlbumSignal) subPropertyOf
> mo:publication_of, functionalProperty
> mo:Track subClassOf mo:MusicalManifestation
> mo:Track disjoint mo:Record
> Property indexed_track (domain mo:Track; range TrackSignal)
Hmm. indexed_track is a bit confusing - what about track_signal?
> subPropertyOf mo:publication_of
>
>
> 2) My view of the work flow
>
>
> There are several mo:MusicalWorks. They are used to make
> mo:Performances which are recorded into TrackSignal(1), ...,
> TrackSignal(n). These signals can be already commercialised as
> AudioFiles on the Web. These TrackSignals are wrapped up in an
> AlbumSignal. This AlbumSignal is commercialised as a mo:Record on a
> particular medium at a particular time. It can be released several
> times on several media.
>
> What do you think? Does it make sense?
Yep, it makes perfect sense :-)
>
>
> 3) The mapping
>
>
> Accroding to that, the ID3 tags are mapped to (my version of) MO like
> this:
> Each MP3 file creates an anonymous mo:MusicalWork
> ARTIST --> mo:MusicArtist attached to the mo:MusicalWork
ARTIST in Id3 is very vague. Better to just use it as a foaf:maker, as
above. You don't know if the artist is the composer, the performer,
both, the arranger, etc.
> ALBUM --> AlbumSignal
As in my example above, I'd map that to a released mo:Record. Unless
you want to cross-reference several releases of this album within your
collection (which I am not sure it is feasible using solely Id3 info,
is it?)
> TITLE --> TrackSignal, connected to the AlbumSignal and the
> mo:MusicalWork
As in my example, above, I'd simply map that to a dc:title on a mo:Track.
> GENRE --> Genre (of the MusicalWork? or SignalTrack?)
I'd associate that with the mo:Track, as above, just for the sake of
simplicity. However, it is arguable, but this maps more closely to
ID3.
> YEAR --> a date associated with an anonymous resource of type
> mo:Record (can possibly be desanonymised with additional information)
As above, a dc:date on the record?
> TRACKNUMBER --> a number attached to an anonymous mo:Track which
> refers to the TrackSignal
> LYRICS --> mo:Lyrics connected to the mo:MusicalWork
Or the performance (eg. if the lyrics were written in a different
context?). But same thing: I am not sure ID3 allows this distinction,
so it might be useless.
> COMPOSER --> mo:Composer
>
Yep, attached to the musical work
>
> Remark2: mo:track_number must be an integer. What are we supposed to
> do with vinyl with A sides and B sides? The tags TRACKNUMBER can
> contain any character string like A3 or even 09/12.
>
Good point - I tried to illustrate it in my example above. We need
more ways of locating a track on a record.
I'll add all that on the Wiki
Cheers, and thanks for all that!
y
>
> >
>