Drafts

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

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

たとえばここに紹介されているように汎用的な語彙、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:だから、このブログには何も問題がない

Spatial Data の LOD を書く

地理情報に関わるLODを書こうとしたときに、語彙がいくつかあって、どれをどのように使うかという選択に迫られる。Spatial Data on the Web Best Practices にそのベストプラクティスが書いてあるのだけれど、いくつか補足をしようと思う。

Feature と Geometry を区別する

f:id:cm3ak:20190102040236p:plain

この区別は上の箇所に書かれている。緯度経度を直接持つような情報は Geometry クラスが期待され、人のような空間位置が一定でないものは Feature クラスが期待される。w3cgeo:SpatialThing はそのどちらもになりうるためセマンティクスに混乱があること、それゆえ、この文書では "SpatialThings" として geosparql:Feature のセマンティクスを想定しているということが書かれている。

例として、都道府県の例を考えてみる。都道府県は空間位置が一定だからGeometryだろうか?そうではない。Polygonで領域を描いたもの、都道府県庁の位置を代表点としてPointで表現したものなど、複数のGeometryを持つ Feature として定義でき、rdfs:subPropertyOf geosparql:hasGeometry となる defaultGeometry という述語で、領域表現を特別扱いすることができる( schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf では "It is Usually the most detailed geometry." と書かれている、この例は私が仕事で使う際に考えたもの)。

文書内には、他に灯台の例が "6. Spatial Things, Features and Geometry" に書かれている。灯台は、ヘリの操縦者からは「高い障害物」として高さと正確な位置が重要になり、水兵からすれば「航路標識」として光の種類とだいたいの位置が重要になる。そういう個々の観点での特徴のまとまりが Feature なのである。

f:id:cm3ak:20190102045600p:plain

A. Applicability of common formats to implementation of best practicesの2つめの表。dcterms は緯度経度を書くような Geometry を扱えず、他は Feature と Geometry それを結ぶ述語は上図のようになっている。但し、すでにみたように、w3cgeo にはセマンティクスの混乱が見られるので、ちゃんと書きたい場合には vcard 以下の語彙を使うことになる。

それにも関わらず、w3cgeo を最もよく見かけるのは、Feature に対して、単一の緯度経度標高のみの属性を書きたいことが圧倒的に多く、その目的で使う分には便利だからだ。文書内ではセマンティクスの混乱についての指摘以外でw3cgeo は2つの例で使われている。

<http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587> 
  a geosparql:Feature, bag:Pand ;
  rdfs:label "Pand 0363100012169587"@nl;
  
# Detailed geometry  
  
  geosparql:hasGeometry <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ;
  bag:geometriePand     <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ;
  
# Centroid

  w3cgeo:lat  "52.37509"^^xsd:float ;
  w3cgeo:long "4.88412"^^xsd:float ;
  
# Bounding box

  georss:box "52.3749,4.8838 52.3753,4.8845"^^xsd:string .

詳細な Geometry を書く geosparql:hasGeometry と並置して、w3cgeo:lat と w3cgeo:long を代表点として書いている。

:myPointOfInterest a w3cgeo:SpatialThing ;
    dcterms:description "Anne Frank's House, Amsterdam."
    w3cgeo:lat "52.37514"^^xsd:float ;
    w3cgeo:long "4.88412"^^xsd:float ;
    .

これは w3cgeo を使えば測地系がWGS 84であることが前提できるという話で書かれているだけだが、上と同様に代表点を記述している。

w3cgeo を使うもう一つの理由は、vcard、georss、geosparql、locn は主に次に説明するgeo URI と呼ばれるものや、Well-known text Literal を使うことが多く、LODとして構造化できないという問題があるため、構造化して書きたければ w3cgeo か schema.org の2つになるということである。これは、

As part of the vocabulary, an RDFS datatype is defined for encoding detailed geometry information as a literal value. A literal representation of a geometry is needed so that geometric values may be treated as a single unit. Such a representation allows geometries to be passed to external functions for computations and to be returned from a query.

