Tags

Introduction

Tags are free-form metadata that can be added to all entry types (Artists, Albums, Songs, …). Tags allow users to link entries together by any sensible properties they can come up with. Tags can be edited more freely than other fields and some of them may even be considered subjective. Therefore tags are based on voting. Tag votes are visible and removable to trusted users and above.

Tags are constructed by a hierarchy system: Tags are displayed as a tree structure, with the “parent” at the top and the children and siblings at the bottom.

Tagging entries

In most cases child tags should describe a subset of the parent tag. Adding Anime tag on an entry already tagged with Sailor Moon is redundant. This doesn’t impact the searchability, as the search can be performed with “Include child tags” -filter.

• There are cases where the subset relationship isn’t as clear. Genre tags for example utilize the tag hierarchy for historical and stylistic origins.

• Additionally, fusion tags such as folk metal are neither subsets of metal or folk music. For tags with multiple separate parent tag candidates, pick the one that makes the most sense.

Tags shouldn’t be used blindly - always read the tag description in unclear cases.

Generally, you should avoid tagging information that is already provided by more specialized fields. For example, tagging albums or songs with artist names is redundant because the artists list already handles this better. Likewise, tagging cover songs with “cover” is useless if the song type is already cover.

Adding tag votes to objective tags is redundant, unless there is a need to “highlight” the tag. By default, entry pages display four most voted tags before clicking “Show all”.

Creating and editing tags

Every tag should reflect some well-defined concept. Avoid overly specific tags that only apply to one or two entries.

Tags should add new information to the entry. Creating “derived tags” that replicate information from the existing fields is discouraged, unless the tag is useful enough (see the tag purposes below) and there is no easy/reliable way to search/list the relevant information (duet for example).

Generally tags should not be created or used for tracking visual details. This includes the creation of visual detail tags in the Vocalist category.

All tags require description and a tag category. Additionally, it’s recommended to locate a fitting tag parent and/or related tags. If tags have the same parent tag, specifying them as related tags is redundant.

Tag description should describe the tag concept in clear English language. For normal tags, skip generic usage instructions such as “tag for albums/artist/songs…“. Use “Valid for” -restrictions instead.

Including external links to objective sources, such as Wikipedia, is recommended.

Tag categories

VocaDB has specific tag categories listed and explained below.

They are the highest hierarchy in the tag system and every tag must be attached to one.

Ideally:

• Tags in the same category share the same usage rules.

• Tags belong to only one category.

Song lists vs Tags

Trusted users are able to create public songlists called pools. Pools can be used for largely the same purpose as tags, grouping songs together based on some common theme. There are a few differences between tags and songlists.

• Pools are listed on the featured songlists page.
• Pools are not voted on, unlike tags. All pools are equal.
• Only trusted users are able to edit pools. Any user can vote on tags. Thus tags are easier to use, but also more unreliable.
• Pools may contain only songs. Tags can be applied to albums and artists as well.
• Songs in a pool can be ordered. Songs with a specified tag are unordered.
• You can add notes to songs in a pool.