Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

"哇ㄟ"@79-AAA-jh = "我的"@79-AAA

f:id:cm3ak:20190728171432p:plain
哇ㄟ筆勒

YouTube で聴いていた歌の間奏部分で、"哇ㄟ筆勒" という表記が出てきてよくわからなかったので、調べてみたら、これは台湾語を漢字と注音記号で書いた表記で、"哇ㄟ" の部分は "我的" の意味、勒 は語気助詞(呢、啊、吧とかの仲間)で「~は?」という疑問を表すものだった。

"哇ㄟ" は発音としてアルファベットで書くと、wa ei となる。台語 警察を呼ぶ Call the policeというページの発音の「我的」で始まるフレーズを聞くとそれっぽい。

勒については 台湾で使われる中国語 語気助詞の違いについて ( 2 ) (音声付き) -「喔 (o),唷 (yo),勒/咧 (lei/lie),囉 (luo)」 | ぽずかふぇ に書かれていたし、大陸中国人にも聞いたけれど知っていた。

ちなみに、表題の 79-AAA-jh は 所謂台湾語=Taiwanese Hokkien を示す Linguasphere のIDである。IETF言語タグ の language tag にはISO 639-3が使われているがそれで台湾語を指すことはできない。linguasphère は単なる研究ネットワークでISOほどの標準化機能は無く、データベースとしてはある研究者が Han-Yu - hortensj-garden.org のように作っているものが存在するのみで知名度は低いが、ISO 639 より網羅性が高い。(階層性を持ち込んでしまうと、研究によって更新されうるので、あまりID体系としては好みじゃないけれど)

項目名付きリテラルという選択肢 - Drafts の補足として。

他の選択肢として、述語を詳細化する以外に typed literal にするという選択肢があって、それについて検討を加えたのと、CSVのセル内の構造データの扱い方についてのメモを書いておく

typed literal について

Triple store で一般的にサポートされている typed literal は XSD data types と呼ばれるもので、intとかdoubleとかdateTimeとかW3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes に見られるようなものだ。これによって数字や日付の一致や比較ができるようになっている。

項目名付きリテラルも"項目名がついたリテラルだ"という処理ができれば、項目の一覧を出したりできるといったように利便性が上がるかもしれないので、typed literal として扱う方法はないか、もしくは、項目名ごとに別々に typed literal にするのはどうなのか、そもそも typed literal は規約上、実装上、どのようになっているのか、と考えて、

を流し読んで、その後の実情などもチェックしたのだけれど、

  • typed literal の扱いは基本的に実装依存
  • typed literal の type を示す URI に何を書くかさえ規定されていない

さっき言及した基本的な xsd についてさえ

Multiple datatypes may be de-fined in the same document, such asxsd:stringandxsd:intthat are defined in thesame document at locationhttp://www.w3.org/2001/XMLSchema. Hence the RDFprocessor would not know what part of the code it should execute for each datatype.

という状況

  • だから論文では以下のインタフェースをJavaScriptで提供するURLをURIにする提案をしている
String getIri()
Boolean isWellFormed (lexicalForm)
Boolean recognisesDatatype (datatypeIri)
String[] getRecognisedDatatypes ()
Boolean isEqual (lexForm1, lexForm2[, datatypeIri2])
Integer compare (lexForm1, lexForm2[, datatypeIri2])
String getNormalForm (lexicalForm1)
String importLiteral (lexicalForm, datatypeIri)
String exportLiteral (lexicalForm, datatypeIri)

という結論です。

Custom Datatype というページに述語の詳細化のメリットが

  • Simpler querying of data by allowing the use of triple patterns, rather than FILTERs for extracting data of a common type.
  • More explicit, fine-grained semantics

デメリットが

  • Increases the number of very similar properties, requiring redundancy of data or reasoning to allow applications to treat them generically
  • Doesn't address the core requirement to indicate the lexical form of a structured value

