神崎さんの https://kanzaki.com/docs/sw/rdf-model.html を読みながら：
- RDFによって「関係の連鎖を辿ることができる」とあるが、これはリソース間の関係であって、リソースと値の関係（＝属性）ではない、と解釈したほうがよさそう。
- 混乱してしまうのは、値にロケーターが入っていること。ロケーターはデータとしては文字列だが、データとしての値とは別扱いしたほうがいいと思う。
- 「辿る」という操作が何であるか、定式化しないといけない。関係から定義される非決定性関数に特定要素を代入することだが、それだと非決定性。任意選択によりパスの集合ができる。
- ある条件のもとで「すべての可能なパスの集合」はプログラムセマンティクスでも使う概念。実行パスと履歴パスとナビゲーション。
- machine-readable, machine-understandable
- [+文]は[+叙述]の手段。
- リソースを記述する語彙の定義する方法・手段が[+スキーマ]
- 「そのクラスの系譜をさかのぼっていくことで、どのような定義が行われているかを理解可能にしようという構想」 -- これは難しい。まさにドクトリン問題（「ドクトリンとは何か？」「ドクトリンの遡り〈さかのぼり〉はいつ止められるか？」）。
- トリプルの集合がRDFグラフ、これは宣言〈トリプル | 文〉と指標〈グラフ〉と同じ。指標は確かにグラフになる。つまり、RDFグラフとは指標（または指標の一部）のこと。
- 主語＝域、述語＝射、目的語＝余域、文＝トリプル＝プロファイル宣言
- 「Dublin Coreの要素タイプを示す名前空間」 -- これはXMLのマズイ所だった。要素は型としての意味を持てても、属性や、要素＋属性を、一級市民的な型として扱えなかった。
- リテラル＝値のレキシカル空間の要素を四角で表す（という習慣あり）。
- 「RDFは主語、述語、目的語の全てをURI参照によって名前付けして表現できるように設計されている」 設計判断がどうも間違っているような。
- トリプルが、プロファイル宣言なのか、モデルの一部（関係の対応ペア）を表しているのか曖昧。
- 文＝トリプルは、どうも、プロファイル宣言ではなくて、モデルの割り当て文のさらに一部のようだ。割り当てる関係の“一個の対応ペア”が文かな。
- 指標、指標内のプロファイル宣言文、モデル、モデル記述内の割り当て文、割り当て文のなかの個別対応ペア、これらを区別しないといけないな。
- 「vCardの語彙を用いて名前とメールアドレスというプロパティを表現しています」-- RDFグラフとデータ型定義の境界線が曖昧。データ型定義との棲み分けをちゃんとすべきでは。
- マルチスパンと（幾つかの）直積への単一の射の関係を使うべき。
- グラフのブランクノードって、なんか嫌な感じだわ。これって、データ型のコンストラクタのことでは。
- 構文領域、意味領域、意味論の枠組みを適用してないような。絡み合うから不適切と判断したのか？ レイフィケーションを明示すべき。
- コンテナモデル、これはデータ型の話だろ！ 複合データ型のコンストラクタ（作り方）の話。
- 「文についての文」、メタな記述、レイフィケーション、ここれはちゃんとやらないとダメなところ。レイフィケーションは文をリソース化することらしい。むしろ、カリー化だが。
- 「プロパティがどんなものであるかはスキーマによって定義され」 -- ウーム。
- データはスキーマへの参照を持つ。ウーム。
- 人やコンピュータが、記述で使われているボキャブラリーのスキーマについて知っている、とはどういうことか？
- 「知っているとは？問題」と言える。「ドクトリンとは？問題」と共に難しい。逆帰納的構成になると思う。impredcative〈非{可述 | 叙述}〉に繋がるか？
次に、https://service.infocom.co.jp/das/loddiary/2015/01/20150127001259.html
- URIの短縮記法は便利ではある。
- @base（相対URIのベース）、@prefix は分かる、便利だ。
- セミコロンでつなげて書くのは、スパン〈カローラ〉を表現する構文。
- 辺の集合の代わりに、スパン〈カローラ〉の集合として書くのも、納得。
- 「@idキーワードをプロパティとすると、値はURIとして解釈されます。」 JSONハイパースキーマとはずれてしまっている。
- トップレベルの@idプロパティは自分のID、プロパティ値に入った@idは参照のURI。出現文脈で解釈が変わるのはいかがなものか？
- トップレベルの「@contex : "URI"」プロパティは、スキーマ参照に近い。
- トップレベルに
"@context" : "http://schema.org/" , "@id" : "http://example.org/photo/2008/0208.jpg" , "@type" : "Photograph"のようなメタデータが含まれるオブジェクトが実用的だし、それ以上は無理な気がする。 - 「@contextの値を配列として複数のコンテクストを列挙します。」、なるほど。
<script type="application/ld+json">は実用的。- JSON-LD-Tiny のようなものが必要そうだ。@id, @context, @type の3つだけだろう。
一般論、疑問、課題など。
- 事物を(1)表現し、(2)保存し、(3)問い合わせる〈検索する〉ことができることが要件。表現の構造、保存のデータ構造、問い合わせ言語〈検索言語〉とそれぞれの意味論〈モデル論〉が必要。
- データを解釈するためにメタデータが必要、メタデータを解釈するためにメタメタデータが必要 ‥‥ 。これは、指標を解釈するためにドクトリン指標が必要、ドクトリン指標を解釈するためにドクトリン・ドクトリン指標が必要 ‥‥ と同じ構造。
- バズワードっぽい言葉が多い： オントロジー、スキーマ、ターム、ボキャブラリー、セマンティクス。形式的定義なしに使うのは辛すぎるし、バカっぽい。特にオントロジーは嫌だ。スキーマで代替する（曖昧語が増えるが）。
- スキーマの恩恵は、論理的推論ができることや、妥当性〈整合性〉検証ができることだろうが、論理系〈演繹系〉なしには出来ない。
- x is connected to Y via the R relationshp と X has attribute A that value is V は違う。
- 検索と{妥当性}?検証はたぶん“関係の2-圏”で定式化できる。
- 制約の推論は論理になる。述語論理との関係が気になる。
- consistency, validity, integrity とかが曖昧に使われている。形式化してくれ。
