RDF Calendar - an application of the Resource Description Framework to iCalendar Data W3C Interest Group Note 29 September 2005 This version http://www.w3.org/TR/2005/NOTE-rdfcal-20050929/ Latest version http://www.w3.org/TR/rdfcal/ Authors Dan Connolly, W3C Libby Miller, ASemantics Copyright ©2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
28 February 2018 This version: http://rdfs.org/sioc/spec/ Latest version: http://rdfs.org/sioc/spec/ Last update: Date: 2018/02/28 18:02:28 Revision: Revision: 1.36 Editors: Uldis Bojārs - University of Latvia John G. Breslin - Data Science Institute, NUI Galway Authors: Diego Berrueta - Fundación CTIC Dan Brickley - Asemantics S.R.L. Stefan Decker - DERI, NUI Galway Sergio Fernández - Fundación C
FOAFスキーマの改訂がDan Brickleyからアナウンスされていた。主な変更点は、foaf:isPrimaryTopicOfプロパティを追加したことと、OWLツールに対応できるよう、OWL DLに準拠する方向で記述の整備を進めたことだ。 foaf:isPrimaryTopicOfは、既存のfoaf:primaryTopicの反対関係にあたるもの。主語人物を主たるトピックとした文書を示し、IFPとして用いることができる。 (例) <foaf:Person> <foaf:isPrimaryTopicOf rdf:resource="http://www.kanzaki.com/info/webwho.rdf"/> </foaf:Person> 人物を特定するIDとして、これまでのfoaf:mboxやfoaf:homepageに加え、その人のFOAFページも使えるというわけだ(homepa
C.C.ライセンスやウェブログページでは、RDFのメタデータをコメント内に埋め込むという手法がしばしば用いられるわけだが、それなら冗長なXML構文ではなく、Turtleなどを使った方が簡単じゃないかな。ちょうど、はてなのAccount Auto-Discoveryの件もあることだし、少し考えてみよう。 Account Auto-Discoveryの7月28日付の仕様では、次のようなRDF/XMLをコメントとして埋め込む例が示されている。 (例) <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:foaf="http://xmlns.com/foaf/0.1/"> <rdf:Description rdf:abou
naoyaさんのHatena IDのAuto-Discoveryを、トラックバックのそれと同様に埋め込みRDFで実現するとどうなるだろうかと考えてみました。 ⇒ RFC: 続・Hatena ID Auto-Discovery の仕様 僕がしたいのは、はてなダイアリーを含めたインターネット上のウェブページ (Permalink) から、そのページを作った人の「はてなのID」を探し出したい、ということです。 それを実現するのに、DC.creatorのlink要素をもつ案を提案されています。さて、これは妥当な表現なのでしょうか? ゴリゴリのRDF的な考え方で進めてみますと、link要素は、rdf:resourceをもつプロパティに対応しています。つまり、naoyaさんの案をRDFで記述することにするならば、次のようなRDFに対応していると考えられるわけです。 <rdf:RDF xmlns:rdf
Hatena ID Auto-Discoveryの議論が続いています。 http://d.hatena.ne.jp/naoya/20050727/1122428017 http://d.hatena.ne.jp/naoya/20050725/1122277102 http://d.hatena.ne.jp/naoya/20050722/1121993475 個人的には、以前にこの日記に書いたIDトラックバックの話とつながっていく予感もしているので注目しています。 rdfとfoafで <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://xmlns.com/foaf/0.1/"> <rdf:Descri
久しぶりにウェブ上の話題を眺めていたら、目に付いたのがページ作者を特定するのにdc.creatorの値としてURIを使うという話。人にURIを与えるのは構わないけれども、その人の「ホームページ」URIとその人自身のURIを混同しそうな気配が垣間見られるのが、若干気になる。 少し考えれば分かることだけれど、人間を名前づけるURIと、その人間が作ったホームページのURIは当然異なる。だから、普通こんな記述はしない。 (誤解を生む例) <rdf:Description rdf:about="http://www.kanzaki.com/memo/2005/07/23-1"> <dc:creator> <foaf:Person rdf:about="http://www.kanzaki.com/"> <foaf:nick>masaka</foaf:nick> </foaf:Person> </dc
XHTML2 is the next iteration in the HTML family. XHTML1 addressed the problems of turning HTML into an XML application. XHTML2 addresses the remaining identified problems in HTML4/XHTML1 Some remaining problems HTML: a great success, but has become a sort of Garden of Eden, with lots of Thou Shalt Nots in the form of guidelines: Accessibility guidelines Usability guidelines Internationalisation gu
ブログのエントリ配信の質問です。 RSS形式とRDF形式は何がどのように違うのでしょうか? どのような用途にはどっちが便利ですか?
http:スキームのURIは、ウェブサーバーから取得できるリソースであるべきか、それとも任意のリソースを識別する役割を与えて良いのか―W3CのTAGで議論されてきた難題、いわゆるhttpRange-14に、一応の解決策が示された。URIの示すサーバーが返す結果コードによって、URIのリソースを解釈しようというものだ。 httpRange-14は、バーナーズ=リーが2002年にHTTP URIs (without "#") should be understood as referring to documents, not carsとしてTAGに提起した(起源はもっと古い)、URIの適用範囲を巡る問題。RDFでは、URI参照(URI+オプションの#フラグメントID)でリソースを識別するが、「人」や「作者」といったネットワークで取得できないリソースの場合、http:スキームの「URI本体」(
Musical baton vocabularyスキーマには、RDFでモデルを考えるに際して迷ったり勘違いしたりしやすいポイントがいくつか含まれている。概要紹介でも簡単に触れたが、参考までにFAQ的にとりあげてみることにしよう。 MusicalBaton要素にはrdf:aboutでRDF/XMLのURIを与えるべきではないのですか すぐに出てきそうなのが、RDF/XMLでバトンを記述するのなら、それがmb:MusicalBaton型リソースのURIになるのではないかという発想。これは、URIとリソース(およびそのリプレゼンテーション)の関係についての、何度も取り上げられている問題ですね。 よく使われる例としては、《W3Cという組織を表すリソースに、http://www.w3.orgというURIを与えたらどうだ》というものがあります。もちろんこれでは、組織としてのW3Cと、そのホームページが
ミュージカル・バトンをRDFで記述しようとMusical baton vocabularyスキーマを考えていたら、案外、練習問題として面白そうなので、概要をメモしておこう。ポイントは、バトンを表すリソースをどう扱うかと、バトンのやり取りをどうやって表現するかというところかな。基本的には遊びなので、気軽にやればいいんですが。 この手のスキーマを考える時、もっとも手っ取り早いのは、それぞれの「質問」項目を人物のプロパティにしてしまう方法だ。 (例) <foaf:Person> <mb:total_volume_of_music_files_on_my_computer> 242MB </mb:total_volume_of_music_files_on_my_computer> <mb:song_playing_right_now> 川田知子のバイオリンリサイタルのMD </mb:song_p
セマンティック・ウェブのレイヤーケーキ URI, Unicode, XMLを基盤に ウェブの蓄積をベースにグローバルなデータ(OpenWorld)を扱う マシンが読める形でデータや知識を共有 RDFによるシンプルで柔軟なデータ形式 RDFS 、オントロジーによる語彙と知識の記述 推論規則と論理フレームワーク 述語論理、記述論理を用いた推論、高度な検索 検索結果をエージェントが判断してさらに処理を継続 署名と証明と信頼 エージェントがなぜこの処理をしたかの論理的な証明 電子署名と暗号化によるデータの保証 セマンティック・ウェブ応用のいくつかの側面 「セマンティック・ウェブ」とひと括りにするとすれ違いや誤解が… 高度なリソース探索 全文検索 v.s. メタデータによる検索 最も分かりやすいセマンティックウェブのアプリケーション(出発点) 鶏と卵:誰がメタデータを与えるのか(SW利用の動機付け)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く