This visual layout and structure of the
specification was adapted from the FOAF
Vocabulary Specification by Dan Brickley and Libby Miller and the SIOC Ontolofy Specification by Uldis Bojar and John G. Breslin. This document was automatically generated using the OntoSpec script.
At that point, the music industry of the eighties leaded by blockbusters was completely changed.
The Music Ontology is an attempt to provide a vocabulary for linking a wide range music-related information,
and to provide a democratic mechanism for doing so.
Anybody can publish Music Ontology data and link it with existing data, in order to help
create a music-related web of data.
For example, John Doe may publish some information about a performance he saw last night (like the fact
that he was there, and a review). Mary Doe may publish the fact that she attended the same performance, that
she recorded it using her cell-phone, and that the corresponding item is available in her podcast.
The Music Ontology provides a vocabulary to express information ranging from this example to:
The Music Ontology is divided in three levels of expressiveness - from the simplest one to the more complex one.
Everything is clustered around the following categories:
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119].
Namespace URIs of the general form "http://www.example.com/." represents some application-dependent
or context-dependent URI as defined in RFC 2396 [RFC 2396].
The XML Namespace URI that MUST be used by implementations of this specification is:
An alphabetical index of Music Ontology terms, by class (categories or types), by
property and by individuals. All the terms are hyperlinked to their detailed description for quick reference.
An alphabetical index of external ontologies terms, by class (categories or types), by
property and by individuals, used by the Music Ontology. All the terms are hyperlinked to their detailed description for quick reference.
A list of terms used within the level 1 of the Music Ontology,
therefore covering simple editorial information (tracks, releases, artists, groups, etc.).
A list of terms used within the level 2 of the Music Ontology,
therefore covering information about the music creation workflow (Composition, Performance, Arrangement, Recording, etc.).
A list of terms used within the level 3 of the Music Ontology,
therefore covering event decomposition (`this particular performer was playing that particular instrument at that particular time').
The Music Ontology definitions presented here are written using
a computer language (RDF/OWL) that makes it easy for software to
process some basic facts about the terms in the Music Ontology, and
consequently about the things described in Music Ontology documents. A Music Ontology
document, unlike a traditional Web page, can be combined with other
Music Ontology documents to create a unified database of information
MO Show/Festival
Relationships
Music Ontology Classes Hierarchy
There are the schemes of the hierarchy of the Music Ontology classes. These schemes show the interaction between the Music Ontology classes and other ontologies classes.
RDF Document Examples
Examples of SPARQL queries against these RDF graphs
Background
The Music Ontology is an effort led by ZitGist LLC.
and the Centre for Digital Music
to express music-related information on the Semantic Web.
The Music Ontology is mainly influenced by:
More detailed are available on the Wiki publication page.
The Music Ontology
Description
This specification serves as the Music Ontology "namespace document". As such
it describes the Music Ontology and the terms (RDF classes and properties) that
constitute it, so that Semantic
Web applications can use those terms in a variety of RDF-compatible
document formats and applications.
This document presents the Music Ontology as a Semantic Web vocabulary or Ontology.
The Music Ontology is straightforward, pragmatic and designed to allow
simultaneous deployment and extension, and is therefore intended for
widescale use.
Evolution and
Extension of the Music Ontology
The Music Ontology is identified by the namespace URI
'http://purl.org/ontology/mo/'.
Revisions and extensions of Music Ontology are conducted through edits to the namespace document, which by convention is published in the Web at the namespace
URI.
The properties and types defined here provide some basic
concepts for use in Music Ontology descriptions. Other vocabularies (e.g. the
Dublin Core metadata elements for
simple bibliographic description, FOAF, etc.) can also be mixed in with the Music Ontology terms, as can local
extensions. The Music Ontology is designed to be extended, and modules may be added
at a later date.
Music Ontology Modules
Music Ontology modules may be used to extend the ontology and avoid making the base ontology too complex.
A list of available modules is available
on the Wiki.
Time, and TimeLine, Event
The parts of the Music Ontology related to the production process of a particular piece of music (composition, performance, arrangement,...) as well as the parts dealing with time-related information are based on three external ontologies. The Music Ontology provides RDFS wrappers for the main classes, properties and individuals of these three ontologies.
The first ontology is: OWL-Time. Three terms of this ontology are used by the Music Ontology: TemporalThing, Instant and Interval.
However the kind of temporal information we may want to express goes a bit beyond OWL-Time, so we use an extension of it, developped in the Centre for Digital Music, Queen Mary, University of London: the TimeLine ontology. Indeed, we may want to express instants and intervals on multiple "timelines" (a timeline being a coherent backbone for temporal things): the one backing a particular audio file, the one behind an audio/video stream, or the physical one, backing a musical performance. Two classes of timelines are defined: PhysicalTimeLine (an instance of it being universaltimeline, which is the one on which we may address "the 13th of october, 2006"), and RelativeTimeLine (instances of this class may back audio signals, and we may address things such as "between 2 and 3 seconds" on them).
There is only one way of addressing temporal things per class of timeline. On a physical time line, a point is identified by a xsd:dateTime -- through the beginsAtDateTime property, and a duration by a xsd:duration -- through the durationXSD property. On a relative time line, a point P is identified by the duration of the interval [0,P], and this duration is identified by a xsd:duration -- through the beginsAtDuration property. A duration is identified by durationXSD.
In order to express knowledge about the production process of a piece of music, we use the Event ontology, also developped at the Centre for Digital Music. Events are seen as a way to arbitrary classify a space/time region. We have the possibiliy to attach to these events: agents (active participants to the event, like a performer, a sound engineer, ...), factors (passive things having a role in the event, like a musical instrument, a musical score, ...) and products (things produced by the event, such as a sound, a musical work, ...). A key feature of this ontology is also to allow "splitting" of events, through the sub_event transitive property. Using events, we may express: this musician was playing this instrument at this given time.
In the current version of the Music Ontology, the main sub-classes of Event are: Performance, Recording, Arrangement, Composition. However, given its abstract definition, we can describe lots of other things using this class: results of feature extraction, beat tracking, segmentation of songs...
Music Creation Workflow
In order to describe music-related events, we consider describing the
workflow beginning with the creation of a musical work to
its release on a particular record. This is our main description
paradigm, and was first used in the music production ontology
developed at C4DM.
In the "easy" case (non-electronic music), We can describe this
workflow within two boundaries: the simplest one and the most expressive one.
The simplest one consider the existence of 4 concepts within this workflow:
MusicalWork (the musical work itself), Performance (the event
corresponding to an actual performance
of the work), Signal (recording the performance as a signal),
and MusicalManifestation
(the release of this signal on a particular record).
The most expressive one consider the existence of 7 concepts:
Composition (the event leading to the creation of a musical work),
MusicalWork, Performance, Sound (the physical sound
produced by the performance), Recording (the event representing the
transduction from a physical sound to a signal, through
the use of a microphone), Signal, and MusicalManifestation.
Thus, we could imagine other ontologies plugged on top of MO, in order
to represent the cognition of a sound (related to Sound),
the different types of microphones that can be used (related to
Recording), and so on.
In order to switch from the simplest workflow to the most expressive
one, we define a single shortcut property:
recorded_as, directly linking a Performance to a Signal.
This property MUST be present in every case, in order to be
able to do a simple query for accessing simple information.
The Music Ontology and Standards
It is important to understand that the Music Ontology as specified in this document is not a standard
in the sense of ISO Standardisation,
or that associated with W3C Process.
The Music Ontology depends heavily on W3C's standards work, specifically on XML, XML Namespaces, RDF, and OWL.
All the Music Ontology documents must be well-formed RDF/XML documents.
This specification contributes an ontology, the "Music Ontology ", to the Semantic
Web, specifying it using W3C's Resource
Description Framework (RDF). As such, the Music Ontology adopts by reference both
a syntax (using XML), a data model (RDF graphs) and a mathematically
grounded definition for the rules that underpin the RDF design.
The Music Ontology and RDF
Why does the Music Ontology use RDF?
The Music Ontology is an application of the Resource Description Framework (RDF) because the subject area we're describing – music: artists, albums and tracks -- has so many competing requirements that a standalone format would not capture them or would lead to trying to describe these requirements in a number of incompatible formats. By using RDF, the Music Ontology gains a powerful extensibility mechanism, allowing Music-Ontology-based descriptions to be mixed with claims made in any other RDF vocabulary.
This is for that reason that the RDF document examples at the beginning of this document suggested to use the FOAF ontology to describe the Person, and its relations with other Person (artist or non-artist), and to use the Music Ontology to specify that that Person is also an Artist. That way, we can re-use other ontologies such as the Relationship ontology, in conjunction with the FOAF ontology, to describe different relationship between Artists.
The Music Ontology as an ontology cannot incorporate everything we might want to talk about that is related to music: artists (people), albums and tracks. Instead of covering all topics within the Music Ontology itself, we describe the basic topics and build into a larger framework - RDF - that allows us to take advantage of work elsewhere on more specific description vocabularies.
RDF provides the Music Ontology with a way to mix together different descriptive vocabularies in a consistent way. Vocabularies can be created by different communities and groups as appropriate and mixed together as required, without needing any centralized agreement on how terms from different vocabularies can be written down in XML or N3.
Check the Ontology namespaces referenced section to find some ontologies that ca be use in conjonction with the Music Ontology.
This mixing happens in two ways: firstly, RDF provides an underlying model of (typed) objects and their attributes or relationships. mo:Album is an example of a type of object (a "class"), while mo:compilation_of and mo:has_track are examples of a relationship and an attribute of an mo:Album; in RDF we call these "properties". Any vocabulary described in RDF shares this basic model, which is discernable in the syntax for RDF, and which removes one level of confusion in understanding a given vocabulary, making it simpler to comprehend and therefore reuse a vocabulary that you have not written yourself. This is the minimal self-documentation that RDF gives you.
Secondly, there are mechanisms for saying which RDF properties are connected to which classes, and how different classes are related to each other, using RDF Syntax and OWL. These can be quite general (all RDF properties by default come from an rdf:Resource for example) or very specific and precise (for example by using OWL constructs). This is another form of self-documentation, which allows you to connect different vocabularies together as you please.
In summary then, RDF is self-documenting in ways which enable the creation and combination of vocabularies in a devolved manner. This is particularly important for an ontology which describes communities, since online communities connect to many other domains of interest, which it would be impossible (as well as suboptimal) for a single group to describe adequately in non-geological time.
RDF is usually written using the XML or N3 syntaxes. If you want to process the data, you will need to use one of the many RDF toolkits available, such as Jena (Java) or Redland (C).
More information about RDF can be found in the RDF Primer.
The Music Ontology cross-reference: Classes, Properties and Individuals
The Music Ontology introduces the following classes, properties and individuals. See the Music Ontology
namespace document in RDF/XML for more detail.
Classes, Properties and Individuals (full detail)
Class: tl:AbstractTimeLine - unstable - level 3
AbstractTimeLine
- Abstract time lines may be used as a backbone for Score, Works, ...
This allows for TimeLine maps to relate works to a given performance (this note was played at this time).
No coordinate systems are defined for these timelines. Their structure is implicitly defined
by the relations between time objects defined on them (eg. this note is before this note, which is
before this silent, which is at the same time as this note).
[back to top]
Class: foaf:Agent - stable - level 1
Agent
- An agent (person, group, software, etc.).
[back to top]
Class: mo:AnalogSignal - stable - level 2
AnalogSignal
- An analog signal.
[back to top]
Class: mo:Arrangement - stable - level 2
Arrangement
- An arrangement event.
Takes as agent the arranger, and produces a score (informational object, not the actually published score).
[back to top]
Class: mo:AudioFile - unstable - level 1
AudioFile
- An audio file, which may be available on a local file system or through http, ftp, etc.
[back to top]
Class: mo:CD - unstable - level 1
CD
- Compact Disc used as medium to record a musical manifestation.
[back to top]
Class: mo:Composition - stable - level 2
Composition
- A composition event.
Takes as agent the composer himself.
It produces a MusicalWork, or a MusicalExpression (when the initial "product" is a score, for example), or both...
[back to top]
Class: mo:CorporateBody - stable - level 1
CorporateBody
- Organization or group of individuals and/or other organizations involved in the music market.
[back to top]
Class: mo:DAT - unstable - level 1
DAT
- Data Audio Tape used as medium to record a musical manifestation.
[back to top]
Class: mo:DCC - unstable - level 1
DCC
- Digital Compact Cassette used as medium to record a musical manifestation.
[back to top]
Class: mo:DVDA - unstable - level 1
DVDA
- DVD-Audio used as medium to record a musical manifestation.
[back to top]
Class: mo:DigitalSignal - stable - level 2
DigitalSignal
- A digital signal
[back to top]
Class: mo:ED2K - unstable - level 1
ED2K
- Something available on the E-Donkey peer-2-peer filesharing network
[back to top]
Class: event:Event - stable - level 2
Event
-
An event: a way of arbitrary classifying a space/time region.
An event has agents (active entities contributing to the event -- a performer, a composer, an engineer, ...),
factors (passive entities contributing to the event -- flute, score, ...),
and products (things produced by the event -- sound, signal, score, ...). For
example, we may describe as Events: performances, composition events, recordings, arrangements,
creation of a musical group, separation of a musical group,
but also sounds, signals, notes (in a score)...
[back to top]
Class: mo:Festival - stable - level 2
Festival
- A festival - musical/artistic event lasting several days, like Glastonbury, Rock Am Ring...
We migth decompose this event (which is in fact just a classification of the space/time region related to
a particular festival) using hasSubEvent in several performances at different space/time.
[back to top]
Class: mo:Genre - stable - level 2
Genre
- An expressive style of music.
Any taxonomy can be plug-in here. You can either define a genre by yourself, like this:
:mygenre a mo:Genre; dc:title "electro rock".
Or you can refer to a DBPedia genre (such as http://dbpedia.org/resource/Baroque_music), allowing semantic web
clients to access easily really detailed structured information about the genre you are refering to.
[back to top]
Class: foaf:Group - stable - level 1
Group
- A group of agents.
[back to top]
Class: time:Instant - stable - level 2
Instant
- A time point (eg. "now":-) )
[back to top]
Class: mo:Instrument - stable - level 2
Instrument
- Any of various devices or contrivances that can be used to produce musical tones or sound.
Any taxonomy can be used to subsume this concept. The default one is one extracted by Ivan Herman
from the Musicbrainz instrument taxonomy, conforming to SKOS. This concept holds a seeAlso link
towards this taxonomy.
[back to top]
Class: mo:Instrumentation - stable - level 2
Instrumentation
- Instrumentation deals with the techniques of writing music for a specific instrument,
including the limitations of the instrument, playing techniques and idiomatic handling of the instrument.
[back to top]
Class: time:Interval - stable - level 2
Interval
- A time interval (eg. "the year 1994")
[back to top]
Class: mo:Label - stable - level 1
Label
- Trade name of a company that produces musical works or expression of musical works.
[back to top]
Class: mo:Libretto - stable - level 2
Libretto
- Libretto
[back to top]
Class: mo:Lyrics - stable - level 2
Lyrics
- Lyrics
[back to top]
Class: mo:MD - unstable - level 1
MD
- Mini Disc used as medium to record a musical manifestation.
[back to top]
Class: mo:MagneticTape - unstable - level 1
MagneticTape
- Magnetic analogue tape used as medium to record a musical manifestation.
[back to top]
Class: mo:Medium - unstable - level 1
Medium
- A means or instrumentality for storing or communicating musical manifestation.
[back to top]
Class: mo:Movement - unstable - level 2
Movement
- A movement is a self-contained part of a musical work. While individual or selected movements from a composition are sometimes performed separately, a performance of the complete work requires all the movements to be performed in succession.
Often a composer attempts to interrelate the movements thematically, or sometimes in more subtle ways, in order that the individual
movements exert a cumulative effect. In some forms, composers sometimes link the movements, or ask for them to be played without a
pause between them.
[back to top]
Class: mo:MusicArtist - stable - level 1
MusicArtist
- A person or a group of people (or a computer :-) ), whose musical
creative work shows sensitivity and imagination
[back to top]
Class: mo:MusicGroup - stable - level 1
MusicGroup
- Group of musicians, or musical ensemble, usually popular or folk, playing parts of or improvising off of a musical arrangement.
[back to top]
Class: mo:MusicalExpression - unstable - level 1
MusicalExpression
- The intellectual or artistic realization of a work in the form of alpha-numeric, musical, or choreographic notation, sound, etc., or any combination of such forms.
For example:
Work #1 Franz Schubert's Trout quintet
* Expression #1 the composer's score
* Expression #2 sound issued from the performance by the Amadeus Quartet and Hephzibah Menuhin on piano
* Expression #3 sound issued from the performance by the Cleveland Quartet and Yo-Yo Ma on the cello
* . . . .
The Music Ontology defines the following sub-concepts of a MusicalExpression, which should be used instead of MusicalExpression itself: Score (the
result of an arrangement), Sound (produced during a performance), Signal. However, it is possible to stick to FRBR and bypass the worflow
mechanism this ontology defines by using the core FRBR properties on such objects. But it is often better to use events to interconnect such
expressions (allowing to go deeply into the production process - `this performer was playing this particular instrument at that
particular time').
[back to top]
Class: mo:MusicalItem - unstable - level 1
MusicalItem
- A single exemplar of a musical expression.
For example, it could be a single exemplar of a CD. This is normally an single object (a CD) possessed by somebody.
From the FRBR final report: The entity defined as item is a concrete entity. It is in many instances a single physical object (e.g., a copy of a one-volume monograph, a single audio cassette, etc.). There are instances, however, where the entity defined as item comprises more than one physical object (e.g., a monograph issued as two separately bound volumes, a recording issued on three separate compact discs, etc.).
In terms of intellectual content and physical form, an item exemplifying a manifestation is normally the same as the manifestation itself. However, variations may occur from one item to another, even when the items exemplify the same manifestation, where those variations are the result of actions external to the intent of the producer of the manifestation (e.g., damage occurring after the item was produced, binding performed by a library, etc.).
[back to top]
Class: mo:MusicalManifestation - stable - level 1
MusicalManifestation
-
This entity is related to the edition/production/publication of a musical expression (musical manifestation are closely related with the music industry (their terms, concepts, definitions, methods (production, publication, etc.), etc.)
From the FRBR final report: The entity defined as manifestation encompasses a wide range of materials, including manuscripts, books, periodicals, maps, posters, sound recordings, films, video recordings, CD-ROMs, multimedia kits, etc. As an entity, manifestation represents all the physical objects that bear the same characteristics, in respect to both intellectual content and physical form.
Work #1 J. S. Bach's Six suites for unaccompanied cello
* Expression #1 sound issued during the performance by Janos Starker recorded in 1963 and 1965
o Manifestation #1 recordings released on 33 1/3 rpm sound discs in 1965 by Mercury
o Manifestation #2 recordings re-released on compact disc in 1991 by Mercury
* Expression #2 sound issued during the performances by Yo-Yo Ma recorded in 1983
o Manifestation #1 recordings released on 33 1/3 rpm sound discs in 1983 by CBS Records
o Manifestation #2 recordings re-released on compact disc in 1992 by CBS Records
Changes that occur deliberately or even inadvertently in the production process that affect the copies result, strictly speaking, in a new manifestation. A manifestation resulting from such a change may be identified as a particular "state" or "issue" of the publication.
Changes that occur to an individual copy after the production process is complete (e.g., the loss of a page, rebinding, etc.) are not considered to result in a new manifestation. That copy is simply considered to be an exemplar (or item) of the manifestation that deviates from the copy as produced.
With the entity defined as manifestation we can describe the physical characteristics of a set of items and the characteristics associated with the production and distribution of that set of items that may be important factors in enabling users to choose a manifestation appropriate to their physical needs and constraints, and to identify and acquire a copy of that manifestation.
Defining manifestation as an entity also enables us to draw relationships between specific manifestations of a work. We can use the relationships between manifestations to identify, for example, the specific publication that was used to create a microreproduction.
[back to top]
Class: mo:MusicalWork - stable - level 2
MusicalWork
- Distinct intellectual or artistic musical creation.
From the FRBR final report: A work is an abstract entity; there is no single material object one can point to as the work. We recognize the work through individual realizations or expressions of the work, but the work itself exists only in the commonality of
content between and among the various expressions of the work. When we speak of Homer's Iliad as a work, our point of reference is not a particular recitation or text of the work, but the intellectual creation that lies behind all the various expressions of the work.
For example:
work #1 J. S. Bach's The art of the fugue
[back to top]
Class: mo:Orchestration - stable - level 2
Orchestration
- Orchestration includes, in addition to instrumentation, the handling of groups of instruments and their balance and interaction.
[back to top]
Class: foaf:Organization - stable - level 1
Organization
- An organization.
[back to top]
Class: tl:OriginMap - stable - level 3
OriginMap
- This time line map represents the relation between the physical timeline and a
continuous time line where the origin is at a given point on the physical timeline
(eg. "the timeline backing this signal corresponds
to the physical timeline: point 0 on this timeline corresponds to the
20th of december at 5pm").
[back to top]
Class: foaf:Person - stable -
Person
- A person.
[back to top]
Class: tl:PhysicalTimeLine - stable - level 3
PhysicalTimeLine
- Well, the actual physical time as we know it. I may want to address "yesterday" on instances
of this class, or "the year 1789"...
[back to top]
Class: mo:PublishedLibretto - stable - level 2
PublishedLibretto
- A published libretto
[back to top]
Class: mo:PublishedLyrics - stable - level 2
PublishedLyrics
- Published lyrics, as a book or as a text file, for example
[back to top]
Class: mo:PublishedScore - stable - level 2
PublishedScore
- A published score (subclass of MusicalManifestation)
[back to top]
Class: mo:Record - stable - level 1
Record
- A published record (manifestation which first aim is to render the product of a recording)
[back to top]
Class: mo:Recording - stable - level 2
Recording
- A recording event.
Takes a sound as a factor to produce a signal (analog or digital).
The location of such events (if any) is the actual location of the corresponding
microphone or the "recording device".
[back to top]
Class: tl:RelativeTimeLine - stable - level 3
RelativeTimeLine
- A semi-infinite continuous timeline. Instances of RelativeTimeLine can
back audio/video signals, sounds. Such timelines can
be linked to a physical time line using the OriginMap.
[back to top]
Class: mo:ReleaseStatus - stable - level 1
ReleaseStatus
- Musical manifestation release status.
[back to top]
Class: mo:ReleaseType - stable - level 1
ReleaseType
- Release type of a particular manifestation, such as "album" or "interview"...
[back to top]
Class: mo:SACD - unstable - level 1
SACD
- Super Audio Compact Disc used as medium to record a musical manifestation.
[back to top]
Class: mo:Score - stable - level 2
Score
- Here, we are dealing with the informational object (the MusicalExpression), not the actually "published" score.
This may be, for example, the product of an arrangement process.
[back to top]
Class: mo:Show - stable - level 2
Show
- A show - a musical event lasting several days, in a particular venue. Examples can be
"The Magic Flute" at the Opera Bastille, August 2005, or a musical in the west end...
[back to top]
Class: mo:Signal - stable - level 1
Signal
- A subclass of MusicalExpression, representing a Signal. Realisation of a MusicalWork through both a Performance and a Recording.
[back to top]
Class: mo:SoloMusicArtist - stable - level 1
SoloMusicArtist
- Single person whose musical creative work shows sensitivity and imagination.
[back to top]
Class: mo:Sound - stable - level 2
Sound
- A subclass of MusicalExpression, representing a sound. Realisation of a MusicalWork during a musical Performance.
[back to top]
Class: mo:Stream - unstable - level 1
Stream
- Transmission over a network used as medium to broadcast a musical manifestation
[back to top]
Class: tl:TimeLine - stable - level 3
TimeLine
-
A time line -- a coherent "backbone" for addressing points and intervals.
We can consider the timeline backing an audio/video signal, the one
corresponding to the "physical" time, or even the one backing a score.
Here, we consider that the timeline is *also* its coordinate system, for
simplification purposes. In the DL version of the timeline ontology,
coordinate systems are defined through restrictions on the way to
address time points/intervals on a timeline.
[back to top]
Class: tl:TimeLineMap - stable - level 3
TimeLineMap
- Two time lines can be related, such as the one backing a continuous signal and
the one backing the digitized signal. This sort of relation is expressed through an instance
of a TimeLine map (eg. "the timeline backing this signal corresponds
to the physical timeline: point 0 on this timeline corresponds to the
20th of december at 5pm").
[back to top]
Class: mo:Torrent - unstable - level 1
Torrent
- Something available on the Bittorrent peer-2-peer filesharing network
[back to top]
Class: mo:Track - stable - level 1
Track
- A track on a particular record
[back to top]
Class: mo:Vinyl - unstable - level 1
Vinyl
- Vinyl used as medium to record a musical manifestation
[back to top]
Property: event:agent - stable - level 2
agent - Associates an event to an active agent.
Example: an engineer, a performer, a composer...
Property: mo:amazon_asin - stable - level 1
amazon_asin - Used to link a work or the expression of a work to its corresponding Amazon ASINs page.
Property: mo:arranged_in - unstable - level 2
arranged_in - Associates a work to an arrangement event where it was arranged
Property: mo:arrangement_of - unstable - level 2
arrangement_of - Associates an arrangement event to a work
Property: tl:atDateTime - stable - level 2
atDateTime - Place a time point on the universal time line by using xsd:dateTime.
Property: tl:atDuration - stable - level 3
atDuration - Place a time point on an abstract time line by expressing its distance to
the point 0, through xsd:duration (example: this instant is at 2s after 0 --> T2S)
Property: mo:available_as - stable - level 1
available_as - Relates a musical manifestation to a musical item (this album, and my particular cd). By using
this property, there is no assumption on wether the full content is available on the linked item.
To be explicit about this, you can use a sub-property, such as mo:item (the full manifestation
is available on that item) or mo:preview (only a part of the manifestation is available on
that item).
This is a subproperty of frbr:examplar.
Property: tl:beginsAtDateTime - stable - level 3
beginsAtDateTime - Links an interval on a physical timeline to its actual start point,
expressed using xsd:dateTime
Property: tl:beginsAtDuration - stable - level 3
beginsAtDuration - Links an interval on a semi-infinite continuous time line to its
start point, addressed using xsd:duration (duration between 0 and the
start point)
Property: mo:biography - stable - level 1
biography - Used to link an artist to their online biography.
Property: mo:bitsPerSample - stable - level 1
bitsPerSample - Associates a digital signal to the number a bits used to encode one sample. Range is xsd:int.
Property: mo:bpm - stable - level 2
bpm - Indicates the BPM of a MusicalWork or a particular Performance
Beats per minute: the pace of music measured by the number of beats occurring in 60 seconds.
Property: mo:channels - stable - level 1
channels - Associates a signal to the number of channels it holds (mono --> 1, stereo --> 2). Range is xsd:int.
Property: mo:collaborated_with - unstable - level 1
collaborated_with - Used to relate two collaborating people on a work.
Property: mo:compilation_of - unstable - level 1
compilation_of - Indicates that a musical manifestation is a compilation of several Signals.
Property: mo:compiled - unstable - level 1
compiled - Used to relate an person or a group of person who compiled the manifestation of a musical work.
Property: mo:compiler - unstable - level 1
compiler - Used to relate the manifestation of a musical work to a person or a group of person who compiled it.
Property: mo:composed_in - unstable - level 2
composed_in - Associates a MusicalWork to the Composition event pertaining
to its creation. For example, I might use this property to associate
the Magic Flute to its composition event, occuring during 1782 and having as
a mo:composer Mozart.
Property: mo:composer - stable - level 2
composer - Associates a composition event to the actual composer. For example,
this property could link the event corresponding to the composition of the
Magic Flute in 1782 to Mozart himself (who obviously has a FOAF profile:-) ).
Property: mo:conducted - unstable - level 2
conducted - Relates agents to the performances they were conducting
Property: mo:conductor - stable - level 2
conductor - Relates a performance to the conductor involved
Property: mo:contains_sample_from - unstable - level 1
contains_sample_from - Relates a signal to another signal, which has been sampled.
Property: mo:discography - stable - level 1
discography - Used to links an artist to an online discography of th