LinkedBrainz/NGS to RDF mappings

This page is for discussing mapping of Next Generation Schema and Advanced Relationships to RDF.

NGS at a glance

The following objects exist in the Next Generation Schema. Here we make a clear distinction between core entities which have a unique MBID, entities which share an MBID with some core entity and perhaps other entities, and objects which are not associated with an MBID directly.

core entities that have mbids:

• Artist
• Release Group
• Release
• Recording
• Work
• Label

entities that share/borrow mbids:

• Track (redirects to a Recording)
• Medium (part of a Release)

just objects:

• Artist Credit
• Tracklist

MO Mappings

The current mapping decisions for mapping NGS to RDF are summarized here. The mappings make use of the Music Ontology and other ontologies. Previous mapping proposals have been moved to the discussion page.

proposal 0

proposed mappings to mo - kurtjx

type	NGS	RDF
core entities with mbids
	'artist'	'mo:MusicArtist' (type=1' => 'mo:SoloMusicArtist', type=2 => 'mo:MusicGroup')
	'release'	'mo:Release'
	'release_group'	'mo:SignalGroup'
	'recording'	'mo:Signal'
	'label'	'mo:Label'
	'work'	'mo:MusicalWork'
entities with a URI (potentially)
	'url'	'foaf:Document'
	'track'	'mo:Track' or 'mo:Signal'
	'medium'	'mo:Medium' and various 'mfo' concepts
objects (no URI?)
	'tracklist'	both a 'mo:Medium' (or mfo subclass) and 'mo:Record'?
	'artist_credit'	collapse into foaf:maker relations

some notes:

• a medium is part of a release but does not have its own mbid - what should be the URI for a medium? perhaps some hash on the end of the release URI?
• in NGS a track simply redirects to a recording and associates a recording to a release - do we use mo:Track or mo:Signal for a track
• tracklist and artist_credit objects are described (completely?) by properties attached to various concepts (e.g. mo:SignalGroup and mo:Signal) and require no URIs for themselves
• what property associates a mo:SignalGroup (release_group) to a mo:Release (release)??? - see http://wiki.musicontology.com/index.php/Classes_Schemas#Extended_release_concept_with_mo:ReleaseEvent

proposal 1 (dataincubator)

These are the mapping I have worked on as part of my http://musicbrainz.dataincubator.org// conversion

mappings to mo - iand

type	NGS	RDF
core entities with mbids
	'artist'	'mo:MusicArtist' (type=1' => mo:SoloMusicArtist, type=2 => mo:MusicGroup)
	'release'	'mo:Release' and 'mo:ReleaseEvent' (1:1 mapping)
	'release_group'	'mo:SignalGroup'
	'recording'	'mo:Signal'
	'label'	'mo:Label'
	'work'	'mo:MusicalWork'
entities with a URI
	'url'	untyped, I parse wikipedia links to create owl:sameAs to dbpedia, and discogs links for owl:sameAs to discogs.dataincubator.org
	'track'	'mo:Track'
	'medium'	'mo:Medium' (and mo:CD, mo:SACD etc depending on format column)
objects (no URI?)
	'tracklist'	I use an rdf:Seq as the object of a http://purl.org/dc/terms/tableOfContents property
	'artist_alias'	'http://ontologi.es/persona#Persona'
	'artist_credit'	collapse into foaf:maker relations. Also want to point to a sequence of artists, similar to http://purl.org/ontology/bibo/authorList

proposal 2

(currently only some additional thoughts (by zazi))

• Alias modeling: It depends on whether the alias is only used as another name for someone, or if the alias includes a completely different (often fictional) identity (see also the discussion on the FOAF-dev mailing list). In that case this alias should also be modeled as another person (e.g. foaf:Person) and related by using an alias property, e.g. foaf:alias. This would be the case, if the artist has a completely different identity for his artist-beeing. For the other case, persona:Persona can be used.
• Please note that Artist Alias is not really about alternate personas but about alternate spellings of an artist name. Therefore it is likely we will simply bind a skos:altLabel to the artist for Artist Aliases. Also note that the MusicBrainz Performance Names policy already dictates separate artists are created for separate personas. --Kurtjx 17:46, 31 August 2010 (UTC)

• Possibly important relationship properties from MO, where people could be involved (all with their domains and ranges): at MO mailing list

• Tracklist modeling: If we don't really need the order, then we shouldn't use rdf:Seq here. We have mo:Record, which consists of mo:Track instances (related by mo:track), which can have a mo:track_number

• URL modeling: If you know the Information Service, behind an URL, the you can additionally use the property is:info_service to relate this link to an Information Service description (is:InfoService)

• Sequence of artists modeling: Do we really need that? - mo:MusicArtist instances can be members (foaf:member and/or mo:member_of) of mo:MusicGroup instances. With mo:Membership we can furthermore describe memberships of a music group.

Advanced Relationship mappings

Mapping Advanced Relationships to RDF could be done using the MuSim ontology.

A link_type becomes and sim:AssociationMethod and each link becomes a sim:Association - this approach is probably best left for cleaning up "left-overs" that aren't readily covered by other vocabs - --Kurtjx 19:43, 16 August 2010 (UTC)

I have planned a mixed approach - direct property relationships where possible, augmented by event based entities that allow start/end information to be included. As a start I have a mapping for almost all the the link types in NGS to foaf, dc, mo and others. I have supplemented this with some custom properties in a http://musicbrainz.dataincubator.org/schema namespace. I could list them all here, but there are quite a lot! Iand 09:28, 3 August 2010 (UTC)

What about the Relationship Vocabulary? (by zazi)