と書かれていて、typed literal については

  • Use a custom datatype to label particular types of structured value that share a common lexical form. These values may be associated with a broad range of different properties. Processing applications may want to implement a common set type conversions or display options for the values.
  • Use a sub-property in all other cases

と書かれている。項目付きリテラルは幅広いプロパティの値として使えるので、規定しても良いけれども、結局ご利益が「項目の一覧を出したり」云々ならば、分析対象の項目名付きリテラルをSPARQLで一覧出力して、それに対してテキスト処理するのが正当であり、それが簡単にできるようにしておけば良い。また、項目ごとに別々の typed literal にするというのは以上より論外の選択肢。

もっといえば、RDF化するまえの元データをデータリポジトリで共有しておいた方がこういう分析には向く。

雑多な表構造メタデータに混ざってくるセル内のリスト構造

"1,4,10" みたいにリスト構造が1個のセルの中に入ってくることってそれなりにある。関わってるプロジェクトのうち2つでエクセルのセル内でリスト構造を扱うことになり、どちらも検討の結果セミコロンがデリミタに選定されている。カンマの方がプログラミング言語的にはリスト構造のデリミタとして一般的だけれども、カンマは文章内の読点や人名の姓名順序の入替を示す場合など他の用例が多すぎる。セミコロンもそれが無いわけではないけれど、ずっとマシ。

デリミタがちゃんと規定されているならば、CSVからRDFに変換する時点で、

  • external-object: 1
  • external-object: 4
  • external-object: 10

のように分割することは可能だし、そのほうがSPARQLの枠内である程度の分析ができるので良い。そもそもリスト構造がある時点で、リストアップされる対象が複数回出現することが多いだろうから、特段理由がない限り、項目付きリテラルではなくちゃんと構造化すると思うので、リスト構造がある場合に項目名付きリテラルを使う機会は少ないかもしれない。

セル内に項目名が現れることがある

話をややこしくしまって悪いけど、表構造データのセルの中に項目名っぽいものがあることがある。備考欄とかに多い。でも、これは仕方なくって、初めから表構造が完璧に決まってることなんてあまりない、データベース作っていって、それで初めて表の構造が定まってきたり、たまに出てくる値を備考欄に押し込めたかったり。

項目名付きリテラルの項目名は表のカラム名相当を対象にしているわけだけど、セル中の項目名についてはどうあつかったらよいのだろうか悩んでいる。

記述法は"関連事件: 尼港事件; OCM: 720; 726;" みたいな記法を思いついているのだけれど、いくつかのプロジェクトで試してからまた報告する。カッコを排し、リストのデリミタを一種類で済ませつつ、複数の項目名を入れ込めるようにするとか、さまざまな要求に従って今はこの形式になっているのだけど、前に作ったJSON Editorを捨ててこの方式でいくのかとか色々ありまして。

  • : と ; は見分けがつきにくい : はかなり良く使われるので固定したい。; の代わりに / を使おうとしたが ファイルのパスを書いたり、日付を書いたりでよく使うのでだめ、, カンマを再検討したけれど、やっぱり | パイプくらいがいいのではないか。
  • Model for Tabular Data and Metadata on the Web non-normative だけれど、こういうセルの parsing の話がある。これはかなり自由度を高く設定しているので、簡単に使い、実装するためのサブセットを見極めたほうがいい気はする。

項目名付きリテラルという選択肢

たとえばここに紹介されているように汎用的な語彙、dct:description の値として "項目名: 値" のようなリテラルを書くというのは図書館のメタデータからきた方法らしい(と神崎さんにオフラインで聞いた)。特にどこかで仕様化やBest practiceとしてまとめられたりはしていないようだ。なので、Linked Data のモデリングというコンテクストでウェブ上で確認できる文書は神崎さんがらみのものしか見つからなかったのだが、そのメリットとして以下のような紹介がある。

平成29年度「ジャパンサーチ(仮称)」利活用フォーマット検討成果物

