Baldanders.info

RDFa 入門

ここでは Web ページにメタデータを記述する RDFa について簡単に説明します。

「メタデータ(metadeta)」というのは「情報に関する情報」といった程度の意味で,特に RDF/RDFa の場合は,検索エンジンなどの機械が理解可能な(machine-understandable)情報を記述することを目標にしています。

  1. まずは RDF から
  2. RDF から RDFa へ
  3. RDFa の基本的なルールと語彙
  4. Dublin Core Terms
  5. Friend of a Friend
  6. Creative Commons Rights Expression Language
  7. 付録: Open Graph

まずは RDF から

RDF(Resource Description Framework)は情報を「主語( subject)」,「述語(predicate)」,「目的語(object)」の3つに分類し,この3つ組(triple)の関係を使って情報を記述します。 例えば「私は猫が好きです」という文章は主語を「私」,述語を「好き」,目的語を「」と分類し,以下の関係で表すことができます。

RDF の Triple (1)
RDF の Triple (1)

更にもうひとつ「猫の名前はべるのです」という情報を加えてみましょう。

RDF の Triple (2)
RDF の Triple (2)

ここで「私は猫が好きです」の目的語である「猫」と「猫の名前はべるのです」の主語である「猫」が同一であるなら上の図のような関係になります。 人間であれば前後の文脈から2つの「猫」が同じものであると推測できますが,機械にはそれができません。 2つの「猫」が同じであるとするためには両者に同じ識別情報(identifier)を与える必要があります。 RDF ではこの識別情報に URI(Uniform Resource Identifier)を用います(URI は URL(Uniform Resource Locator)の拡張と考えていただければ概ね間違いないです)。 また URI によって一意に決まる情報を「リソース(resource)」と呼びます。

一方で,「べるの」という目的語はただの文字列で一意である必要がありません。 このようなデータを「リテラル・データ(literal data)」と呼びます。 リテラル・データは目的語には使えますが主語には使えません。 主語は必ずリソースである必要があります。

主語や目的語と同じく述語もまた URI で表現します。 従って「私は犬も好きです」と言うとき

RDF の Triple (3)
RDF の Triple (3)

「猫」に対する「好き」と「犬」に対する「好き」が同一であるとするなら,「私」と「猫」,「私」と「犬」との関係は「好き」という点において同じであると「理解」することができます。 これが machine-understandable であるということの意味です。

(RDF で使われる述語等のセットを語彙(vocabulary)といいます。 語彙は RDF Schema のルールに従えばだれでも定義することができます(語彙の定義に興味のある方はこちらのページをどうぞ)。 しかし通常は Dublin Core Terms などの汎用の語彙を使うべきです)

このように RDF では, Triple を用いてリソースをノードとした意味(semantic)の網(web)を構成していくのです。

RDF から RDFa へ

RDF は仕様としては良く出来ていましたが,主な形式である RDF/XML の記述が複雑なため使い勝手がイマイチなのと HTML に情報を埋め込む方法がなかったため(RSS(RDF Site Summary)など一部での利用を除いて)普及しているとは言えない状況です。 この状況を改善するために RDFa(Resource Description Framework in Attributes)が提案されました。 RDFa は Microformats からの fork と言えるもので, relproperty といった HTML 要素の属性を使い, RDF の語彙によって HTML 上の情報同士を関連付けていきます。

RDFa は2013年に W3C によってバージョン 1.1 が勧告(Recommendation)となりました。

RDFa の基本的なルールと語彙

RDFa で利用することのできる属性は以下のとおりです。

RDF 要素属性名内容
主語 about, src主語となるリソースを指示します
述語 rel, rev目的語がリソースである述語を指示します(rev は主語と目的語が反転します)
property目的語がリテラル・データである述語を指示します
inlist 目的語がコレクションになります(他の述語と組み合わせて使います)
目的語resource, href目的語となるリソースを指示します
content目的語となるリテラル・データを記述します
クラス typeof主語または述語となるリソースのタイプを指示します
データタイプ datatypeリテラル・データのデータタイプを指示します
語彙 prefix, vocab語彙を指示します
RDFa で利用できる属性

語彙を追加するには主に prefix を用います。 prefix は接頭辞(prefix)を指定することで複数の語彙を指示できます。 たとえば Dublin Core Terms および ccREL の語彙を追加する場合は以下のように記述します。

