LinkedBrainz/NGS to RDF mappings: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
Line 136: Line 136:
(currently only some additional thoughts (by [http://wiki.musicbrainz.org/User:Zazi zazi]))
(currently only some additional thoughts (by [http://wiki.musicbrainz.org/User:Zazi 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 [http://lists.foaf-project.org/pipermail/foaf-dev/2010-June/010253.html 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.
* 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 [http://lists.foaf-project.org/pipermail/foaf-dev/2010-June/010253.html 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.


- Possibly important relationship properties from MO, where people could be involved (all with their domains and ranges): [http://groups.google.com/group/music-ontology-specification-group/msg/31cfa6318cd183e1 at MO mailing list]
* Possibly important relationship properties from MO, where people could be involved (all with their domains and ranges): [http://groups.google.com/group/music-ontology-specification-group/msg/31cfa6318cd183e1 at MO mailing list]


- Tracklist modeling: If we don't really need the order, then we shouldn't use rdf:Seq here. We have [http://musicontology.com/#term_Record mo:Record], which consists of [http://musicontology.com/#term_Track mo:Track] instances (related by [http://musicontology.com/#term_track mo:track]), which can have a [http://musicontology.com/#term_track_number mo:track_number]
* Tracklist modeling: If we don't really need the order, then we shouldn't use rdf:Seq here. We have [http://musicontology.com/#term_Record mo:Record], which consists of [http://musicontology.com/#term_Track mo:Track] instances (related by [http://musicontology.com/#term_track mo:track]), which can have a [http://musicontology.com/#term_track_number mo:track_number]


- URL modeling: If you know the Information Service, behind an URL, the you can additionally use the property [http://purl.org/ontology/is/infoservice.html#info_service is:info_service] to relate this link to an Information Service description ([http://purl.org/ontology/is/infoservice.html#InfoService is:InfoService])
* URL modeling: If you know the Information Service, behind an URL, the you can additionally use the property [http://purl.org/ontology/is/infoservice.html#info_service is:info_service] to relate this link to an Information Service description ([http://purl.org/ontology/is/infoservice.html#InfoService is:InfoService])


- Sequence of artists modeling: Do we really need that? - [http://musicontology.com/#term_MusicArtist mo:MusicArtist] instances can be members ([http://xmlns.com/foaf/spec/#term_member foaf:member] and/or [http://musicontology.com/#term_member_of mo:member_of]) of [http://musicontology.com/#term_MusicGroup mo:MusicGroup] instances. With [http://musicontology.com/#term_Membership mo:Membership] we can furthermore describe memberships of a music group.
* Sequence of artists modeling: Do we really need that? - [http://musicontology.com/#term_MusicArtist mo:MusicArtist] instances can be members ([http://xmlns.com/foaf/spec/#term_member foaf:member] and/or [http://musicontology.com/#term_member_of mo:member_of]) of [http://musicontology.com/#term_MusicGroup mo:MusicGroup] instances. With [http://musicontology.com/#term_Membership mo:Membership] we can furthermore describe memberships of a music group.


==Advanced Relationship mappings==
==Advanced Relationship mappings==

Revision as of 19:44, 16 August 2010

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:

entities that share/borrow mbids:

just objects:

MO Mappings

mappings to the Music Ontology can be collected here. jump in and have your say :-)

proposal 0

proposed mappings to mo - kurtjx
type NGS RDF
core entities

with mbids

'artist' 'mo:MusicArtist'
'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:Record'
objects

(no URI?)

'tracklist' absorbed into mo:SignalGroup
'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.
  • 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)

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)