リソース記述フレームワーク

リソース記述フレームワークRDF )は、グラフデータを記述および交換するための手法です。元々は、ワールド・ワイド・ウェブ・コンソーシアム(W3C)によってメタデータのデータモデルとして設計されました。RDFは様々な構文表記法と形式を提供しており、その中で最も広く使用されているのはTurtle(Terse RDF Triple Language)です。

RDFは、3つの文からなる有向グラフです。RDFグラフ文は、(1)主語を表すノード、(2)述語を表す主語から目的語へのアーク、(3)目的語を表すノードによって表現されます。これらの各部分は、国際化リソース識別子(IRI)によって識別できます。目的語はリテラル値にすることもできます。このシンプルで柔軟なデータモデルは、複雑な状況、関係性、その他の関心対象を表現するための 豊富な表現力を備えながら、適度に抽象化されています。

RDFは1999年にW3C勧告として採用されました。RDF 1.0仕様は2004年に、RDF 1.1仕様は2014年に公開されました。SPARQLRDFグラフの標準クエリ言語です。RDFスキーマ(RDFS)、Webオントロジー言語(OWL)、SHACL(Shapes Constraint Language)は、RDFデータを記述するために使用されるオントロジー言語です。

概要

RDFデータモデル[ 1 ]は、古典的な概念モデリング手法(実体関連図クラス図など)に類似しています。これは、リソース(特にWebリソース)に関する記述を、主語-述語-目的語という形式の表現(トリプル)で記述するという考え方に基づいています。主語はリソースを示し、述語はリソースの特性や側面を示し、主語目的語の関係を表します。

例えば、「空は青い色をしている」という概念をRDFで表現する方法の一つは、トリプルで表現することです。トリプルとは、「空」を表す主語、 「色をしている」を表す述語、そして「青い」を表す目的語です。したがって、RDFでは、オブジェクト指向設計における典型的なエンティティ-属性-値モデルのアプローチ(エンティティ(空)、属性(色)、値(青))とは対照的に、目的語(またはエンティティ) ではなく主語を使用します。

RDFは、複数のシリアル化形式(本質的には特殊なファイル形式)を持つ抽象モデルです。さらに、リソースやトリプルの特定のエンコーディングは、形式によって異なります。

このリソース記述メカニズムは、W3Cのセマンティックウェブ活動における主要な構成要素です。セマンティックウェブとは、自動化されたソフトウェアがウェブ全体に分散された機械可読情報を保存、交換、使用できるワールドワイドウェブの進化段階であり、ユーザーはより効率的かつ確実に情報を処理できるようになります。RDFのシンプルなデータモデルと、異なる抽象的な概念をモデル化できる能力により、セマンティックウェブ活動とは無関係な知識管理アプリケーションでもRDFの利用が増加しています。

RDFステートメントの集合は、本質的にラベル付き有向マルチグラフを表します。そのため、RDFデータモデルは、他のリレーショナルモデルやオントロジーモデルよりも、特定の種類の知識表現に適しています。

RDFSOWLSHACLが示すように、 RDF 上に 追加のオントロジー言語を構築できます。

歴史

当初のRDF設計は、「ベンダー中立かつオペレーティングシステムに依存しないメタデータシステムの構築」を意図したもので、[ 2 ] W3CのPlatform for Internet Content Selection(PICS)(初期のウェブコンテンツラベルシステム)[ 3 ]から派生したものであったが、このプロジェクトはダブリンコアMeta Content Framework(MCF)[ 2 ]のアイデアも取り入れていた。MCFは1995年から1997年にかけてアップルRamanathan V. Guha氏とネットスケープTim Bray氏によって開発された。[ 4 ]

RDFの最初の公開草案は1997年10月に登場し、[ 5 ] [ 6 ] IBMMicrosoftNetscapeNokiaReutersSoftQuadミシガン大学の代表者を含むW3Cワーキンググループによって発行されました。[ 3 ]

1999年、W3Cは最初の推奨RDF仕様であるモデルおよび構文仕様(「RDF M&S」)を公開しました。[ 7 ]これはRDFのデータモデルとXMLシリアル化を記述しました。[ 8 ]

この時期には、RDFに関する2つの根強い誤解が生じました。1つ目は、MCFの影響とRDFの「リソース記述」という頭文字から、RDFはメタデータの表現に特化しているという考え方です。2つ目は、RDFはデータモデルではなくXML形式であり、RDF/XMLシリアル化のみがXMLベースであるという考え方です。この時期にRDFはあまり採用されませんでしたが、ブリストル、ブリストル大学HP研究所のILRT 、そしてボストンのMITで重要な研究が行われました。RSS 1.0FOAFは、この時期にRDFの代表的なアプリケーションとなりました。

