Property talk:P1814
Documentation
the reading of a Japanese name in kana
[ぁ-ゔァ-ヴー「」・ \-〜?!、()0-90-9]+
”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P1814#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1814#Entity types
List of violations of this constraint: Database reports/Constraint violations/P1814#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1814#Label in 'ja' language, search, SPARQL
This property is being used by: Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
|
|
|
Discussion
[edit]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)
- ある文(statement)における値(value)のデータ型(datatype)が"Monolingual text"であり、その値の言語コード(language code)が"ja"である場合に限って修飾子(qualifier)としてname in kana (P1814)を使用するのがいいと思います(例1例2)。修飾子としてname in kana (P1814)を使用する場合、大元となるプロパティ(property)はname in native language (P1559)やnative label (P1705)に限らず、official name (P1448)、demonym (P1549)、title (P1476)など、データ型に"Monolingual text"を指定しているものであればなんでもいいでしょう。
- "ja-Kana"のような仮名専用のコードを作成することにはどちらかというと反対( weak oppose)です。仮名表記があるということはそれに対応する日本語としての本来の表記(仮名表記と同じ場合もあります)があるはずです。name in native language (P1559)やnative label (P1705)の値に"ja-Kana"を指定したところで、name in kana (P1814)を独立した文に対して直接使用すること(現時点で最も多い使われ方です)と大して違いはないと考えます。name in kana (P1814)を修飾子として使うことに比べ、"ja-Kana"のようなコードを導入することにメリットはあるのでしょうか。--本日晴天 (talk) 16:12, 8 November 2016 (UTC)
- How about using name in kana (P1814) only as qualifier of Japanese text (example 1, example 2). In
thiseither usage, the base properties can be anything that need monolingual text values(e.g. official name (P1448), demonym (P1549), title (P1476)). --本日晴天 (talk) 07:59, 12 November 2016 (UTC) --本日晴天 (talk) 16:41, 14 November 2016 (UTC)- Itou Nagatoshi (Q11379598)のようにUnicodeにない漢字を用いている場合や上 (Q2410263)、𱁬 (Q7676480)のような漢字を主題とする項目であれば例外的にname in kana (P1814)を単独で使用していいかもしれませんね。--本日晴天 (talk) 16:41, 14 November 2016 (UTC)
- name in kana (P1814) might be used alone (not as qualifier) in several cases: Itou Nagatoshi (Q11379598), the name contains a kanji which isn't encoded in the Unicode character set; 上 (Q2410263) and 𱁬 (Q7676480), items about individual kanji character.--本日晴天 (talk) 16:41, 14 November 2016 (UTC)
- I think I would rather see this replaced with a more generic Wikidata property for romanization system (Q20085670) such as a subproperty of transliteration or transcription (P2440) (much like revised Hepburn romanization (P2125)). It could easily be added as a qualifier to any of name (P2561), name in native language (P1559), native label (P1705), birth name (P1477), short name (P1813), taxon common name (P1843) or others (in a manner similar to literal translation (P2441) or taxon name (P225)). In situations where one wants to apply kana to something not available within Unicode, there are other "name" properties to choose from and a kana transliteration would be generically more useful than one tied to just names (some were mentioned above but in addition: working title (P1638), subtitle (P1680), etc.). 50.53.1.33 15:39, 12 April 2017 (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)
- 平仮名・片仮名の使い分けに関してはw:ja:Wikipedia:スタイルマニュアル_(導入部)#読み仮名に従うことを推奨する、くらいにしておくのが無難かと思います。半角スペース以外の記号を禁止するくらいの変更はあってもいいかもしれませんが。平仮名・片仮名の使い分けに関して独自のガイドラインを作るにすることにも反対はしませんが、その場合は非日本語話者や外部からP1814を移入するBotへの配慮は必要になるでしょう。
- 漢字が使われていないラベルの項目では使用すべきでないというのは条件が厳しいと思います。Akira 100percent (Q22123227)やQ11254948などは漢字が含まれていませんが、読み仮名は記載した方がいいでしょう。私は「仮名文字および中黒などの約物のみが使われていて読みが自明なもの」かどうかで使用条件を定めるべきだと考えます。私としては以下に示す使われ方を想定しています。
P1814は原則として文の修飾子として使用する。修飾される文のプロパティおよび値は以下の要件をすべて満たしていなければならない。
|
- 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 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)
- 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 |
| ||||||||||||||||||||||||||||||
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)
- 基本的には、各国語での表記は label または alias として格納されているはずで、その中でどれが母語の表記なのかを明示的にするのが name in native language (P1559) なのではないでしょうか。もっと一般化した「表記」を示すプロパティーがあってもいいと思いますが、そういうのがない限り、name in kana (P1814) を修飾子に限定するのは少し無理があると思います。 --Okkn (talk) 06:00, 3 January 2018 (UTC)
- しかし native language (母語) の項目に「日本語」の表記が入るのも、やや変です。かといってウィキデータに日本語での読みが登録されてない、というのも変な話です。読み仮名を格納する良い方法はどこになるでしょう。--Was a bee (talk) 05:51, 3 January 2018 (UTC)
name |
| ||||||||||||
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)
- ただ、name in native language (P1559) も name (P2561) も人名用のプロパティーだと思われますので、これらを人名以外の場面で使うことは推奨されません。実際にはname (P2561)のリンク元を見るとよくわからない使われ方がたくさんなされていますが…。 --Okkn (talk) 12:03, 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 subject (P5168)が利用可能になりましたので、P1814を通常のプロパティーとして使用する際に読み仮名がどの日本語の名前(Label or Alias)に対応するものであるのかを明示的に示せるようになったことをご報告いたします。--Okkn (talk) 06:43, 18 May 2018 (UTC)
format constraint
[edit]Notified participants of WikiProject property constraints
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)
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)
- I have removed numbers from regex. Please revert if there are objections. Laftp0 (talk) 10:43, 9 December 2022 (UTC)
- I think it is better to allow numbers. 数字は許容した方がいいように思います。 Kokage si (talk) 09:26, 10 January 2024 (UTC)
- I included numbers again. Kokage si (talk) 13:09, 16 January 2024 (UTC)
- I think it is better to allow numbers. 数字は許容した方がいいように思います。 Kokage si (talk) 09:26, 10 January 2024 (UTC)
- All Properties
- Properties with string-datatype
- Properties used on 100000+ items
- Properties with format constraints
- Properties with conflicts with constraints
- Properties with entity type constraints
- Properties with scope constraints
- Properties with label language constraints
- Person properties
- Han character properties