という事情でそうなっている(GeoSPARQL - A Geographic Query Language for RDF Data | OGC

緯度経度情報をつかって何をしたいかというと、計算して絞り込んで可視化するといったことになるのだが、計算の部分では領域の被覆をチェックするなどgeosparqlなどの発展的なSPARQLを使いたくなる(=WKT Literal とかで表現しておきたい)一方、可視化の部分では緯度と経度に切り分けて取り出したかったりするのだが、GitHub - mapbox/wellknown: GeoJSON-emitting WKT parser for browsers and node とかでパースすることと組み合わせれば、それで問題は無いはず。

geo URI と geohash

vcard では geo URI をつかうと書かれているが、それでは1D~3Dは使えない。

f:id:cm3ak:20190102093445p:plain

RFC 5870 - A Uniform Resource Identifier for Geographic Locations ('geo' URI)

7.3. GML 'Circle' とか 7.4. GML 'Sphere' って項目があるからてっきりそのくらいの形は扱えるのかと思いきや、geo:%lat%,%lon%;u=%unc% という表現形式で、緯度経度とメートルで範囲を表したuncertaintyが指定できるだけなので、基本点しか表現できないと思ったほうが良い。

vcard が元々名刺のような情報を書くことを考えれば当然かもしれない。自宅や会社の位置を書くのに Polygon で書ける必要があるだろうか?

似たように点でしか表現できないが緯度経度をidentifier化できるものに

geohash.org

がある。あまり使いどころが多いように思えないが、リンクになっていることで、それぞれのフォーマットに dereferenceable になるのは良いかもね。

f:id:cm3ak:20190103030229p:plain

  • osm: open the location in OpenStreetMaps
  • gmaps: open the location in Google Maps
  • gc: go to the nearest geocaches in Geocaching.com
  • gpx: go directly to GPX download page
  • garmin: go directly to Garmin download page
  • text: show coordinates as plain text
  • url: show Geohash URL as plain text
  • maxlen: maximum length of the Geohash

次に述べるような「フォーマット」じゃないけれど、よくあるサービス用のURLを生成してくれるのは嬉しい。

データフォーマット

f:id:cm3ak:20190103023334p:plain

A. Applicability of common formats to implementation of best practices の1つめの表から抜粋)

Well-known text フォーマットは既に述べたとおりで、Supported by most triple storesそしてGeoJSONに変換できる強みがあるので、今の文脈だと最も利便性が高いだろう。3Dサポートが必要になった時には、GMLを使う。この2つで十分じゃないかな。他にHTMLはウェブでの発見性という利便性が強調されていたけど、LODの Content negotiation 使えばそれで問題ないわけだし。

結局語彙はどれを使うべきか

  • データフォーマットでWKTGML使うなら、語彙はgeosparqlを中心につかえばよい。
    • ウェブでの表示は GeoJSON に変換して表示する
    • WKT は多くのtriple storeで演算がサポートされているようだ。
  • 構造化で簡単に緯度経度だけ付記したければw3cgeoでの記載を伴わせる。
  • ISA Programme Location Core Vocabulary locn は何でも使えるようにしてあるが、逆にわざわざ使う場面は少ないかも。多様な形式で書かれたデータを変換など事前にせず雑多なままデータ化したいときに便利かもしれない。
  • vcard と georss は名刺情報や更新される地理情報を書くときなど、用途次第では周辺ツールの対応があって有効かも。

ResourceSync について最近あったQA

口頭でどこかで答えたりしたことをメモっておいてツッコミ可能にしておく。

ResourceSyncって何?(ツイッター的140字)

ResourceSyncとは:OAI-PMHの後継と目されている静的連携のためのプロトコルで、sitemapsを拡張したもの。メタデータだけじゃなくてコンテンツも同期の対象にしうるとこと、情報発信側からのプッシュが可能なことが特徴。まだ普及していないが幾つか実装はある。詳しくは http://current.ndl.go.jp/ca1845 参照

ライブラリとかソフトウェアの実装状況は?

は上の記事にも載ってるけど、一番使いやすそう。他、時期的に上に漏れてる話として僕が把握しているのは

