> Thanks for the introduction, Robert -- and thanks in advance for the advice,
> Yves! I've signed up for the MO mailing list; I can repost these questions
> there if you like.
(cc'ing the MO list)
>
> Many of our questions have to do with the relationship between MusicBrainz's
> Next Generation Schema (NGS) and the Music Ontology. I see, for instance,
> that you have written mappings from the current MB schema to MO using D2RQ.
> Do you have any thoughts about similar mappings for the NGS? Were there any
> mappings that were particularly tricky for the first mapping you did?
I think it will be much simpler once Musicbrainz switch to the NGS. As
you may have noticed, we have quite a detailed model of
work/performances/etc., which was mainly driven by classical music
use-cases and live recordings/bootlegs. In the D2RQ mapping, I used
lots of small tricks to make the current Musicbrainz data (especially
the current advanced relationships) fit in such a model. The NGS work
will make Musicbrainz closer to this sort of model, and the D2RQ
mapping will then become a no-brainer, I hope :-)
The only thing that will need some thinking is the new "work" table in
the NGS, which covers everything from a musical work to a performance
to a recording session. We'll probably need to add some sub-types to
it to cover explicitly these different types of things. The BBC Music
team are quite keen on that as well, as it will simplify their work to
generate their RDF feeds.
>
> On an unrelated note, I'm interested in your thoughts on the proper
> representation of "solo" MusicArtists. For instance, consider the artist
> who calls himself "Sting". Not only is he a member of the MusicalGroup "The
> Police", but he also has a distinguished solo career. However, as a
> "soloist", he's not really performing alone; he has a lineup that contains
> regulars like Dominic Miller and Jason Rebello. In other words, a solo
> artist seems to share some properties with a MusicGroup.
>
> According to the MusicOntology, what is the correct way to model these
> relationships? As you can see, there's the potential to have things become
> rather tangled if we're not careful.
>
Hmm... Interesting :-) I think I would create two URIs for "Sting",
one which is the mo:SoloMusicArtist (the foaf:Person), so Sting
himself, and one which would be a mo:MusicalGroup, which would have as
a foaf:member Sting himself, Dominic Miller and Jason Rebello. Does
that make sense?
Cheers!
y
> Hmm... Interesting :-) I think I would create two URIs for "Sting",
> one which is the mo:SoloMusicArtist (the foaf:Person), so Sting
> himself, and one which would be a mo:MusicalGroup, which would have as
> a foaf:member Sting himself, Dominic Miller and Jason Rebello. Does
> that make sense?
>
I think it make sense. People have to take care of one thing: a label we
use to refer to something is not related to its identifier (URI).
So, I agree with Yves's suggestion. You would have a SoloMusicArtist.
This resource could have multiple names such as "Sting", "Gordon
Sumner", etc. Or you could create a mo:artistName with "Sting" as artist
name.
Then you create a MusicGroup named "Sting" with the SoloMusicArtist
described above as a member of the group. The same would be done for
"The Police".
Then, if you have some UI displaying this information, you would endup
with something like:
"Sting - the artist"
"Sting - the music group"
"The Police - the music group"
Take care,
Fred
On Wed, Jun 10, 2009 at 6:54 AM, Brian Karlak<zen...@metaweb.com> wrote:
>
> On Jun 9, 2009, at 9:09 AM, Yves Raimond wrote:
>
>>> On an unrelated note, I'm interested in your thoughts on the proper
>>> representation of "solo" MusicArtists. For instance, consider the artist
>>> who calls himself "Sting". Not only is he a member of the MusicalGroup
>>> "The
>>> Police", but he also has a distinguished solo career. However, as a
>>> "soloist", he's not really performing alone; he has a lineup that
>>> contains
>>> regulars like Dominic Miller and Jason Rebello. In other words, a solo
>>> artist seems to share some properties with a MusicGroup.
>>>
>>
>> Hmm... Interesting :-) I think I would create two URIs for "Sting",
>> one which is the mo:SoloMusicArtist (the foaf:Person), so Sting
>> himself, and one which would be a mo:MusicalGroup, which would have as
>> a foaf:member Sting himself, Dominic Miller and Jason Rebello. Does
>> that make sense?
>
> Yes, this definitely seems likes one correct solution. As Fredrick points
> out, it's important to keep the label separate from the identifier, and
> modeling Sting as two separate entities with two separate identifiers is one
> way to do that.
>
> However, it does seem a bit unnatural to create a MusicGroup with the name
> of a solo performer. Consider Robert Plant or Paul McCartney. Most
> laypeople would disagree that there is a "group" called Robert Plant.
> Instead, common parlance says that "Robert Plant" has a band that backs
> him. (Of course, laypeople don't necessarily give squat about modeling data
> correctly -- but in a user-contributed database like MusicBrainz or
> Freebase, it is a concern.)
>
Or perhaps something labeled as "Sting (supporting band)", "Robert
Plant (supporting band)"? Would that be more natural? However, I agree
with Simon that the band will change over time, and you'd have
troubles modelling that in that way.
> It seems that an alternate solution would be to model Sting as a single
> MusicArtist entity, who is the sole maker of his Records. Sting would not
> be a MusicGroup. The members of his support band (Dominic Miller and Jason
> Rebello, among others) would be listed as mo:performers on each of the
> Records and/or Tracks that they contributed to, but would not otherwise be
> collected in a MusicGroup.
>
> Would this be proper under the MusicOntology? It has the advantages that it
> matches people's natural understanding better. However, it has the
> disadvantage that it hides information about longstanding relationships
> between solo performers (like the collaboration between Randy Rhodes and
> Ozzy Osborne).
>
Yes, this is a really good way to do it. It also solves Simon's
problem, as the mo:performers involved in any performance might change
over time.
Cheers,
y
> Brian
>
>
>