Drafts

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

■

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

デリミタがちゃんと規定されているならば、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 の話がある。これはかなり自由度を高く設定しているので、簡単に使い、実装するためのサブセットを見極めたほうがいい気はする。