内容記述及び注記概要・要約、注記、備考など物理特徴以外のその他の情報を、同じく(必要に応じて導入句付きの)「記述」として扱う。 項目(プロパティ)を細分化しないのは、その方が検索利用しやすいこと、識別・選択のためには導入句があれば用が足りること、分野/提供者ごとに異なる多様な項目をアーカイブで反映するのは困難なこと、詳しくはソース情報によって確認できること、による。 なお情報の表示にあたっては、導入句を値から切り離し、項目名に付加して「記述(注記)」のような表示項目として用いることで、より確認しやすくなると考えられる。

"分野/提供者ごとに異なる多様な項目をアーカイブで反映するのは困難"というのは入力された多様な項目をスクリプトで自動でRDF化したりするときに適切な述語を生成することが困難という意味で、述語としては dct:description を使うとその困難を避けられるということだ。"その方が検索利用しやすいこと" というのはリテラル部分を検索エンジンに投げ込んでおいた場合を主に想定しているが、データセットやデータのクラス情報をちゃんとモデリングして区切っておけば、SPARQLでのFilter句でも1000万レコードくらいはサクッといける(そうな)ので、SPARQLでの検索にも条件付きでメリットとなる。

導入句を加えるとプロパティ値が識別子自身と違ってしまう。人間が確認するという意味での利用者タスクにとっては問題ないが、項目名ではなく値については機械利用という観点も考える必要がある。

例えば、時刻やurlに導入句を加えてしまうと、そのままで扱いにくくなってしまうという問題点がある。そういう場合は型付きリテラルにするか、述語を詳細化するかという選択があるが、導入句を加えると機械利用の利便性が損なわれる=うまくモデリングすると機械利用のご利益が見込まれるということなので、私はこの悩みが生じたら「述語の詳細化とentity linkingのご利益がある」シグナルだと考えたらいいと思っている。

このプラクティスを何と呼ぼうか?

まあ、そんなわけで規格化された話でもないのだけれど、もっとこの話を広めたいと思って、ブログ記事にした。「導入句付きのリテラル」は英語に直訳して、"Plain literals with prefixes" とか "prefixed plain literals" とかかな。"Attribute–value pair as plain literals" もよいと思う。日本語の別案だと「項目名付きリテラル」。神崎さんは導入句というのが図書館由来ですでに使われているのを知ってと仰っていたし、たしかには見つかるけれど、まあコンテクストも違うので、「項目名付きリテラル」の方が誤解がなくていいのじゃないかなとは思っている(別に「導入句付きのリテラル」で広まってくれても構わない、ことばの政治がやりたいわけじゃないので、単に誤解がないほうが良いと思うのと、"導入句"をググった結果、図書館的にもそんなに定着した言い方ではないのではと思ったので代案を提示している)。

参考

片付けと執筆が少しできるようになった方法

僕は片付けと執筆が苦手だし、山ほどライフハックとも呼べる方法を試してきたのだけれど、片付けについてはここ6カ月続いている方法、執筆についてはここ数週間ながらなかなか良さそうだと思っている方法があり、ちょっと共通点があるので、ここに書いてみようと思う。

共通するフレームワーク:タイマーと数えるもの、そしてデフォルト値

研究室に着いたら、家に帰ったら、30分以内で10個、物を片付ける。

f:id:cm3ak:20190615184128p:plain
数取器

10個終わったらやめてもいいし、30分経つまで10個以上やってもいいし、そういうところは自由。今日は片付けるぞーって時はそれぞれの数字が上がるし、ミーティングが迫ってるって時には小さくなったりもする。

数は頭で数えてもアプリで数えてもなんでもいいんだけど、僕は数取器が好きだ。頭で数えるのは、なんか無理で、途中で数を忘れたり、認知負荷で楽しさが低減したりするんだけど、頭悪いんかなw

執筆の場合

最近英語ばかり書いているが1時間で6文だ。少ない!!!と思うかもしれないが、書くことがボヤっとしか決まってない内容だと、途中で調べたりも必要なので、無理のない数であることは重要だ。「やりきらない」癖を付けてはいけない。つけるなら「やりきる」癖だ。これも、もっと多くてももっと早くても良いのだから。

そして、数については語数でかかる時間がかわるのだが、語数で数取器にカウントするのは面倒すぎる。だから、iPod touch (もちろんiPhoneでもなんでもいい)のストップウォッチを使って、一文ごとにラップを取っている。僕は一文が長くなる傾向にあるので、そういう意味でも1文に10分かけるとヤバいという感覚がついてきた。

まとめ

タイマーと数えるもの、そしてデフォルト値。

  • 片付け:=タイマーと数取器、10個30分
  • 執筆:=タイマーとストップウォッチのラップ、6文1時間

元ネタ?

タイマーをつけると3つのいいことがある

  • 時間がおわるまで他のことをしにくい
  • 無駄に時間をかけないし、時間の見積もりが上手くなる
  • 元気が出る

最後のはなんだと思うかもしれないが、「インスタント沼」という作品に、「水道の蛇口をひねれ!」という印象的なセリフがある。

ハナメがつまらなそうにしていると、電球おじさんが水道の蛇口をひねって水を出しっぱなしにし、洗面台があふれるまでに自販機で飲み物を買って帰るというゲームを始める。その次は、風呂の蛇口捻って、御飯やにいって戻ってくる。そしてハナメは元気になるんだ。

amzn.to

sqlite で ダブルクオートの含まれた tsv をインポートする

