Class Schemas - motools/musicontology GitHub Wiki
1. Introduction to Class Schemas
1.1. Dereferencing
2. Stable class schemas
2.1. Basic Ontologies
2.1.1. event:Event overview
2.1.2. timeline:TimeLine overview
2.1.3. The 4 levels of the FRBR Ontology
2.2. The 4 levels of the Music Ontology
2.2.1. mo:MusicalWork schema
2.2.1.1. mo:MusicalWork schema extended
2.2.1.2. mo:Arrangement schema
2.2.2. mo:MusicalExpression schema
2.2.2.1. mo:MusicalExpression and event:Event schemas
2.2.2.2. mo:MusicalExpression schema and event relations (extended)
2.2.3. mo:MusicalManifestation schema
2.2.3.1. mo:MusicalManifestation schema (simple)
2.2.3.2. mo:MusicalManifestation schema (extended)
2.2.4. mo:MusicalItem schema
2.2.4.1. mo:MusicalItem schema (simple)
2.2.4.2. mo:MusicalItem schema (extended)
2.2.5. mo:MusicalManifestation and mo:MusicalItem schema (partial)
2.3. mo:MusicArtist, mo:MusicGroup, and mo:Organization schemas
2.3.1. mo:MusicArtist, mo:MusicGroup, and mo:Label schemas (simple)
2.3.2. mo:MusicArtist, mo:MusicGroup, mo:Label and mo:Membership schemas (extended)
2.4. mo:ReleaseStatus schema
2.5. mo:ReleaseType schema
3. Unstable class schemas
3.1. Extended release concept with mo:ReleaseEvent
3.2. Recording Session concept to capture Recordings
All Classes and Properties are dereferenceable via their URI (in fact, more would have do be done with content-negotiation, etc.)
A basic event:Event can make use of up to six basic properties:
Note: Please also have look at the definition of the Event Ontology for this concept.
Note: Please also have look at the definition of the Timeline Ontology for this concept.
To understand the Music Ontology it is somehow essential to understand its underlying ontology - the FRBR Ontology - with its 4 levels: frbr:Work, frbr:Expression, frbr:Manifestation, frbr:Item, where MO derives from on each level.
Note: To bypass the levels from the most abstract level to a lower level, please use the property frbr:subject, which has a range of frbr:Endeavour (the superclass of the 4 levels concept). This enables, for example, a bypass from a mo:MusicalWork instance to a mo:SignalGroup instance.
The red arrows are from the owl:disjointWith property that means each level of the 4 levels concept is disjoint to each other.
A mo:Signal instance can be associated with mo:Track instances (mo:MusicalManifestation) by utilising mo:published_as and mo:encodes (over its related mo:Medium instances). A mo:Track instance (mo:MusicalManifestation) can be associated with mo:Medium (mo:MusicalItem) instances by utilising mo:available_as (for release related issues) or mo:item (for user related issues). To associate mo:Signal (mo:SignalGroup) instances with their related mo:Release (mo:MusicalManifestation) instances, please make use of the extended release concept.
mo:MusicalWork has its origin in frbr:Work and as a sub class it has currently only mo:Movement.
- mo:MusicalWork,
- its subclass(es) (
- and its related events (
mo:Arrangement and its sub classes
(based on MO version 1.X)
- mo:Expression,
- its subclasses (
- mo:Score,
- mo:Signal with
- mo:Lyrics,
- mo:Libretto) and
- event:Event and its related musical event sub classes
(based on MO 2.0)
- mo:Expression,
- its subclasses (
- and its related events (
mo:MusicalManifestation has its origin in frbr:Manifestation and it has the following sub classes currently
- mo:MusicalManifestation has the following sub classes currently
- mo:PublishedLyrics,
- mo:PublishedLibretto,
- mo:PublishedScore,
- mo:Release (with its mo:record property),
- mo:Record (with its mo:track property) and
- mo:Track.
- One could especially make use of its related release properties
- mo:release_status,
- mo:release_type and
- mo:other_release_of (a mo:MusicalManifestation to mo:MusicalManifestation relation).
- The related event:Event for mo:MusicalManifestation is
- mo:ReleaseEvent (with its mo:release property to create release events from a mo:SignalGroup instance (see also the extended release concept)).
(based on Music Ontology version 1.X)
mo:MusicalItem had its origin in frbr:Item and only one direct sub class
- mo:Medium with its concrete sub classes
- mo:DAT,
- mo:DCC,
- mo:CD,
- mo:MD,
- mo:SACD,
- mo:Torrent,
- mo:ED2K,
- mo:Datapikay,
- mo:Vinyl,
- mo:MagneticTape,
- mo:Stream,
- mo:DVDA,
- mo:AudioFile.
(based on Music Ontology version 2.0)
mo:MusicalItem isn't a sub class of frbr:Item anymore (see its description for details) and only one direct sub class
- mo:Medium with its concrete sub classes
- mo:DAT,
- mo:DCC,
- mo:CD,
- mo:MD,
- mo:SACD,
- mo:Torrent,
- mo:ED2K,
- mo:Vinyl,
- mo:MagneticTape,
- mo:Stream,
- mo:DVDA,
- mo:AudioFile.
This graphic is to illustrate a relation (mo:available_as as sub property of frbr:exemplar) between a mo:MusicalManifestation instance (e.g. mo:Release, mo:Record or mo:Track) and a mo:MusicalItem instance (e.g. mo:CD).
(based on Music Ontology version 1.X)
This graphic illustrates the construction (origins) of the important musical concepts
- mo:MusicArtist and its sub class mo:SoloMusicArtist,
- mo:MusicGroup and
- mo:Label.
The overall concept is foaf:Agent with its sub classes
mo:CorporateBody is a more general concept to model musical corporated bodies, such as labels or concert agencies.
(based on Music Ontology version 2.0)
This graphic shows not only the construction (origins) of the important musical concepts
- mo:MusicArtist and its sub class mo:SoloMusicArtist,
- mo:MusicGroup with its releated mo:Membership event to model music group memberships (by using mo:membership and mo:group, or for simple (permanent) relations mo:member) and
- mo:Label, it illustrates furthermore, the broad range of related roles during the music production and consumption process:
- mo:SoundEngineer,
- mo:Arranger (currently no link to the documentation available),
- mo:Composer,
- mo:Listener,
- mo:Conductor and
- mo:Performer (Note: currently these concepts are all linked to their related properties in the documentation, which can also be utilised with a more abstract foaf:Agent as range).
The overall concept is foaf:Agent with its sub classes
foaf:Group and foaf:Organization are both sub classes of frbr:CorporateBody. mo:CorporateBody is a more general concept to model musical corporate bodies, such as labels or concert agencies.
The mo:ReleaseStatus concept is for describing the current release status of a related mo:MusicalManifestation instance. Currently, in the Music Ontology the following individuals are defined:
This list of mo:ReleaseStatus individuals might be extended in future Music Ontology releases or could also be extended by self defined sub ontology definitions.
The mo:ReleaseType concept is for describing the release type of a related mo:MusicalManifestation instance. Currently, in the Music Ontology the following individuals are defined:
- mo:interview,
- mo:live,
- mo:spokenword,
- mo:ep,
- mo:remix,
- mo:compilation,
- mo:soundtrack,
- mo:album and
- mo:audiobook.
This list of mo:ReleaseType individuals might be extended in future Music Ontology releases or could also be extended by self defined sub ontology definitions.
These schemas are unstable at the moment considering the work we are currently doing for these two portions of the ontology.
A mo:ReleaseEvent consumes often mo:SignalGroup or mo:Signal instances as event:factor. The event:product objects of such events are then often one or more mo:Release instance(s), which are related through the
mo:release property (instead of the dropped mo:release_event from version 2.0). In other cases, e.g. releasing a mo:Score instance somewhere as a mo:PublishedScore instance, one has to use just the event:product property for the publishing relations.
Due to the fact that mo:ReleaseEvent is an event:Event, one can associate a place (event:place) and a time (event:time) to it. Furthermore, could a mo:Label be assigned with the property mo:label (this property has as domain mo:Release, since version 2.1).
Note: Please also have look at the notes of Proposal Revision 1.14 for this concept.
Each mo:Recording instance of a mo:RecordingSession instance is connected to it with the property event:sub_event. Hence, the mo:RecordingSession instance is a composite of mo:Recording instances. The product (mo:produced_signal_group) of a mo:RecordingSession event is mo:SignalGroup instance, which can contain all procuded mo:Signal instances of that mo:RecordingSession instance.
Due to the fact that mo:RecordingSession is an event:Event, one can associate a place (event:place) and a time (event:time) to it.
Note: Please also have look at the notes of Proposal Revision 1.14 for this concept.
