Property talk:P1814

Add topic
Active discussions


name in kana
the reading of a Japanese name in kana
DescriptionThe reading of a Japanese name written in kana (hiragana and/or katakana)
Representskana (Q187659), furigana (Q504694), Modern kana usage (Q2572881), historical kana orthography (Q1142552)
Data typeString
Template parameterex: "各国語表記" ja:Template:政治家 (Japanese policians)
Domain(People, places) (note: this should be moved to the property statements)
Allowed values[ぁ-ゔァ-ヴー「」・  \-〜?!、0-90-9]+
ExampleJapan (Q17) → にっぽん
Mount Fuji (Q39231) → ふじさん
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: usageCategory:Pages using Wikidata property P1814 (Q27664932)
  • Items with the most statements of this property
  • Count of items by number of statements (chart)
  • Count of items by number of sitelinks (chart)
  • Items with the most identifier properties
  • Items with no other statements
  • Most recently created items
  • Items with novalue claims
  • Items with unknown value claims
  • Usage history (total)
  • Chart by item creation date
  • Database reports/Constraint violations/P1814
  • Map
  • Random list
  • Proposal discussionProposal discussion
    Current uses
    Main statement205,05793.4% of uses
    Qualifier14,5056.6% of uses
    Reference6<0.1% of uses
    Search for values
    [create Create a translatable help page (preferably in English) for this property to be included here]
    Format “[ぁ-ゔァ-ヴー「」・  \-〜?!、0-90-9]+: value must be formatted using this pattern (PCRE syntax). (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P1814#Format, SPARQL
    Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P1814#allowed entity types
    Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P1814#scope, SPARQL
    Label required in languages: ja: Entities using this property should have labels in one of the following languages: ja (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P1814#label in language, search, SPARQL

    Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)


    Use of property and name in native language (P1559) or native label (P1705)Edit

    There were some questions about the use of this property at Wikidata:Bistro#Transcriptions_pour_les_langues_non-romanes. It occurred to me that now that we have Help:Monolingual text languages, we could create additional language (sub-)codes for Japanese, e.g. "ja-Kana". Given current tools, it's probably easier to use name in kana (P1814) than that. As I don't read Japanese, I don't want to recommend one solution over the other.
    --- Jura 13:00, 7 November 2016 (UTC)

    修飾子としての使用は除いて、このプロパティは漢字が使われていないラベルの項目では使用すべきではないでしょう。--Afaz (talk) 04:06, 19 June 2017 (UTC)

    How do you give a reading in kana to items?Edit

    I've just come from the discussion page of ja:Wikipedia:井戸端/subj/ウィキデータを活用した索引の整備の実現可能性について. It suggests that this property set up some criteria for a manner of giving the reading in kana as a data value. Do you think which is the most appropriate manner, writing all items' name in kana (P1814) in hiragana (Q48332) or in katakana (Q82946) uniformly, or allowing use of both of them depending on conditions? Their usage is inconsistent at present (e.g. Gō Katō (Q326335), Yoshiyuki Kato (Q47357), Miliyah Kato (Q271895)). I also agree with Afaz who has given their opinion above that editors should not use this property to the item in which its label does not include any kanji (Q82772) at all, so I'll removing name in kana (P1814) from those items, except for the ones used as a qualifier. 前掲の井戸端の話題から参りました。こちらで、このプロパティの値(読み仮名)の表記法についての基準となるルールを整備してはいかがかと思います。読み仮名を全て平仮名で統一するか、全て片仮名で統一するか、あるいは状況に応じて平仮名と片仮名の両方の使用を許容するか、どれが最も妥当でしょうか。現状は、Gō Katō (Q326335)Yoshiyuki Kato (Q47357)Miliyah Kato (Q271895)といったように、表記法に一貫性のない状態です。また、漢字が全く使われていないラベルの項目では使用すべきでないという、上述のAfazさんの意見に同意し、該当する項目からname in kana (P1814)を除去しようと思います(ただし、修飾子として使用されているものは除外)。--Doraemonplus (talk) 08:08, 23 December 2017 (UTC) 追記--Doraemonplus (talk) 08:23, 23 December 2017 (UTC)

    漢字が使われていないラベルの項目では使用すべきでないというのは条件が厳しいと思います。Akira 100percent (Q22123227)Q11254948などは漢字が含まれていませんが、読み仮名は記載した方がいいでしょう。私は「仮名文字および中黒などの約物のみが使われていて読みが自明なもの」かどうかで使用条件を定めるべきだと考えます。私としては以下に示す使われ方を想定しています。
    1. プロパティのデータ型はmonolingualtextもしくはstringであること。
    2. 値とするテキストは日本語もしくは日本における表記であること。
    3. 値とするテキストは読みが自明でないこと。読みが自明でないテキストとしては、漢字やラテン文字を含んでいる場合、約物以外の記号(☆や♡など)を使用しているものなどが挙げられる。
    P1814を修飾子として使用することを前提としていますが、3つのうち上2つの制約により、P1814が使用可能な項目は概ね日本もしくは日本語に関連したものに制限されます。汎用的に使用可能で、「各国語表記」に相当するプロパティが存在しない(あってもdemonym (P1549)のように限定的)からです。私としてはこれをそのままP1814の使い方のガイドライン案としたいところですが、皆様はどう思われるでしょうか。--本日晴天 (talk) 05:04, 30 December 2017 (UTC)
    プロパティは個々のQに対応するプロパティであるべきで、特定の言語(日本語)にのみ対応するものをQのプロパティとしてつけるのはWikidataとしてあるべき姿ではないような気がしています。(P1814をそのまま使うのは、たとえば、Nihonbashi (Q1141952)に英語の発音記号を言語なしでPとしてつけるようなものに感じています)
    たとえば絵画や音楽の作品名では、元の言葉が何であれ日本語名称の読みが難しいケースは多々あり、その付けかたもまちまちで、パターンも多数存在します。また、複数の日本語表記が当てられてかつその読みがそれぞれ難しいものはいくつもあります(Danseuses de Delphes (Q28496953)La terrasse des audiences du clair de lune (Q29217416)など)。
    現在のname in kana (P1814)の使い方では、複数の日本語表記が蔓延してしまっているものについてLabel/Ailiasの、どの日本語表記に対する読みかを明示的に指定できません。(日本語を理解できない人に理解できない かつ、Machine readableとはいえない)それほど深く考えてはいませんが、Wikidataの性質的にはname in kana (P1814)Revised Hepburn romanization (P2125)はプロパティとして出発点がずれてしまっている気がしています。現状のまま読み仮名をつけないことには賛成ですが、それ以上にP1814/P2125をQのプロパティとして使い続けるのは無理があるように感じています。
    ぼんやり考えている程度ですが、name in kana (P1814)Revised Hepburn romanization (P2125)native label (P1705)に表記をつけたサブロパティか、もしくはtransliteration (P2440)のサブプロパティのみとして使用するのがいいのではないかと考えてはいます。(language of work or name (P407) = Japanese (Q5287)ではnative label (P1705)の表記に対しての読み、それ以外ではtitle (P1476)に対応する表記を作成してそのサブプロパティとする)こうすると、複数の表記とAiliasの両方に対応できて、他の言語で翻字が存在する場合にもなんとかなるだろうとおもっていますが、ぼんやり考えている程度なので問題はまだあるかもしれません。ひとまずはヘボン式ローマ字以外のローマ字(訓令式、日本式、パスポート式)にプロパティが必要そうだなあ、とは考えています。また、日本語限定の構造から脱却するにはどうにかしてtransliteration (P2440)に絡めたい思いはあるのですがそこまで考えられていません。
    なお、WikidataはWikipediaのサブプロジェクトとか、同じ概念が同じ表記で存在するものではないので、Wikipediaの何かを直接Wikidataから生成するのはよほど考え抜いたものでない限りはあまり賛成できません。Wikipediaの項目がすべてWikidataと同期する、というのができていなければ実現できず、私が見た中でもWikipediaからWikidataに移行した後に、Wikipediaで名前を変更していてWikidataのラベルとWikipediaのタイトルがずれているものは多数存在します。--Suisui (talk) 16:26, 1 January 2018 (UTC)
      Comment プロパティーの値がLabel/Aliasのどの表記に対応するものか明示的に指定できていない問題は、name in kana (P1814)に限らず、named after (P138)でも生じているように思います。例えば「バセドウ病」と「グレーブス病」の2つの呼び方があるtoxic diffuse goiter (Q16483)などです。その点に関しては、ここだけでは決められませんが、named after (P138)name in kana (P1814)の両者での問題に解決できる「以下のlabel/aliasについての」のようなmonolingualtextの修飾子を用意するのがシンプルで良い気がします。 --Okkn (talk) 05:44, 3 January 2018 (UTC)
    スタイルが統一されていた方が、プログラムなどを介して利用する人は使いやすいですね。こうした取り組みに賛成です。個人的に気になるところとして、中国の人名や地名の読み仮名はどうなるでしょうか。たとえば Mao Zedong (Q5816) には name in native language (P1559) の項目があります。現状では中国語の二つの字体(?)の記述がありますが、日本語の読みはどんな感じに入るでしょう。単純なアイデアとしては次のような方法ですが。
    name in native language
      毛澤東 (Chinese)
      毛泽东 (Chinese)
      毛沢東 (Japanese)
    name in kana もう たくとう
    0 references
    add reference

    add value
    しかし native language (母語) の項目に「日本語」の表記が入るのも、やや変です。かといってウィキデータに日本語での読みが登録されてない、というのも変な話です。読み仮名を格納する良い方法はどこになるでしょう。--Was a bee (talk) 05:51, 3 January 2018 (UTC)
    基本的には、各国語での表記は label または alias として格納されているはずで、その中でどれが母語の表記なのかを明示的にするのが name in native language (P1559) なのではないでしょうか。もっと一般化した「表記」を示すプロパティーがあってもいいと思いますが、そういうのがない限り、name in kana (P1814) を修飾子に限定するのは少し無理があると思います。 --Okkn (talk) 06:00, 3 January 2018 (UTC)
    私も修飾子に限定するという点はやや厳しいかと思います。理念として「日本語単独のプロパティがあるのはよろしくない」というのは分かりますが、現状 name in kana (P1814) は他によい方法がない中での応急処置のようなものかと。この点については、本来的には label/alias の所が構造化され、複雑はデータを記録できるようになってくれなりしないと、どう仕様もない所があると思います。--Was a bee (talk) 07:04, 3 January 2018 (UTC)
    中国の人名や地名に対して日本語表記+読み仮名を記載するのであれば、name (P2561)を使うという方法があります(このプロパティの存在をすっかり忘れていました)。漠然としたプロパティではありますが、母語とか原語じゃないからってP1814を直接使ったりするよりは幾分マシかと思います。--本日晴天 (talk) 11:40, 3 January 2018 (UTC)
      毛沢東 (Japanese)
    name in kana もう たくとう
    0 references
    add reference

    add value
    ただ、name in native language (P1559)name (P2561) も人名用のプロパティーだと思われますので、これらを人名以外の場面で使うことは推奨されません。実際にはname (P2561)のリンク元を見るとよくわからない使われ方がたくさんなされていますが…。 --Okkn (talk) 12:03, 3 January 2018 (UTC)
    name in native language (P1559)は人物用(人物以外用ではnative label (P1705)が類似)ですが、name (P2561)は人物以外に使ってもいいのではないでしょうか。確かにProperty:P2561ではinstance of (P31)の値の1つがWikidata property for items about people (Q18608871)ですが、一方でクラス制約などのプロパティ制約が何一つありません。このページでも使われているTemplate:Person propertiesには載っていませんし、Template:Name propertiesでは一般(Gereral)のところに分類されています。気になるようであればProperty talk:P2561で問い合わせた方がいいかもしれません。--本日晴天 (talk) 14:21, 3 January 2018 (UTC)
    ちょっとした情報ですが、Wikidata:WikiProject Names/PropertiesにおいてもP1814を修飾子として使うことが想定されているようです。--本日晴天 (talk) 14:27, 3 January 2018 (UTC)

    @Afaz, 本日晴天, Doraemonplus, Suisui, Was a bee: P1814を修飾子以外で使うことの是非はまだ議論の余地が残されていますが、applies to name of item (P5168)が利用可能になりましたので、P1814を通常のプロパティーとして使用する際に読み仮名がどの日本語の名前(Label or Alias)に対応するものであるのかを明示的に示せるようになったことをご報告いたします。--Okkn (talk) 06:43, 18 May 2018 (UTC)

    format constraintEdit

    Lucas Werkmeister (WMDE)
    Jarekt - mostly interested in properties related to Commons
    John Samuel
    Yair rand
    Jon Harald Søby
    Was a bee
    Peter F. Patel-Schneider
    ZI Jony
    Mathieu Kappler
      Notified participants of WikiProject property constraints Ash Crow
    Harmonia Amanda
    Чаховіч Уладзіслаў
    Place Clichy
    Jon Harald Søby
    Sight Contamination
    Aya Reyad
    Tris T7
    Klaas van Buiten
    Bruno Biondi
    ZI Jony
    Da Dapper Don
    Data Gamer
    Luca favorido
    The Sir of Data Analytics
    Susanna Giaccai
      Notified participants of WikiProject Names @Nikki, Thibaut120094, Ivan A. Krestinin:
    I wanted to let you know that the current format constraint of this property, format as a regular expression (P1793) [\p{Hiragana}\p{Katakana}ー・  ]+, doesn’t work in the checkConstraints gadget, due to the \p{Hiragana} and \p{Katakana} character classes. In the WikibaseQualityConstraints extension, we check the format constraint (Q21502404) constraint type using the Wikidata Query Service, which uses java.util.regex.Pattern for regular expressions (Javadoc), where categories for scripts are denoted as \p{IsHiragana} or \p{script=Hiragana} (see the “Unicode support” section of the Javadoc), but \p{Hiragana} isn’t supported. Unfortunately, neither of these forms is understood by PCRE, which is what KrBot uses to check the same constraint: PCRE only supports \p{Hiragana}.

    I’m not sure what the best way forward is. I can think of a few options:

    • Someone discovers a form of the regex that’s understood by both the Java and PCRE flavors. I don’t think this exists, but if I’m wrong, it would be the ideal solution :)
    • We add some way to restrict where a constraint is checked, and you define the constraint twice, once restricted to WikibaseQualityConstraints (with \p{IsHiragana}) and once restricted to KrBot (with \p{Hiragana}). But that’s a fairly ugly hack, and the two versions of the constraint might diverge.
    • We settle on one of the regex forms and adapt the other constraint-checking system to rewrite the regular expression accordingly before testing it – that is, either KrBot learns to turn \p{script=Hiragana} into \p{Hiragana}, or WikibaseQualityConstraints learns to turn \p{Hiragana} into \p{script=Hiragana}. I would prefer the first version, because it’s more explicit: if the regular expression just contains \p{AbcdXyz}, how can I know that I need to turn it into \p{script=AbcdXyz} and not \p{block=AbcdXyz} or \p{general_category=AbcdXyz}? In the PCRE syntax, all those properties are combined into the single \p{AbcdXyz} syntax, but in Java they’re different. (Though I must admit – the first version is also the one that means less work for me and more work for Ivan A. Krestinin.)

    What do you think? --Lucas Werkmeister (WMDE) (talk) 18:11, 16 January 2018 (UTC)

    @Lucas Werkmeister (WMDE): I replaced [\p{Hiragana}\p{Katakana} with [ぁ-ゔァ-ヴ(diff). Let's see how this works. --本日晴天 (talk) 12:23, 18 January 2018 (UTC)

    Should we add a comma to the list of accepted characters? Japanese names are usually in the format "Surname, Name", but when I added the kana reading "マツナガ, シュウゾウ" to Shuzo Matsunaga (Q47068396), it raised a regex error. After removing the comma, the error was gone. —capmo (talk) 16:04, 30 May 2018 (UTC)

    @Capmo: His correct name is 松永脩蔵. NDL Authorities add a comma and a space between surname and given name for some reasons. Another example: [1](Natsume Sōseki (Q180903)). We often add a space between surname and given name at value of name in native language (P1559), name in kana (P1814), etc. but comma isn't used.--本日晴天 (talk) 02:55, 31 May 2018 (UTC)
    Return to "P1814" page.