sqlite で tsv 読み込むには .separator "\t" してから .import allCountries.txt geonames みたいにインポートするけれど、これだと各項目にダブルクオートが含まれてると項目数を誤認識してエラーになる。csvのセパレータ変えただけの仕様なので項目全体をダブルクオートで囲んで元のダブルクオートを二重にしておけばいいのだけれど、例(Shui-k"ou Kuan"Shui-k""ou Kuan" ダブルクオートをこのように使う言語もあるのだ Shui-k”ou Kuan) そのワンライナーは、

cat allCountries.txt | perl -pe 's/"/""/g;s/([^\t]*)/"$1"/g' > allCountries_escaped.txt

たまたまとあるツイートのリプで見かけたので記録しておく。

1つめの検索結果に出てくる Happy Elements北京市に本社を置く中国のモバイルゲーム開発会社だ。検索結果には他のゲームの名もあるし、大正ロマンというのは江戸に並んで日本的なもののイメージを描くのに便利であるため、ゲームで多用されるのかもしれない。ゲーム以外だと、茎(STEM)のショートムービーに代表されるように椎名林檎大正ロマン的な雰囲気を歌詞に多用する。頽廃的で個人主義的な恋愛など、描きたいことに共通点があるのかもしれない。

大正ロマンが描かれること自体に問題性は無いのだけれど、軍のイメージが流入することも多いっぽいのが問題をややこしくしている。どうやら憲兵を描いて大正ロマンの看板を掲げたのかな、検索結果にも「憲兵」というのがあってそれが批判対象にもなっている。僕からすると、椎名林檎の次にイメージがあるのは「花子とアン」で、柳原白蓮大正ロマンWikipediaの項目に加筆したりしたくらいなので、大正ロマン憲兵のようなものに抗する側のものという印象をもっていて、大正ロマンの一環として理解するのには違和感を抱く。しかし、日本語を読めない人が勝手に付けたイメージではなくて大正ロマン風と評されることの多い「千本桜」についてもたびたび指摘されるように、イメージとしてコンタミが生じているのもなんとなくは知っているから、全くの勘違いとも言い切れないのがややこしいところだ。

それにしても、おそらく韓国の方々が問題視している三一運動との同時代性についても、大正ロマンとかかわりの深い大正デモクラシーの代表的思想家吉野作造"『中央公論』などに朝鮮総督府の失政を糾弾し、朝鮮の人々に政治的自由を与え、同化政策を放棄せよとの主張を発表した"くらいなので、さすがに批判した側とされた側をいっしょくたにするのはどうなんよと思う。

ここまで知識を共有してもPC的判断は割れるだろうけど、そこに答えを出すことには興味ないので、ここまで。概念が作られたり再構築される過程やその検出に興味があるので、記録しておく。

翻訳本をMendeleyで入力してBibTeXで使いたいから、Notesに原著情報書くことにした

翻訳のある本を原著で読んで、引用したい場合、社会学のレポートでBibTeXを使う手順 - 503 Service Unavailable にある

@BOOK{Esping-Andersen1990,
  title = {The Three Worlds of Welfare Capitalism},
  author = {Esping-Andersen, Gosta},
  year = {1990},
  publisher = {Princeton University Press},
  jtitle = {福祉資本主義の三つの世界},
  jauthor = {岡沢 憲芙 and 宮本 太郎},
  jyear = {2001},
  jpublisher = {ミネルヴァ書房},
  isbn = {9784623033232},
  url = {http://amazon.co.jp/o/ASIN/4623033236/}
}

みたいに入れてもよいと思うけど、この書き方は「翻訳のある外国語文献の場合は、原書の情報に加え、以下のフィールドを追加。」と紹介されている通り*1、厳密にいうと、英語で原著を読んで邦訳があることを読者に教えてあげるねって書き方なので、原著がメインに押し出されてるんだよね。翻訳書を読んで原著読んでないのにこの書き方するの、僕は結構気が引ける。

あと、jってなんやねんというのがありまして。LaTeX tiny Tips で配布されてる bst ファイルで定義されているだけで、もちろんBibTeXの一般語彙ではないです(ジャワ語(Javanese)に翻訳された本とか、ロジバン語(Lojban, ISO639がjboなんだよねw)に翻訳された本(!?)とか考えると、jtitleのjがJapanのJなら汎用性を持たない構造だなと分かるわけです)。

使えるんだからいいじゃないか!というのも一理あるんだけど、中途半端に流通したりすると、QA: 文献リストの邦訳論文について ←こういう混乱が生じるわけです。BibTeXにはちゃんと情報入れたのに、なんで邦訳の情報が表示されないのと。外部環境とセットにならないと明白にならないセマンティックスをデータに入れてしまうとこうなる。

根本的な問題を言うと、BibTeXが悪い。ありがちな、翻訳書をどう書くかという問題について、スマートな解決策を持っていないフォーマットなのだから、BibTeXが悪い。というかそもそも語彙についてW3CIETFみたいな標準化団体を持たない世界なのでやんぬるかな。

しかし、その悪いBibTeXを使うときに、(1)無理くり構造化する (2)構造化をあきらめて備考的に原著情報を書く という2つの選択肢があるので、(2)でええやんと思います。

@book{Nancy1999jp,
author = {ナンシー, ジャン=リュック and バイイ, ジャン=クリストフ},
isbn = {9784787210401},
pages = {121},
publisher = {青弓社},
title = {遠くの都市},
translator = {小倉, 正史},
year = {2007},
annote = {原タイトル: Los Angeles ou la ville au loin
原著者名: Jean Luc Nancy
原出版社: Fayard
原著出版年: 1999}
}

Mendeley で入力しているときには Tools>Options から Translators という項目が追加できるので、翻訳者は追加できます。他の情報はNotesに入れるとannoteとして出力されます。こういう微妙な対応関係は Mendeleydesktopの属性とBibTeX属性の対応 - 発声練習 に書かれている。

碌な代替がないから僕はBibTeXの方がplain textよりは好きなんだけど、ちなみにRISは

  • TA Translated Author
  • TT Translated Title

の2つの項目を持ってはいる。EndNote XML は知らない。ORCIDとか出てきたらAuthorにもID与えたいよねとか考えると BibTeX後方互換性のあるまともな標準化が必要なのかも? jtitle の代わりに original-title 、あとoriginal-isbn みたいなID参照系の語彙が広まってくれればいい、というだけの話なのかもしれない。

その他参考:

*1:だから、このブログには何も問題がない