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.