1999年の勧告は2004年に6つの仕様に置き換えられました: [ 9 ]「RDF入門書」、「 RDF概念と概要」、「RDF/XML構文仕様(改訂版)」、[ 12 ]RDFセマンティクス」、 RDF語彙記述言語1.0 RDFテストケース[ 15 ]

このシリーズは、 2014年に以下の6つの「RDF 1.1」文書に置き換えられました:「RDF 1.1 入門書」、RDF 1.1概念と抽象構文」、 RDF 1.1 XML構文」、RDF 1.1セマンティクス」 RDF スキーマ 1.1」「 RDF 1.1テストケース」[ 21 ]

RDFトピック

語彙

RDF仕様で定義されている語彙は以下のとおりである。[ 22 ]

クラス

rdf
rdf:XMLLiteral
XMLリテラル値のクラス
rdf:Property
プロパティのクラス
rdf:Statement
RDFステートメントのクラス
rdf:Alt、、rdf:Bagrdf:Seq
選択肢のコンテナ、順序なしコンテナ、順序付きコンテナ(rdfs:Containerはこれら 3 つのスーパークラスです)
rdf:List
RDFリストのクラス
rdf:nil
rdf:List空のリストを表すインスタンス
rdfs
rdfs:Resource
クラスのリソース、すべて
rdfs:Literal
リテラル値のクラス(例:文字列整数)
rdfs:Class
クラスのクラス
rdfs:Datatype
RDFデータ型のクラス
rdfs:Container
RDFコンテナのクラス
rdfs:ContainerMembershipProperty
コンテナメンバーシッププロパティのクラス、、、rdf:_1... rdf:_2、これらはすべてサブプロパティですrdfs:member

プロパティ

rdf
rdf:type
rdf:Propertyリソースがクラスのインスタンスであることを示すために使用されるインスタンス
rdf:first
主題RDFリストの最初の項目
rdf:rest
主題RDFリストの残りrdf:first
rdf:value
構造化された値に使用される慣用的なプロパティ
rdf:subject
RDFステートメントの主語
rdf:predicate
RDF文の述語
rdf:object
RDF文の目的語

rdf:Statement、、rdf:subject具体化rdf:predicaterdf:object使用されます(下記参照)

rdfs
rdfs:subClassOf
主語はクラスのサブクラスである
rdfs:subPropertyOf
主語はプロパティのサブプロパティである
rdfs:domain
対象プロパティのドメイン
rdfs:range
対象プロパティの範囲
rdfs:label
人間が読める主題の名前
rdfs:comment
対象リソースの説明
rdfs:member
対象リソースのメンバー
rdfs:seeAlso
対象リソースに関する詳細情報
rdfs:isDefinedBy
主題リソースの定義

この語彙は、 RDF スキーマの基盤として使用され、拡張されています。

シリアル化形式

