Wikidata

User:KAMEDA, Akihiro/note1

< User:KAMEDA, Akihiro

wikibase:label で Description も得られる

edit

recurring event の修飾子としての頻度はまともな利用が無かった

edit

リバートされて、説明して、記述しなおした件、そもそも頻度を修飾子として用いる例はあるのかと、修飾子としての利用をしている記事を検索 したら、instance of のところで event interval を指定して、修飾子 constraint 違反をくらっている記事ばかりだった Nuit Blanche (Q2633280) Kom in de Kas (Q2004206) Dutch National Jamboree (Q4433028) Oxonmoot (Q101526620) Q2473639 ので直した。annual event (Q11483816) とかつけるという手もあるけどね。ちなみに、あるイベントのコピーイベントみたいなのが生まれて、それは biennial だった場合、subclass の継承に問題が生じるよね。たぶん、イベントのクラスとして interval を含むのはそもそも間違いだと思うよ。

面白クエリ集

edit
  • "10 cool queries for Wikidata that will blow your mind. Number 7 will shock you. - Wikimedia Deutschland Blog". Retrieved 2022-03-24.

Wikidata の数値は基本 Decimal

edit

Wikidata の日付の精度について

edit

"KAMEDA Akihiro on Twitter". Retrieved 2022-10-11. SPARQLで日付をシンプルに引くと、1970年と1970年1月1日は混同されているように見える（全部後者表示）。でもちゃんと内部では精度情報を持っていて "11"で日まで、"8"だったらx十年代までの精度例 ←を探すクエリ [1]

Wikidata の Quantity 型をつかったクエリ

edit

from "KAMEDA Akihiro on Twitter/ Twitter". Retrieved 2022-03-24. "@_masaka たぶんそういうことですね、そのDataType のページの"Pending data types"にintegerはあるので将来実装されるかもしれませんけれど。Quantity型面白いですね、mileで定義されてようがkmで定義されてようが揃えて比較するクエリとかが書きやすい"

モデルを理解するためのサンプルをここに置いておいた

"sample of normalized quantity in Wikidata". Retrieved 2022-03-24.

Wikidata の粒度の方が Wikipedia より細かいときに Wikipedia との対応をどう関係づけるべきか

edit

メインの記事を選定して、それと対応付けておいて、あとは described at URL (P973)使えばいいんじゃないかな P973のたぶんそういう使用例

例えば、John Somerville (Q104631467) は赤記事が言及されている曖昧性解消ページにリンクしてたりする。

described at URL (P973) は そのセマンティクスに関する議論 があったプロパティで、なかなか難しいけどね。

https://www.wikidata.org/wiki/Talk:Q1988927 は表題の事例に相当するけどウクライナ語ができないので、解決を諦めた。

Eijkman Institute for Molecular Biology (Q1303680) は分けてみた。多言語がある記事だと、described at URL (P973) も不適切な気が一瞬するが（つまり、まとめて指したくなるが）、どの言語版にその情報があるかわからないから described at URL (P973) で個々に書くのは有用だろう

関連項目:

複数の項目を扱ったWikipedia記事に対応するWikidata項目はunionを使って表現する

edit

例として upper and lower bounds (Q13222579) があるけれど、これは disjoint union of (P2738) upper bound (Q42866132), lower bound (Q12254923) で表現されている。厳密には、list of values as qualifiers (Q23766486) を介しているが、これは RDF では union の先のまとまりを rdf:List などで表現しなければ、開世界仮説上にて、実質の union のセマンティクスが表現できないから（もっと集合範囲が広がる可能性を持ち続けるならば union を記述する意味がない、一つの subclass でしかない）。そして、この union 関係の逆としては subclass を書けばよいことは 基本プロパティのページで比較を見ればわかります。

Wikidata の の最大元と最小元

edit

entity (Q35120) と ‎nothing (Q154242)。 もちろん部分集合には最大元がない（比較不能である元があるのが普通）。これによって上限と下限は常に存在するので、  は complete lattice (Q2362924)。

