Term overloading/ambiguity in the MO

40 views
Skip to first unread message

Jared Thomas

unread,
Aug 12, 2015, 1:55:06 PM8/12/15
to Music Ontology Specification Group
The trigger for this topic same when looking at the definition of "Label" in the MO; http://purl.org/ontology/mo/Label

which is described as "Trade name of a company that produces musical works or expression of musical works." In my exeperiance, the term label is used to describe the trade name of a company that manages artists and their releases, i. e. producing physical musical manifestations (releases) and oganising their distribution and publication (the act of releasing on a release date).


Labels are not the agent that has the most pertinent relationship to a musical work - in my experience the term used for that agent is the "publisher" http://purl.org/ontology/mo/publisher , (defined as: Used to relate a musical manifestation to a person or a group of person who published it.) and the relationship is that the publisher holds the publication rights to the work in the only way that a work can be manifested in its purest from - the score or sheet music.http://purl.org/ontology/mo/PublishedScore 

again, in my experinece, the Lable publishes the release, but the publisher owns the publication rights to the sheet music (and sometimes may actually publish it)


And this illustrates the problem, many terms in the ontology are overloaded (in the descriptions if only one or two occur in the actual ontology).


label

Associates a release event with the label releasing the record

URI: http://purl.org/ontology/mo/label
Label: label
Status: testing
Range: Label
Domain: genid81

Label

Trade name of a company that produces musical works or expression of musical works.

URI: http://purl.org/ontology/mo/Label
Label: label
Status: stable
Parent Class: CorporateBody
Properties: lc


 in the cae of Label/label, whilst technically, the capitalisation of the first character makes them unique, the scope for verbal misinterpretation and errors due to typing is big.


In the wider sense of what I am trying to illustrate, the other prime offenders are:

  • "publisher" - see my descriptions above
  • "produce" - in the most basic sense to create, but also the executive editorial function in the creation of a music manifestation.
  • "producer" - the agent carrying out the act of producing (see above)

Some of these no doubt occur because of local usage of terminology, but in the case of the English language, that local usage can be widespread.


There is the other issue of the naming of superclasses (for example the way that in MusicBrainz, all agents related to a music object were called "artists" - even composers) - I don't think this occurs much in the MO.


Can I suggest that, to prevent misunderstandings and for general usability the attributes "alias" and for each alias the "alias_context" are added to the class and property descriptions? this would greatly assist in mapping the varied "real-world" ontologies that have emerged back to the cannonnical classes and properties in the MO.



Bo Ferri

unread,
Aug 12, 2015, 3:34:11 PM8/12/15
to music-ontology-sp...@googlegroups.com
Hi Jared,

I don't really get your concrete issue and/or remark?

- re. the example mo:label vs mo:Label: mo:label is a property and
mo:Label is a class (generally, there are many terms in different
languages that are overloaded - that's the nature of language and we
also need to deal with this issue in ontologies)
- re. given definition of terms: there are always different opinions and
options on how to define a certain term; I think one shouldn't think too
close there, rather then there's often/always a kind of shared
understanding for a certain term (especially in our context/domain -
music); so don't view the given definitions "as is", please; you can
view them as an approach to form shared understanding and if you would
like to suggest better definitions for one or another term, then please
feel free to do so (this is a community-driven ontology); you can do
this via this mailing list here; however, you can also raise an issue at
the ontology project at github [1]
- re. super classes: every class in MO has a super class (via
rdfs:subClassOf); if it's no class from the MO namespace, then it's
taken from somewhere else, e.g., FOAF, or it is owl:Thing at least


If you found concrete misconceptions, e.g., things that don't really fit
together, then please provide some illustrative examples that showcase a
concrete problem and we can discuss each issue here or at the issue
tracker at github.

Thanks a lot in advance for all your feedback and remarks.

Cheers,


Bo/T


[1] https://github.com/motools/musicontology/issues
> Range: Label <http://musicontology.com/specification/#term-Label>
> Domain: genid81 <http://musicontology.com/specification/#term-genid81>
>
>
> Label
>
> Trade name of a company that produces musical works or expression of
> musical works.
>
> URI: http://purl.org/ontology/mo/Label
> Label: label
> Status: stable
> Parent Class: CorporateBody
> <http://musicontology.com/specification/#term-CorporateBody>
> Properties: lc <http://musicontology.com/specification/#term-lc>
>
>
>
> in the cae of Label/label, whilst technically, the capitalisation of
> the first character makes them unique, the scope for verbal
> misinterpretation and errors due to typing is big.
>
>
> In the wider sense of what I am trying to illustrate, the other prime
> offenders are:
>
> * "publisher" - see my descriptions above
> * "produce" - in the most basic sense to create, but also the
> executive editorial function in the creation of a music manifestation.
> * "producer" - the agent carrying out the act of producing (see above)
>
> Some of these no doubt occur because of local usage of terminology, but
> in the case of the English language, that local usage can be widespread.
>
>
> There is the other issue of the naming of superclasses (for example the
> way that in MusicBrainz, all agents related to a music object were
> called "artists" - even composers) - I don't think this occurs much in
> the MO.
>
>
> Can I suggest that, to prevent misunderstandings and for general
> usability the attributes "alias" and for each alias the "alias_context"
> are added to the class and property descriptions? this would greatly
> assist in mapping the varied "real-world" ontologies that have emerged
> back to the cannonnical classes and properties in the MO.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Music Ontology Specification Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> music-ontology-specific...@googlegroups.com
> <mailto:music-ontology-specific...@googlegroups.com>.
> To post to this group, send email to
> music-ontology-sp...@googlegroups.com
> <mailto:music-ontology-sp...@googlegroups.com>.
> Visit this group at
> http://groups.google.com/group/music-ontology-specification-group.
> For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages