mo:Genre - why not om:MusicGenre?

[tomasz.chodakowski]

It might be overly pedantic (never enough for a system potentially re-
used by many) but wouldn't it be better to have mo:MusicGenre instead
of mo:Genre. mo:MusicGenre would be specific to the ontology's domain
(as opposed to literary, film, video game genres) and be more inline
with the intended (?) design choices for mo:MusicArtist,
mo:MusicalWork, etc. Further, mo:Genre counterpart could be defined in
a specialized genre theory[1][2] ontology, if needed.

WDYT?

Cheers,
Tomasz

[1] http://www.aber.ac.uk/media/Documents/intgenre/intgenre1.html
[2] http://www.springerlink.com/content/f8648xw167035430/

[za...@elbklang.net]

Hi Tomasz,

you are absolutely right with your argumentation - the abstract form of a
music genre is a genre, especially, if we might consider a separate genre
ontology definition. Currently, mo:genre is just a hook and not really
well definied. There is just the documentation, which says: "Associates an
event (like a performance or a recording) to a particular musical genre.".
It would be interesting, if you plan to design something in that
direction. Unfortunatelly, I think that the property mo:genre is currently
used in some projects (e.g. BBC Music). So I don't know wether the
developer of that projects are happy about this change ;)
I would welcome it.

Cheers,

zazi

PS: interesting 2nd source

[Loïc DIAS DA SILVA]

Why not create mo:MusicGenre keeping mo:genre as deprecated ?

[Kurt J]

It's also important to note the difference between mo:Genre (class)
and mo:genre (property). As zazi points out, both are already used in
some projects (dbtune/myspace for sure) so simply removing them is
probably not an option. It might be interesting to create
mo:MusicGenre as a sub class of mo:Genre, but IMHO the namespace
already implies we're talking about a music genre.

All this being said, I think the questions around genre modelling are
very interesting and thanks to Tomasz for the references, i hope to
read more when i have more time :-)

Maybe a more well defined genre ontology belongs in a separate
namespace and the mo:genre property can be used to point to class
instances from this genre namespace...

-Kurt J

[Tomasz Chodakowski]

That's a minor syntactical change (just to keep naming consitent) but
potentially disruptive, as you mentioned, so it might not be worth the
hassle. After all we are dealing with URIs. However, that brings me to
a more serious problem.

How is versioning handled in MO? I know that's a big and hairy issue,
but at least on a syntactical level - are there uris that denote
specific MO versions?

It's great that MO is being actively used but we need a way to cater
for change or the whole Semantic Web will end at version 1.x ;) Having
version specific uris for MO could be a first step toward that. Am I
missing something here?

Cheers,
T.

ps: We were considering developing formal Genre ontology - interesting
but non-trivial problem. We ended up using OWL/SKOS hybrid for our
genre taxonomy with MusicGenre as a subclass of skos:Concept and
specific genres as individuals.

[Yves Raimond]

Hello!

>> It might be overly pedantic (never enough for a system potentially re-
>> used by many) but wouldn't it be better to have mo:MusicGenre instead
>> of mo:Genre. mo:MusicGenre would be specific to the ontology's domain
>> (as opposed to literary, film, video game genres) and be more inline
>> with the intended (?) design choices for mo:MusicArtist,
>> mo:MusicalWork, etc. Further, mo:Genre counterpart could be defined in
>> a specialized genre theory[1][2] ontology, if needed.

Hmm, I am not sure I follow the argumentation here. MO is about the
music domain, so everything in its namespace is music-related. So
mo:Genre is a music genre (and if we were to mint an URI for a broader
meaning of "genre", we'll probably not do it within a music ontology?)

However, you're right that Genre is not consistent with MusicArtist,
MusicalWork etc. But I think it would be quite a cost to change it, as
it is already being used a fair bit, especially as this seems quite a
minor problem?

>> [1] http://www.aber.ac.uk/media/Documents/intgenre/intgenre1.html
>> [2] http://www.springerlink.com/content/f8648xw167035430/

/me reading those - very interesting!

Cheers,
y

[Yves Raimond]

> That's a minor syntactical change (just to keep naming consitent) but
> potentially disruptive, as you mentioned, so it might not be worth the
> hassle. After all we are dealing with URIs. However, that brings me to
> a more serious problem.
>
>  How is versioning handled in MO? I know that's a big and hairy issue,
> but at least on a syntactical level - are there uris that denote
> specific MO versions?

There are at least two types of versioning we are or should be doing:

1) Keep a persistent URI for each version of the RDF spec, and link
from the current to the previous one. We do that for the programmes
ontology (http://www.bbc.co.uk/ontologies/programmes) but we don't do
it yet in MO.
2) We had to change a few terms at the beginning of MO to make naming
consistent (under_score instead of camelCase). We took the following
approach:

<owl:ObjectProperty
rdf:about="http://purl.org/ontology/mo/usedInPerformance"
vs:term_status="deprecated">
<rdfs:isDefinedBy rdf:resource="http://purl.org/ontology/mo/"/>
<owl:equivalentProperty
rdf:resource="http://purl.org/ontology/mo/performed_in"/>
</owl:ObjectProperty>

However, this brings some concerns, as the owl:equivalentProperty
means that the vs:term_status="deprecated" also applies to the new URI
(mo:performed_in). I am not sure how to do that properly though.

As these old properties are not used anywhere anymore (they got
changed more than 2 years ago), I think it'd be worth removing them
completely for now.

>  It's great that MO is being actively used but we need a way to cater
> for change or the whole Semantic Web will end at version 1.x ;) Having
> version specific uris for MO could be a first step toward that. Am I
> missing something here?

I don't agree on version specific URIs for everything. A good example
of that is FOAF, which is stuck to version 0.1 since its beginning :-)
A good rule of thumb is to not create version-specific URIs for
concepts/properties, but create version-specific URIs for the RDF and
HTML documents. (Again, I think the Programmes Ontology does it quite
nicely).

Cheers!
y