Wikinegata

edit

Wikinegataの論文。OWAの中で、negation の情報をどう推測するか。基本的には、Aに似たエンティティ   を寄せ集めてきて、(1) sの十分な数について、s p o が成立 (2) A p o は書かれていない (3) A p o2 ( o2 ≠ o ）という条件が満たされれば、 A p o は偽と推測するというストラテジ。

Wikidata で negation 書くには no value を指定する

edit

DataReuseDays2022

edit

特に面白かったの

  • Histropedia: Triumphs and challenges of reusing Wikidata スライド分かりやすい。事例もいい。Wikidata Schemaも興味ある。
  • Building family trees and other diagrams with Wikidata 普通に仕事につかえそう。完璧にニーズ満たしてるのはないから contribute は必要だけど。
  • Wikidata & OpenStreetMap editing session nsi.guide OSM のブランド（スタバとか）検索できるやつ。
  • Lightweight entity linking with OpenTapioca 寝ちゃって聞いてないんだけど論文もあるし、あとで読む

P123 の type constraint 整理

edit

Fantastoria さんとのやりとり の後で整理したもの。

publisher (P123) の type constraint とそのスーパークラスは こういうクエリ で確かめられる。CSV でダウンロードして少し成形する（各行を"illustrated work P279 subclass of creative work thing|thing"みたいにする）と、Simple Dynamic Modelling の可視化ツールでネットワークが見れるが、大抵あまりに複雑すぎるので表で理解した方が早い（今は既に整理済みなので比較的シンプルになっている）。publication (Q732577) document (Q49848) のサブクラスが複数含まれていたから、それらを消した。organization (Q43229) は単に不適切だったので消した。たぶん Earth Island Journal (Q106776582) のように兼ねていることがあるからだが、organization (Q43229)単体では publisher は持ちえない。electronic game (Q2249149) は publisher を持つのは artificial object (Q16686448) の側面を持つからで、 game (Q11410) 単体では publisher は持ちえない。electronic game (Q2249149) を加え、そのサブクラスと {Q|11410}} を消した。manifestation (Q286583) group of manifestations (Q17538690) は加え、そのサブクラスを消した。release (group) series (Q110940584) single series (Q64341971) とかは series of creative works (Q7725310) のサブクラスなので消した。imprint (Q2608849) は会社とブランドの関係だから、owned by (P127) で繋がれるべき 例 Minute Maid (Q1206056). そういうのはまたインスタンスレベルでデータを整理しなきゃいけない。もともと、publisher は work ではなくmanifestation につくという本を基本とした FRBR 的なデータモデルに基づくわけだが、ranked list (Q80793969) みたいな本から離れたものは work と manifestation の区切りが本ほどハッキリしていないので、work なのに publisher を持っているということもあるかもしれない。でも、それは本来、クラスの方に manifestation の性格があることを付け加えるべきである。Global Frequency (Q834204) のように comics (Q1004) については manifestation 込みの comic book (Q1760610) こういうクラスがあるのでそれを付せばいい。こういうの調べるのは 特定クラスのインスタンスの creator と publisher を列挙するクエリが便利 series of creative works (Q7725310) も多数該当するが、クラスを適宜加えるべきかな。

色んなクラス software (Q7397) document (Q49848) data (Q494756) publication (Q732577) data set (Q1172284) に manifestation を親クラスとしてつけることで、リストから削除した。一方で、VDI standard (Q2505632) はインスタンスレベルで 両面性を持つべきであり、その側面を考慮しつつ外した。こういう感じで整理したが、それでもいくつかは「publisher っていう気がするな…」というものを残した。

参考：

- FRBR について publisher が manifestation についてるという証拠。より詳しくは、じんもんこんの「FRBRモデルのWork/Expression関係に基づく関連管理」あたりが参考になる。

Data set のサブクラス一覧

edit

