見られるようなものだ。これによって数字や日付の一致や比較ができるようになっている。しての同値と一緒だし、このセットを見るかぎりご利益はない。ドキュメントみたいに、リテラルから構造化データにエンコードして処理をするということが考えられるけれど、それはデータ構造ごとにできるand/orやりたい処理が異なってしまうので、定式化できないという結論です。casesと書かれている。項目付きリテラルは幅広いプロパティの値として使えるので、規定しても良いけれども、結局ご利益が「項目の一覧を出したり」云々ならば、分析対象の項目名付きリテラルをSPARQLで一覧出力して、それに対してテキスト処理するのが正当であり、それが簡単にできるようにしておけば良い。するというのは以上より論外の選択肢。いえば、RDF化するまえの元データをデータリポジトリで共有しておいた方がこういう分析には向く。みたいにリスト構造が1個のセルの中に入ってくることってそれなりにある。関わってるプロジェクトのうち2つでエクセルのセル内でリスト構造を扱うことになり、どちらも検討の結果セミコロンがデリミタに選定されている。カンマの方がプログラミング言語的にはリスト構造のデリミタとして一般的だけれども、カンマは文章内の読点や人名の姓名順序の入替を示す場合など他の用例が多すぎる。セミコロンもそれが無いわけではないけれど、ずっとマシ。10のように分割することは可能だし、そのほうがSPARQLの枠内である程度の分析ができるので良い。そもそもリスト構造がある時点で、リストアップされる対象が複数回出現することが多いだろうから、特段理由がない限り、項目付きリテラルではなくちゃんと構造化すると思うので、リスト構造がある場合に項目名付きリテラルを使う機会は少ないかもしれない。セル内に項目名が現れることがある話をややこしくしまって悪いけど、表構造データのセルの中に項目名っぽいものがあることがある。これは仕方なくって、初めから表構造が完璧に決まってることなんてあまりない、データベース作っていって、それで初めて表の構造が定まってきたり、たまに出てくる値を備考欄に押し込めたかったり。項目名付きリテラルの項目名は表のカラム名相当を対象にしているわけだけど、セル中の項目名についてはどうあつかったらよいのだろうか悩んでいる。みたいな記法を思いついているのだけれど、いくつかのプロジェクトで試してからまた報告する。Editorを捨ててこの方式でいくのかとか色々ありまして。良く使われるので固定したい。パイプくらいがいいのではないか。これはかなり自由度を高く設定しているので、簡単に使い、実装するためのサブセットを見極めたほうがいい気はする。アーカイブズポータルの各アイテム詳細表示でJSONを選択すると、JSON-LDによるRDFメタデータが。ようなリテラルを書くというのは図書館のメタデータからきた方法らしい(と神崎さんにオフラインで聞いた)。practiceとしてまとめられたりはしていないようだ。モデリングというコンテクストでウェブ上で確認できる文書は神崎さんがらみのものしか見つからなかったのだが、そのメリットとして以下のような紹介がある。物理特徴以外のその他の情報を、同じく(必要に応じて導入句付きの)「記述」として扱う。項目(プロパティ)を細分化しないのは、その方が検索利用しやすいこと、識別・選択のためには導入句があれば用が足りること、分野/提供者ごとに異なる多様な項目をアーカイブで反映するのは困難なこと、詳しくはソース情報によって確認できること、による。情報の表示にあたっては、導入句を値から切り離し、項目名に付加して「記述(注記)」のような表示項目として用いることで、より確認しやすくなると考えられる。使うとその困難を避けられるということだ。いうのはリテラル部分を検索エンジンに投げ込んでおいた場合を主に想定しているが、データセットやデータのクラス情報をちゃんとモデリングして区切っておけば、SPARQLでのFilter句でも1000万レコードくらいはサクッといける(そうな)ので、SPARQLでの検索にも条件付きでメリットとなる。導入句を加えるとプロパティ値が識別子自身と違ってしまう。人間が確認するという意味での利用者タスクにとっては問題ないが、項目名ではなく値については機械利用という観点も考える必要がある。時刻やurlに導入句を加えてしまうと、そのままで扱いにくくなってしまうという問題点がある。linkingのご利益がある」シグナルだと考えたらいいと思っている。このプラクティスを何と呼ぼうか?まあ、そんなわけで規格化された話でもないのだけれど、もっとこの話を広めたいと思って、ブログ記事にした。