Talk:LinkedBrainz/NGS to RDF mappings

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.

• Medium and Tracklist modelling: I guess the NGS schema doesn't really reach the item level. I know mo:MusicalItem is not a sub class of frbr:Item. However, it still acts like one on the item level - it acts as an exemplar of a manifestation. That's why, I proposed that we need media types on the manifestation level. I did this in the my recent Music Ontology v 2.1.2 proposal and introduced furthermore a namespace for such dcterms:MediaType based instances (http://purl.org/ontology/mt/, that is based on kurtjx MFO, MO, MusicBrainz, ID3 TMED frame media types).

ARs

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)