RDF 1.1 タートルシリアル化
ファイル名拡張子
.ttl
インターネットメディアの種類
テキスト/タートル[ 23 ]
開発者ワールドワイドウェブコンソーシアム
標準RDF 1.1 Turtle: 簡潔なRDFトリプル言語2014年1月9日 (2014年1月9日
オープンフォーマット?はい
RDF 1.1 TriGシリアル化
ファイル名拡張子
.trig
インターネットメディアの種類
アプリケーション/トリガー[ 24 ]
開発者ワールドワイドウェブコンソーシアム
標準RDF 1.1 TriG: RDFデータセット言語2014年2月25日 (2014年2月25日
オープンフォーマット?はい
RDF/XMLシリアル化
ファイル名拡張子
.rdf
インターネットメディアの種類
アプリケーション/rdf+xml [ 25 ]
開発者ワールドワイドウェブコンソーシアム
標準概念と抽象構文2004年2月10日 (2004年2月10日
オープンフォーマット?はい

次のようないくつかの一般的なシリアル化形式が使用されています。

  • Turtle [ 26 ]コンパクトで人間に優しいフォーマットです。
  • TriG [ 27 ]Turtleをデータセットに拡張したものです。
  • N-Triples [ 28 ]非常にシンプルで解析しやすい行ベースのフォーマットですが、Turtleほどコンパクトではありません。
  • N-Quads [ 29 ] [ 30 ]N-Triplesのスーパーセットであり、複数のRDFグラフをシリアル化します。
  • JSON-LD [ 31 ] JSONベースのシリアル化。
  • N3またはNotation3 は、Turtle に非常によく似た非標準のシリアル化ですが、推論ルールを定義する機能など、いくつかの追加機能があります。
  • RDF/XML [ 32 ]は、RDFをシリアル化するための最初の標準フォーマットであったXMLベースの構文です。
  • RDF/JSON[ 33 ]は、シンプルなJSON表記法を使用してRDFトリプルを表現するための代替構文です。

RDF/XMLは、RDFを定義する他のW3C仕様の中で導入され、歴史的に最初のW3C標準RDFシリアル化形式であったため、誤解を招くように単にRDFと呼ばれることがあります。しかし、RDF/XML形式を抽象的なRDFモデル自体と区別することが重要です。RDF/XML形式は現在でも使用されていますが、多くのRDFユーザーは、より人間に優しい[ 34 ]ことと、XML QName の構文上の制約により一部のRDFグラフがRDF/XMLで表現できないことの両方から、他のRDFシリアル化形式を好んでいます。

少しの努力で、実質的に任意のXML を、 GRDDL (「グリドル」と発音) (Gleaning Resource Descriptions from Dialects of Languages) を使用して RDF として解釈することもできます。

RDF トリプルは、トリプルストアと呼ばれるタイプのデータベースに保存できます。

リソースの識別

RDF文の主語は、URI(Uniform Resource Identifier )または空白ノードのいずれかであり、どちらもリソースを表します。空白ノードによって示されるリソースは匿名リソースと呼ばれます。これらはRDF文から直接識別することはできません。述語は、リソースを示すURIであり、関係性を表します。目的語は、URI、空白ノード、またはUnicode文字列リテラルです。RDF 1.1以降、リソースは国際化リソース識別子(IRI)によって識別されます。IRIはURIの一般化です。[ 35 ]

セマンティックWebアプリケーション、そしてRSSFOAF(Friend of a Friend)といった比較的一般的なRDFアプリケーションでは、リソースは、ワールドワイドウェブ上の実際のデータを意図的に示し、アクセスするために使用できるURIで表現される傾向があります。しかし、RDFは一般的に、インターネットベースのリソースの記述に限定されません。実際、リソースを指定するURIは、逆参照可能である必要は全くありません。例えば、「http:」で始まり、RDF文の主語として使用されるURIは、必ずしもHTTP経由でアクセス可能なリソースを表す必要はなく、実体のあるネットワークアクセス可能なリソースを表す必要もありません。そのようなURIは、全く何でも表すことができます。しかし、HTTP GETリクエストで使用された際に300レベルのコードで返される、#記号のないURIは、アクセスに成功したインターネットリソースを表すものとして扱うべきであるという点については、広く合意されています。

したがって、RDF文の生産者と消費者は、リソース識別子の意味について合意する必要があります。このような合意はRDF自体に固有のものではありませんが、Dublin Coreメタデータのように、RDFで使用するためにURI空間に部分的にマッピングされる統制語彙がいくつか一般的に使用されています。RDFベースのオントロジーをWeb上で公開する目的は、多くの場合、RDFでデータを表現するために用いられるリソース識別子の意図された意味を確立、あるいは限定することです。例えば、次のURIは、

http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#メルロー

このURIは、所有者によって、醸造業者別のメルロー赤ワインのクラス(つまり、上記のURIの各インスタンスは、単一の醸造業者によって生産されるすべてのワインのクラスを表す)を指すように意図されています。この定義は、OWLオントロジー(それ自体はRDF文書)によって表現されており、OWLオントロジー内でこのクラスが使用されています。定義を注意深く分析しないと、上記のURIのインスタンスがワインの種類ではなく、物理的な何かであると誤って結論付けてしまう可能性があります。

これは「裸の」リソース識別子ではなく、「#」文字を含みフラグメント識別子で終わるURI 参照であることに注意してください。

文の具体化とコンテキスト

(主語、述語、目的語) で構成される基本的な RDF トリプル。

文の集合によってモデル化された知識体系は、具体化の対象となり得ます。具体化では、各文(つまり、主語・述語・目的語の3要素すべて)にURIが割り当てられ、追加の文を作成できるリソースとして扱われます(例:「ジェーンは、ジョンが文書Xの著者であると述べています」)。具体化は、各文の信頼性や有用性の度合いを推論するために重要となる場合があります。

具象化されたRDFデータベースでは、リソースである元の文それぞれに、それに関する少なくとも3つの追加文が存在する可能性が高くなります。1つは、その主語が何らかのリソースであることを主張する文、1つは、その述語が何らかのリソースであることを主張する文、そしてもう1つは、その目的語が何らかのリソースまたはリテラルであることを主張する文です。アプリケーションのニーズに応じて、元の文に関する追加の文が存在する場合もあります。

ロジックで利用可能な概念(および概念グラフトピックマップなどのグラフィカル表記法で説明されている概念)を借用して、一部のRDFモデル実装では、状況コンテキスト、またはスコープと呼ばれるさまざまな基準に従ってステートメントをグループ化すると便利な場合があることが認識されています。これは、 RDF仕様の共同編集者であるGraham Klyneの記事で説明されています。[ 36 ] [ 37 ]たとえば、ステートメントは、URIで名前が付けられたコンテキストに関連付けることができ、「〜が真である」関係を主張できます。別の例として、ステートメントをそのソース(特定のRDF/XMLドキュメントのURIなど、URIで識別できます)ごとにグループ化すると便利な場合があります。次に、ソースが更新されると、モデル内の対応するステートメントも変更できます。

スコープの実装は、必ずしも完全に具体化された文を必要としません。実装によっては、URIが割り当てられていない文に単一のスコープ識別子を関連付けることができます。[ 38 ] [ 39 ] 同様に、トリプルの集合がURIで名前付けされた名前付きグラフは、トリプルを具体化することなくコンテキストを表すことができます。[ 40 ]

クエリ言語と推論言語

RDF グラフの主なクエリ言語はSPARQLです。SPARQL はSQLに似た言語であり、2008 年 1 月 15 日時点で W3C勧告となっています。

以下は、架空のオントロジーを使用してアフリカの国の首都を表示する SPARQL クエリの例です。

PREFIX: <http://example.com/exampleOntology#> SELECT ?capital ?country WHERE { ?x: cityname ?capital ;: isCapitalOf ?y . ?y: countryname ?country ;: isInContinent: Africa . }

RDF グラフをクエリするその他の非標準の方法は次のとおりです。

  • RDQL、SPARQLの前身、SQLのような
  • Versa、コンパクトな構文(SQL に似ていない)、4SuitePython)でのみ実装されています。
  • RQLはRDFスキーマとリソース記述を統一的に照会するための最初の宣言型言語の1つであり、RDFSuiteに実装されています。[ 41 ]
  • SeRQL 、 Sesameの一部
  • XUL には、RDF 内のデータ一致ルールを宣言するためのテンプレート要素があります。XUL はデータバインディングに RDF を広範に使用します。

SHACLの高度な機能仕様[ 42 ](W3Cワーキンググループノート)の最新版はSHACLコミュニティグループによって管理されており、[ 43 ]ではSHACLの形状に基づいたRDFのデータ変換、推論、マッピングに使用されるSHACLルールのサポートが定義されています。

検証と説明

RDFグラフの記述と検証に最も多く使われている言語はSHACL(Shapes Constraint Language)です。[ 44 ] SHACL仕様はSHACL CoreとSHACL-SPARQLの2つの部分に分かれています。SHACL Coreは、カーディナリティ、値の範囲など、組み込み制約のリストで構成されています。SHACL-SPARQLはSPARQLベースの制約と、新しい制約コンポーネントを宣言するための拡張メカニズムを記述しています。

RDF グラフを記述および検証するその他の非標準の方法は次のとおりです。

  • SPARQL推論記法(SPIN)[ 45 ]はSPARQLクエリに基づいていましたが、SHACLに取って代わられ、事実上廃止されました。[ 46 ]
  • ShEx(Shape Expressions)[ 47 ]はRDFの検証と記述のための簡潔な言語である。

例1: エリック・ミラーという人物の説明

次の例は、W3Cのウェブサイト[ 48 ]から引用したもので、「http://www.w3.org/People/EM/contact#meで識別される人物がおり、その名前はEric Miller、電子メールアドレスはe.miller123(at)example(セキュリティ上の理由により変更)、肩書きはDr.」という記述を含むリソースについて説明しています。

エリック・ミラーを記述したRDFグラフ[ 48 ]

リソース「http://www.w3.org/People/EM/contact#me」が主題です。

オブジェクトは次のとおりです。

  • 「エリック・ミラー」(述語「名前は」付き)、
  • mailto:e.miller123(at)example(述語「メールアドレスは」)と
  • 「Dr.」(述語「そ​​の肩書きは」付き)。

サブジェクトは URI です。

述語にもURIがあります。例えば、各述語のURIは次のようになります。

  • 「whose name is」はhttp://www.w3.org/2000/10/swap/pim/contact#fullNameです。
  • 「誰のメールアドレスが」はhttp://www.w3.org/2000/10/swap/pim/contact#mailboxです。
  • 「whose title is」は http://www.w3.org/2000/10/swap/pim/contact#personalTitle です。

さらに、主語にはタイプ (URI http://www.w3.org/1999/02/22-rdf-syntax-ns#type) があり、これは人 (URI http://www.w3.org/2000/10/swap/pim/contact#Person) です。

したがって、次の「主語、述語、目的語」の RDF トリプルを表現できます。

  • http://www.w3.org/People/EM/contact#me、http://www.w3.org/2000/10/swap/pim/contact#fullName、「エリック・ミラー」
  • http://www.w3.org/People/EM/contact#me、http://www.w3.org/2000/10/swap/pim/contact#mailbox、mailto:e.miller123(at)example
  • http://www.w3.org/People/EM/contact#me、http://www.w3.org/2000/10/swap/pim/contact#personalTitle、「Dr.」
  • http://www.w3.org/People/EM/contact#me、http://www.w3.org/1999/02/22-rdf-syntax-ns#type、http://www.w3.org/2000/10/swap/pim/contact#Person

標準の N-Triples 形式では、この RDF は次のように記述できます。

<http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#fullName> "Eric Miller" . <http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#mailbox> <mailto:e.miller123(at)example> . <http://www.w3.org/People/EM/contact#me> <http://www.w3.org/2000/10/swap/pim/contact#personalTitle> "Dr." . <http://www.w3.org/People/EM/contact#me> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/10/swap/pim/contact#Person> 

同様に、標準の Turtle (構文) 形式では次のように記述できます。

@prefix eric: <http://www.w3.org/People/EM/contact#> @prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> eric : me連絡先: fullName "Eric Miller" . eric : me連絡先:メールボックス<mailto:e.miller123(at)example> . eric : me連絡先: personalTitle "Dr." . eric : me rdf : type連絡先: Person .

あるいは、より簡潔に言うと、Turtle の一般的な省略構文を使用すると次のようになります。

@prefix eric: <http://www.w3.org/People/EM/contact#> @prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> eric : me contact : fullName "Eric Miller" ; contact : mailbox <mailto:e.miller123(at)example> ; contact : personalTitle "Dr." ; rdf : type contact : Person .

または、RDF/XML 形式で次のように記述することもできます。

<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:contact= "http://www.w3.org/2000/10/swap/pim/contact#" xmlns:eric= "http://www.w3.org/People/EM/contact#" xmlns:rdf= "http://www.w3.org/1999/02/22-rdf-syntax-ns#" > <rdf:Description rdf:about= "http://www.w3.org/People/EM/contact#me" > <contact:fullName>エリック・ミラー</contact:fullName> </rdf:Description> <rdf:Description rdf:about= "http://www.w3.org/People/EM/contact#me" > <contact:mailbox rdf:resource= "mailto:e.miller123(at)example" /> </rdf:Description> <rdf:Description rdf:about= "http://www.w3.org/People/EM/contact#me" > <contact:personalTitle>博士</contact:personalTitle> </rdf:Description> <rdf:Description rdf:about= "http://www.w3.org/People/EM/contact#me" > <rdf:type rdf:resource= "http://www.w3.org/2000/10/swap/pim/contact#Person" /> </rdf:Description> </rdf:RDF>

例2: ニューヨークの郵便略称

RDFにおける特定の概念は論理学言語学から引用されており、主語-述語および主語-述語-目的語の構造は、RDFにおけるこれらの用語の用法と類似しつつも異なる意味を持ちます。この例は以下を示しています。

英語の「ニューヨークには郵便略語 NY がある」では、「ニューヨーク」が主語、 「郵便略語がある」が述語、「NY」が目的語 になります。

RDFトリプルとしてエンコードする場合、主語と述語はURIで指定されたリソースである必要があります。目的語はリソースまたはリテラル要素です。例えば、RDFのN-トリプル形式では、この文は次のようになります。

<urn:x-states:New%20York> <http://purl.org/dc/terms/alternative> "ニューヨーク" 

この例では、「urn:x-states:New%20York」は米国のニューヨーク州を表すリソースのURI 、「http://purl.org/dc/terms/alternative」は述語(人間が読める定義はこちら[ 49 ]を参照)のURI、「NY」はリテラル文字列です。ここで選択したURIは標準的ではありませんが、その意味が読み手にとって理解できる限り、標準的である必要はありません。

例3: トニー・ベンに関するWikipediaの記事

同様に、「https://en.wikipedia.org/wiki/Tony_Benn」が特定のリソースを識別している場合(そのURIがハイパーリンクとしてトラバースできるかどうか、あるいはリソースが実際にTony Bennに関するWikipediaの記事であるどうかは関係ありません)、このリソースのタイトルが「Tony Benn」であり、その発行者が「Wikipedia」であると言うことは、有効なRDFステートメントとして表現できる2つのアサーションになります。RDFのN-Triples形式では、これらのステートメントは次のようになります。

<https://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/title> 「トニー・ベン」. <https://en.wikipedia.org/wiki/Tony_Benn> <http://purl.org/dc/elements/1.1/publisher> 「Wikipedia」.

英語を話す人にとっては、同じ情報は次のように簡単に表現できます。

Wikipediaが公開しているこのリソースのタイトルは「トニー・ベン」です。

しかし、RDFは情報を機械が理解できる形式的な方法で表現します。RDFの目的は、特定のソフトウェアが理解できる方法でリソースを記述できるように、エンコードと解釈のメカニズムを提供することです。言い換えれば、ソフトウェアが、そうでなければ利用できない情報にアクセスし、利用できるようにすることです。

上記のどちらの記述も冗長です。RDFリソース(主語または述語)の要件の一つは、一意であることであるためです。主語リソースは、記述対象のリソースを正確に特定するために一意である必要があります。述語は、記述を処理するソフトウェアにとってタイトルまたは発行者の概念が曖昧になる可能性を減らすために、一意である必要があります。ソフトウェアが http://purl.org/dc/elements/1.1/title (ダブリン・コア・メタデータ・イニシアティブによって確立されたタイトルの概念の具体的な定義)を認識できる場合、このタイトルが土地のタイトルや名誉称号、あるいは単にタイトルを組み合わせたものとは異なることも認識します。

Turtleで記述された以下の例は、複数のRDF語彙を組み合わせることで、このような単純な主張をどのように詳細化できるかを示しています。ここでは、Wikipediaページの主要トピックが「Tony Benn」という名前の「人物」であることに注目してください。

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix dc: <http://purl.org/dc/elements/1.1/> .<https://en.wikipedia.org/wiki/Tony_Benn> dc :発行者"Wikipedia" ; dc :タイトル"Tony Benn" ; foaf : primaryTopic [ a foaf : Person ; foaf : name "Tony Benn" ] .

アプリケーション

  • DBpedia – Wikipedia の記事から事実を抽出し、RDF データとして公開します。
  • YAGO – DBpedia と同様に、Wikipedia の記事から事実を抽出し、RDF データとして公開します。
  • Wikidata – ウィキメディア財団がホストする共同編集可能な知識ベース。
  • Creative Commons – RDF を使用して、Web ページや mp3 ファイルにライセンス情報を埋め込みます。
  • FOAF (Friend of a Friend)人々、彼らの興味、相互関係を説明するために設計されています。
  • Haystackクライアント– MIT CS & AIラボのセマンティックウェブブラウザ。[ 50 ]
  • IDEASグループ– RDFをエンコーディングとして使用したエンタープライズアーキテクチャのための正式な4Dオントロジーを開発しています。 [ 51 ]
  • マイクロソフトはRDFベースのプロファイル管理機能を提供する製品「Connected Services Framework」[ 52 ]を出荷しました。
  • MusicBrainz – 音楽アルバムに関する情報を公開しています。[ 53 ]
  • NEPOMUK は、ソーシャルセマンティックデスクトップ向けのオープンソースソフトウェア仕様であり、収集されたメタデータの保存形式として RDF を使用します。NEPOMUK は、KDE ​​SC 4デスクトップ環境への統合によって広く知られています。
  • コクランは、エビデンスに基づく医療における臨床研究メタアナリシスの世界的な出版社です。彼らはオントロジー駆動型データアーキテクチャを用いて、RDFベースの構造化データを用いて公開レビューに意味的な注釈を付けています。[ 54 ]
  • RDF サイト サマリー – Web ページの更新に関する情報を公開するための「 RSS 」言語の 1 つ。ニュース記事の要約を配布したり、ブログコンテンツを共有したりするためによく使用されます。
  • SKOS( Simple Knowledge Organization System) – 語彙/シソーラスアプリケーションをサポートすることを目的としたKR表現
  • SIOC(意味的に相互リンクされたオンラインコミュニティ) – オンラインコミュニティを記述し、掲示板、ウェブログ、メーリングリストからのインターネットベースのディスカッション間の接続を作成するように設計されています。[ 55 ]
  • Smart-M3 – RDFを使用するためのインフラストラクチャを提供し、特にRDFのオントロジーに依存しない性質を利用して異種の情報のマッシュアップを可能にします[ 56 ]
  • LV2 - Turtleを使用してAPI / ABIの機能とプロパティを記述する自由なプラグイン形式[ 57 ]
  • ソフトウェア パッケージ データ交換–部品表を指定するための標準。

RDFの用途としては、ソーシャルネットワーキングの研究などが挙げられます。また、ビジネス分野の人々が、プロダクトプレイスメントに活用できる業界関係者との関係をより深く理解するのに役立ちます。[ 58 ] また、科学者が人々がどのように互いにつながっているかを理解する上でも役立ちます。

RDFは、道路の交通パターンをより深く理解するために使用されています。これは、交通パターンに関する情報が異なるWebサイトにあり、RDFがWeb上のさまざまなソースからの情報を統合するために使用されるためです。以前は、キーワード検索を使用する方法が一般的でしたが、この方法は同義語を考慮していないという問題がありました。そのため、オントロジーはこの状況で役立ちます。しかし、交通を効率的に調査しようとすると、交通を完全に理解するためには、人、通り、道路に関連する概念を十分に理解する必要があるという問題があります。これらは人間の概念であるため、ファジー論理を追加する必要があります。これは、道路の滑りやすさなど、道路を説明するのに役立つ値が正確な概念ではなく、測定できないためです。これは、ファジー論理とオントロジーの両方を組み込むことが最善の解決策であることを意味します。[ 59 ]

参照

RDFの表記法

類似の概念

他の

参考文献

引用

  1. ^ 「リソース記述フレームワーク(RDF)モデルおよび構文仕様」。W3C 1999年1月5日。2023年7月14日時点のオリジナルよりアーカイブ。
  2. ^ a b「World Wide Web Consortium、リソース記述フレームワークの公開草案を公開」 . W3C . マサチューセッツ州ケンブリッジ. 1997年10月3日. 2022年6月22日時点のオリジナルよりアーカイブ。
  3. ^ a b Lash, Alex (1997年10月3日). 「W3C、RDF仕様策定に向けた第一歩」 . CNET News . 2011年6月16日時点のオリジナルよりアーカイブ。 2015年11月28日閲覧
  4. ^ Hammersley, Ben (2005). RSSとAtomを使ったフィード開発. セバストーポル: O'Reilly. pp.  2–3 . ISBN 978-0-596-00881-9
  5. ^ Lassila, Ora; Swick, Ralph R. (1997年10月2日). 「リソース記述フレームワーク(RDF):モデルと構文」 . W3C . 2015年11月24日閲覧
  6. ^ Swick, Ralph (1997年12月11日). 「リソース記述フレームワーク (RDF)」 . W3C . 1998年2月14日時点のオリジナルよりアーカイブ。 2015年11月24日閲覧
  7. ^パワーズ 2003、2ページ。
  8. ^ 「リソース記述フレームワーク(RDF)モデルおよび構文仕様」 1999年2月22日. 2014年5月5日閲覧
  9. ^パワーズ 2003、3ページ。
  10. ^ Manola, Frank; Miller, Eric (2004-02-10), RDF Primer , W3C , 2015-11-21取得
  11. ^ Klyne, Graham; Carroll, Jeremy J. (2004-02-10), Resource Description Framework (RDF): Concepts and Abstract Syntax , W3C , 2015-11-21取得
  12. ^ Beckett, Dave (2004-02-10), RDF/XML 構文仕様 (改訂版) , W3C , 2015-11-21取得
  13. ^ Hayes, Patrick (2014-02-10), RDF Semantics2015年11月21日閲覧
  14. ^ Brickley, Dan; Guha, RV (2004-02-10), RDF語彙記述言語1.0: RDFスキーマ: W3C勧告 2004年2月10日、W3C 、 2015年11月21日取得
  15. ^ Grant, Jan; Beckett, Dave (2004-02-10), RDF Test Cases , W3C , 2015-11-21取得
  16. ^シュライバー、ガス; Raimond、Yves (2014-06-24)、RDF 1.1 Primer、W3C 2015-11-22取得
  17. ^ Cyganiak, Richard; Wood, David; Lanthaler, Markus (2014-02-25), RDF 1.1 Concepts and Abstract Syntax , W3C , 2015-11-22取得
  18. ^ガンドン、ファビアン; Schreiber、Guus (2014-02-25)、RDF 1.1 XML 構文、W3C 、 2015-11-22取得
  19. ^ Hayes, Patrick J.; Patel-Schneider, Peter F. (2014-02-25), RDF 1.1 Semantics , W3C , 2015-11-22取得
  20. ^ Brickley, Dan; Guha, RV (2014-02-25), RDF Schema 1.1 , W3C , 2015-11-22取得
  21. ^ Kellogg, Gregg; Lanthaler, Markus (2014-02-25), RDF 1.1 Test Cases , W3C , 2015-11-22取得
  22. ^ 「RDF語彙記述言語1.0:RDFスキーマ」 . W3C . 2004年2月10日. 2011年1月5日閲覧
  23. ^ 「RDF 1.1 Turtle: Terse RDF Triple Language」 . W3C. 2014年1月9日. 2014年2月22日閲覧
  24. ^ 「RDF 1.1 TriG: RDFデータセット言語」 . W3C. 2014年2月25日. 2022年12月21日閲覧
  25. ^ "application/rdf+xml Media Type Registration" . Ietf Datatracker . IETF. 2004年9月. p. 2. 2011年1月8日閲覧
  26. ^ 「RDF 1.1 Turtle: Terse RDF Triple Language」。W3C。2014年1月9日。
  27. ^ 「RDF 1.1 TriG: RDFデータセット言語」 W3C、2014年2月25日。
  28. ^ 「RDF 1.1 N-Triples: RDFグラフの行ベース構文」 W3C 2014年1月9日。
  29. ^ 「N-Quads: コンテキストによるN-Triplesの拡張」 2012年6月25日. 2013年4月26日時点のオリジナルよりアーカイブ。
  30. ^ 「RDF 1.1 N-Quads」 . W3C . 2014年2月25日.
  31. ^ 「JSON-LD 1.0: リンクデータのためのJSONベースのシリアル化」 W3C。
  32. ^ 「RDF 1.1 XML構文」 W3C 2014年2月25日。
  33. ^ 「RDF 1.1 JSON代替シリアル化(RDF/JSON)」 W3C 2013年11月7日。
  34. ^ 「RDF構文の問題」 Vuk Miličić. 2011年7月21日. 2016年3月8日時点のオリジナルよりアーカイブ。
  35. ^ 「RDF 1.1 概念と抽象構文」。W3C 2014年2月25日。2024年1月14日時点のオリジナルよりアーカイブ。
  36. ^ Klyne, Graham. RDFにおける情報モデリングのコンテキスト」ninebynine.org .
  37. ^ Klyne, Graham (2002年3月13日). 「RDFコンテキスト - 出所と部分的知識」 . ninebynine.org . 2023年7月29日時点のオリジナルよりアーカイブ。
  38. ^ 「4Suite RDFスコープの概念」Uche Ogbuji . 2008年12月8日時点のオリジナルよりアーカイブ
  39. ^ 「Redland Notes - Contexts」 . Redland RDF Libraries . 2004年. 2023年7月29日時点のオリジナルよりアーカイブ。
  40. ^ 「Named Graphs / Semantic Web Interest Group」 . W3C . 2023年10月1日時点のオリジナルよりアーカイブ。
  41. ^ 「RDFクエリ言語(RQL)」 . ICS-FORTH RDFSuite . ICS-FORTH. 2016年3月5日時点のオリジナルよりアーカイブ。 2011年3月29日閲覧
  42. ^ Knublauch, Holger; Allemang, Dean; Steyskal, Simon 編 (2017年6月8日). 「SHACL の高度な機能」 . W3C . RDF Data Shapes Working Group (2017年6月8日公開) . 2021年4月6日閲覧
  43. ^ 「SHACL 高度な機能 1.1」 。 2025年3月11日閲覧
  44. ^ [1] SHACL仕様
  45. ^ [2] SPINウェブサイト
  46. ^ [3] SHACLとSPINの比較
  47. ^ [4] ShEx仕様
  48. ^ a b「RDF入門」 . W3C . 2009年3月13日閲覧
  49. ^ DCMIメタデータ用語の代替。Dublincore.org。2022年1月10日閲覧。
  50. ^ 「Haystack Group @ MIT CSAIL」 . groups.csail.mit.edu .
  51. ^ 「IDEAS Group」 . www.ideasgroup.org . 2018年12月16日時点のオリジナルよりアーカイブ2007年8月30日閲覧。
  52. ^接続サービス フレームワーク」。microsoft.com
  53. ^ “LinkedBrainz/RDF - MusicBrainz Wiki” . wiki.musicbrainz.org
  54. ^ 「ナレッジグラフ技術コクランのCOVID-19対応にどのように役立っているか」。datalanguage.com
  55. ^ 「SIOCプロジェクト」 . sioc-project.org
  56. ^ Oliver Ian、Honkola Jukka、Ziegler Jurgen (2008). 「動的でローカライズされた空間ベースのセマンティックウェブ」IADIS WWW/Internet 2008. Proceedings、p. 426、IADIS Press、 ISBN 978-972-8924-68-3
  57. ^ 「LV2 コア仕様」 . gitlab.com .
  58. ^ソーシャルネットワークにおける関連性の高い意味的関連性を発見するためのRDFアプローチ(Thushar AK、P. Santhi Thilagam著)
  59. ^セマンティックウェブ上のファジーオントロジーとRDFに基づく交通情報検索 Jun Zhai、Yi Yu、Yiduo Liang、Jiatao Jiang (2008)

出典

さらに読む

  • W3CのRDF:仕様、ガイド、リソース
  • RDFセマンティクス:RDFとRDFSの両方におけるセマンティクスの仕様と推論規則の完全なシステム