Property talk:P1814

From Wikidata
Jump to navigation Jump to search

Documentation

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)
See alsorevised Hepburn romanization (P2125)
Lists
  • 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
    Total297,963
    Main statement270,06790.6% of uses
    Qualifier27,8759.4% of uses
    Reference21<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#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 'ja' language, search, SPARQL

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

    Discussion

    [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)[reply]

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

    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)[reply]

    平仮名・片仮名の使い分けに関してはw:ja:Wikipedia:スタイルマニュアル_(導入部)#読み仮名に従うことを推奨する、くらいにしておくのが無難かと思います。半角スペース以外の記号を禁止するくらいの変更はあってもいいかもしれませんが。平仮名・片仮名の使い分けに関して独自のガイドラインを作るにすることにも反対はしませんが、その場合は非日本語話者や外部からP1814を移入するBotへの配慮は必要になるでしょう。
    漢字が使われていないラベルの項目では使用すべきでないというのは条件が厳しいと思います。Akira 100percent (Q22123227)Q11254948などは漢字が含まれていませんが、読み仮名は記載した方がいいでしょう。私は「仮名文字および中黒などの約物のみが使われていて読みが自明なもの」かどうかで使用条件を定めるべきだと考えます。私としては以下に示す使われ方を想定しています。
    P1814を修飾子として使用することを前提としていますが、3つのうち上2つの制約により、P1814が使用可能な項目は概ね日本もしくは日本語に関連したものに制限されます。汎用的に使用可能で、「各国語表記」に相当するプロパティが存在しない(あってもdemonym (P1549)のように限定的)からです。私としてはこれをそのままP1814の使い方のガイドライン案としたいところですが、皆様はどう思われるでしょうか。--本日晴天 (talk) 05:04, 30 December 2017 (UTC)[reply]
    プロパティは個々の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 or transcription (P2440)のサブプロパティのみとして使用するのがいいのではないかと考えてはいます。(language of work or name (P407) = Japanese (Q5287)ではnative label (P1705)の表記に対しての読み、それ以外ではtitle (P1476)に対応する表記を作成してそのサブプロパティとする)こうすると、複数の表記とAiliasの両方に対応できて、他の言語で翻字が存在する場合にもなんとかなるだろうとおもっていますが、ぼんやり考えている程度なので問題はまだあるかもしれません。ひとまずはヘボン式ローマ字以外のローマ字(訓令式、日本式、パスポート式)にプロパティが必要そうだなあ、とは考えています。また、日本語限定の構造から脱却するにはどうにかしてtransliteration or transcription (P2440)に絡めたい思いはあるのですがそこまで考えられていません。
    (追記)ラベルの変更を考えると、P1705とP1476両方につけておいたほうがメンテナンス生良さそうですね。。
    なお、WikidataはWikipediaのサブプロジェクトとか、同じ概念が同じ表記で存在するものではないので、Wikipediaの何かを直接Wikidataから生成するのはよほど考え抜いたものでない限りはあまり賛成できません。Wikipediaの項目がすべてWikidataと同期する、というのができていなければ実現できず、私が見た中でもWikipediaからWikidataに移行した後に、Wikipediaで名前を変更していてWikidataのラベルとWikipediaのタイトルがずれているものは多数存在します。--Suisui (talk) 16:26, 1 January 2018 (UTC)[reply]
     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)[reply]
    スタイルが統一されていた方が、プログラムなどを介して利用する人は使いやすいですね。こうした取り組みに賛成です。個人的に気になるところとして、中国の人名や地名の読み仮名はどうなるでしょうか。たとえば Mao Zedong (Q5816) には name in native language (P1559) の項目があります。現状では中国語の二つの字体(?)の記述がありますが、日本語の読みはどんな感じに入るでしょう。単純なアイデアとしては次のような方法ですが。
    name in native language
    Normal rank 毛澤東 (Chinese)
    Normal rank 毛泽东 (Chinese)
    Normal rank 毛沢東 (Japanese)
    name in kana もう たくとう
    0 references
    add reference
    add value
    しかし native language (母語) の項目に「日本語」の表記が入るのも、やや変です。かといってウィキデータに日本語での読みが登録されてない、というのも変な話です。読み仮名を格納する良い方法はどこになるでしょう。--Was a bee (talk) 05:51, 3 January 2018 (UTC)[reply]
    基本的には、各国語での表記は label または alias として格納されているはずで、その中でどれが母語の表記なのかを明示的にするのが name in native language (P1559) なのではないでしょうか。もっと一般化した「表記」を示すプロパティーがあってもいいと思いますが、そういうのがない限り、name in kana (P1814) を修飾子に限定するのは少し無理があると思います。 --Okkn (talk) 06:00, 3 January 2018 (UTC)[reply]
    私も修飾子に限定するという点はやや厳しいかと思います。理念として「日本語単独のプロパティがあるのはよろしくない」というのは分かりますが、現状 name in kana (P1814) は他によい方法がない中での応急処置のようなものかと。この点については、本来的には label/alias の所が構造化され、複雑はデータを記録できるようになってくれなりしないと、どう仕様もない所があると思います。--Was a bee (talk) 07:04, 3 January 2018 (UTC)[reply]
    中国の人名や地名に対して日本語表記+読み仮名を記載するのであれば、name (P2561)を使うという方法があります(このプロパティの存在をすっかり忘れていました)。漠然としたプロパティではありますが、母語とか原語じゃないからってP1814を直接使ったりするよりは幾分マシかと思います。--本日晴天 (talk) 11:40, 3 January 2018 (UTC)[reply]
    name
    Normal rank 毛沢東 (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)[reply]
    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)[reply]
    ちょっとした情報ですが、Wikidata:WikiProject Names/PropertiesにおいてもP1814を修飾子として使うことが想定されているようです。--本日晴天 (talk) 14:27, 3 January 2018 (UTC)[reply]

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

    format constraint

    [edit]
    Lucas Werkmeister (WMDE)
    Jarekt - mostly interested in properties related to Commons
    MisterSynergy
    John Samuel
    Sannita
    Yair rand
    Jon Harald Søby
    Pasleim
    Jura
    PKM
    ChristianKl
    Sjoerddebruin
    Fralambert
    Manu1400
    Was a bee
    Malore
    Ivanhercaz
    Peter F. Patel-Schneider
    Pizza1016
    Ogoorcs
    ZI Jony
    Eihel
    cdo256
    Epìdosis
    Dhx1
    99of9
    Mathieu Kappler
    Lectrician1
    SM5POR
    Infrastruktur
    Samoasambia

    Notified participants of WikiProject property constraints

    Ash Crow
    Dereckson
    Harmonia Amanda
    Hsarrazin
    Jura
    Чаховіч Уладзіслаў
    Joxemai
    Place Clichy
    Branthecan
    Azertus
    Jon Harald Søby
    PKM
    Pmt
    Sight Contamination
    MaksOttoVonStirlitz
    BeatrixBelibaste
    Moebeus
    Dcflyer
    Looniverse
    Aya Reyad
    Infovarius
    Tris T7
    Klaas 'Z4us' van B. V
    Deborahjay
    Bruno Biondi
    ZI Jony
    Laddo
    Da Dapper Don
    Data Gamer
    Luca favorido
    The Sir of Data Analytics
    Skim
    E4024
    JhowieNitnek
    Envlh
    Susanna Giaccai
    Epìdosis
    Aluxosm
    Dnshitobu
    Ruky Wunpini
    Balû
    ★Trekker

    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)[reply]

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

    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)[reply]

    @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)[reply]

    numbers

    [edit]

    Should we include numbers in regex? They are not kana and always pronounced. Note that revised Hepburn romanization (P2125) doesn't include numbers. Laftp0 (talk) 14:58, 8 December 2022 (UTC)[reply]

    I have removed numbers from regex. Please revert if there are objections. Laftp0 (talk) 10:43, 9 December 2022 (UTC)[reply]
    I think it is better to allow numbers. 数字は許容した方がいいように思います。 Kokage si (talk) 09:26, 10 January 2024 (UTC)[reply]
    I included numbers again. Kokage si (talk) 13:09, 16 January 2024 (UTC)[reply]