<html prefix='dc: http://purl.org/dc/terms/ cc: http://creativecommons.org/ns#'>

ただし, HTML5 では以下の語彙が組込み済みとなっているため,これらについて改めて指示する必要はありません。

主語・述語・目的語の Triple の指定は,以下のように行います。 たとえば,以下のテキストがあるとします。

アルベルト・アインシュタインについて

アルベルト・アインシュタインは1879年3月14日,ドイツ生まれの理論物理学者です。 彼による革命的な3つの論文光電効果の理論ブラウン運動の理論特殊相対性理論が発表された1905年は奇跡の年と呼ばれています。

アインシュタインに関する記述ですね。 このテキストのマークアップは以下のとおりです。

<section id='AlbertEinstein'>
<h4>アルベルト・アインシュタインについて</h4>
<p>
アルベルト・アインシュタインは1879年3月14日,ドイツ生まれの理論物理学者です。
彼による革命的な3つの論文<q>光電効果の理論</q><q>ブラウン運動の理論</q><q>特殊相対性理論</q>が発表された1905年は<q><a href='http://www.einstein1905.info/einstein/1905.html'>奇跡の年</a></q>と呼ばれています。
</p>
</section>

これに名前・生年月日等のメタデータを加えます。 人物についての記述ですので FoaF および BIO 語彙が中心になります。

<section id='AlbertEinstein' about='#AlbertEinstein' prefix='bio: http://purl.org/vocab/bio/0.1/' typeof='foaf:Person'>
<h4>アルベルト・アインシュタインについて</h4>
<p property='bio:biography'>
<span property='foaf:name'>アルベルト・アインシュタイン</span>は<span id='birth' resource='#birth' rel='bio:birth' typeof='bio:Birth'><span property='dc:date' content='1879-03-14' datatype='xsd:date'>1879年3月14日</span></span>,<span property='bio:olb'>ドイツ生まれの理論物理学者</span>です。
彼による革命的な3つの論文<span id='docs' resource='#docs' rel='foaf:made' rev='foaf:maker' typeof='foaf:Document'><q property='dc:title'>光電効果の理論</q><q property='dc:title'>ブラウン運動の理論</q><q property='dc:title'>特殊相対性理論</q>が発表された<span property='dc:created' content='1905' datatype='xsd:date'>1905年</span>は<q><a href='http://www.einstein1905.info/einstein/1905.html' rel='dc:references'>奇跡の年</a></q></span>と呼ばれています。
</p>
</section>

ちょっとゴチャゴチャし過ぎちゃいましたかね。 関係を分かりやすくするために Distiller を使って RDF/XML に変換してみます。

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
  xmlns:foaf="http://xmlns.com/foaf/0.1/"
  xmlns:bio="http://purl.org/vocab/bio/0.1/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/terms/"
>
  <bio:Birth rdf:about="#birth">
    <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1879-03-14</dc:date>
  </bio:Birth>
  <foaf:Person rdf:about="#AlbertEinstein">
    <foaf:name>アルベルト・アインシュタイン</foaf:name>
    <bio:olb>ドイツ生まれの理論物理学者</bio:olb>
    <bio:biography>
アルベルト・アインシュタインは1879年3月14日,ドイツ生まれの理論物理学者です。
彼による革命的な3つの論文光電効果の理論ブラウン運動の理論特殊相対性理論が発表された1905年は奇跡の年と呼ばれています。
</bio:biography>
    <bio:birth rdf:resource="#birth"/>
    <foaf:made>
      <foaf:Document rdf:about="#docs">
        <dc:title>特殊相対性理論</dc:title>
        <dc:title>ブラウン運動の理論</dc:title>
        <dc:title>光電効果の理論</dc:title>
        <dc:created rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1905</dc:created>
        <dc:references rdf:resource="http://www.einstein1905.info/einstein/1905.html"/>
        <foaf:maker rdf:resource="#AlbertEinstein"/>
      </foaf:Document>
    </foaf:made>
  </foaf:Person>
</rdf:RDF>

更にこれを RDF のグラフで表すと以下のようになります。 (図のクリックで拡大されます)

