Japanese Katakana alias sort names and Latin search hints

Tags: #<Tag:0x00007fe30e3d3a30> #<Tag:0x00007fe30e3d3918>

I have been using JASRAC uses to write Japanese alias sort names in full katakana and written as you pronounce.
And I’ve been using their uses to build Latin search hints as well (same rules but in Latin transcription).

@ashes_2 recently pointed me to their written guidelines.
I think it is so interesting and I don’t think I have followed 100% of their guidelines because I only extrapolated from their existing examples in their DB.
We should have a Japanese alias sort name paragraph linking to it or repeating it somewhere in Style/Language/Japanese

I suggest カタカナ読みの表記 for entity alias sort name and optionally アルファベット読みの表記 for search hint alias.


Ah, thanks to ashes for linking the JASRAC page. I’ve been using mainly hiragana for sorting Japanese name all this time as I’m not aware JASRAC has already established a sort name guideline with using katakana. I will look into it and follow the guide next time.


Hi all.

It is a pity report.
I thought it was convenient from the standpoint of the editor.
However, from the point of view of the user, I noticed that it had no convenience to reward the editor’s hardships.
I will write the details bellow now.
But that will shrink our hope.

well, I am Japanese native and I am currently having a very complex feeling.

To agree on logically.

  1. Normalization is necessary for convenience of retrieval.
  2. Consistent rules are required for convenience of normalization.
  3. The number of songs managed by JASRAC is the largest in Japan (probably).
  4. Both MB and JASRAC are genres of the same music.

To hesitate to agree on logically.

  1. There are already a lot of songs in the MB and it is difficult to correct them all.
  2. The JASRAC normalization policy is currently quite different from the Japanese input method using the computer IME (input method editor).
  3. Perhaps the person who imagines JASRAC’s normalization policy when searching may not be one in 1000 people natively.
  4. The purpose of normalizing in the first place is to increase the search hit ratio.
  5. Currently, the Policies of the Agency for Cultural Affairs(文化庁) provides funds to integrate JASRAC and other major DBs and collect usage fees.
    • However, it is undecided on what range to charge for fee. Whether to make a simple search even for a fee or to charge out the contact information of the right holder? All are indeterminate.
  6. MusicBrainz are Do not have to worry? about the possibility of asserting the copyright of the database.

What I can not praise in aesthetic sense.

  1. Multiple normalization rules for overlaying vowels are defined, which rule will be confused as to which one to apply.
  2. The normalization of the long phonetic symbol “ー” used for vowels is not beautiful.

エーケービー フォーティエイト NOW
エエケエビイ フォオティエイト JASRAC method
エィケィビィ フォウティエイト Bad sample

That is [ィイー], [ォオー], [ィエー], [ィイー],[ウオー] and so on.

大森 靖子
おおもり せいこ NOW
オオモリ セイコ JASRAC method
オーモリ セエコ Bad sample
オウモリ セーコ Bad sample

That is [ウオー], [イエー] and so on.

すぅめたる should be add Alias
スウメタル ??JASRAC method?? add tobe this Alias
スゥメタル ??JASRAC method?? add tobe this Alias
スーメタル in scope of JASRAC method, bad sample, but should be add Alias

However, some unified entry may be necessary for people who are not native.
Therefore, we add a rule to the future editor “We recommend adding JASRAC method to alias”.
To alias!

More over, it may be that some people think that Romanize should be used.
In addition, it is worse, there are two kinds.
Romanization: the government ordinance method; 訓令式, and the Hepburn method; ヘボン式.

Social background.
Perhaps this JASRAC method was created by JASRAC imitating the telephone directory method that was installed in public phones long before the personal computer became popular.
And since mobile phones became popular, there were number of call box has fallen off sharply.
Therefore, people who know how to use the phone book are older than a certain age.

Again, I want to emphasize.
The JASRAC method is logically consistent, so it would be useful for the editor if we want to make it consistent.
Because I agree with the recruitment is useful from the standpoint of the editor.
At that time, I was losing sight of the user.
However, users who do not edit have an unfamiliar system that can not be imagined.
I actually tried out the sample I wrote above and felt it.
“I can not imagine that there are people who can enter this in the search box without looking at the reference.”
The purpose of normalizing in the first place is to increase the search hit ratio.

Jeluang, how do you think?
I want to hear your opinion with a non-native perspective.
and all how?


Your reasoning is perfectly valid for aliases but the JASRAC full Katakana spellout is proposed not for aliases but for the main work title sort name.
In CD stores, I saw they naturally completely follow this あいうえお/あかさたなはまやらわん and sorting would be made impractical if we would mix syllabaries, alphabets or even use any kind of native repeating or prolongative marks.

I don’t think you will find any funny stuff in my random example, do you? :sweat_smile:

In a previous version of MusicBrainz, my work importer was actually creating those work aliases with their JASRAC sort names. But it’s now defunct, unhopefully.

By the way, my OP proposes for all entity alias sort names, not limited to work alias sort names.
The Latin proposal is completely optional but aimed at non Japanese readers.


As a non-native, I usually try to follow how the artist usually show their name is written. For example, they usually write their name normally followed by the reading in parentheses “()” whether it’s in hiragana or katakana. But if there’s a standard of doing it, I’ll probably follow that as well.

1 Like

In our MB system, those parentheses are replaced by our sort name field.
Ultimately, the aim besides having the reading (which is already quite useful with Japanese names), is to display lists (works, artists, etc.) in natural order when you are in Japanese locale, in an hypothetical future.

1 Like

I guess I should’ve specified that when I meant the name in parentheses. :sweat_smile:

1 Like