(こういうのは Scrapbox とかで Wiki 的にupdateすべきだ…)

resumptionToken の代替は?

OAI-PMHでは、3.5の Flow Control に resumptionTokenを使ってちょっとずつリソースを取ってくる実装がmust指定されている 。今こういうのは必要なくなっているのかというと、確かに回線は安定したし、太くなったし、必要は薄れているんだけれど、ResourceSync は zip で固めたコンテンツも流すんだから、その分ダウンロードが途中で切れるとかいう問題も発生しうると思う。最も大事なのは、ResourceList も複数に分けることができるのだから、ある程度は適切なサイズになるように設計すること。そして、適切なサイズのダウンロードに失敗するようなら、もう一度取りに行けばいい話。

一応、巨大ファイルの断続的ダウンロードについての解決策も、もう一つ低レイヤーの解決策が普及してきていて、HTTP range requests を使えばよいと思う。

増分同期で from で指定したいのはこっちが前回いつとりに行ったかじゃない?

ResourceSync にも Resource List の at や Change List の from といった情報があるがこれは情報を出す側の視点であって、取りに行く側からはどれを取りに行ったらいいかが OAI-PMH より複雑、というのはそれはそう。差分を処理したいときには、Change List Index から順に辿っていって、ダウンロードが必要か必要じゃないかを1つ1つ判別しつつクロールしていくことになる。resync/resync at master · resync/resync にも from オプションがあったりして、そういう利便性はライブラリレベルで解決されるべきだし、そういう方向性になっている。基本的にコストをハーベストする側に載せているので、ハーベストする側が実装を工夫する必要があるケースは他にもあると思う。

PubSubHubbub の実装は必須なの?

まず、PubSubHubbub (PuSH)じゃなくて、今は WebSub に名前変わってる。それを使う Change Notification と Framework Notification が "Additional" Specifications になっているので、必須じゃないです。Hub になるとこをどこが担うの?とか組織連携的な課題があるので、研究実験や必要性を検討した上で必須だという結論に至った実装でない限り、実装は後回しで良いんじゃないかな。

だったら OAI-PMH から移行する動機は?

  • 十分な大きさの画像サムネイルを同期したいでしょ?
  • アーカイブ」ならEADが大事だったりするし、メタデータの構造やファイルフォーマットはもっと自由に書きたいでしょ?
  • もう、グーグルに拾われないとそもそも流入が望まれないのでSEOも運営上大事で、sitemaps 互換なのでSEOにもなる。

(僕はデジタルアーカイブや研究資源データベースに関する相談で聞かれるので、そういう偏りのある回答ではある)

sitemaps から、連携の必要性に応じて増築していって、ある時点で整理するという形でもよいかも。

ジャパンサーチがOAI-PMHでデータ取るって聞いてるんだけど

tl;dr OAI-PMHは必須じゃないし、ResourceSync ベースでもなんとかなりそうだよ。

僕も、OAI-PMHとウェブサイトから手動でアップロードの2つだって聞いてる。でも、ジャパンサーチ(仮称)の連携フォーマット(案) の冒頭の方に、「連携を容易にするため、原則、ファイルベースでの連携を行う(OAI-PMH は必須としない)」と強調されているように、ファイルベースになるなら ResourceSync も親和性が高いのではと期待はできる。「複数のファイルをzip形式で圧縮したファイルにも対応する。」となっているが、余計なファイルが含まれているとエラーになるようなので、ジャパンサーチ専用にファイルを生成する必要はでてきそう。それが特定の Resource List Index から自動生成できるだろうから、Resource List Index の URL を入れると、必要なファイルが返ってくるというものを誰かが作れば済む話ではある。「連携機関のメタデータモデルをそのままの形で受け入れる。メタデータモデルは原則として自由であるが、最低限の必須項目(①オリジナル(ソース)データの一意の ID、②名称/タイトルの 2 項目)がある等の制約を設ける。」というのも先ほどの自由なメタデータ記述を阻害しないように設計されている。