LinkedBrainz/NGS to RDF mappings: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
 
(30 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This page is for discussing mapping of [[Next Generation Schema]] and [[Advanced Relationships]] to RDF.
This page is for defining the mapping of [[Next Generation Schema]] and [[Advanced Relationships]] to RDF. Much of the old content has been moved to the [[Talk:NGS_to_RDF_mappings|talk page]].

==NGS Objects==
==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.
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:
core entities that have mbids:
* [[NextGenerationSchema#Artist|Artist]]
* [[MusicBrainz Database/Schema#Artist|Artist]]
* [[NextGenerationSchema#Release_Group|Release Group]]
* [[MusicBrainz Database/Schema#Release_Group|Release Group]]
* [[NextGenerationSchema#Release|Release]]
* [[MusicBrainz Database/Schema#Release|Release]]
* [[NextGenerationSchema#Recording|Recording]]
* [[MusicBrainz Database/Schema#Recording|Recording]]
* [[NextGenerationSchema#Work|Work]]
* [[MusicBrainz Database/Schema#Work|Work]]
* [[NextGenerationSchema#Label|Label]]
* [[MusicBrainz Database/Schema#Label|Label]]
entities that share/borrow mbids:
entities that share/borrow mbids:
* [[NextGenerationSchema#Track|Track]] (redirects to a [[NextGenerationSchema#Recording|Recording]])
* [[MusicBrainz Database/Schema#Track|Track]] (redirects to a [[MusicBrainz Database/Schema#Recording|Recording]])
* [[NextGenerationSchema#Medium|Medium]] (part of a [[NextGenerationSchema#Release|Release]])
* [[MusicBrainz Database/Schema#Medium|Medium]] (part of a [[MusicBrainz Database/Schema#Release|Release]])
just objects:
just objects:
* [[NextGenerationSchema#Artist_Credit|Artist Credit]]
* [[MusicBrainz Database/Schema#Artist_Credit|Artist Credit]]
* [[NextGenerationSchema#Tracklist|Tracklist]]
* [[MusicBrainz Database/Schema#Tracklist|Tracklist]]


==MO Mappings==
==Mappings==
mappings to the [http://musicontology.com/ Music Ontology] can be collected here. jump in and have your say :-)
The current mapping decisions for mapping NGS to RDF are summarized here. The mappings make use of the [http://musicontology.com/ Music Ontology] and other ontologies. Previous mapping proposals have been moved to the [[Talk:NGS_to_RDF_mappings|discussion page]].

===proposal 0===


===Core===
{|
{|
|+ align="bottom" |''proposed mappings to mo - kurtjx''
|+ align="bottom" |''core NGS mappings to RDF''
! type
! type
! NGS
! NGS
Line 32: Line 32:
|-
|-
|'artist'
|'artist'
| '[http://musicontology.com/#term_MusicArtist mo:MusicArtist]' (type=1 => '[http://musicontology.com/#term_SoloMusicArtist mo:SoloMusicArtist]', type=2 => '[http://musicontology.com/#term_MusicGroup mo:MusicGroup]')
| 'mo:MusicArtist'
|-
|-
|'release'
|'release'
|'[http://musicontology.com/#term_Release mo:Release]' and '[http://musicontology.com/#term_ReleaseEvent mo:ReleaseEvent]' (currently 1:1 relations)
|'mo:Release'
|-
|-
|'release_group'
|'release_group'
|'mo:SignalGroup'
|'[http://musicontology.com/#term_SignalGroup mo:SignalGroup]'
|-
|-
|'recording'
|'recording'
|'mo:Signal'
|'[http://musicontology.com/#term_Signal mo:Signal]'
|-
|-
|'label'
|'label'
|'mo:Label'
|'[http://musicontology.com/#term_Label mo:Label]'
|-
|-
|'work'
|'work'
|'mo:MusicalWork'
|'[http://musicontology.com/#term_MusicalWork mo:MusicalWork]'
|-
|-
|rowspan="4"|entities
|rowspan="4"|entities
with a URI
with a URI

(potentially)
|-
|-
|'url'
|'url'
|'rdfs:seeAlso' or 'owl:sameAs' links to [http://dbpedia.org/ DBpedia] etc.
|'foaf:Document'
|-
|-
|'track'
|'track'
|'[http://musicontology.com/#term_Track mo:Track]' with a URI that includes the track.id
|'mo:Track' or 'mo:Signal'
|-
|-
|'medium'
|'medium'
|'[http://musicontology.com/#term_Record mo:Record]' with a URI that includes the medium.id and various '[http://purl.org/ontology/mt/ mt]' instances (related via the [http://musicontology.com/#term_media_type mo:media_type] property)
|'mo:Record'
|-
|-
|rowspan="3"|objects
|rowspan="3"|objects
(no URI?)
|-
|-
|'tracklist'
|'tracklist'
|'[http://musicontology.com/#term_Record mo:Record]' (tracklist currently are not treated separately, parts of this table are mapped to property values of the related [http://musicontology.com/#term_Record mo:Record] instances)
|absorbed into mo:SignalGroup
|-
|-
|'artist_credit'
|'artist_credit'
|collapse into foaf:maker relations
|collapse into [http://xmlns.com/foaf/spec/#term_maker foaf:maker] relations
|}
|}


===Advanced Relationships===
some notes:
Currently, only the some of the most basic [[Advanced Relationships]] are modeled.
* 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
* 'has a Wikipedia page at' creates 'owl:sameAs' link to corresponding DBpedia resource
* '''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
* 'has BBC Music Page at' creates 'owl:sameAs' to BBC Music
* ...
* currently (2011/07/29) all link types that relate to common web [http://infoserviceonto.wordpress.com/2010/06/23/what-is-an-information-service/ information services] are at least implemented and the URLs are associated with its specific [http://purl.org/ontology/is/inst/ information service instance] (see also [https://github.com/BarryNorton/D2R-LinkedBrainz-Fork/wiki/Information-Services here])

===Implementation===
* a [http://d2rq.org D2RQ] based implementation can be found [https://github.com/BarryNorton/D2R-LinkedBrainz-Fork/blob/master/musicbrainz_mapping.n3 here]

==URIs - Thing v Page ==
In the Linked Data paradigm, it is important to make a distinction between the ''thing'' and the ''page describing that thing''. Both the ''thing'' and the ''page'' should have their own URI. Think of this simple example to understand why - you might want to say ''"The page about James Brown was created on this date in 1998"'' - if James Brown and the page about James Brown shared the same URI, we would think James Brown was created in 1998 (which is false).

To mitigate this problem we used the [http://www.w3.org/TR/cooluris/#hashuri hash URI] approach. For example the URI for the page about James Brown would be:
http://musicbrainz.org/artist/20ff3303-4fe2-4a47-a1b6-291e26aa3438
While the URI for James Brown himself includes a hash suffix simply with an underscore character:
http://musicbrainz.org/artist/20ff3303-4fe2-4a47-a1b6-291e26aa3438#_
Now we can unambiguously make statements about James Brown and statements about the the page about James Brown. Other core entities follow this same pattern.
[[Category:LinkedBrainz]] [[Category:To Be Reviewed]]

Latest revision as of 14:12, 26 May 2015

This page is for defining the mapping of Next Generation Schema and Advanced Relationships to RDF. Much of the old content has been moved to the talk page.

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:

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.

Core

core NGS mappings to RDF
type NGS RDF
core entities

with mbids

'artist' 'mo:MusicArtist' (type=1 => 'mo:SoloMusicArtist', type=2 => 'mo:MusicGroup')
'release' 'mo:Release' and 'mo:ReleaseEvent' (currently 1:1 relations)
'release_group' 'mo:SignalGroup'
'recording' 'mo:Signal'
'label' 'mo:Label'
'work' 'mo:MusicalWork'
entities

with a URI

'url' 'rdfs:seeAlso' or 'owl:sameAs' links to DBpedia etc.
'track' 'mo:Track' with a URI that includes the track.id
'medium' 'mo:Record' with a URI that includes the medium.id and various 'mt' instances (related via the mo:media_type property)
objects
'tracklist' 'mo:Record' (tracklist currently are not treated separately, parts of this table are mapped to property values of the related mo:Record instances)
'artist_credit' collapse into foaf:maker relations

Advanced Relationships

Currently, only the some of the most basic Advanced Relationships are modeled.

  • 'has a Wikipedia page at' creates 'owl:sameAs' link to corresponding DBpedia resource
  • 'has BBC Music Page at' creates 'owl:sameAs' to BBC Music
  • ...
  • currently (2011/07/29) all link types that relate to common web information services are at least implemented and the URLs are associated with its specific information service instance (see also here)

Implementation

  • a D2RQ based implementation can be found here

URIs - Thing v Page

In the Linked Data paradigm, it is important to make a distinction between the thing and the page describing that thing. Both the thing and the page should have their own URI. Think of this simple example to understand why - you might want to say "The page about James Brown was created on this date in 1998" - if James Brown and the page about James Brown shared the same URI, we would think James Brown was created in 1998 (which is false).

To mitigate this problem we used the hash URI approach. For example the URI for the page about James Brown would be:

  http://musicbrainz.org/artist/20ff3303-4fe2-4a47-a1b6-291e26aa3438

While the URI for James Brown himself includes a hash suffix simply with an underscore character:

  http://musicbrainz.org/artist/20ff3303-4fe2-4a47-a1b6-291e26aa3438#_

Now we can unambiguously make statements about James Brown and statements about the the page about James Brown. Other core entities follow this same pattern.