About Albert Einstein (by RDF Graph)
About Albert Einstein (by RDF Graph)(refs W3C RDF Validation Service

RDFa と RDF/XML の記述を見比べるといくつかわかることがあります。

まず,全体の主語は #AlbertEinstein で,主語を指示している <section> 要素の子要素が全て #AlbertEinstein に対する目的語になっています。 このように, RDFa では HTML 要素の親子関係から主語と目的語を推測します。 明示的な主語が見つからない場合にはページそのもの(の URI)が主語となります。

次に #docs に注目してみます。 #docs#AlbertEinstein の目的語ですが(述語は foaf:made),同時に #docs を含む <span> 要素の子要素の主語にもなっています(#docs 自体は resource 属性で指示されている点に注目して下さい)。 RDFa では,リソースは aboutresource といったHTML 要素の属性を使って主語か目的語かを指示するのですが,絶対的なものではなく, HTML 要素の親子関係によって主語と目的語が反転する場合があります。 他の例でいくと,以下のようなテキストの場合,

<div id='AlbertEinstein' about='#AlbertEinstein' typeof='foaf:Person' rel='foaf:made'>
  <ul>
    <li id='doc1' about='#doc1' typeof='foaf:Document'><span property='dc:title'>ブラウン運動の理論</span></li>
    <li id='doc2' about='#doc2' typeof='foaf:Document'><span property='dc:title'>光電効果の理論</span></li>
    <li id='doc3' about='#doc3' typeof='foaf:Document'><span property='dc:title'>特殊相対性理論</span></li>
  </ul>
</div>

RDF/XML に変換するとこのようになります。

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
  xmlns:foaf="http://xmlns.com/foaf/0.1/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/terms/"
>
  <foaf:Person rdf:about="#AlbertEinstein">
    <foaf:made>
      <foaf:Document rdf:about="#doc1">
        <dc:title>ブラウン運動の理論</dc:title>
      </foaf:Document>
    </foaf:made>
    <foaf:made>
      <foaf:Document rdf:about="#doc2">
        <dc:title>光電効果の理論</dc:title>
      </foaf:Document>
    </foaf:made>
    <foaf:made>
      <foaf:Document rdf:about="#doc3">
        <dc:title>特殊相対性理論</dc:title>
      </foaf:Document>
    </foaf:made>
  </foaf:Person>
</rdf:RDF>

about 属性で指示している #doc1#doc3#AlbertEinstein の目的語になっているのがわかると思います)

目的語がリテラル・データの場合,通常は HTML 要素で囲まれた内容がリテラル・データとなりますが, content 属性があると content の内容が優先されます。 たとえば

<span id='birth' resource='#birth' rel='bio:birth' typeof='bio:Birth'><span property='dc:date' content='1879-03-14' datatype='xsd:date'>1879年3月14日</span></span>

の記述部分では, dc:date の目的語は 1879年3月14日 ではなく 1879-03-14 となります(RDF/XML の記述を参照してみてください)。

何故このようなことをするかというと, 1879年3月14日 では機械が日付として解釈できないからです。 このため機械が解釈可能な W3C Date and Time Formats(今回の例では 1879-03-14)で上書きしているのです。 HTML の内容と解離するようなものはダメですが,機械可読な状態に「翻訳」するのであれば,この方法は有効です。

さて,基本的なルールについては以上です。 ここからは Web 上でよく使われる語彙について解説していきます。

Dublin Core Terms

DCMI(Dublin Core Metadata Initiative)が管理・運用している語彙のセットを Dublin Core Terms といいます。

(Dublin Core の名前は1995年3月に米国オハイオ州のダブリン(Dublin)で開催された OCLC/NCSA Metadata Workshop での討議結果をDublin Core Metadata と呼んだところに由来しているそうです)

Dublin Core Terms は15の基本要素(http://purl.org/dc/elements/1.1/)を再定義したものと,その拡張語彙から構成されています。 以下に Dublin Core Terms の一覧を示します。

dcterms:subPropertyOfdomainrange
contributordc:contributorrdfs:Resourcedcterms:Agent
creatordc:creator, dcterms:contributorrdfs:Resourcedcterms:Agent
coveragedc:coveragerdfs:Resourcedcterms:LocationPeriodOrJurisdiction
spatialdc:coverage, dcterms:coveragerdfs:Resourcedcterms:Location
temporaldc:coverage, dcterms:coveragerdfs:Resourcedcterms:PeriodOfTime
datedc:daterdfs:Resourcerdfs:Literal
availabledc:date, dcterms:daterdfs:Resourcerdfs:Literal
createddc:date, dcterms:daterdfs:Resourcerdfs:Literal
dateAccepteddc:date, dcterms:daterdfs:Resourcerdfs:Literal
dateCopyrighteddc:date, dcterms:daterdfs:Resourcerdfs:Literal
dateSubmitteddc:date, dcterms:daterdfs:Resourcerdfs:Literal
issueddc:date, dcterms:daterdfs:Resourcerdfs:Literal
modifieddc:date, dcterms:daterdfs:Resourcerdfs:Literal
validdc:date, dcterms:daterdfs:Resourcerdfs:Literal
descriptiondc:descriptionrdfs:Resourcerdfs:Resource
abstractdc:description, dcterms:descriptionrdfs:Resourcerdfs:Resource
tableOfContentsdc:description, dcterms:descriptionrdfs:Resourcerdfs:Resource
formatdc:formatrdfs:Resourcedcterms:MediaTypeOrExtent
extentdc:format, dcterms:formatrdfs:Resourcedcterms:SizeOrDuration
mediumdc:format, dcterms:formatdcterms:PhysicalResourcedcterms:PhysicalMedium
identifierdc:identifierrdfs:Resourcerdfs:Literal
bibliographicCitationdc:identifier, dcterms:identifierdcterms:BibliographicResourcerdfs:Literal
languagedc:languagerdfs:Resourcedcterms:LinguisticSystem
publisherdc:publisherrdfs:Resourcedcterms:Agent
relationdc:relationrdfs:Resourcerdfs:Resource
sourcedc:source, dcterms:relationrdfs:Resourcerdfs:Resource
conformsTodc:relation, dcterms:relationrdfs:Resourcedcterms:Standard
hasFormatdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
hasPartdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
hasVersiondc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
isFormatOfdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
isPartOfdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
isReferencedBydc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
isReplacedBydc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
isRequiredBydc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
isVersionOfdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
referencesdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
replacesdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
requiresdc:relation, dcterms:relationrdfs:Resourcerdfs:Resource
rightsdc:rightsrdfs:Resourcedcterms:RightsStatement
accessRightsdc:rights, dcterms:rightsrdfs:Resourcedcterms:RightsStatement
licensedc:rights, dcterms:rightsrdfs:Resourcedcterms:LicenseDocument
subjectdc:subjectrdfs:Resourcerdfs:Resource
titledc:titlerdfs:Resourcerdfs:Literal
alternativedc:title, dcterms:titlerdfs:Resourcerdfs:Literal
typedc:typerdfs:Resourcerdfs:Class
audiencerdfs:Resourcedcterms:AgentClass
educationLeveldcterms:audiencerdfs:Resourcedcterms:AgentClass
mediatordcterms:audiencerdfs:Resourcedcterms:AgentClass
accrualMethoddcmitype:Collectiondcterms:MethodOfAccrual
accrualPeriodicitydcmitype:Collectiondcterms:Frequency
accrualPolicydcmitype:Collectiondcterms:Policy
instructionalMethodrdfs:Resourcedcterms:MethodOfInstruction
provenancerdfs:Resourcedcterms:ProvenanceStatement
rightsHolderrdfs:Resourcedcterms:Agent
dcterms: の述語一覧
(via DCプロパティと定義域、値域一覧 licensed (and guideline) by KANZAKI, Masahide, 2008-2010

この表では包含関係を明確にするため接頭辞を

として再定義しています。 dc: と同じ名前で dcterms: で再定義された述語は強調して表示しています。 domain は主語として使えるリソースの種類を, range は目的語として使えるリソースの種類(またはリテラル・データ)を示しています。

またリソースのタイプを示すクラスとしては以下のものが用意されています。

クラス説明
dc:Collection リソースのコレクション
dc:Dataset データベースなどの符号化されたデータ構造
dc:Event 時間に基づいた非永続的な事象
dc:Image 写真,絵画,映画,地図,音楽記号などの象徴的な視覚表現
dc:InteractiveResource対話的なリソース。 Web ページのフォームやチャットなど
dc:MovingImage アニメーション,映画,テレビ番組,ビデオなどの動画。 dc:Image のサブクラス
dc:PhysicalObject 彫刻などの実体,あるいは3次元オブジェクト。これらの映像表現は dc:Image クラスなどに分類される
dc:Service サービス。銀行サービスなどオンラインでないものも含まれる
dc:Software ソフトウェアのソースコードまたはバイナリ
dc:Sound 音楽ファイル,CD,スピーチなど音声表現
dc:StillImage 絵画,グラフィックデザイン,地図,図案などの静止画像。 dc:Image のサブクラス
dc:Text 書籍,手紙,論文,詩,新聞など語(words)による表現。画像データでも文字表現が主なものであればこのクラスに分類される
Dublin Core Terms のクラス

Friend of a Friend

FoaF(Friend of a Friend)は知人・友人のネットワークを記述するための語彙です。 また(自分を含む)人物の Profile 情報を記述するためにも使えます。

(最近は後者の利用が多いような気がします。 後述する Open Graph なんかよりこちらのほうが断然 COOL なのですが(Open Graph より FoaF のほうが先なんですよ),サポートするサービス・プロバイダが皆無なため SEO(Search Engine Optimization)的には不利と言えます)

まずFoaF の基本クラス(主語または述語となるリソースのタイプ)は以下のとおりです。

クラス説明
foaf:Agent エージェント(人間,グループ,ソフトウェア,人工物など)
foaf:Person 人物。実存するかどうかは問わない。 foaf:Agent のサブクラス
foaf:Organization 会社,組織など。 foaf:Agent のサブクラス
foaf:Group 個々の foaf:Agent の集合体としてのグループ。 foaf:Agent のサブクラス
foaf:Project プロジェクト。公式・非公式を問わない
foaf:Document (広い意味での)文書。映像作品や Web ページなども含まれる
foaf:Image 映像。 foaf:Document のサブクラス
foaf:PersonalProfileDocument人物について記述された RDF 文書
FoaF の基本クラス

このうち foaf:Agent クラスに関する述語について主なものを挙げます。

述語domainrange説明
foaf:mbox foaf:Agent owl:Thing mailto: から始まるメールアドレスの URI。識別子(identifier)として機能する
foaf:mbox_sha1sum foaf:Agent rdfs:Literal foaf:mbox の SHA1 ハッシュ値。 foaf:mbox を示さなくても,この値を識別子として使うことができる
foaf:name owl:Thing rdfs:Literal 名前(人とは限らない)
foaf:givenName 姓名の「名」
foaf:familyName foaf:Personrdfs:Literal 姓名の「姓」
foaf:nick ニックネーム
foaf:depiction owl:Thing foaf:Image 対象を描いた絵や写真など
foaf:birthday foaf:Agent rdfs:Literal 誕生日
foaf:schoolHomepage foaf:Personfoaf:Document対象の人物の母校
foaf:workplaceHomepagefoaf:Personfoaf:Document対象の人物の勤務先
foaf:workInfoHomepage foaf:Personfoaf:Document対象の人物の仕事内容
foaf:knows foaf:Personfoaf:Person 知人(相互に知り合ってるレベル)
foaf:homepage owl:Thing foaf:Documentホームページ
foaf:weblog foaf:Agent foaf:Documentウェブログ
foaf:tipjar foaf:Agent foaf:Document対象への支払いや寄付の方法を記述したページ。 Flattr にも使える?
foaf:interest foaf:Agent foaf:Document関心を持ってる事に関するページ
foaf:topic_interest foaf:Agent owl:Thing 関心を持ってるトピック
foaf:publications foaf:Personfoaf:Document対象の人物の出版物
foaf:made foaf:Personowl:Thing 対象の人物の作品
foaf:currentProject foaf:Personowl:Thing 対象の人物が現在手がけているプロジェクト
foaf:pastProject foaf:Personowl:Thing 対象の人物が過去に手がけてたプロジェクト
FoaF の述語一覧(1)

また foaf:Agent で記述される作品やプロジェクト等に関する述語(上記以外)も挙げておきます。

述語domainrange説明
foaf:page owl:Thing foaf:Documentページ
foaf:topic foaf:Documentowl:Thing ページに関するトピック。 foaf:page の逆
foaf:primaryTopic foaf:Documentowl:Thing 主語ページ・文書のメイントピック
foaf:isPrimaryTopicOfowl:Thing foaf:Document目的語ページ・文書のメイントピック。 foaf:primaryTopic の逆で foaf:page のサブプロパティ
foaf:maker owl:Thing foaf:Agent 主語を作った人。 foaf:made の逆
foaf:logo owl:Thing owl:Thing ロゴ
foaf:depicts foaf:Image owl:Thing 映像が描写している対象。 foaf:depiction の逆
foaf:thumbnail foaf:Image foaf:Image 映像のサムネイル
FoaF の述語一覧(2)

foaf:makerDublin Core Termsdc:creator と被りますが, foaf:maker のほうが構造化リソースとしての作者を記述することができます。

FoaF にはオンラインサービスのアカウントに関する語彙もあります。 以下にオンラインサービスのアカウントに関するクラスと述語を挙げます。

クラス説明
foaf:OnlineAccount オンラインサービスのアカウント
foaf:OnlineGamingAccount オンラインゲームのアカウント。 foaf:OnlineAccount のサブクラス
foaf:OnlineEcommerceAccountオンラインショップ等のアカウント。foaf:OnlineAccount のサブクラス
foaf:OnlineChatAccount チャットやメッセージング・サービスのアカウント。 foaf:OnlineAccount のサブクラス
FoaF のアカウント関連クラス
述語domainrange説明
foaf:account foaf:Agent foaf:OnlineAccountオンラインサービスのアカウント
foaf:accountServiceHomepagefoaf:OnlineAccountfoaf:Document オンラインサービスのホームページ
foaf:accountName foaf:OnlineAccountrdfs:Literal オンラインサービスのアカウント名(識別子)
FoaF の述語一覧(3)

Creative Commons Rights Expression Language

ccREL(Creative Commons Rights Expression Language)は Web 上の作品の著作権情報を記述するための語彙です。 Creative Commons License 3.0 を念頭に設計されていますが,他の(自由な)著作権ライセンスや利用ガイドラインにも対応しています。

ccREL の語彙は「著作権ライセンスを記述する」語彙と「著作権ライセンスを表示する」語彙とに分かれます。 以下は ccREL の基本クラス(主語または述語となるリソースのタイプ)です。

クラス説明
cc:Work 作品
cc:License ライセンス。 dc:LicenseDocument のサブクラス
cc:Jurisdiction準拠法
cc:Permission ライセンスにおける許諾事項
cc:Requirement ライセンスにおける要求(条件)事項
cc:Prohibition ライセンスにおける禁止事項
ccREL(cc: http://creativecommons.org/ns#)のクラス

このうち「著作権ライセンスを表示する」語彙である cc:Work に関する述語を挙げてみます。

述語domainrange説明
cc:license cc:Workcc:License ライセンス
cc:morePermissionscc:Workrdfs:Resource(cc:license 以外の)追加の許諾
cc:useGuidelines cc:Workrdfs:Resource利用ガイドライン
cc:attributionURL cc:Workrdfs:Resource著作(権)者
cc:attributionNamecc:Workrdfs:Literal 著作(権)者名
cc:Work 関連の述語

明確な「利用許諾(license)」がない場合,またはライセンスに対して付加情報(免責事項など)がある場合には cc:useGuidelines を使います。 また,ライセンスに対して追加の許諾がある場合(ライセンスとしては by-nc だけど条件によっては個別に商用利用も許可するなど)には cc:morePermissions を使います。

作品の著作権は著作者に自動的に付与されますが,権利自体は譲渡可能なため(譲渡できない権利もあります),著作者と著作者が異なる場合があります。 その場合は cc:attributionURLcc:attributionName で権利の帰属先を明示します。 著作者と著作権者が同一であるなら foaf:maker 等で置き換えることもできます。

(「製作委員会」方式などで権利を集約している場合や(独占契約を結ぶ代わりに)出版社および権利管理団体に権利を譲渡する場合は権利の帰属先が変わります。 著作権ライセンスの場合は「誰が作ったか」よりも「誰に権利があるか」のほうが重要なので権利の帰属先を明記することは重要です。 もちろん(たとえ著作者であっても)権利のない人が勝手にライセンスを設定することはできません)

RDFa であれば主語を明示することでページ内のテキスト,映像,音声等に対して個別に権利表示を行うことができます。 たとえば先程のdcterms: の述語一覧の表はDCプロパティと定義域、値域一覧のものを流用していますが,以下のように記述しています。

<figure id='dct-list' about='#dct-list' typeof='dc:Text'>
<table>
[...]
</table>
<figcaption><span property='dc:title'>dcterms: の述語一覧</span>(via <q><a href="http://www.kanzaki.com/docs/sw/dc-domain-range.html" rel='dc:source'><span property='dc:title'>DCプロパティと定義域、値域一覧</span></a></q> <span about="http://www.kanzaki.com/docs/sw/dc-domain-range.html"><a href="http://www.kanzaki.com/info/ccl#NoOnlineDistribution" rel='cc:license'>licensed</a> (and <a href="http://www.kanzaki.com/info/disclaimer" rel='cc:useGuidelines'>guideline</a>) by <a href="http://www.kanzaki.com/info/who" rel='foaf:maker' typeof='foaf:Person'><span property='foaf:name'>KANZAKI, Masahide</span></a>, <span property='dc:dateCopyrighted' datatype='xsd:date'>2008</span>-<span property='dc:modified' datatype='xsd:date'>2010</span></span>)</figcaption>
</figure>

これを RDF Graph にすると以下のようになり,元になった Web ページを指し示しているのがわかると思います。 (図のクリックで拡大されます)

dcterms: の述語一覧 の RDF Graph
dcterms: の述語一覧の RDF Graph(refs W3C RDF Validation Service

Creative Commons License では提示される内容が「コモンズ証(Commons Deed)」「法的条項(Legal Code)」「メタデータ(Metadata)」の3つのレイヤに分かれていて,そのうちメタデータのレイヤを RDF で実装しています。 たとえば「表示-継承(by-sa)」ライセンスの場合は各レイヤの URI は以下のようになっています。

実際にはコモンズ証にも RDFa 付与がされていますが,明示的にメタデータへ誘導するのなら,このページのフッタ部のように記述するのがいいかもしれません。

Licensed under <a href='http://creativecommons.org/licenses/by/4.0/' rel='cc:license' typeof='cc:License'><span resource='http://creativecommons.org/licenses/by/4.0/rdf' rel='dc:relation'><img src='/images/cc/by.s.png' alt='Attribution License' height='12'></span></a>

Creative Commons License について詳しくはクリエイティブ・コモンズ・ライセンスについてを参照して下さい。

(Creative Commons License のメタデータはかなり不遇な経緯をたどっています。 というより, RDF 自体が不遇なのかもしれませんが。 最初の Creative Commons License が登場した2002年当時は RDF をまともに解釈できる parser がありませんでした。 その後, Creative Commons License については mozCC のようなツールも登場しますが, mozCC はどういうわけかコメントアウトされた RDF 情報しか読まず,他のツールも似たり寄ったりの状況です。 さらに Microformats の rel-license も登場しますが,これも URL からあらかじめ持ってる知識でライセンスの種類を推測するだけの実装がほとんどで,「意味を理解する」という RDF の目標からは遠いものです。 近年 RDFa やその語彙である ccREL が整備されてきましたが,果たしてどうなるでしょうか)

付録: Open Graph

Open Graph Protocol はもともと Facebook で提案されたもので, RFDa のような体裁をとっていますが(Validator でチェックしてもエラーにはなりません),似て非なるものです。 Open Graph は以下のような関係を想定しています。

Open Graph の相関図
Open Graph の相関図
  • The actor : 行動をおこすユーザ
  • The app : 行動をおこすためのアプリケーション
  • The action : 行動
  • The object : 行動の対象となる「もの」

つまり Open Graph の記述は The App からみれば制御情報に過ぎず, Open Graph 自体は意味を構成していません。 そして,当然ながら Facebook 以外のサービスには使いづらいため Twitter Card の登場に加え mixiGREE も OGP に独自の仕様を混ぜています。 もはやこれは「濫用」と呼ぶべき状況かもしれません。

Open Graph が RDFa と異なる点は以下のとおりです。

  • <head> 要素内の <meta> 要素にしか記述できない。他は全て無視される
  • したがってページ全体に関する記述しかできず,ページ内の構造を記述できない。また他の語彙とも組み合わせられない
  • 記述を <meta> 要素に限定しているためリテラル・データしか扱えない
  • リテラル・データの datatypeOpen Graph で用意されているものを使わなければならない

Open Graph を設置する際は以上の点に気をつけて下さい。 具体的な設定方法については割愛します(SEO 関連のサイトを探せば大抵設定方法が載っています)。