First round of revisions (Music Ontology)
Frederick Giasson
This is the first round of revisions of the ontology (after only one day, wow!)
I am really happy to see the enthusiasm of everybody about that new ontology.
so:
1. mo:Artist revision
2. mo:Album revision
3. Linking revision
4. mo:image revision
5. Labels
6. OWL cardinality
7. Music Genres
8. mo:bpm
9. mo:instrument
=====================
1. mo:Artist revision
=====================
Alex suggest to:
---
mo:Artist rdfs:subClassOf foaf:Agent
---
By doing this, one could reuse all the FOAF ontology, the BIO ontology, etc.
Then he suggest to create subclasses out of mo:Artist like:
---
mo:SoloArtist rdfs:subClassOf mo:Artist
mo:Band rdfs:subClassOf mo:Artist
---
He args that adding them would be useful for querying the RDF graph. I agree
with him naturally.
Then I would add:
---
mo:Band rdfs:subClassOf foaf:Group
---
That way, we could delete the mo:member_of property and use the foaf:member
property directly into a mo:Band instance since it is a subclass of foaf:Group.
This bring another question. If we take a look at the mo:published property's
description, we can read:
---
published - Indicates the artist that published an album or a track. The artist
is generally an organization that manufactures (or contracts out manufacturing),
distributes (or contracts out distribution) and promotes (or contracts out
promotion). They are usually the largest company that deals with a particular
recording. Note that this is usually distinct from the label, which might be an
independent organization but is also frequently one of many brands used by a
publisher to promote their catalogue.
---
This suppose that an Artist can also be a publisher and that a publisher can be
a Label.
David Sheet also proposed to add a "label" property and a "label catalog number"
property or something like that.
So what I would propose is to use that method and to create a new mo:Label class:
---
mo:Label rdfs:subClassOf mo:Artist
---
That way, we could specify that the mo:publisher is a Label. We could always
have the possibility to say that a mo:SoloArtist also mo:published something, etc.
Also, we could create:
---
mo:catalog_number
domain: mo:Label
---
Finally I think that this proposition of Alex is great and this method would
easily let us upgrading the ontology later.
=====================
=====================
2. mo:Album revision
=====================
Alex suggest to change:
---
mo:Artist
for
mo:Release
---
or something like that. He arg that mo:Album is not just an aggregation of a
couple of tracks.
I agree with him. One can release something: an album, an interview, etc. So,
mo:Release is probably more suitable than mo:Album as the superclass of all
mo:Type subclasses of the ontology.
Alex and David suggested to create a sort of mo:release_type property to specify
things like: this release is published on a MaxiCD, a vynil, etc.
However, I would suggest to create classes:
---
mo:Medium (superclass)
mo:CD (rdfs:subClassOf mo:Medium)
mo:Vynil (rdfs:subClassOf mo:Medium)
etc.
---
This method would follow the method used to specify the mo:Type and the
mo:Status of the current mo:Album (mo:Release).
We would assign the medium with which an album is published to a mo:Album
(mo:Release) instance using rdf:type.
We could even create classes like mo:Stream (live web stream) etc.
Also, David suggested that it would be important to describe the encoding of a
medium (MP3 CBR @ 128kbps, OGG @ 160kbps, FLAC, etc)
So, what I would suggest is to create:
---
mo:encoding
domain: mo:Medium
range: #Literal
---
NOTE: I am not sure about the range:#Literal. Since people could write anything
in a literal, it would be a pain to make something matching an Encoding Literal
in SPARQL. So we should think about creating Classes of Encoding Type. Not sure
what to do here.
Finally, a release would look like something like this:
---
<mo:Release
rdf:about="http://mm.Music.org/album/65f4f0c5-ef9e-490c-aee3-909e7ae6b2ab">
<dc:title>Harvester of Sorrow</dc:title>
<dc:creator
rdf:resource="http://mm.Music.org/artist/65f4f0c5-ef9e-490c-aee3-909e7ae6b2ab"/>
<dcterms:created>1988-01-01T00:00:00Z</dcterms:created>
<rdf:type rdf:resource="http://purl.org/ontology/mo/Single" />
<rdf:type rdf:resource="http://purl.org/ontology/mo/Official" />
<rdf:type rdf:resource="http://purl.org/ontology/mo/CD" />
<mo:encoding rdf:resource="http://purl.org/ontology/mo/MP3_CBR_128kbps" />
...
</mo:Release>
---
Another way could be
---
<mo:Release
rdf:about="http://mm.Music.org/album/65f4f0c5-ef9e-490c-aee3-909e7ae6b2ab">
...
<mo:medium rdf:parseType="Resource">
<rdf:type rdf:resource="http://purl.org/ontology/mo/CD" />
<mo:encoding
rdf:resource="http://purl.org/ontology/mo/MP3_CBR_128kbps" />
</mo:link>
...
</mo:Release>
---
I'll need more input from you to decide which method to use (if any).
=====================
=====================
3. Linking revision
=====================
How to do the Linking of objects to URL?
Right now the method used is simple. I simply created a list of properties to
link to a web page using the URL.
The result is the list of linkto_XXXX properties.
However this method is not that beautiful and will be eventually difficult to
maintain when the ontology will evolve later.
Method #1
---------
I talked about this issue with DanC on #swig and there is what he had to say
about it:
[11:44] DanC: I suggest using foaf:primaryTopic rather than linkto_wikipedia
[11:44] DanC: maybe make a class for WikipediaArticle
[11:44] fgiasson: DanC: yeah, but the domain is a foaf:Document
[11:44] DanC: flip it around
[11:45] DanC: i.e. use [ owl:inverseOf foaf:primaryTopic ]. I think they
actually give it a name: foaf:isPrimaryTopicOf
[11:45] DanC: my point is: the relationship between an artist and a wikipedia
article about the artist isn't specific to wikipedia
However, adding one more level of relationship (foaf:Document) is not necessarly
good in the point of view of the queries against the RDF graph.
However, this lead to the possible method #2
Method #2
---------
This method consist in creating a mo:linkto property that act as a linking
resource. Then, we specify that this linking resource if of type
WikipediaArticle (instead of using mo:linkto_wikipedia). And then, we add a
property mo:url to specify the URL of the link.
<mo:Artist
rdf:about="http://mm.musicbrainz.org/artist/65f4f0c5-ef9e-490c-aee3-909e7ae6b2ab">
...
<mo:linkto rdf:parseType="Resource">
<rdf:type rdf:resource="http://purl.org/ontology/mo/WikipediaArticle" />
<mo:url rdf:resource="http://wikipedia.org/The_Wikipedia_Article" />
</mo:linkto>
...
</mo:Artist>
This method could be queried something like this:
PREFIX mo: <http://purl.org/ontology/mo/>
SELECT ?linkto_url
WHERE
{
<http://mm.musicbrainz.org/album/a89e1d92-5381-4dab-ba51-733137d0e431>
mo:has_track ?track.
?artist a mo:Artist;
mo:linkto ?linkto.
?linkto a <mo:WikipediaArticle>;
mo:url ?linkto_url.
}
This is less straightforward, however we could possibly have some advantages
using such a method. By example, we could think about other type of link than
mo:url.
However, Alex Passant doesn't really like that method considering that it would
create many "virtual" classes. He is proposing the method #3 instead.
Method #3
---------
This method is proposed by Alex and it consist of:
1- creating a mo:linkto super-property.
2- creating multiple mo:wikipedia, mo:musicmoz, etc. that would be
rdfs:subPropertyOf the mo:linkto super-property.
The advantage is that people could create their own subPropertyOf mo:linkto to
fill their own purposes.
In that case, I would just modify the name of the current linkto_XXXX
properties, and I would change the RDFS accordingly to the new super mo:linkto
property.
Alex's method #3 make sense. We would have to check if there is advantages of
using method #2 instead of method #3.
Otherwise, does anyone have another idea about how to describe these type of links?
=====================
=====================
4. mo:Image revision
=====================
Alex suggest to remove the mo:image property and to use foaf:depiction instead.
Yeah sure. In fact, if we agree that mm:Artist is a subclass of foaf:Agent, then
we will be able to use all of the foaf:properties.
so mo:image and mo:member_of would be deleted from the ontology.
=====================
=====================
5. Labels
=====================
Alex said in a previous email:
---
Would be useful to link each Release (and maybe Artists) to its label,
using linkto_label (to get the same naming convention).
I think a Label class is appropriate, to get additional information
about the label (creation date, involved people, maybe also links and
affiliations between labels). Maybe also as a subclass of foaf:Agent ?
---
I would report you at what I said in the section #1.
By creating:
---
mo:Label rdfs:subClassOf mo:Artist
---
we would be able to describe all the things alex said (creation date, involved
people, maybe also links and
affiliations between labels) since mo:Label would be a rdfs:subClassOf mo:Artist.
But I am thinking about something else right now. Why not:
---
mo:Label rdfs:subClassOf mm:Artist
mo:Label rdfs:subClassOf foaf:Group
---
That way we would consider as an Artist and as a foaf:Group. It would enable us
to create a group of people involved in a Label. That way, mo:Label and mo:Band
would be the same thing, except on the semantic: music group versus music
publication group.
=====================
=====================
6. OWL cardinality
=====================
Alex suggest:
---
A kind of detail, but it may be useful to add cardinality to
properties as compilation_of , medley_of, mashup_of, constraining the
range to be > 1
---
We have nothing to lose by doing that :)
=====================
=====================
7. Music Genres
=====================
David propose to add Genres to the ontology.
Yeah well, this is more than important :)
However, the question is: where to stop?
If we take a look at: http://en.wikipedia.org/wiki/List_of_music_genres
We can see that there exist at least hundred of genres.
The first thing we have to think about is of should we describe genres in the
ontology?
First of all, genres would be applicable at many levels:
---
mo:Artist (an artist is paying music of on or more genre)
mo:Release (a release is of genre X)
mo:Track (a track is of genre X)
Eventually we could say that a mo:Label is of genre X (considering that a
mo:Label is in fact a mo:Artist).
etc.
---
But how to describe genres in the ontology?
---
mo:Genre (superclass)
mo:ClassicalMusic (rdfs:subClassOf mo:Genre)
mo:Jazz (rdfs:subClassOf mo:Genre)
mo:genre
domain: mo:Artist, mo:Release, mo:Track
range: mo:Genre
---
But where to stop with the subclasses of mo:Genre? I would suggest to define in
the ontology the major genres listed here
(http://en.wikipedia.org/wiki/List_of_music_genres).
Eventually people will be able to extend it by creating new classes that will
fill their own purposes.
=====================
=====================
8. mo:bpm
=====================
David suggest a new property: mo:bpm (beat per minute).
I agree that it could be useful. I would suggest:
---
mo:bpm
domain: mo:Track
range: #Literal (that would be an integer describing the BPM of a track).
---
=====================
=====================
9. mo:instrument
=====================
David suggest to specify the instrumentation of artists/releases/tracks.
I agree that it is an important information to have. So I would suggest:
---
mo:Instrument (superclass)
mo:Guitar (rdfs:subClassOf mo:Instrument)
mo:Piano (rdfs:subClassOf mo:Instrument)
Etc.
mo:instrument
domain: mo:Artist, mo:Release, mo:Track
range: mo:Instrument
---
=====================
This is what is finishing the first round of recommendation from users (not bad
for the first day, no?)
I am really impressed by the enthousiasm around that new music ontology, and the
work that everybody is putting in it will make it a really great music ontology.
Take care and happy Marry Christmas all!
Fred