database (Q8513) も data set (Q1172284) のサブクラス。（ bot に変な変更されていた ので戻した） index (Q873506) は database (Q8513) のサブクラスになっていたが、チェコ語の単一記事からの merge に由来するもので、一般的に、デジタルなデータとさえ限らないので、外した。catalogue (Q2352616) も必ずしも data set (Q1172284) ではないから外した（ 07:18, 2017 June 12 by Pigsonthewing の編集の revert に相当。前後の文脈が不明）

集合の変化に関するプロパティが足らない

edit

領域の分離 detachment (Q5265556) （一部が独立する）、split into に相当する元のものが消滅して複数になる現象（この逆プロパティは separated from (P807) で存在する）、integrates の相当する元の複数のものが消滅して一つになる現象 （この逆プロパティは merged into (P7888) で存在する、National Research and Innovation Agency (Q97200300) の事例を考えると integrate というより Absorption merger? union (Q185359) より時系列的な含意のある）、それらの上位プロパティとしての reform 概念、それと end time (P582) qualifier of has part(s) (P527) (or its sub-property) statements. See the relationship between Google (Q95) and Niantic (Q13462819) for an example との関連整理、その際に start time (P580) や end time (P582) が qualifierなのにdissolved, abolished or demolished date (P576) は merged into (P7888) に伴う必須「プロパティ」である非対称さ、obsolete な情報を deprecated した場合に情報が検索しにくくなる問題、 replaced by (P1366) のディスカッションでの applies part の微妙さ、Wikidata:Property_proposal/merged_into で描かれている We can not achieve this with part of (P361) and a date qualifier because Platform for Catalonia (Q2737634) does not exist after the fusion. It is an argument similar to the one given in the proposal of separated from (P807): Presbyterian Church in America (Q3555519) did not exists before the separation 問題、全部整理してプロパティを提案したりクエリを作ったりすべきだと思う。はじめ merged into を replaced by のサブプロパティにしようと思ったけど、そういうの論理的な厳密性とか使われ方とか検査しないと危ない。

博物館が運営しているバーチャルミュージアム

edit

Museu Histórico da Imigração Japonesa no Brasil (Q10333505) (TKさんが作成に関わられたという話で知った）の場合、そこにクラスとしてバーチャルミュージアムを付けてしまうと、maintained by (P126) が自己言及の形を取らないといけないとか、inception (P571) や coordinate location (P625) のように妥当しないプロパティを抱えることになるので分けた方がいい。一方で、main subject (P921) などは当然共有しているし、official website (P856) に関しては distinct-values constraint (Q21502410) 違反になる。後者は Eijkman Institute for Molecular Biology (Q1303680) でもあった問題で、例外も多数規定されている（それはそれで問題があるものも多い）制約。ウェブサイトのバーチャルミュージアム機能程度ならば、official website (P856) に qualifier として何かつけることで解決したくなるな。渡航者リストとかは別項をたててもいいけど。qualifierを眺めるクエリ poLabel つけるとタイムアウトするし、distinct でカウントしてもタイムアウトするし難しい。P1552 has characteristic (P1552) あたりはよさそう？→そもそも分離して書くほどじゃないものならば書かない。美術館・博物館のウェブサイトは多かれ少なかれ何らかの形でその収蔵品に関わる情報をみせているものだし。その側面からはちゃんと博物館を探せるようにすることが大事。→ 石川さんのデータを再訪する

韓国の国立博物館一覧

edit

https://w.wiki/64z9 

#defaultView:Map
SELECT ?item ?itemLabel ?inception ?coordinate
WHERE 
{
  ?item wdt:P31 wd:Q17431399;
        wdt:P17 wd:Q884.
  OPTIONAL {?item wdt:P571 ?inception;
  wdt:P625 ?coordinate.}
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],ja,en". } 
}

National Museum of Korea (Q494407) の日本語 Wikipedia 記事を加筆したついで。

Retrieved from "https://www.wikidata.org/w/index.php?title=User:KAMEDA,_Akihiro/note1&oldid=1784960638"