Dublin Core Metadata Mappings

EXPLANATION OF THIS SECTION

This section specifies all of the Dublin Core fields that may be extracted and saved by jSongMiner, as well as the mappings between them and the general metadata field labels produced by jSongMiner. Details of these general field labels are provided in a separate section of the manual. All of these general jSongMiner fields are converted into Dublin-core formatted fields, and the Dublin Core-formatted fields do not contain any values not also available in the original general fields. The general jSongMiner fields are in fact first extracted by jSongMiner, and then converted into Dublin Core-formatted data using the mappings specified below. First qualified Dublin Core data is produced from these original fields, and then unqualified Dublin Core data is produced from the qualified data. The original fields may or may not then be discarded, based on user settings.

This processing is done separately for song, artist and album data, although this data may in the end be combined into a single final file, depending on user settings. Note that if the user elects to package song, artist and album data together into a single output file, then unqualified Dublin Core fields will be generated only for the mappings in the song section below. If separate output files are generated, then each may have its own unqualified Dublin Core fields. Qualified Dublin Core is generated for all three types of resources either way.

The mappings are specified below as follows: the first value in each pair is the qualified Dublin Core tag that is output by jSongMiner, and the second value is the general jSongMiner field from which it is derived. There is some intentional redundancy in these mappings (e.g. when generating a song output file, the general jSongMiner field "Album Title" is mapped to both "dc.Source^albumtitle" and to "dc.Relation^albumtitle)". This is consistent with the general philosophy of Dublin Core.

The qualified Dublin Core mappings below also specify how unqualified Dublin Core-formatted data is generated and output by jSongMiner. The qualified Dublin Core field names listed below are presented in the priority order used by jSongMiner when generating the unqualified Dublin Core fields from the qualified Dublin Core fields. For example, consider the case of the "dc.Coverage" unqualified Dublin Core field for songs. The two possible values for this field are, as noted below, "dc.Coverage^releasecountry" and "dc.Coverage^releaseyear", in that order. The value of dc.Coverage will be set to that of "dc.Coverage^releasecountry" if it is available, but to "dc.Coverage^releaseyear" if it is not. If the value for a given qualified or unqualified Dublin Core field cannot be extracted, then jSongMiner either omits it (the suggested option) or includes it with an indication that it is unknown, depending on the user settings.

Each unqualified Dublin Core field may only have a single value. As is typical with Dublin Core, this value may have varying meanings, depending on the data that happens to be available for a given resource. A given qualified field, however, may have multiple values. For example, the "dc.Relation^similartrack" field can have multiple values, as there will be more than just one track similar to any given track. Although each of these similar tracks will have the same "dc.Relation^similartrack" field label, the ordering in which the values are output by jSongMiner indicates importance if relevant, from most important to least important. The first similar track listed is therefore implicitly more similar to the track under consideration than the second similar track listed.

Unlike the general jSongMiner metadata field labels, the Dublin Core-formatted metadata output by jSongMiner does not indicate the source of the metadata. So, while the general metadata label for a song's title might be "Echo Nest API: Song Title", which indicates that the Echo Nest is the source of the metadata, the corresponding Dublin Core-formatted metadata field label output by jSongMiner would simply be "dc.Title^songtitle" (qualified) or "dc.Title" (unqualified). In practice, different sources might provide different values for a given field. For example, two sources might return a tempo of 120 BPM, but another might return a tempo of 60 BPM. jSongMiner eliminates identical duplicates, but keeps differing values. So, in the previous example, jSongMiner would discard the duplicate of 120 BPM, and would output two values for "dc.Description^tempo", namely 60 BPM and 120 BPM. Of course, in the case of unqualified Dublin Core fields, only one value is permitted, so in cases of conflicting information from different sources jSongMiner only outputs the value considered to come from the more reliable source.

The format in which field values are presented may vary, depending on how the information is furnished by the web services and other sources that provide them. Efforts have been made where possible to have jSongMiner standardize the ways in which values are presented and stored, but the dynamic nature of web services makes it impossible to guarantee formatting consistency in all cases.

QUALIFIED DUBLIN CORE MAPPINGS FOR FIELDS EXTRACTED AND STORED IN SONG DATA FILES:

QUALIFIED DUBLIN CORE MAPPINGS FOR FIELDS EXTRACTED AND STORED IN ARTIST DATA FILES:

QUALIFIED DUBLIN CORE MAPPINGS FOR FIELDS EXTRACTED AND STORED IN ALBUM DATA FILES:

-top of page-