ちょっとしたメモ

昨年の6月頃から動きがあったDublin Coreのモデルを再定義するという話の結果、新DCMI抽象モデル案、DCMI名前空間ポリシー改訂案、そしてDCプロパティの定義域、値域案が公開され、3月5日までが公開コメント期間となっている。注目の定義域、値域は、基本15要素には採用せず、その代わりこれらと同じプロパティをdcterms:空間にも定義して、こちらに定義域、値域を持たせるという案だ。

プロパティに定義域、値域を持たせれば、主語、述語のクラスを推論できることに加え、プロパティの使い方に関する約束を示すことにもなる。アプリケーションは、dc:creatorの目的語がリテラルなのかリソースノードなのかについて余計な検証をすることなく、安心して処理できるようになるわけだ。仕様案の言葉でいえば次のようになる。

In practice, this means that the domain indicates the class of resources that the property should be used to describe, while the range indicates the class of resources that should be used as values for that property.

一方で、これまでこうした定義はなかったから、既存のデータはdc:creatorの目的語に名前を文字列で書き込んでいるものもあれば、foaf:Personなどのインスタンスとしてグラフを伸ばして名前、メールアドレスなどを加えているものもある。値域が後付で決められると、どっちにころんでも既存データに矛盾が生じてしまう。

そこで、従来の「dc:」プロパティには手を付けず、dcterms:createdなどと同じ名前空間に、基本15要素に対応するプロパティを追加して、dcterms:プロパティは全て定義域、値域を定義するという方法が提案された。つまり、作者を表すプロパティは

• http://purl.org/dc/elements/1.1/creator
• http://purl.org/dc/terms/creator

の2つが用意されるということだ（後者は前者のサブプロパティとして関連づけられる）。dcterms:creatorの値域は、新たに提案されているクラスAgentとなる。

概ね妥当なところだと思われるが、少々厄介なのはdcterms:created、dcterms:modifiedなどの日時に関連するプロパティの値域がPeriodクラスとされているところ。日付は2007-02-07のようにISO-8861形式などの文字列記述が普通だから、ここは型付きリテラルのほうが使いやすいのではなかろうか。

なお、dcterms:titleやdcterms:descriptionの値域はrdfs:Resourceとされているが、これは「URIもしくは空白ノード」ではなく、リテラルも含むことになる（リテラルもrdfs:Resourceの一種）。この点は、仕様案にも次のように記述されている。

Note: for completeness, the tables below include has domain and/or has range relationships with the class rdfs:Resource (italicised in the tables). Such a relationship is implicit even in the absence of an explicit has domain or has range assertion, so those assertions will not be present in the term declarations.

DCの定義域、値域は影響の大きい話なので、注目しておきたい。コメントは件名に[Domains and Ranges Public Comment]を加えてDC-ARCHITECTUREメーリングリストへ。