mo:catalogue_number domain is mo:Release not mo:ReleaseEvent
iand
I noticed that the domain of mo:catalogue_number is mo:Release yet the
domain of mo:label is mo:ReleaseEvent
My understanding was that a mo:ReleaseEvent represents the event of a
music label issuing a particular release. Since the catalogue number
is assigned by the label as part of this event, shouldn't the
mo:catalogue_number property have a domain of mo:ReleaseEvent?
Here's an example of a MusicBrainz release with 2 release events by
the same label (Epic) with different catalogue numbers (for different
formats)
http://musicbrainz.org/release/ef927fa4-2f6b-4431-8867-0573b0e9c234.html
Am I missing something obvious?
Ian
Bob Ferris
as far as I remember my own thoughts about this, a mo:ReleaseEvent could
be used to release several mo:Releases and each instances could be of a
different medium. Hence the catalogue number should be set there. If we
include the catalogue number into the mo:ReleaseEvent, you have to model
a new mo:ReleaseEvent instance for every medium specific release of that
"abstract album".
However, and that is also sometimes the question for myself (maybe we
have also answered them several times ;) ), the association to the
medium is on the item level (in general to have a medium independent
description of musical work/expression). mo:Medium is a subclass of
mo:MusicalItem. On could related a mo:MusicalManifestation to a
mo:MusicalItem by using the mo:available_as property (or mo:item for
user specific copies).
However, if I have a specific catalogue number assigned to my
mo:Release, the mo:available_as relation could only include one
mo:Medium. Hence, I need for each medium specific mo:Release instance
(described to its mo:catalogue_number) more or less only a relation like
mo:medium (re. the meaning).
Please have maybe also a look to the "overview" of the 4 levels of
FRBR[1] and the 4 levels of MO[2].
Cheers,
Bob
[1]
http://wiki.musicontology.com/index.php/Classes_Schemas#The_4_levels_of_the_FRBR_Ontology
[2]
http://wiki.musicontology.com/index.php/Classes_Schemas#The_4_levels_of_the_Music_Ontology
Ian Davis
> Hi Ian,
>
> as far as I remember my own thoughts about this, a mo:ReleaseEvent could be
> used to release several mo:Releases and each instances could be of a
> different medium. Hence the catalogue number should be set there. If we
> include the catalogue number into the mo:ReleaseEvent, you have to model a
> new mo:ReleaseEvent instance for every medium specific release of that
> "abstract album".
> However, and that is also sometimes the question for myself (maybe we have
> also answered them several times ;) ), the association to the medium is on
> the item level (in general to have a medium independent description of
> musical work/expression). mo:Medium is a subclass of mo:MusicalItem. On
> could related a mo:MusicalManifestation to a mo:MusicalItem by using the
> mo:available_as property (or mo:item for user specific copies).
> However, if I have a specific catalogue number assigned to my mo:Release,
> the mo:available_as relation could only include one mo:Medium. Hence, I need
> for each medium specific mo:Release instance (described to its
> mo:catalogue_number) more or less only a relation like mo:medium (re. the
> meaning).
I need to think about this a bit more. My understanding of FRBR (and I
may be a bit rusty since I wrote the FRBR schema 5 years ago) is that
Item represents a singe physical item, i.e. the copy of a particular
bok sitting on my desk. If you have a copy of the book then that is a
separate item.
Ian
Bob Ferris
Yes, that's why the mo:Medium concept and relation was and is discussed
a lot. I think for this reason, Yves (?) decoupled mo:MusicalItem from
frbr:Item[1].
There are two case:
1. A item independent, but medium specific description of an album. This
should be covered by mo:Release
2. A item specific description of an album. This is the concrete copy I
bought somewhere - my exemplar.
=> This is case is for me the true frbr:Item based case.
Cheers,
Bob
[1]
http://wiki.musicontology.com/index.php/Classes_Schemas#mo:MusicalItem_schema_.28extended.29
Yves Raimond
Definitely not - music releases are horribly complex :-/
Right now, in MO, there are three different "things" in a single release:
* The mo:Record - which is a particular disc with a given set of tracks
* The mo:Release - which is a bundle of discs, liner notes, etc.
* The mo:ReleaseEvent - which is an event involving a label, a
country, a date and a release.
The argument for mo:catalogue_number to be associated with the
mo:Release was that it is specific to this particular manifestation.
So for each barcode/catalogue number pair, you'd have a new release
object. Which itself may be associated with multiple release events
(for example, instead of creating a release event per 'region', you
might perfectly want to create one release event per country).
So if you link a FRBR item to a release, you know exactly all its
"physical" properties.
That is one bit of MO that is slightly different than Musicbrainz -
instead of having just one thing ('release' in the Mbz schema), we
have two (mo:Release and mo:ReleaseEvent). But one entry in the
'release' table in Mbz should correspond to one mo:Release, and
several mo:ReleaseEvent if you want to be more precise about the
release location (or other factors of the event).
I hope that's clearer :-/
Best,
y
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups "Music Ontology Specification Group" group.
> To post to this group, send email to music-ontology-sp...@googlegroups.com.
> To unsubscribe from this group, send email to music-ontology-specific...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/music-ontology-specification-group?hl=en.
>
>
Bob Ferris
I don't know, whether I get something wrong here, but the link Ian
provided[1], is a link to a "MB release group". As we've figured out, a
"MB release group" is a mo:SignalGroup and therefore on the
mo:MusicalExpression level.
That means, the different "MB release events" (mo:ReleaseEvent) are
derived from that mo:SignalGroup instance. The difference to MB is now,
that MO can describe such different "releases" (mo:Release) of each
mo:ReleaseEvent, e.g.
- a mo:Release instance for the medium CD
- a mo:Release instance for the medium Vinyl
- etc.
Of course, it should also be possible the other way around, that a
mo:Release instance could be associated to a several mo:ReleaseEvents,
but then the whole mo:Release instance must be exactly the same (same
cover art, same booklet, etc.).
I think the difficulty is the n:n relation from mo:ReleaseEvent to
mo:Release:
1. A mo:ReleaseEvent could produce several mo:Release instance (e.g.
each of a different medium)
2. A mo:Release could a associated to several mo:ReleaseEvent instances.
However, than it is more or less a reuse of an existing mo:Release
instance, which was published somewhere first, e.g. in a specific
country, and the follow up mo:ReleaseEvents are then in different countries.
Finally, I think someone has to write down some good examples, which
cover all the described cases.
Cheers,
Bob
[1] http://musicbrainz.org/release/ef927fa4-2f6b-4431-8867-0573b0e9c234.html
Simon Reinhardt
On Jul 22, 11:14 am, Yves Raimond <yves.raim...@gmail.com> wrote:
> * The mo:Record - which is a particular disc with a given set of tracks
> * The mo:Release - which is a bundle of discs, liner notes, etc.
> * The mo:ReleaseEvent - which is an event involving a label, a
> country, a date and a release.
>
> The argument for mo:catalogue_number to be associated with the
> mo:Release was that it is specific to this particular manifestation.
> So for each barcode/catalogue number pair, you'd have a new release
> object. Which itself may be associated with multiple release events
> (for example, instead of creating a release event per 'region', you
> might perfectly want to create one release event per country).
mo:Release. But why is mo:label attached to mo:ReleaseEvent? Shouldn't
it be a property of mo:Release for the same reason? After all a
barcode-unique release should usually have one and the same label, or?
mo:ReleaseEvent to me just covers the fact that releases come out on
different days in different countries. For example in Germany CDs come
out on a Friday whereas in the UK it's a Monday.
It's a shame that MusicBrainz won't implement multiple release events
in NGS. The database is already full of them so that will only mean
that you get duplicate release entries which only differ in date and
country - and that just gets confusing for the users.
Regards,
Simon
Yves Raimond
> On Jul 22, 11:14 am, Yves Raimond <yves.raim...@gmail.com> wrote:
>> * The mo:Record - which is a particular disc with a given set of tracks
>> * The mo:Release - which is a bundle of discs, liner notes, etc.
>> * The mo:ReleaseEvent - which is an event involving a label, a
>> country, a date and a release.
>>
>> The argument for mo:catalogue_number to be associated with the
>> mo:Release was that it is specific to this particular manifestation.
>> So for each barcode/catalogue number pair, you'd have a new release
>> object. Which itself may be associated with multiple release events
>> (for example, instead of creating a release event per 'region', you
>> might perfectly want to create one release event per country).
>
> I agree that mo:catalogue_number should be a property of the
> mo:Release. But why is mo:label attached to mo:ReleaseEvent? Shouldn't
> it be a property of mo:Release for the same reason? After all a
> barcode-unique release should usually have one and the same label, or?
> mo:ReleaseEvent to me just covers the fact that releases come out on
> different days in different countries. For example in Germany CDs come
> out on a Friday whereas in the UK it's a Monday.
You're absolutely right, as usual :-) I sort of thought of the label
as an 'agent' of a release event, which may have biased my views. I
just added it to:
http://wiki.musicontology.com/index.php/Todo_list
Cheers,
y
>
> It's a shame that MusicBrainz won't implement multiple release events
> in NGS. The database is already full of them so that will only mean
> that you get duplicate release entries which only differ in date and
> country - and that just gets confusing for the users.
>
> Regards,
> Simon
>
Bob Ferris
> Hello!
>
>> On Jul 22, 11:14 am, Yves Raimond<yves.raim...@gmail.com> wrote:
>>> * The mo:Record - which is a particular disc with a given set of tracks
>>> * The mo:Release - which is a bundle of discs, liner notes, etc.
>>> * The mo:ReleaseEvent - which is an event involving a label, a
>>> country, a date and a release.
>>>
>>> The argument for mo:catalogue_number to be associated with the
>>> mo:Release was that it is specific to this particular manifestation.
>>> So for each barcode/catalogue number pair, you'd have a new release
>>> object. Which itself may be associated with multiple release events
>>> (for example, instead of creating a release event per 'region', you
>>> might perfectly want to create one release event per country).
>>
>> I agree that mo:catalogue_number should be a property of the
>> mo:Release. But why is mo:label attached to mo:ReleaseEvent? Shouldn't
>> it be a property of mo:Release for the same reason? After all a
>> barcode-unique release should usually have one and the same label, or?
>> mo:ReleaseEvent to me just covers the fact that releases come out on
>> different days in different countries. For example in Germany CDs come
>> out on a Friday whereas in the UK it's a Monday.
>
> You're absolutely right, as usual :-) I sort of thought of the label
> as an 'agent' of a release event, which may have biased my views. I
> just added it to:
> http://wiki.musicontology.com/index.php/Todo_list
>
However, if you would like to create an release event for different
media, you have only to add the label one time at the release event,
where you have to add it several times on the on the different releases.
Although, you are right, barcode/catalogue number is in strong relation
with the label, but also in strong relation with the media type, which
should be related with the release.
barcode/catalogue number := 'abstract album' + label + medium + X (?)
Therefore, I would leave it as it currently is. I think more important
is the media relation on the manifestation level, or?
Cheers,
Bob
Simon Reinhardt
> However, if you would like to create an release event for different
> media, you have only to add the label one time at the release event,
> where you have to add it several times on the on the different releases.
> Although, you are right, barcode/catalogue number is in strong relation
> with the label, but also in strong relation with the media type, which
> should be related with the release.
versions of a release if they get released on the same day?
I think a release event should be considered part of a release (making
mo:release_event an inverse functional property?).
> barcode/catalogue number := 'abstract album' + label + medium + X (?)
> Therefore, I would leave it as it currently is. I think more important
> is the media relation on the manifestation level, or?
the copies that have been made. It is therefore independent of the
real item and on a higher abstraction level. (In a more event-based
model you can explain this by saying that there is a master CD (the
manifestation?) from which the copies have been made.)
Sure, you get pretty close to the physical level of items and there
are some characteristics of a medium that aren't the same for all
copies (like http://en.wikipedia.org/wiki/Matrix_numbers). But I think
it's important to be able to describe the media type across all
copies. Otherwise I can only describe my own copy and you wouldn't
know if it applies to others as well.
Regards,
Simon
Bob Ferris
> On Jul 26, 12:15 am, Bob Ferris<z...@elbklang.net> wrote:
>> However, if you would like to create an release event for different
>> media, you have only to add the label one time at the release event,
>> where you have to add it several times on the on the different releases.
>> Although, you are right, barcode/catalogue number is in strong relation
>> with the label, but also in strong relation with the media type, which
>> should be related with the release.
>
> Hmm, so you want to re-use a release event between different media
> versions of a release if they get released on the same day?
> I think a release event should be considered part of a release (making
> mo:release_event an inverse functional property?).
Then we don't really need an separate release event, if we can put all
the related properties (more or less release date, release country and
label) also in the release itself.
My use case here is
:AReleaseEvent a mo:ReleaseEvent ;
event:time [
a time:Instant ;
time:inXSDDateTime "2010-07-15T11:21:52+01:00"^^xsd:dateTime
] ;
mo:label :AllCityDublin ;
event:place :England .
:AllCityDublin a mo:Label .
:England a geo:SpatialThing .
:CDRelease a mo:Release ;
mo:medium mo:CD ;
mo:catalogue_number "1234"^^xsd:string .
:MCRelease a mo:Release ;
mo:medium mo:Magnetictape ;
mo:catalogue_number "1235"^^xsd:string .
:VinylRelease a mo:Release ;
mo:medium mo:Vinyl ;
mo:catalogue_number "1236"^^xsd:string .
Today, it is often the case that digital (MP3, ...) and analogue (CD,
vinyl, ...) releases have different release events.
>
>> barcode/catalogue number := 'abstract album' + label + medium + X (?)
>
> Not sure I understand this correctly.
The uniqueness of a barcode/catalogue number of an release consists of
the 'abstract album' (mo:SignalGroup), the label (mo:Label), and the
media type (mo:Medium) and X (maybe cover art, test pressings etc.)
>
>> Therefore, I would leave it as it currently is. I think more important
>> is the media relation on the manifestation level, or?
>
> To me it is. The fact that something was release on CD is true for all
> the copies that have been made. It is therefore independent of the
> real item and on a higher abstraction level. (In a more event-based
> model you can explain this by saying that there is a master CD (the
> manifestation?) from which the copies have been made.)
> Sure, you get pretty close to the physical level of items and there
> are some characteristics of a medium that aren't the same for all
> copies (like http://en.wikipedia.org/wiki/Matrix_numbers). But I think
> it's important to be able to describe the media type across all
> copies.
Yes, that's what I am also thinking. However, I'm a bit unsure, if we
can currently model that issue correct. We have mo:available_as, but if
the catalogue number is on the manifestation level, we need the medium
relation also there, or?
Cheers,
Bob
Simon Reinhardt
> Am 26.07.2010 00:40, schrieb Simon Reinhardt:
> > Hmm, so you want to re-use a release event between different media
> > versions of a release if they get released on the same day?
> > I think a release event should be considered part of a release (making
> > mo:release_event an inverse functional property?).
>
> Then we don't really need an separate release event, if we can put all
> the related properties (more or less release date, release country and
> label) also in the release itself.
"The release with the barcode xyz came out on Monday in the UK and on
Friday in Germany."
Nonetheless each of those release events are part of the release and
should not be re-used for other releases - that's what I think anyway.
> Today, it is often the case that digital (MP3, ...) and analogue (CD,
> vinyl, ...) releases have different release events.
Also you get regular editions and special editions being released on
the same day but I would still use separate release events for them.
> The uniqueness of a barcode/catalogue number of an release consists of
> the 'abstract album' (mo:SignalGroup), the label (mo:Label), and the
> media type (mo:Medium) and X (maybe cover art, test pressings etc.)
release with all it's properties very precisely. It will always have
the same number of tracks with the same audio, the same medium, etc.
Differences I've observed were in the matrix numbers on the CDs,
sometimes they get sold with or without surrounding boxes, and often
they put the barcode of the regular release on a promo (I even have a
promo that lists the barcodes of various editions of the album). But
promos are special because they're not regular trading items. And it's
not really *their* barcode.
With catalogue numbers it's different. They only get sort of unique
when combined with a label. But even then I've seen cases where
different releases of an album shared the same barcode so generally
the pair (catalogue number, label) is less unique than barcode.
And be aware that in Japan they don't (only) give catalogue numbers to
the releases but to each individual medium. :-)
> Yes, that's what I am also thinking. However, I'm a bit unsure, if we
> can currently model that issue correct. We have mo:available_as, but if
> the catalogue number is on the manifestation level, we need the medium
> relation also there, or?
Regards,
Simon
Bob Ferris
> On Jul 26, 1:18 am, Bob Ferris<z...@elbklang.net> wrote:
>> Am 26.07.2010 00:40, schrieb Simon Reinhardt:
>>> Hmm, so you want to re-use a release event between different media
>>> versions of a release if they get released on the same day?
>>> I think a release event should be considered part of a release (making
>>> mo:release_event an inverse functional property?).
>>
>> Then we don't really need an separate release event, if we can put all
>> the related properties (more or less release date, release country and
>> label) also in the release itself.
>
> We do because a release can have multiple release events:
>
> "The release with the barcode xyz came out on Monday in the UK and on
> Friday in Germany."
>
> Nonetheless each of those release events are part of the release and
> should not be re-used for other releases - that's what I think anyway.
Well, I still think it is a n:n relation between release event and
release as I've also described here[1].
Cheers,
Bob
[1]
http://groups.google.com/group/music-ontology-specification-group/msg/2beb7f8f387d5b25