RFC: changes in the editorial part of MO
Yves Raimond
I just gave a try at merging the different proposals (Simon's, Zazi's
and Antoine's) made on this mailing list for making the editorial part
of the music ontology (record, releases, etc.) more consistent. I also
tried to keep it as close as possible to future evolutions of the
Musicbrainz DB schema, and in particular the "cultural identifier"
work. I think a clarification of that part of MO should be the bulk of
its next release.
So here it is, all in RDF/Turtle with in-line comments detailing the
problems we try to address, and an example (Sgt. Pepper's Lonely
Hearts Club Band). The RDF is available in the motools SVN [1].
@prefix mo: <http://purl.org/ontology/mo/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix event: <http://purl.org/NET/c4dm/event.owl#> .
@prefix tl: <http://purl.org/NET/c4dm/timeline.owl#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix : <#> .
# Three entities to consider
# 1) Cultural identifier (e.g. "Sgt. Pepper")
# - Issued from a recording session lasting 129 days, starting on
the 6th of December 1966
# 2) Tracklist
# - A set of tracks: Track 1 is ... Track 2 is ...
# - One cultural identifier may have many tracklists
# 3) Release (e.g. UK on the 1st of June 1967, US on the 2nd of June 1967)
# - One tracklist may have many releases
# Relationships to existing MO concepts
# 1)
# mo:Signal has been used for it so far, but this is confusing
(we want something higher-level)
# We want to keep a track of a recording session event, which
product is this cultural identifier
# 2)
# Corresponds to our current mo:Record
# 3)
# Not handled yet. We can model that as another event.
# We need to reconsider the status of mo:release_type and
mo:release_status when adding it
# Existing level 1 MO stuff
mo:Track a owl:Class .
mo:Record a owl:Class .
mo:Signal a owl:Class .
mo:track a owl:ObjectProperty; rdfs:domain mo:Record; rdfs:range mo:Track .
# 1) Cultural identifier
# Based on Zazi's email,
http://groups.google.com/group/music-ontology-specification-group/browse_thread/thread/8e1ec6cc68e2c035
mo:RecordingSession
a owl:Class;
rdfs:subPropertyOf event:Event .
# an mo:RecordingSession can be decomposed in several
performances/recordings using event:sub_event to be described in
further details
# also, we should add it to the range of mo:performer, mo:engineer etc.
mo:Album
a owl:Class ;
rdfs:subClassOf mo:MusicalExpression . # Matches Musicbrainz
terminology, but not sure if it is an appropriate name
mo:produced_album
a owl:ObjectProperty;
rdfs:domain mo:RecordingSession; rdfs:range mo:Album .
# 2) Tracklist
mo:Tracklist
a owl:Class;
owl:equivalentClass mo:Record . # Do we need that? Or can we keep
on using mo:Record?
# Adding Zazi's trackcount property
mo:track_count
a owl:DatatypeProperty;
rdfs:range mo:Tracklist .
# Handling multi-disc releases
mo:sub_tracklist
a owl:ObjectProperty;
rdfs:domain mo:Tracklist;
rdfs:range mo:Tracklist .
# 3) Release events
mo:ReleaseEvent
a owl:Class;
rdfs:subClassOf event:Event .
mo:label
a owl:ObjectProperty;
rdfs:domain mo:ReleaseEvent;
rdfs:subPropertyOf event:agent .
mo:released_record
a owl:ObjectProperty;
rdfs:domain mo:ReleaseEvent;
rdfs:range mo:Record ;
rdfs:subPropertyOf event:factor .
mo:release
a owl:ObjectProperty;
rdfs:domain mo:Record;
rdfs:range mo:ReleaseEvent;
owl:inverseOf mo:released_record .
# EXAMPLE
:session
a mo:RecordingSession ;
event:place <http://dbpedia.org/resource/Abbey_Road_Studios> ;
event:time [ tl:start "1966-12-06" ; tl:duration "P129D" ] ;
mo:performer <http://dbpedia.org/resource/The_Beatles> ;
mo:produced_album :album .
:album
a mo:Album;
dc:title "Sgt. Pepper's Lonely Hearts Club Band" ;
owl:sameAs <http://dbpedia.org/resource/Sgt._Pepper's_Lonely_Hearts_Club_Band>
;
mo:published_as :original_tracklist, :cd_tracklist .
:original_tracklist
a mo:Tracklist;
dc:title "Sgt. Pepper's Lonely Hearts Club Band (original tracklist)";
mo:sub_tracklist :disc1, :disc2 ;
mo:release :uk, :us .
:disc1
a mo:Tracklist;
dc:title "Sgt. Pepper's Lonely Hearts Club Band (original
tracklist, disc 1)";
mo:track_count 7;
mo:track :splhc, :wlhmf, :lsd, :gb, :fh, :slh, :bbmk .
:disc2
a mo:Tracklist;
dc:title "Sgt. Pepper's Lonely Hearts Club Band (original tracklist)";
mo:track_count 6;
mo:track :wwy, :wsf, :lr, :gmgm, :splhcr, :dl .
:cd_tracklist
a mo:Tracklist;
dc:title "Sgt. Pepper's Lonely Hearts Club Band (CD tracklist)";
mo:track_count 13 .
:uk
a mo:ReleaseEvent;
event:place [ rdfs:label "UK" ];
event:time [ tl:at "1967-06-01" ] .
:us
a mo:ReleaseEvent;
event:place [ rdfs:label "US" ];
event:time [ tl:at "1967-06-02" ] .
Let me know what you think. I am not convinced by the naming of things
(especially mo:Album), but does this separation in three concepts
makes sense?
Cheers!
y
Simon Reinhardt
Good to see this moving on! Here are my comments.
An album is a work to me rather than an expression. Creating a concept
for an album, deciding what material to put together and how, lyrics,
cover-art, that's all part of the album and it is work-stuff to me.
The problem with the name you mentioned is, I guess, that this entity
doesn't have to be an album, it could be a single or a compilation or
generally everything that MusicBrainz describes with the release type.
And the album is above the recording session - the Beatles could have
performed and recorded Sgt. Pepper several times and released those
new recordings. Well, they didn't but it sometimes happens. Especially
with complete live performances of albums.
Maybe you were just talking about something else but that's what
"album" usually means to me. :-)
Similarly I have a different understanding of releases. A release to
me is more than an event. It's a manifestation with a certain barcode
number (EAN/UPC) and other properties (catalogue numbers, sort of
packaging, contained media, tracklist, ...). A release might have
several events attached to it (this case is not covered by
MusicBrainz' new schema yet, I think) - this is usually the case for
European releases: the UK and Germany have different "release days" in
the week so one and the same release with the same EAN gets released
on different dates in different places. The USA often get a different
release, it might have the same tracklist (as in contained titles and
their order) but a different barcode number, different distributor,
different track times (because of a different master disc).
Catalogue numbers would be another identifier suitable for identifying
releases however they are more corse-grained than barcode numbers: two
releases with the same catalogue number might have a different barcode
number. And I have Japanese editions of albums from a English group
which contain additional stuff, so they are really different releases,
made by Japanese labels with their own catalogue numbers - but then
for some reason the catalogue number for the original label release is
on there as well. So it's not *that* suitable for exactly identifying
releases. :-)
Also in Japanese multi-disc releases each disc will have a catalogue
number of its own. Here the release catalogue number is either the one
of the first disc, a range or a superset. Examples: EPCE-5600~1
(containing discs EPCE-5600 and EPCE-5601), YRCN-90025 (containing
discs YRCN-90025 and YRBN-80008), PCCA-02839 (containing PCCA-02839-1
and PCCA-02839-2), AVCD-31594/B (containing AVCD-31594 and
AVCD-31594B).
But anyway, I got sidetracked, this catalogue number stuff doesn't
really have anything to do with the issues at hand. :-)
Now to the tracklists. I agree they should be shareable between
releases. Luckily RDF is flexible enough to allow this easily. In an
earlier iteration on MusicBrainz' new schema it was planned to not
"share" entities but instead build a completely hierarchical structure
where each release would have its own exclusive tracklist. Allowing
people to re-use and link to existing entities is not so easy editing-
wise.
But I'm forgetting multi-disc releases here. A release first of all
contains media (several CDs etc. - but what's that for online
releases? The different files?). Those media can contain all sorts of
stuff: audio-data in various formats, data tracks, DVD film stuff,
there can be multi-side media which either have different stuff on
both sides or the same stuff in different audio quality.
There's an abstraction over all that data which gives titles to
various structural units and therefore closely sticks to the structure
of the medium / several media. This abstraction, the tracklist, can be
very complex [1]. But it is important to remember that it relates to
the medium as is nicely illustrated by your Sgt. Pepper example. And
the tracklist sometimes doesn't reflect the actual data accurately
(hidden tracks, or [2]). Especially for vinyl releases where there are
no tracks it is just a convention to say "everything from roughly here
to roughly there in this signal I will call that". I think we need
some good properties to relate releases to media, releases to their
tracklist, parts of a tracklist to parts of the data on media (to CD
tracks or positions in a signal). Maybe also stuff to describe the
actual structural units of a medium (the actual tracks of a CD).
You might be able to come up with a generalised tracklist which
abstracts from the different media-bound tracklists and can be related
to an album. But normally I'd say tracklists are part of the release.
So, to summarise my view on the world of music (CD-centred):
A musician creates a concept for an album. They write material, they
arrange it, they perform it, they record that performance, they
engineer the recording, they put the result of that onto a master disc
and press discs from that. A concept for the cover and that is made
and realised, they discs get packaged into cases with booklets and
sold.
A special edition gets created by putting different stuff onto a
different master disc and so on. Later the original edition gets
repressed but sold under a different barcode number. All that stuff
happens.
Later they might perform the material again (maybe a different
arrangement), record it again and so on.
The entities here are Albums (the overall work), having several
Performances, Recordings, Releases. Different Albums can share a
Release as well (box set releases which combine CDs that have been
released separately before). Each Release has one or more Event, one
(zero?) or more Medium and a Tracklist. Different Releases can share a
Tracklist. Parts of Tracklists get related to parts of the data on a
Medium. How to describe the structure of Tracklists and the structure
of data on a Medium is to be figured out.
This is of course just my view, formed by what I found at MusicBrainz,
the different proposals made there and the stuff I saw when editing
there. MO approached things in a different way and I certainly don't
want to impose my view on it. :-)
The good thing is that RDF is so flexible that I could come up with
alternative concepts to describe my music in a different way and still
re-use parts of MO and provide mappings to others.
That's it for now ;-)
Simon
[1] http://en.wikipedia.org/wiki/BE_(Pain_of_Salvation_album)#Track_Listing.2FTitle_Meanings
[2] http://en.wikipedia.org/wiki/Sgt._Pepper's_Lonely_Hearts_Club_Band#Inner_groove
zazi
>
> Good to see this moving on! Here are my comments.
>
> An album is a work to me rather than an expression. Creating a concept
> for an album, deciding what material to put together and how, lyrics,
> cover-art, that's all part of the album and it is work-stuff to me.
your description more to the already existing Record concept (in my
opinion).
Of course Album isn't the right name for that concept and album exists
already as an Individual of a ReleaseType.
I tend more to SignalGroup (subClassOf MusicalExpression; the product of
a RecordingSession; the substitution of Yves' Album definition) or a
similar description because it is responsible to hold an ordered set of
recorded signals that can be released as a specific Record (with
cover-art etc.).
> The problem with the name you mentioned is, I guess, that this entity
> doesn't have to be an album, it could be a single or a compilation or
> generally everything that MusicBrainz describes with the release type.
> And the album is above the recording session - the Beatles could have
> performed and recorded Sgt. Pepper several times and released those
> new recordings. Well, they didn't but it sometimes happens. Especially
> with complete live performances of albums.
> Maybe you were just talking about something else but that's what
> "album" usually means to me. :-)
follow your idea, we need a concept that holds a set of MusicalWorks as
a Composition holds serveral Movements (I am right). Thus it is the most
abstract form of a set "tracks" e.g. an "album". However, we may re-use
here the Composition concept and explain the term composition like the
term composite of the OO design pattern Composite and leave the domain
of classical composition (maybe it is already the intend of that
concept).
That's maybe the way I like to do it. It should be possible to select
one MusicalWork instance, where I can browse to all released Records
(linked to the Mediums over the property available_as) that includes a
copy or transformation of a recorded Signal (of a SignalGroup, whatever,
trust me expressing such terms in German is quite harder ;) ) of that
MusicalWork.
> Similarly I have a different understanding of releases. A release to
> me is more than an event. It's a manifestation with a certain barcode
> number (EAN/UPC) and other properties (catalogue numbers, sort of
> packaging, contained media, tracklist, ...). A release might have
> several events attached to it (this case is not covered by
> MusicBrainz' new schema yet, I think) - this is usually the case for
> European releases: the UK and Germany have different "release days" in
> the week so one and the same release with the same EAN gets released
> on different dates in different places. The USA often get a different
> release, it might have the same tracklist (as in contained titles and
> their order) but a different barcode number, different distributor,
> different track times (because of a different master disc).
my descriptions the product of a Release (subClassOf:Event) is a Record,
because it holds the date and the place of the release. Furthermore, the
Record is available_as a Medium (subClassOf MusicalItem) and this Medium
instance holds the barcode number or similar properties that are
releated to that specific exemplar of the Manifestation Record.
> Catalogue numbers would be another identifier suitable for identifying
> releases however they are more corse-grained than barcode numbers: two
> releases with the same catalogue number might have a different barcode
> number.
instances of that Record.
> And I have Japanese editions of albums from a English group
> which contain additional stuff, so they are really different releases,
> made by Japanese labels with their own catalogue numbers - but then
> for some reason the catalogue number for the original label release is
> on there as well. So it's not *that* suitable for exactly identifying
> releases. :-)
> Also in Japanese multi-disc releases each disc will have a catalogue
> number of its own. Here the release catalogue number is either the one
> of the first disc, a range or a superset. Examples: EPCE-5600~1
> (containing discs EPCE-5600 and EPCE-5601), YRCN-90025 (containing
> discs YRCN-90025 and YRBN-80008), PCCA-02839 (containing PCCA-02839-1
> and PCCA-02839-2), AVCD-31594/B (containing AVCD-31594 and
> AVCD-31594B).
> But anyway, I got sidetracked, this catalogue number stuff doesn't
> really have anything to do with the issues at hand. :-)
Medium holds a Record. For Example: 2 CDs, 8 Vinyls and 36 MP3s. Thus a
group per ReleaseType per Record is necessary.
>
> Now to the tracklists. I agree they should be shareable between
> releases. Luckily RDF is flexible enough to allow this easily. In an
> earlier iteration on MusicBrainz' new schema it was planned to not
> "share" entities but instead build a completely hierarchical structure
> where each release would have its own exclusive tracklist. Allowing
> people to re-use and link to existing entities is not so easy editing-
> wise.
> But I'm forgetting multi-disc releases here. A release first of all
> contains media (several CDs etc. - but what's that for online
> releases? The different files?).
without multiple instances of one ReleaseType. I don't really know where
to put this property to hold a group of Mediums per ReleaseType. Maybe
in the Medium class. However, how can someone restrict this list to hold
just instances of one specific ReleaseType? (OWL-DL guys where are you? ;) )
> Those media can contain all sorts of
> stuff: audio-data in various formats, data tracks, DVD film stuff,
> there can be multi-side media which either have different stuff on
> both sides or the same stuff in different audio quality.
> There's an abstraction over all that data which gives titles to
> various structural units and therefore closely sticks to the structure
> of the medium / several media. This abstraction, the tracklist, can be
> very complex [1]. But it is important to remember that it relates to
> the medium as is nicely illustrated by your Sgt. Pepper example. And
> the tracklist sometimes doesn't reflect the actual data accurately
> (hidden tracks, or [2]). Especially for vinyl releases where there are
> no tracks it is just a convention to say "everything from roughly here
> to roughly there in this signal I will call that".
Between the tracks is in general a break of some seconds silence.
> I think we need
> some good properties to relate releases to media, releases to their
> tracklist, parts of a tracklist to parts of the data on media (to CD
> tracks or positions in a signal). Maybe also stuff to describe the
> actual structural units of a medium (the actual tracks of a CD).
> You might be able to come up with a generalised tracklist which
> abstracts from the different media-bound tracklists and can be related
> to an album. But normally I'd say tracklists are part of the release.
descriptions of that Track, without the "master"-signal from the record,
because the track copy has its own signal) of a Record to the instances
of the Medium a ReleaseType. This enable descriptions for example: Track
number 1 of the Record is "the same as" Track number 1 of CD 1 and Track
number 17 of the Record is "the same as" Track number 1 of CD 2.
>
> So, to summarise my view on the world of music (CD-centred):
>
> A musician creates a concept for an album.
> They write material, they
> arrange it, they perform it, they record that performance, they
> engineer the recording, they put the result of that onto a master disc
> and press discs from that.
RecordingSession.
> A concept for the cover and that is made
> and realised, they discs get packaged into cases with booklets and
> sold.
> A special edition gets created by putting different stuff onto a
> different master disc and so on. Later the original edition gets
> repressed but sold under a different barcode number. All that stuff
> happens.
of that Record.
> Later they might perform the material again (maybe a different
> arrangement), record it again and so on.
>
> The entities here are Albums (the overall work), having several
> Performances, Recordings, Releases. Different Albums can share a
> Release as well (box set releases which combine CDs that have been
> released separately before). Each Release has one or more Event, one
> (zero?) or more Medium and a Tracklist. Different Releases can share a
> Tracklist.
beetween different Record instances.
> Parts of Tracklists get related to parts of the data on a
> Medium. How to describe the structure of Tracklists and the structure
> of data on a Medium is to be figured out.
>
> This is of course just my view, formed by what I found at MusicBrainz,
> the different proposals made there and the stuff I saw when editing
> there. MO approached things in a different way and I certainly don't
> want to impose my view on it. :-)
frustrating for me, to see 10 ore more entries after a tracks search
with MusicBrainz, which can be related to at least one MusicalWork.
Cheers zazi
> The good thing is that RDF is so flexible that I could come up with
> alternative concepts to describe my music in a different way and still
> re-use parts of MO and provide mappings to others.
through an own metadata schema (MMD)?
> That's it for now ;-)
> Simon
>
> [1] http://en.wikipedia.org/wiki/BE_(Pain_of_Salvation_album)#Track_Listing.2FTitle_Meanings
> [2] http://en.wikipedia.org/wiki/Sgt._Pepper's_Lonely_Hearts_Club_Band#Inner_groove
> >
--------------------BEGIN-OF-SIGNATURE--------------------
Bob Ferris
website: http://elbklang.net
e-mail: za...@elbklang.net
--------------------END-OF-SIGNATURE----------------------
Simon Reinhardt
> I tend more to SignalGroup (subClassOf MusicalExpression; the product of
> a RecordingSession; the substitution of Yves' Album definition) or a
> similar description because it is responsible to hold an ordered set of
> recorded signals that can be released as a specific Record (with
> cover-art etc.).
> > Similarly I have a different understanding of releases. A release to
> > me is more than an event. It's a manifestation with a certain barcode
> > number (EAN/UPC) and other properties (catalogue numbers, sort of
> > packaging, contained media, tracklist, ...). A release might have
> > several events attached to it (this case is not covered by
> > MusicBrainz' new schema yet, I think) - this is usually the case for
> > European releases: the UK and Germany have different "release days" in
> > the week so one and the same release with the same EAN gets released
> > on different dates in different places. The USA often get a different
> > release, it might have the same tracklist (as in contained titles and
> > their order) but a different barcode number, different distributor,
> > different track times (because of a different master disc).
>
> Okay, your opinion that a release is the product of a release event. In
> my descriptions the product of a Release (subClassOf:Event) is a Record,
> because it holds the date and the place of the release. Furthermore, the
> Record is available_as a Medium (subClassOf MusicalItem) and this Medium
> instance holds the barcode number or similar properties that are
> releated to that specific exemplar of the Manifestation Record.
release is a thing which consists of packaging, several CDs, a
booklet, ...
You can either describe the actual thing you hold in your hand (a
MusicalItem) or the set of items with common properties (a
MusicalManifestation). This set should be defined in a way that at
least properties like the barcode are the same for each item.
This release then contains a CD which is what I call a medium. And it
can contain several of those. Again, you can either describe the thing
you hold in your hand or the set of CDs with common properties. The
former is what is useful data to most people, the latter is more
accurate and useful to collectors.
I'm not talking about online releases yet since they confuse me. ;-)
> > Catalogue numbers would be another identifier suitable for identifying
> > releases however they are more corse-grained than barcode numbers: two
> > releases with the same catalogue number might have a different barcode
> > number.
>
> So the catalogue number is more related to the Record than to the Medium
> instances of that Record.
normally related to a Release but they can also be related to a CD
(what I call a Medium).
> > And I have Japanese editions of albums from a English group
> > which contain additional stuff, so they are really different releases,
> > made by Japanese labels with their own catalogue numbers - but then
> > for some reason the catalogue number for the original label release is
> > on there as well. So it's not *that* suitable for exactly identifying
> > releases. :-)
> > Also in Japanese multi-disc releases each disc will have a catalogue
> > number of its own. Here the release catalogue number is either the one
> > of the first disc, a range or a superset. Examples: EPCE-5600~1
> > (containing discs EPCE-5600 and EPCE-5601), YRCN-90025 (containing
> > discs YRCN-90025 and YRBN-80008), PCCA-02839 (containing PCCA-02839-1
> > and PCCA-02839-2), AVCD-31594/B (containing AVCD-31594 and
> > AVCD-31594B).
> > But anyway, I got sidetracked, this catalogue number stuff doesn't
> > really have anything to do with the issues at hand. :-)
>
> So the problem is, we need to identify how many instances of a specific
> Medium holds a Record. For Example: 2 CDs, 8 Vinyls and 36 MP3s.
understandings of the term Medium. I use it as explained above, not
like MO does.
> Thus a group per ReleaseType per Record is necessary.
ReleaseType is a property of the Release or the ReleaseGroup.
> > Now to the tracklists. I agree they should be shareable between
> > releases. Luckily RDF is flexible enough to allow this easily. In an
> > earlier iteration on MusicBrainz' new schema it was planned to not
> > "share" entities but instead build a completely hierarchical structure
> > where each release would have its own exclusive tracklist. Allowing
> > people to re-use and link to existing entities is not so easy editing-
> > wise.
> > But I'm forgetting multi-disc releases here. A release first of all
> > contains media (several CDs etc. - but what's that for online
> > releases? The different files?).
>
> That is the available Record concept and the property available_as, but
> without multiple instances of one ReleaseType. I don't really know where
> to put this property to hold a group of Mediums per ReleaseType. Maybe
> in the Medium class. However, how can someone restrict this list to hold
> just instances of one specific ReleaseType? (OWL-DL guys where are you? ;) )
> > The entities here are Albums (the overall work), having several
> > Performances, Recordings, Releases. Different Albums can share a
> > Release as well (box set releases which combine CDs that have been
> > released separately before). Each Release has one or more Event, one
> > (zero?) or more Medium and a Tracklist. Different Releases can share a
> > Tracklist.
>
> So we have to put the "tracklist" to the SignalGroup, to share it
> beetween different Record instances.
for all Releases in a ReleaseGroup (annoyingly sticking to my
terminology here ;-) ). But often it is the same. In that case the
respective Releases (Records if you want) just point to the same
Tracklist resource, thus share it.
> > The good thing is that RDF is so flexible that I could come up with
> > alternative concepts to describe my music in a different way and still
> > re-use parts of MO and provide mappings to others.
>
> Yes, but why marked MusicBrainz RDF as deprecated and substitute it
> through an own metadata schema (MMD)?
adoption of the MB Web service because it was ackward to work with.
Since they introduced the XML Web service the adoption rate increased
a lot. Now it would certainly be nice if they'd publish RDF themselves
again but for now he leaves it to others to figure out the mapping to
RDF which is probably not bad either because it gives us more freedom
in designing it.
Regards,
Simon
Marcelo Albuquerque
Reading the emails, I decided to give my humble contribution.
I see that the main point is to define what the concepts are necessary
to represent information about music and then think about the
relationships between them.
I've been researching the concepts of metadata and various standards
that are used to represent information about music and musical sound
in collections and confirmed my initial hypothesis that there is no
standard for the objective to represent/provide information on this
domain (this is evidenced by several publications that indicate that
each institution or person using concepts and metadata to your
specific needs).
Based on FRBR, that is a model to structuring of bibliographic
resources toward more books, the MO is the beginning of that I call
Conceptual Model Base, but due to its origin (FRBR) some points are
difficult to be understood as, for example, the issue of "Work" (And
you can include several types of items, it had ambiguous meaning,
because now you can reference a song, sometimes all the achievements
of a career musician and other time you can treat of an album).
So I think the first thing to be done is to achieve a broad debate to
try to establish a path that is used as a standard, because if this is
not done efforts alone will be for nothing, because each will continue
to apply concepts, relations and metadata according to their needs.
Thus it is important to build a Conceptual Model Base, so it becomes a
standard for structural and semantic representation of music in
information systems, and can solve some of our problems.
Cheers
Marcelo Albuquerque
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Yves Raimond
>
> An album is a work to me rather than an expression. Creating a concept
> for an album, deciding what material to put together and how, lyrics,
> cover-art, that's all part of the album and it is work-stuff to me.
> The problem with the name you mentioned is, I guess, that this entity
> doesn't have to be an album, it could be a single or a compilation or
> generally everything that MusicBrainz describes with the release type.
> And the album is above the recording session - the Beatles could have
> performed and recorded Sgt. Pepper several times and released those
> new recordings. Well, they didn't but it sometimes happens. Especially
> with complete live performances of albums.
> Maybe you were just talking about something else but that's what
> "album" usually means to me. :-)
created the same way as Sgt. Pepper was. Most of the time, albums do
not have a musical work backing them. Rather, a collection of works is
backing them. Anyway, I think we should leave some flexibility here,
and MO is already quite well suited for that.
Also, I agree my use of the term "album" was not particularly good, I
am happy to use another term.
disagree (although there's obviously a terminology problem).
Just to add a couple of requirements:
1) We should not change too much MO. Of course, we should aim at not
breaking existing data. So the newly introduced concepts should fit
nicely in the current structure, or preferably just clarify the
existing structure.
2) These changes should only be related to editorial things (passed
the recording step).
With that in mind, I think your comments lead to the following questions:
1) What should we call the "mo:Album" concept in my example? Zazi
proposed mo:SignalGroup, which would make sense, given mo:Signal.
2) For release-specific information, I see two options. Either we keep
the ReleaseEvent, and add a product of it which would be a mo:Release.
Either we consider the mo:Record as release-specific - that would mean
that for a CD release and a Vinyl release, you would have two
mo:Record instances. The latter has the advantage of being simpler,
and is currently used that way (mainly for Musicbrainz mapping
reasons). And it also has the advantage of matching the FRBR
manifestation definition.
3) We need more terms for handling the relationships between tracks
and parts of a medium than the current mo:track and mo:track_number,
which could be used to relate a track to a part of a physical medium.
I will update my proposal to reflect your comments.
Cheers!
y
zazi
Yves Raimond schrieb:
>
>> An album is a work to me rather than an expression. Creating a concept
>> for an album, deciding what material to put together and how, lyrics,
>> cover-art, that's all part of the album and it is work-stuff to me.
>> The problem with the name you mentioned is, I guess, that this entity
>> doesn't have to be an album, it could be a single or a compilation or
>> generally everything that MusicBrainz describes with the release type.
>> And the album is above the recording session - the Beatles could have
>> performed and recorded Sgt. Pepper several times and released those
>> new recordings. Well, they didn't but it sometimes happens. Especially
>> with complete live performances of albums.
>> Maybe you were just talking about something else but that's what
>> "album" usually means to me. :-)
>
> Hmm. I don't know if I agree. I would argue that most albums are not
> created the same way as Sgt. Pepper was. Most of the time, albums do
> not have a musical work backing them. Rather, a collection of works is
> backing them. Anyway, I think we should leave some flexibility here,
> and MO is already quite well suited for that.
the intellectual property rights etc. In Germany we have a couple of law
to protect intellectual creations. So I think, if a song is a kind of
MusicalWork a set of songs must also be a kind of MusicalWork.
Generally, the problem in most of the misunderstanding cases, is the
incomplete explanation of the usage of the different concepts and their
relationships to satisfy different usecases. I think the MO holds many
undocumented usecases. Fortunately, this will be done in the future.
1. We have a SignalGroup or something like at the Expression level. This
is a kind of "pre-release", which may holds all "tracks" that are
related to a "album" for publishing in different countries etc.
2. A "release" at the Manifestation contains the full range (that means
also all bonus tracks etc.) of "tracks" that are included into that
SignalGroup or less (maybe the basic set of "tracks" for that "album").
3. This concepts are connected through the Release(Event) concept.
4. (the really new interpretation ;) ): A physical exemplar of that
"release" in form of a CD(-set), Vinyl(-set), Mp3-set etc. is a copy of
that "release" (so we are now at the Item level). Therefore I suggest a
new subclass of MusicalItem called MediumTrack. The class instances of
MediumTrack are related to Track instances of the "release" through the
new property track, which is a subPropertyOf item (or maybe we can do
that about signal/signal mapping, because every Track carries a Signal
instance). Furthermore, we have to connect the MediumTrack instances to
a specific Medium instance through the property medium or mediumTrack
(the discussion ground of the point 3) here). For example the Medium
instance of the CD copy of the "release" contains 16 MediumTrack
instances that are mapped to the Track instances of that "release". I
think Yves mention something like track/track mapping over the releated
Signal instance, which sounds really good for me.
Finally, with that interpretation of "copy" we lost the level of a
personal copy of a CD-Album. So there are two solutions:
1. We get rid of the personal copy in our modelling. Where do we need
that? Do anyone have some examples for an usecase?
2. We move the described changes one level higher and prefer the way as
it is (in my opinion) also currently done that a Record instance holds a
particular [Medium]-"album" (set of "tracks") and for another medium we
need an extra Record instance.
Cheers zazi
> 3) We need more terms for handling the relationships between tracks
> and parts of a medium than the current mo:track and mo:track_number,
> which could be used to relate a track to a part of a physical medium.
>
> I will update my proposal to reflect your comments.
>
> Cheers!
> y
>
>
>> That's it for now ;-)
>> Simon
>>
>> [1] http://en.wikipedia.org/wiki/BE_(Pain_of_Salvation_album)#Track_Listing.2FTitle_Meanings
>> [2] http://en.wikipedia.org/wiki/Sgt._Pepper's_Lonely_Hearts_Club_Band#Inner_groove
>
> >
zazi
here are my solution of the proposed changes:
--------------------------------------------------------------------------
The recording session concept:
mo:RecordingSession
a owl:Class ;
rdfs:comment "This Class is the composite of several recordings,
which should hold a MusicalWork instance with several Movement
instances."^^xsd:string ;
rdfs:label "recording session"^^xsd:string ;
rdfs:subClassOf event:Event ;
mo:level "2" ;
owl:equivalentClass
[ a owl:Restriction ;
owl:minCardinality "1"^^xsd:int ;
owl:onProperty mo:signalGroup
] ;
owl:equivalentClass
[ a owl:Restriction ;
owl:minCardinality "1"^^xsd:int ;
owl:onProperty mo:recording
] ;
vs:term_status "unstable" .
mo:recording
a owl:ObjectProperty ;
rdfs:comment "This property restricts the containing sub events
of a RecordSession to Recording instances"^^xsd:string ;
rdfs:domain mo:RecordingSession ;
rdfs:label "recording"^^xsd:string ;
rdfs:range mo:Recording ;
rdfs:subPropertyOf event:sub_event ;
mo:level "2" ;
vs:term_status "unstable" .
mo:signalGroup
a owl:ObjectProperty ;
rdfs:comment "This property maps the product of a RecordSession
to a SignalGroup instance."^^xsd:string ;
rdfs:domain mo:RecordingSession ;
rdfs:label "signalgroup"^^xsd:string ;
rdfs:range mo:SignalGroup ;
rdfs:subPropertyOf event:product ;
mo:level "2" ;
vs:term_status "unstable" .
The recording session event produces a signal group from a set of
recordings and connects the MusicalWork instance to the produced
SignalGroup instance.
---------------------------------------------------------------------------
The signal group concept:
mo:SignalGroup
a owl:Class ;
rdfs:comment "This Class is the composite of several Signal
instances, that are the result of one RecordSession."^^xsd:string ;
rdfs:label "signal group"^^xsd:string ;
rdfs:subClassOf mo:MusicalExpression ;
mo:level "2" ;
owl:equivalentClass
[ a owl:Restriction ;
owl:minCardinality "1"^^xsd:int ;
owl:onProperty mo:signal
] ;
owl:equivalentClass
[ a owl:Restriction ;
owl:cardinality "1"^^xsd:int ;
owl:onProperty mo:musicalWork
] ;
vs:term_status "unstable" .
mo:musicalWork
a owl:ObjectProperty ;
rdfs:comment "This property releates a signal group to is musical
work e.g. a production of an album to its abstract album, because the
artist can also record an album and that concludes into a new signal
group."^^xsd:string ;
rdfs:domain mo:SignalGroup ;
rdfs:label "musical work"^^xsd:string ;
rdfs:range mo:MusicalWork ;
rdfs:subPropertyOf event:factor ;
mo:level "1" ;
vs:term_status "unstable" .
mo:signal
a owl:ObjectProperty ;
rdfs:comment "This property is the hook for a set of Signal
instances. It should hold at least one Signal instance."^^xsd:string ;
rdfs:domain mo:SignalGroup ;
rdfs:label "signal"^^xsd:string ;
rdfs:range mo:Signal ;
mo:level "2" ;
vs:term_status "unstable" .
This is the pre-release-container to hold a set of signals that can be
included into different releases.
---------------------------------------------------------------------------
The release event concept:
mo:Release
a owl:Class ;
rdfs:comment "This is the release event that gets as input factor
a SignalGroup instance and procudes one ore more RecordPackage
instance(s), which contains one ore more Record instances of a specific
ReleaseType."^^xsd:string ;
rdfs:label "release event"^^xsd:string ;
rdfs:subClassOf event:Event ;
mo:level "1" ;
owl:equivalentClass
[ a owl:Restriction ;
owl:minCardinality "1"^^xsd:int ;
owl:onProperty mo:recordPackage
] ;
owl:equivalentClass
[ a owl:Restriction ;
owl:minCardinality "1"^^xsd:int ;
owl:onProperty mo:releasedSignal
] ;
vs:term_status "unstable" .
mo:label
a owl:ObjectProperty ;
rdfs:comment "This property relates a release to a specific label
that releases for that release one or more record packages (of maybe a
specific medium)."^^xsd:string ;
rdfs:domain mo:Release ;
rdfs:label "release label"^^xsd:string ;
rdfs:range mo:Label ;
rdfs:subPropertyOf event:agent ;
mo:level "1" ;
vs:term_status "unstable" .
mo:recordPackage
a owl:ObjectProperty ;
rdfs:comment "This is the product relation of a release event. It
can be used to model a release of a set of signals (maybe from a signal
group to get its relation to musical work) that will be released in a
specific country at a specific date. This result can also be a set of
record packages - one for a specific medium (e.g. CD, vinyl,
Mp3)."^^xsd:string ;
rdfs:domain mo:Release ;
rdfs:label "produced record package"^^xsd:string ;
rdfs:range mo:RecordPackage ;
rdfs:subPropertyOf event:product ;
mo:level "1" ;
vs:term_status "unstable" .
mo:releasedSignal
a owl:ObjectProperty ;
rdfs:comment "With that property it is possible to attach a
complete group of signals (SignalGroup) to a release or just a fine
selection of single single that are from different signal
groups."^^xsd:string ;
rdfs:domain mo:Release ;
rdfs:label "released signal set"^^xsd:string ;
rdfs:range mo:SignalGroup , mo:Signal ;
rdfs:subPropertyOf event:factor ;
mo:level "1" ;
vs:term_status "unstable" .
The release event produces record packages from one specific signal
group or a selection of single signals, which are included into
different SignalGroup instances (maybe for a compilation or something
like that). I think the range of releasedSignal needs therefore a
specific restriction (union: SignalGroup or (Set of Signals)).
---------------------------------------------------------------------------
The record package concept:
mo:RecordPackage
a owl:Class ;
rdfs:comment "This the container that holds one ore more Record
instances of a specific medium (CD, Vinyl, Mp3). Furthermore, it has
relations to the cover-art, libretto etc."^^xsd:string ;
rdfs:label "record package"^^xsd:string ;
rdfs:subClassOf mo:MusicalManifestation ;
mo:level "1" ;
vs:term_status "unstable" .
mo:catalogue_number
a owl:FunctionalProperty ;
rdfs:comment "This is the catalogue number of a specific record
package of a release."^^xsd:string ;
rdfs:domain mo:RecordPackage ;
rdfs:label "catalogue number"^^xsd:string ;
rdfs:range xsd:string ;
mo:level "1" ;
vs:term_status "unstable" .
mo:record
a owl:ObjectProperty ;
rdfs:comment "This propery connects to Record instances that are
included into a record package."^^xsd:string ;
rdfs:domain mo:RecordPackage ;
rdfs:label "record"^^xsd:string ;
rdfs:range mo:Record ;
mo:level "1" ;
vs:term_status "unstable" .
This is the container to hold one or more Record instances.
---------------------------------------------------------------------------
The track concept (only extensions and changes):
mo:Track
a owl:Class ;
rdfs:comment "A track on a particular record" ;
rdfs:isDefinedBy mo: ;
rdfs:label "Track" ;
rdfs:subClassOf mo:MusicalManifestation ;
mo:level "1" ;
vs:term_status "stable" .
mo:orginated_signal
a owl:ObjectProperty ;
rdfs:comment "This property links to the originated signal of that
track. This enable mappings like signal 3 of this signal group relates
to track 4 at cd 1 (as Record instance) of this record
package."^^xsd:string ;
rdfs:domain mo:Track ;
rdfs:label "originated signal"^^xsd:string ;
rdfs:range mo:Signal ;
mo:level "1" ;
vs:term_status "unstable" .
mo:track_signal
a owl:ObjectProperty ;
rdfs:comment "This property links to the signal behind the track,
often this signal is of lesser quality then the master
signal."^^xsd:string ;
rdfs:domain mo:Track ;
rdfs:label "track signal"^^xsd:string ;
rdfs:range mo:Signal ;
mo:level "1" ;
vs:term_status "unstable " .
I like to associate the underlying track signal and also the signal
where this "copy" comes from. Of course, there exists also the property
encodes for MusicalItem, where signal mapping is covered, but I think it
is better placed at the Track domain.
Furthermore, I moved the Track class as a sibiling of Record and not a
sub class, because this classes should be disjoint (as it was also in
discussion).
---------------------------------------------------------------------------
The counter property for record and track counting:
mo:count
a owl:FunctionalProperty ;
rdfs:comment "This is a counter property for record packages (as
record counter) and records (as track counter)."^^xsd:string ;
rdfs:domain mo:Record , mo:RecordPackage ;
rdfs:label "counter"^^xsd:string ;
rdfs:range xsd:integer ;
mo:level "1" ;
vs:term_status "unstable " .
---------------------------------------------------------------------------
I'm not sure about the usage of the minimal cardinality restriction and
the some values from restriction, if I like to say that there must at
least one value of that property from that class and only from that
class. Per definition someValueFrom says that there must at least one
value from that class, but the property can also have values from other
classes.
Cheers zazi
Yves Raimond
perhaps worth renaming it to mo:signal_group
> The recording session event produces a signal group from a set of
> recordings and connects the MusicalWork instance to the produced
> SignalGroup instance.
>
> ---------------------------------------------------------------------------
>
> The signal group concept:
>
> mo:SignalGroup
> a owl:Class ;
> rdfs:comment "This Class is the composite of several Signal
> instances, that are the result of one RecordSession."^^xsd:string ;
> rdfs:label "signal group"^^xsd:string ;
> rdfs:subClassOf mo:MusicalExpression ;
> mo:level "2" ;
> owl:equivalentClass
> [ a owl:Restriction ;
> owl:minCardinality "1"^^xsd:int ;
> owl:onProperty mo:signal
> ] ;
> owl:equivalentClass
> [ a owl:Restriction ;
> owl:cardinality "1"^^xsd:int ;
> owl:onProperty mo:musicalWork
> ] ;
> vs:term_status "unstable" .
>
grasp (or even changing the name, if we find a better one).
> mo:musicalWork
> a owl:ObjectProperty ;
> rdfs:comment "This property releates a signal group to is musical
> work e.g. a production of an album to its abstract album, because the
> artist can also record an album and that concludes into a new signal
> group."^^xsd:string ;
> rdfs:domain mo:SignalGroup ;
> rdfs:label "musical work"^^xsd:string ;
> rdfs:range mo:MusicalWork ;
> rdfs:subPropertyOf event:factor ;
> mo:level "1" ;
> vs:term_status "unstable" .
>
more explicit.
etc.) includes records, not signals? I think this would be perhaps
clearer to have a clear {signalgroup --> record --> release event}
workflow, without defining all possible relationships between these
three concepts (again, I am still not convinced by the naming).
>
---------------------------------------------------------------------------
>
> The track concept (only extensions and changes):
>
> mo:Track
> a owl:Class ;
> rdfs:comment "A track on a particular record" ;
> rdfs:isDefinedBy mo: ;
> rdfs:label "Track" ;
> rdfs:subClassOf mo:MusicalManifestation ;
> mo:level "1" ;
> vs:term_status "stable" .
>
> mo:orginated_signal
> a owl:ObjectProperty ;
> rdfs:comment "This property links to the originated signal of that
> track. This enable mappings like signal 3 of this signal group relates
> to track 4 at cd 1 (as Record instance) of this record
> package."^^xsd:string ;
> rdfs:domain mo:Track ;
> rdfs:label "originated signal"^^xsd:string ;
> rdfs:range mo:Signal ;
> mo:level "1" ;
> vs:term_status "unstable" .
>
> mo:track_signal
> a owl:ObjectProperty ;
> rdfs:comment "This property links to the signal behind the track,
> often this signal is of lesser quality then the master
> signal."^^xsd:string ;
> rdfs:domain mo:Track ;
> rdfs:label "track signal"^^xsd:string ;
> rdfs:range mo:Signal ;
> mo:level "1" ;
> vs:term_status "unstable " .
>
The good thing is that this published_as property has quite loose
semantics. If we just add SignalGroup to its range, then SignalGroup
is just "the set of audio stuff that gets out of an entire recording
session". Then, records linked to that SignalGroup are just "sets of
similar physical items that are in some way derived from the
SignalGroup".
> I like to associate the underlying track signal and also the signal
> where this "copy" comes from. Of course, there exists also the property
> encodes for MusicalItem, where signal mapping is covered, but I think it
> is better placed at the Track domain.
mp3 and the audio signal it encodes.
> Furthermore, I moved the Track class as a sibiling of Record and not a
> sub class, because this classes should be disjoint (as it was also in
> discussion).
>
> ---------------------------------------------------------------------------
>
> The counter property for record and track counting:
>
> mo:count
> a owl:FunctionalProperty ;
> rdfs:comment "This is a counter property for record packages (as
> record counter) and records (as track counter)."^^xsd:string ;
> rdfs:domain mo:Record , mo:RecordPackage ;
> rdfs:label "counter"^^xsd:string ;
> rdfs:range xsd:integer ;
> mo:level "1" ;
> vs:term_status "unstable " .
>
> ---------------------------------------------------------------------------
>
> I'm not sure about the usage of the minimal cardinality restriction and
> the some values from restriction, if I like to say that there must at
> least one value of that property from that class and only from that
> class. Per definition someValueFrom says that there must at least one
> value from that class, but the property can also have values from other
> classes.
>
Thanks for that again, that's really helpful!
Cheers,
y
> Cheers zazi
>
> >
>
zazi
Yves Raimond schrieb:
>> The recording session event produces a signal group from a set of
>> recordings and connects the MusicalWork instance to the produced
>> SignalGroup instance.
>>
>> ---------------------------------------------------------------------------
>>
>> The signal group concept:
>>
>> mo:SignalGroup
>> a owl:Class ;
>> rdfs:comment "This Class is the composite of several Signal
>> instances, that are the result of one RecordSession."^^xsd:string ;
>> rdfs:label "signal group"^^xsd:string ;
>> rdfs:subClassOf mo:MusicalExpression ;
>> mo:level "2" ;
>> owl:equivalentClass
>> [ a owl:Restriction ;
>> owl:minCardinality "1"^^xsd:int ;
>> owl:onProperty mo:signal
>> ] ;
>> owl:equivalentClass
>> [ a owl:Restriction ;
>> owl:cardinality "1"^^xsd:int ;
>> owl:onProperty mo:musicalWork
>> ] ;
>> vs:term_status "unstable" .
>>
>
> OK. Perhaps worth expending the comment, as it might be difficult to
> grasp (or even changing the name, if we find a better one).
>
>
>> mo:musicalWork
>> a owl:ObjectProperty ;
>> rdfs:comment "This property releates a signal group to is musical
>> work e.g. a production of an album to its abstract album, because the
>> artist can also record an album and that concludes into a new signal
>> group."^^xsd:string ;
>> rdfs:domain mo:SignalGroup ;
>> rdfs:label "musical work"^^xsd:string ;
>> rdfs:range mo:MusicalWork ;
>> rdfs:subPropertyOf event:factor ;
>> mo:level "1" ;
>> vs:term_status "unstable" .
>>
>
> I don't think we need it: the link is done by mo:RecordingSession
process and link directly the idea with its results, or how would you
direct from the finished production to its orgin?
appendix, but in this case it might be more explicit, because many
people see a release as our intention of a Record, or?
that Records include one or more Tracks and the origin Signals of that
Tracks are derived from the Signals, which are used in the ReleaseEvent
(a SignalGroup or a selection of single Signals from different
SignalGroups (for a compilation or something like that).
> I think this would be perhaps
> clearer to have a clear {signalgroup --> record --> release event}
> workflow, without defining all possible relationships between these
> three concepts (again, I am still not convinced by the naming).
RecordPackages (one per ReleaseType).
substitute through the ReleaseEvent and its surroundings, or? So I
think, they are on the same position and I don't know how to handle them
separately in this case. My point of view is, to use published_as for
unreleased songs and the ReleaseEvent for official copies, because one
can share also self-made production through his friend, or something
like that, you know what I mean?
>
>> mo:track_signal
>> a owl:ObjectProperty ;
>> rdfs:comment "This property links to the signal behind the track,
>> often this signal is of lesser quality then the master
>> signal."^^xsd:string ;
>> rdfs:domain mo:Track ;
>> rdfs:label "track signal"^^xsd:string ;
>> rdfs:range mo:Signal ;
>> mo:level "1" ;
>> vs:term_status "unstable " .
>>
>
> inverse of mo:published_as
kbps encoded Mp3 signal, which has a poorer quality than its high
quality "master" signal (from e.g. a SignalGroup).
So originated_signal links to the "master" signal, where track_signal
links to the encoded signal (and replaces maybe the encodes property
from MusicalItem).
>
> The good thing is that this published_as property has quite loose
> semantics. If we just add SignalGroup to its range, then SignalGroup
> is just "the set of audio stuff that gets out of an entire recording
> session". Then, records linked to that SignalGroup are just "sets of
> similar physical items that are in some way derived from the
> SignalGroup".
>
>> I like to associate the underlying track signal and also the signal
>> where this "copy" comes from. Of course, there exists also the property
>> encodes for MusicalItem, where signal mapping is covered, but I think it
>> is better placed at the Track domain.
>
> Yes, mo:encodes is really aimed to capture the relationship between an
> mp3 and the audio signal it encodes.
>
>> Furthermore, I moved the Track class as a sibiling of Record and not a
>> sub class, because this classes should be disjoint (as it was also in
>> discussion).
>>
>> ---------------------------------------------------------------------------
>>
>> The counter property for record and track counting:
>>
>> mo:count
>> a owl:FunctionalProperty ;
>> rdfs:comment "This is a counter property for record packages (as
>> record counter) and records (as track counter)."^^xsd:string ;
>> rdfs:domain mo:Record , mo:RecordPackage ;
>> rdfs:label "counter"^^xsd:string ;
>> rdfs:range xsd:integer ;
>> mo:level "1" ;
>> vs:term_status "unstable " .
>>
>> ---------------------------------------------------------------------------
>>
>
> Cool :)
FunctionalProperty maybe.
>
>> I'm not sure about the usage of the minimal cardinality restriction and
>> the some values from restriction, if I like to say that there must at
>> least one value of that property from that class and only from that
>> class. Per definition someValueFrom says that there must at least one
>> value from that class, but the property can also have values from other
>> classes.
>>
>
> Hmm. What property are you thinking of, here?
I'm sure if it makes in these cases a difference, when the ranges just
include one class and I define a restriction with someValuesFrom,
because there can't be instances of other classes for values of the
restricted property - if they exists they must be from that class and
with the someValuesFrom restriction I say that there must exist at least
one instance from the range class of that property.
>
>
> Thanks for that again, that's really helpful!
that extension it is maybe possible.
Cheers zazi
>
> Cheers,
> y
>
>
>> Cheers zazi
>>
>
> >
zazi
here is a graphical representation of the current proposals:
http://www1.inf.tu-dresden.de/~s9736463/mo-workflow_ext.png
just for integrating the new extensions into the production/publishing
workflow.
Cheers zazi
Yves Raimond
I think it is OK to leave one level of indirection.
:work a mo:MusicalWork.
:recording_session a mo:RecordingSession; event:factor :work;
event:product :signal_group; mo:performer ...
We don't need every single property linking any two concepts in the
ontology IMHO (we already have quite a lot of terms...)
Yes, it might be confusing. A release is not a release event.
On that, I will comment on your picture in your next email ;-)
The thing is try to keep the terms we have now, which are quite well
suited for online releases, and just add the minimal amount of terms
that would allow us to deal more neatly with albums/releases. I
*think* there is still room for mo:Record, even when there is a
mo:ReleaseEvent happening. However, it implies a bit of shuffling in
your workflow, which I will try to draw as well :)
>>
>>> mo:track_signal
>>> a owl:ObjectProperty ;
>>> rdfs:comment "This property links to the signal behind the track,
>>> often this signal is of lesser quality then the master
>>> signal."^^xsd:string ;
>>> rdfs:domain mo:Track ;
>>> rdfs:label "track signal"^^xsd:string ;
>>> rdfs:range mo:Signal ;
>>> mo:level "1" ;
>>> vs:term_status "unstable " .
>>>
>>
>> inverse of mo:published_as
>
> Why? This property should link to Signal behind the Track, e.g. the 128
> kbps encoded Mp3 signal, which has a poorer quality than its high
> quality "master" signal (from e.g. a SignalGroup).
> So originated_signal links to the "master" signal, where track_signal
> links to the encoded signal (and replaces maybe the encodes property
> from MusicalItem).
>
Hmm. You can have two distinct mo:Signal for these two signals (the
original one and the 128 kbps encoded mp3 signal).
:signal1 mo:published_as :track1 .
:track1 mo:available_as <test.mp3> .
<test.mp3> mo:encodes :signal2 .
:signal2 is the deteriorated signal, and :signal1 is the original one.
So I am not sure we need more terms to deal with that?
>>
>> The good thing is that this published_as property has quite loose
>> semantics. If we just add SignalGroup to its range, then SignalGroup
>> is just "the set of audio stuff that gets out of an entire recording
>> session". Then, records linked to that SignalGroup are just "sets of
>> similar physical items that are in some way derived from the
>> SignalGroup".
>>
>>> I like to associate the underlying track signal and also the signal
>>> where this "copy" comes from. Of course, there exists also the property
>>> encodes for MusicalItem, where signal mapping is covered, but I think it
>>> is better placed at the Track domain.
>>
>> Yes, mo:encodes is really aimed to capture the relationship between an
>> mp3 and the audio signal it encodes.
>>
>>> Furthermore, I moved the Track class as a sibiling of Record and not a
>>> sub class, because this classes should be disjoint (as it was also in
>>> discussion).
>
> Is this change okay?
>
Yes, I think so. This statement was a bit weird in the first place.
>>>
>>> ---------------------------------------------------------------------------
>>>
>>> The counter property for record and track counting:
>>>
>>> mo:count
>>> a owl:FunctionalProperty ;
>>> rdfs:comment "This is a counter property for record packages (as
>>> record counter) and records (as track counter)."^^xsd:string ;
>>> rdfs:domain mo:Record , mo:RecordPackage ;
>>> rdfs:label "counter"^^xsd:string ;
>>> rdfs:range xsd:integer ;
>>> mo:level "1" ;
>>> vs:term_status "unstable " .
>>>
>>> ---------------------------------------------------------------------------
>>>
>>
>> Cool :)
>
> I changed it to DatatypeProperty, because I misinterpreted the usage of
> FunctionalProperty maybe.
>
Yes, this should be a data type property.
>>
>>> I'm not sure about the usage of the minimal cardinality restriction and
>>> the some values from restriction, if I like to say that there must at
>>> least one value of that property from that class and only from that
>>> class. Per definition someValueFrom says that there must at least one
>>> value from that class, but the property can also have values from other
>>> classes.
>>>
>>
>> Hmm. What property are you thinking of, here?
>
> These properties where I now defined the cardinality restrictions, but
> I'm sure if it makes in these cases a difference, when the ranges just
> include one class and I define a restriction with someValuesFrom,
> because there can't be instances of other classes for values of the
> restricted property - if they exists they must be from that class and
> with the someValuesFrom restriction I say that there must exist at least
> one instance from the range class of that property.
>
I'll take a deeper look when we include these changes in the ontology.
Cheers, and thanks again for all that! I think we're getting close!
y
zazi
Yves Raimond schrieb:
Okay, if we attach the musical work as a factor to the RecordingSession
event it makes from the top-down approach no difference. However, how
would be the linking done if we have as input our mp3-file, which we
like to follow backwards to its musical work origin?
Of course, mo:Record is still part of the modified production/release
workflow.
I know that is currently also possible, but this is maybe a more direct
link to the signals.
:track1 mo:originated_signal signal1 .
:track mo:track_signal :signal2 ;
With that modelling it is easier to change the carrier medium of the
track(-signal), without changing the track_signal. Nevertheless, I think
in general, through every carrier medium change the track_signal will
also change, and there is at last for every track on a specific medium a
separate instance. So let us keep the existing modelling for that part
;) and skip these two Track properties.
Cheers zazi
Yves Raimond
>> We don't need every single property linking any two concepts in the
>> ontology IMHO (we already have quite a lot of terms...)
>
> Okay, if we attach the musical work as a factor to the RecordingSession
> event it makes from the top-down approach no difference. However, how
> would be the linking done if we have as input our mp3-file, which we
> like to follow backwards to its musical work origin?
http://dowhatimean.net/2006/06/an-rdf-design-pattern-inverse-property-labels
I think we should avoid creating too much inverse properties. We did
it a lot at the beginning of MO, and it tends to make MO difficult to
maintain (lots of terms...).
>> The thing is try to keep the terms we have now, which are quite well
>> suited for online releases, and just add the minimal amount of terms
>> that would allow us to deal more neatly with albums/releases. I
>> *think* there is still room for mo:Record,
>
> Of course, mo:Record is still part of the modified production/release
> workflow.
>
(Sorry, meant to respond to your other email, but am a bit lagging on
email these days :-) )
Cheers!
y
>
> Cheers zazi
>
> >
>
George Fazekas
Sorry for not replying to you before, I had lots of things to catch up
with.
I have read these mails with great interest and try to think of some
constructive critique from
two points of view: how extensible it is and whether the new concepts
map to record production practices.
I have to admit though that the life of music after the studio is not
at all my expertise.... so be sceptic.
First, the Recording Session concept has three fairly common uses:
#1 The recording of a particular song (precisely the performance(s) of
it) consisting of several physical recording events.
#2 A single event with strictly limited time span (usually much
shorter than 24 hours), where several
people come together to perform and assist. This may or may not be
recorded.
(Though the primary purpose is generally to make recordings, this is
not always the case, or more often the recordings are discarded.)
#3 A set of events (could span several days or months) where
recordings were made which are usually associated with one or more
particular released mo:Record.
The 1st is used by artists/producers, but #2 is significantly more
common though.
#3 is more of what people further up the workflow chain (eg Label/
Distributor types) talk about.
The original MO workflow description can cover all the above cases
very well and can be mapped on detailed record production practices.
However, I found it difficult to match the new concepts. If I
understand right, the use case is: be able to collect things for a
certain release event.
I think this could be done simply as an extension to existing MO
concepts, rather than rearranging them.
For consistency, I would call all container types xxxxxGroup: e.g.
SignalGroup :
a set of signals associated with the release (maybe recorded in very
different conditions wrt time, different sessions etc.. )
RecordingGroup : (instead of recording session) :
a set of recording events, e.g. I record a drum-kit with 8
microphones, a song or a set of songs. (the use of session makes this
very confusing)
RecordGroup :
a set of records published together (?), e.g. a group of mo:Tracks
would keep the RecordPackage concept for the broader description which
includes the libretto etc.. plus can model e.g. box sets by referring
to several
RecordGroups.
I would keep mo:Track as a subclass of Record and the mo:published_as
shortcut property intact.
This might be a very production centric view, and may have several
flaws in your use case, but it sounds more logical to me.
A uniform way of expressing collections or container types would be
easy to introduce for any concept.
What about a group of scores or lyrics booklets released at a specific
time...
Also, we should be able to group things together flexibly in an
independent hierarchy when needed.
e.g. it is rarely the case that a particular session produces a
particular signal group which is released. It is more likely a
composition from
a subset of several recording groups (sessions) or samples obtained
elsewhere.
hope this makes some sense.
best,
George
George Fazekas
maybe it would be more clear to call RecordPackage -> ReleasePackage
so it's explicit that it refers to things released by the event, a
pink panther, a gift voucher...
maybe shouldn't be a musical manifestation at all just a
frbr:Manifestation ...(?)
George
zazi
Thank you for your interesting answer and suggestions.
George Fazekas schrieb:
> Hello Zazi,
>
> Sorry for not replying to you before, I had lots of things to catch up
> with.
>
> I have read these mails with great interest and try to think of some
> constructive critique from
> two points of view: how extensible it is and whether the new concepts
> map to record production practices.
> I have to admit though that the life of music after the studio is not
> at all my expertise.... so be sceptic.
>
> First, the Recording Session concept has three fairly common uses:
Yes, of course, generally one can think about different uses of the
RecordingSession concept. My intention was just the third one ;)
>
> #1 The recording of a particular song (precisely the performance(s) of
> it) consisting of several physical recording events.
I think recordings for a RecordingSession should be these recordings
that cover a whole song (in the production/release workflow). So they
are the arrangement of single recordings of the parts of a song (e.g.
voice, drums, guitar).
>
> #2 A single event with strictly limited time span (usually much
> shorter than 24 hours), where several
> people come together to perform and assist. This may or may not be
> recorded.
> (Though the primary purpose is generally to make recordings, this is
> not always the case, or more often the recordings are discarded.)
This is the case of a jam session. I don't if it is necessary to keep
that kind of information. In my proposal the RecordingSession can have a
place (generally a studio) and a time (maybe a specific day, or a couple
of days, where the single recordings happened - so the RecordingSession
temporal information covers the range between the first recording and
the last recording of a MusicalWork realisation).
However, the aim of a RecordingSession in my proposal should be to
produce a SignalGroup that is linked to its abstract MusicalWork (during
the factor property of that event (as Yves suggest it) or during a
separate property for the signal group concept (my suggestion)).
>
> #3 A set of events (could span several days or months) where
> recordings were made which are usually associated with one or more
> particular released mo:Record.
That's more or less how I like to define it.
>
>
>
> The 1st is used by artists/producers, but #2 is significantly more
> common though.
> #3 is more of what people further up the workflow chain (eg Label/
> Distributor types) talk about.
Here is a small gap in the current modelling of MO.
>
> The original MO workflow description can cover all the above cases
> very well and can be mapped on detailed record production practices.
Yes, but a couple of people and I think that there is a gap in the
release workflow.
> However, I found it difficult to match the new concepts. If I
> understand right, the use case is: be able to collect things for a
> certain release event.
No, to have the opportunity that release R1 in country C1 includes the
same signals (recordings) of SignalGroup SG1 as release R2 in country C2
and that track T1 of compilation COMP1 encodes also signal S1 of SG1.
> I think this could be done simply as an extension to existing MO
> concepts, rather than rearranging them.
Currently, for it is a kind of parallel workflow:
1. produce a song and record it; the result is a signal, which a publish
at my personal website (so it is no offical release over a record
label; no ReleaseEvent is necessary)
2. the signal of the produced song should be published at serveral
release in different countries (so it is an offical release and has to
follow the ReleaseEvent)
>
> For consistency, I would call all container types xxxxxGroup: e.g.
> SignalGroup :
Good idea.
> a set of signals associated with the release (maybe recorded in very
> different conditions wrt time, different sessions etc.. )
>
> RecordingGroup : (instead of recording session) :
> a set of recording events, e.g. I record a drum-kit with 8
> microphones, a song or a set of songs. (the use of session makes this
> very confusing)
Okay, but couldn't the recording of a song also a single recording that
uses the sub_event property to hold all recordings that are include into
that song?
>
> RecordGroup :
> a set of records published together (?), e.g. a group of mo:Tracks
Okay, so you tend to rename Record to RecordGroup?
>
> would keep the RecordPackage concept for the broader description which
> includes the libretto etc.. plus can model e.g. box sets by referring
> to several
> RecordGroups.
Yes, of course, this is necessary and that was also my intention to link
the libretto, cover art etc. as it was proposed in a past answer.
>
> I would keep mo:Track as a subclass of Record and the mo:published_as
> shortcut property intact.
Can you explain your intention here a little bit more in detail. I don't
understand why to keep Track as a subclass of Record. Okay, the
published_as property can be used by both concepts, but a Record (or
RecordGroup) is maybe the publication of a SignalGroup and a Track is
the publication of a single Signal. Furthermore, if we like to establish
the relation from RecordPackage to Record (RecordGroup), we can not link
directly Tracks to a RecordPackage because the tracks a part of a record
that is part of the record package.
>
> This might be a very production centric view, and may have several
> flaws in your use case, but it sounds more logical to me.
> A uniform way of expressing collections or container types would be
> easy to introduce for any concept.
> What about a group of scores or lyrics booklets released at a specific
> time...
I though that a libretto is a group of lyrics.
> Also, we should be able to group things together flexibly in an
> independent hierarchy when needed.
> e.g. it is rarely the case that a particular session produces a
> particular signal group which is released. It is more likely a
> composition from
> a subset of several recording groups (sessions) or samples obtained
> elsewhere.
> hope this makes some sense.
The current design of the releasedSignal property is that the value can be
1. a set if single signals from different SignalGroup; this is generally
useful for compilations that one know the original of a specific track
("this track is taken from the album ...")
2. a single SignalGroup; to keep the relation to an abstract album
(MusicalWork); during the ReleaseEvent the signal-track-mapping will be
done to every medium-specific record package, e.g. record package A
consists of two vinyl Records that include 12 signals from the
SignalGroup and record package B consists of one CD Record that includes
all 15 signals from the SignalGroup (so it has e.g. all bonus tracks).
Finally, the goal of the proposal (which was more or less mentioned by a
couple of people before I published my opinion) is to keep the linkage
between a single release track of a specific recorded signal that
derives from an abstract album (MusicalWork). So when I search for
"Transmission" from Joy Division, I get just one result and browsing
through this result I can get all releases (medium-independent
ReleaseEvents in different countries, which can be the album where
"Transmission" is originally available or compilations (e.g. the sound
track from the film "Control", where a cover-version from that track is
available) where this track is published on and furthermore all mixes,
remixes, re-recordings etc.
... and to reply also to your next email ;)
> one more small thing..
>
> maybe it would be more clear to call RecordPackage -> ReleasePackage
> so it's explicit that it refers to things released by the event, a
> pink panther, a gift voucher...
> maybe shouldn't be a musical manifestation at all just a
> frbr:Manifestation ...(?)
Good idea, but then we have also to generalize the ReleaseEvent. I don't
if these two classes make the ground for a separate ontology. Maybe an
already existing ontology covers the release/publishing workflow and we
can reuse that concepts or expand them for the music domain.
Cheers zazi
>
> best,
> George
>
zazi
> Hello!
>
>
>>> We don't need every single property linking any two concepts in the
>>> ontology IMHO (we already have quite a lot of terms...)
>> Okay, if we attach the musical work as a factor to the RecordingSession
>> event it makes from the top-down approach no difference. However, how
>> would be the linking done if we have as input our mp3-file, which we
>> like to follow backwards to its musical work origin?
>
> Wrt. to inverse properties, I quite like that blog post by Richard:
> http://dowhatimean.net/2006/06/an-rdf-design-pattern-inverse-property-labels
>
> I think we should avoid creating too much inverse properties. We did
> it a lot at the beginning of MO, and it tends to make MO difficult to
> maintain (lots of terms...).
>
Yes, I've read that article. In my current definitions I left out the
inverse properties, because it was a little bit unclear how to define
this in my specific solution (but I think you know how to do that ;) ).
However, I prefer that design pattern, because it simplifies the
complexity of an ontology.
Regarding to that specific backward linking I like to explain an example:
During the analysis of my personal collection the MIR systems discovers
a new album that don't exists already in its huge distributed database
(therefore it has to request all specific services and datasets, where
it gets its information). So the systems likes to create a new entry for
that album. Therefore, is also the abstract album (MusicalWork) a part.
So it has to create an abstract album, without the production
information. So I have to by-pass the whole production workflow and
directly create a "working draft" instance of that abstact album
(MusicalWork). So I think it is a better place to provide that by-pass.
Okay, in this specific case the releated SignalGroup is also just a
"working draft" instance, because the real SignalGroup (model) isn't
available in the database.
Do you know what I mean? ;)
Cheers zazi