A few comments about the ontology
Alexandre Passant
First, well done for the ontology Fred !
I'm really looking forward the data :)
Here are some remarks / idea about the ontology:
* Regarding the Artist class, what about getting mo:Artist subclass of
foaf:Agent ?
Looking at your examples for group and artists, you define them both
using FOAF and MO, so what about merging both ?
It will allow to re-use foaf:properties as name, homepage, the BIO
vocabulary ...
Then, you could also consider subclasses of mo:Artist:
- mo:SoloArtist (subclass of foaf:Person)
- mo:Band (subclass of foaf:Group)
Distinguish SoloArtist and Bands could also be useful for the queries IMHO.
BTW, you mention "various artist" in the Artist description, but is
that really needed ? V/A isn't simply a Release / Track with more than
one artist ? Or is that to deal with V/A bands, created for a single
release (eg: charity record), in that case it could also be subclass
of foaf:Group.
* Regarding Album, I'm a bit confused with the name (as in the
MusicBrain ontology), since Album makes me think of something with
more than a few tracks.
So getting EP or interview as a type of an Album sounds strange to me.
Maybe Release would be more appropriate ?
Also, as David suggested [1], format is really important for each
release. Indeed, if you don't consider only the music but also the
release "object", this is important to know if that's a 10" vynil or
MaxiCD, 12" or CD ... Adding a release_type property would be nice,
especially for people collecting records that want precisely to
identify the record (+ using mo:miscellanous to add other record
properties as vynil color, picture-disc ...)
Maybe it's a bit outside the ontology if we consider it deals only
with the music itself, but I think that's worth adding it.
* mo:Image
Maybe reuse foaf:depiction ?
* Label
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 ?
* Music community
I'm wondering if all these links could fit into a single top class, so
that it will be easier to add new community links in MO extensions
(eg: linkto_jamendo -http://jamendo.com), and so get all community
sites for an artist with a single query on the top class.
* OWL Cardinality:
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
Best,
Alex.
Frederick Giasson
> First, well done for the ontology Fred !
Thanks :)
But it seems that there are many things to get done before I get satisfied by it ;)
> I'm really looking forward the data :)
Yah me too eheheh. Sometime in January.
> * Regarding the Artist class, what about getting mo:Artist subclass of
> foaf:Agent ?
> Looking at your examples for group and artists, you define them both
> using FOAF and MO, so what about merging both ?
> It will allow to re-use foaf:properties as name, homepage, the BIO
> vocabulary ...
> Then, you could also consider subclasses of mo:Artist:
> - mo:SoloArtist (subclass of foaf:Person)
> - mo:Band (subclass of foaf:Group)
> Distinguish SoloArtist and Bands could also be useful for the queries IMHO.
Totally agree here. When I have done that, I had mainly in mind the triple store
indexing and sparql querying of the data produced by the ontology.
This explains why I was creating both FOAF an MO data for artists and group.
3store do inference on type (dunno if it works fine or not since I never used
it) but Virtuoso, for example, don't for the moment (planned for the next months
or so).
Considering that, if one use a triple store that doesn't do type inference and
that mo:Artist is a subClassOf foaf:Person (to be consistent with the example in
the spec) then queries such as:
?person a foaf:Person.
would not return any mo:Artist, since the triple store is not doing any
inference on type, and that he is not aware that a mo:Artist is in fact a
foaf:Person.
However, I re-thought about that and:
1- Triple stores will evolve quickly, so we don't have to consider them while
developing an ontology that can be used for the next 25 years.
2- In fact, developers always has the possibility to use the method I was
proposing if they put musicbrainz data into their triple store. The only problem
would be if he get data from elsewhere.
3- If one develop a specialized system (a music search website for example), the
interface could know that a mo:Artist is a foaf:Person, so the problem could be
solved at the interface level.
So, considering that, Alex was right, and we should think about fixing the
ontology according to what he said.
> BTW, you mention "various artist" in the Artist description, but is
> that really needed ? V/A isn't simply a Release / Track with more than
> one artist ? Or is that to deal with V/A bands, created for a single
> release (eg: charity record), in that case it could also be subclass
> of foaf:Group.
I'll fix that too :)
> * Regarding Album, I'm a bit confused with the name (as in the
> MusicBrain ontology), since Album makes me think of something with
> more than a few tracks.
> So getting EP or interview as a type of an Album sounds strange to me.
> Maybe Release would be more appropriate ?
I agree. I will check and propose some name we could use instead of Albums to
refer to the Release concept ( it will probably me mo:Release as you suggested ;) ).
> Also, as David suggested [1], format is really important for each
> release. Indeed, if you don't consider only the music but also the
> release "object", this is important to know if that's a 10" vynil or
> MaxiCD, 12" or CD ... Adding a release_type property would be nice,
> especially for people collecting records that want precisely to
> identify the record (+ using mo:miscellanous to add other record
> properties as vynil color, picture-disc ...)
> Maybe it's a bit outside the ontology if we consider it deals only
> with the music itself, but I think that's worth adding it.
Definitely that it is. I will propose that as well (the proposition email should
be sent by the end of the day (EST).
> * mo:Image
> Maybe reuse foaf:depiction ?
Considering the changes above (subclasses), yeah, it would be much better that way.
> * Label
> Would be useful to link each Release (and maybe Artists) to its label,
> using linkto_label (to get the same naming convention).
link, you mean a URL link or a relationship link?
> 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 ?
Agree. However, is someone aware of the characteristics of a Label?
> * Music community
> I'm wondering if all these links could fit into a single top class, so
> that it will be easier to add new community links in MO extensions
> (eg: linkto_jamendo -http://jamendo.com), and so get all community
> sites for an artist with a single query on the top class.
Agree too
> * OWL Cardinality:
> 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
Good point :)
Okay, I will come bakc on these propositions with another email later today.
Thank you very very much for these good propositions.
Take care,
Fred