DEIM Forum 2014 E4-5

オントロジーを利用した LBSN 基盤フレームワークの設計
稲葉 鉄平†

簗井 美咲†

高橋 正和†

石川 佳治†,††† 名古屋大学 大学院情報科学研究科†† 国立情報学研究所
E-mail: †{inaba,yanai,takahashi,ishikawa}@db.ss.is.nagoya-u.ac.jp
あらまし

位置情報を利用した SNS(Location Based Social Network, LBSN) が次々と登場し，GPS 付きデバイスの普及とともに多くのユーザを獲得している．本稿では，LBSN アプリケーションの開発支援とアプリケーションの表
現力の向上を目的とした LBSN 基盤フレームワークを提案する．本研究の特徴は，周辺環境の情報源として Linked

Open Data を想定し，オントロジーを利用した意味的な処理を行うところにある．本稿では特に，RDF ストリーム
記述の仕様，地理空間・時間の位相幾何関係の表現のための SPARQL の拡張について詳しく述べる．
キーワード

オントロジー, Linked Open Data, LBSN, イベント処理
ムでも処理対象のデータを RDF 記述するものとし，Semantic

1. は じ め に

Web 技術を利用した意味的処理により，有益なサービスの記述

スマートフォンなどの GPS 機能を持つデバイスの普及によを可能にする．

り，位置情報を利用した SNS (Location Based Social Network,

もうひとつの特徴は，複合イベント処理 (Complex Event

LBSN) [5] が流行している．代表的な LBSN には，自分が訪れProcessing, CEP) [6] の考え方を取り入れることである．これた施設をチェックインという形で周知する FourSquare （ 1） やは，データストリームからより高次のイベントを検出しよう（ 2）

施設に対するレビューを投稿・閲覧できる Yelpなどがある．

とする処理のことを指す．本システムでは，周辺環境の情報の2009 年 3 月に登場した FourSquare は 4500 万人以上（2014 年

変化やユーザのインタラクションよってシステム内で発生する

1 月），2004 年に登場した Yelp は 1 億 1700 万人以上（2013データストリームをイベント単位で扱うものとし，イベントを

年 10 月）のユーザを獲得しており，このようなサービスから

RDF で記述するためのルール，イベントに対する意味的な処の情報を参照した上での行動決定が一般的になりつつある．

理のためのオントロジーを提供し，それらを利用した問合せ機

既存の LBSN の開発は，それぞれが独立して行われている

構を実現する．

場合がほとんどである．そこで，本研究ではさまざまな LBSN

本研究において実現を目指しているシステムは，LOD やの共通基盤機能を提供する LBSN ツールキットの開発を大きSemantic Web 技術を利用可能な，複合イベント処理のためのな目的とし，LBSN に共通する要素を整理し，共通基盤とな

LBSN ツールキットである．そのツールキットの実現のためにる LBSN システムアーキテクチャを開発する．システム内で管は，Semantic Web とその周辺の既存技術を拡張する必要があ

理される情報には，ソーシャルな情報以外にも周辺施設の待ちる．本稿では，ソーシャルな情報，時空間データ，イベントス

時間の案内やタイムセールといった時間依存のイベント情報なトリームをどのように RDF で扱うのか，また，それらを処理ども含んでおり，ソフトウェアエンジニアは，このツールキッ

するために，RDF 問合せ言語である SPARQL をどのようにトにアプリケーションに依存の処理を載せることによりアプリ拡張するのかについて議論する．

ケーションが構築が可能になるという想定である．
提 案 す る フ レ ー ム ワ ー ク の 特 徴 は ，Linked Open Data

2. 関 連 研 究(LOD) [11], [12] を積極的に活用して行く点である．LOD は，

2. 1 セマンティックな地理空間情報を扱うシステム

決められたルールを満たした標準的なフォーマットで記述され，本研究の類似研究として Semantic GeoStreaming Toolkit

誰もがアクセス可能なデータのことを指す．LOD のデータ量(SGST) [10] がある．これは RDF 形式の地理データストリーは増加傾向にあり，今後の様々な情報の公開が期待される．そムの管理，問合せ，情報統合のためのツールキットである．地

こで，本システムでは，LBSN サービスの実現のために必要な理空間の問合せに GeoSPARQL [3] を利用している．

周辺環境の情報や知識情報を LOD から取得する．

Geo-Store [9] は，Location-Based Service (LBS) のための

LOD はもともと Semantic Web 関連のコミュニティに端を発

RDF トリプルストアである．ヒルベルト曲線を利用した地理する言葉であり，RDF 形式で記述されることが多い．本システ

空間インデックスを用いて，地理空間的な範囲問合せ，k-最近
傍問合せを実現している．問合せ言語は独自に SPARQL を拡（ 1）：https://foursquare.com/

張したものを使用しているが，GeoSPARQL や stSPARQL [8]（ 2）：http://www.yelp.com/

を実装する計画があることが言及されている．

上述したシステムは，地理空間情報を扱うアプリケーション

スを考慮した問合せ方式が必要である．EP-SPARQL [1] は，やサービスのために，RDF ベースの地理空間情報に対する処理

SPARQL にいくつかの句と関数を追加し，RDF ストリームのを実現している．そこでの意味的な処理のためには，SPARQL

時間的なセマンティクスを問い合わせる方法の提案である．

などの問合せ言語を利用して，ユーザーが RDF に対するパター

上記，C-SPARQL や EP-SPARQL で想定する RDF スト

ン照合を明示的に記述する必要がある．それに対して，本研究

リームは RDF の基本構成である h 主語, 述語, 目的語 i にタイでは，オントロジーを利用して，アプリケーション固有のイベ

ムスタンプを付与した形式となっており，RDF の枠組みの外ント知識をモデリングすることが可能であり，ユーザが RDF

側でタイムスタンプを表現している．

パターンを記述するのではなく，イベントそのものを記述する

一方で，RDF の枠組みの中で時間情報を記述するための仕組みの構築を目指している．本稿においては，SPARQL の概念体系の提案が W3C の Time Ontology [7] によってなされ拡張と RDF のマッチングについて述べているが，今後の研究ている．ここでは，時間的実体を瞬間 (instant) と時間間隔において，オントロジーの記述を RDF パターン照合処理に落(interval) にわけて記述できるほか，持続期間 (duration) をとし込む仕組みを検討する．

記述できる．さらに，時間のセマンティクスを表現するための2. 2 地理空間データの RDF 表現と問合せ述語を提供している．しかし，時間データに対する SPARQL

Semantic Web 技 術 を 地 理 空 間 デ ー タ に 対 し て 拡 張 し（ 3）た 例 と し て Open Geospatial Consortium(OGC)

によるの拡張，RDF ストア上での推論や問合せの実装は行われていない．

GeoSPARQL [3] が あ る ．GeoSPARQL は ，OGC が 定 め た

RDF の特性を生かすためには，時間的情報も RDF の枠組み

Well-known-Text(WKT) や GML を地理空間のデータモデの中で表現されるべきであり，本システムでは Time Ontology

ルとして使用するとともに，地理空間情報を表現するための軽を用いてイベントなどの時間的実体とそれらの間に成り立つ関度なオントロジーも提供している．さらに「含んでいる (Con-係を記述するものとする．その際に，Time Ontology は，2006

tains)」，「交わっている (Intersects)」といった地理空間的実体

年の時点で Working Draft となりそれ以降更新されていない間の位相幾何関係を推論し，問い合わせるために SPARQL をことに注意しなければならない．

拡張している．Parliament（ 4） などの一部のトリプルストアでは，GeoSPARQL の機能が実装されている．
本研究で提案するシステムにおいても，地理空間データ表現と問合せに GeoSPARQL を用いる．
同様の提案として stRDF と stSPARQL [8] がある．こちら
も WKT や GML を利用し，地理空間の位相幾何関係を推論可

3. システムの設計
本研究で構築を目指しているシステムの全体像を図 1 に示す．
この図では主に基盤フレームワークが提供する部分 (オレンジ)とソフトウェアエンジニアがアプリケーションごとに記述する
部分 (青緑) に分かれている．

能な問合せの仕組みを提供しているが，オントロジーによる概念体系の作り方が GeoSPARQL と若干異なっている．

2. 3 RDF ストリームに対する問合せ
LBSN のシステム上で発生するイベントや周辺環境から発せられるセンサデータは，時々刻々と変化するストリームデータ
である．SPARQL は静的データに対する問合せを想定しており，ストリームデータに対して待ち構えたり，定期的に問合せをする機能は標準化されていない．
そのような連続的問合せのための SPARQL の拡張として提案されたのが C-SPARQL [2] である．C-SPARQL では，RDF
ストリームに対して時間窓を指定して問い合わせるための新し

図 1 システムのアーキテクチャ

い句を SPARQL に追加している．さらに，問合せ結果を RDF
ストリームに整形する機能も有する．実装については言及されていない．
本研究では，LBSN 上での連続的問合せに，C-SPARQL の機能を導入する．

2. 4 時間データの RDF 表現と時間のセマンティクスに対する問合せ

入力データは，周辺環境やモバイル端末からのデータスト
リームであり，RDF の形式でないストリームについてはアプ
リケーションエンジニアによって作成されたデータストリーム
ラッパで RDF に変換されてシステム内に入力される．

LBSN コアシステムは，LBSN システムの核となる機能を提供するもので，各種データへのアクセスと管理，および，与えLBSN 上で時間軸上の実体に対する意味的な処理を実現すられた問合せの処理機能や，LBSN に関するデータの汎用的なるためには，時間的な前後関係など，時間的なセマンティク

分析機能を実現する．アクセス対象となるデータは，ローカルに存在する RDF ストア，GIS，リレーショナルデータベース（ 3）：http://www.opengeospatial.org/（ 4）：http://parliament.semwebcentral.org/

だけでなく，外部の Linked Open Data やその他の情報源にも存在する．

CEP エンジンでは，入力データが処理され，複合イベント

す．SBPolygon は WKT 形式で経度・緯度のリストとして記の発見が行われる．CEP クエリは，SPARQL ベースの言語

述された地理的な多角形データを持つ Geometry のインスタンで記述された連続的クエリである．これは，CEP マネジャに，スである．

SPARQL より抽象的な記述法で書かれた複合イベント仕様を与えることで生成されたクエリである．

図 3 は，Show Base で開催されるショーを表しており，ShowAが Interval1 という期間において開催されることを表している．

LBSN アプリケーションモジュールは，アプリケーション固Interval1 は，２つの Instant によって実体化されており，In-有の処理を実現するモジュールであり，本ツールキットが提供

terval1 が 2013 年 12 月 5 日 11 時 10 分に始まり，2013 年 12

する API を用いて，アプリケーション個別に実装される．

月 5 日 11 時 30 分に終わることを示している．

本システムの特徴は，データ処理時にオントロジーを参照している点である．オントロジーは，LBSN の共通の知識についてまとめた LBSN オントロジーと，エンジニアがアプリケー
ションごとに構築するアプリケーションオントロジーに大別される．

4. オントロジーに基づく LBSN 上の概念の記述

Show_Base a tdl:Theatre;
geo:hasGeometry SBPolygon.
SBPolygon a geo:Polygon;
geo:asWKT "POLYGON((139.8779 35.6333,
139.8781 35.6332,139.8781
35.6329,139.8779 35.6329,
139.8779 35.6333))"^^sf:wktLiteral.
図 2 シアターを表す RDF

4. 1 オントロジーの設計方針
LBSN 上には，「あるユーザ p が時刻 t に座標 (x, y) に 存在した」というイベントのように，どのようなサービスでも必ShowA a tdl:Show;
tdl:hasPlace Show_Base;
tdl:hasInterval Interval1.

要となる概念がある．このような共通な概念については，上述の LBSN オントロジー内でモデリングして提供する．LBSN
オントロジーは，このようなイベントについて概念体系（イベントオントロジー）に加えて，人と人との関係を記述するための FOAF [4]，時間的な概念を記述するための Time Ontology，

GeoSPARQL で使用されている地理空間オントロジーなど既存の語彙も構成要素となる．

Interval1 a time:Interval;
time:hasBeginning InstBegin1;
time:hasEnd InstEnd1;
InstBegin1 a time:Instant;time:inXSDDateTime "2013-12-05T11:10"^^xsd:dateTime .
InstEnd1 a time:Instant;time:inXSDDateTime "2013-12-05T11:130"^^xsd:dateTime .

一方で，特定の対象ドメインに固有の概念も存在する．たとえば，災害避難に関する LBSN を考えた場合，救助活動に関するイベントや災害の種類についての知識体系が必要である．このようなドメイン依存の知識は，上述のアプリケ−ションオン
トロジー内でモデリングする．モデリングには，LBSN オント
ロジーの既存概念を特殊化していく方法と，新しい概念体系を構築する方法がある．例えば，「避難所」などは LBSN オントロ
ジー上で定義された「地理的オブジェクト」を特殊化して定義するのに対し，「災害」そのものについての知識の定義のためには，新しい概念体系を構築する必要がある．LBSN アプリケー
ション構築時には，2 種類のオントロジーを統合して利用する．

4. 2 処理対象となる RDF の例
ここからは，これまでに述べた方針に基づいて，アミューズメ
ントパークの案内アプリで処理される RDF の例を示す．以下で例示する RDF 内で用いる接頭辞について，foaf は FOAF，geo
は GeoSPARQL 用のオントロジー，time は Time Ontologyで定義された概念であることを示し，lbsn は LBSN オントロ
ジーで独自定義した概念，tdl はアプリケーションオントロジー

図 3 ショーを表す RDF

4. 2. 2 イベントストリーム
次にイベントストリームの例を紹介する．本システムでは，
イベントストリームは，瞬間的イベントのストリームと見なして扱う．イベントオントロジーで定義される「瞬間的イベント(Instant Event) 」とは，時区間上の点として表されるイベン
トである．これは，Time Ontology の「Instant（瞬間）」という概念を利用して実体化される．図 4 は，本フレームワーク
で扱うイベントストリームのイメージである．各ストリームにURI が与えられており，LBSN アプリケーションエンジニアによる情報源の識別に利用される．タイムスタンプは，それぞれのイベントにひとつずつ付与されている．このタイムスタンプ
は，瞬間的イベントが RDF の枠組み内で保持している Instantと同じ時刻を指し示しており，連続的クエリの時間窓の処理な
ど，RDF のマッチングの外側にあるシステム的な処理に利用される．
h http://www.lbsn.com/sample.trdf iで定義された概念であることを示す．接頭辞がないものは，イInstant Event

Timestamp

ンスタンスであることを示している．

Instant Event 1

τ1

4. 2. 1 静的なデータ

Instant Event 2

τ2

図 2 は，アミューズメントパーク内のイベントスペースを示

Instant Event 3

τ3

Instant Event 4

τ4

…

…

す RDF である．このデータは，3 つのインスタンスから構成される．Show Base がイベントスペースそのものを表すインス
タンスで，地理空間として SBPolygon を持っていることを表

図 4 瞬間的イベントのストリーム

ストリームの形で扱うイベントの例として「lbsn:Exists」が上記のような CEP 問合せは，より高次なレベルで記述されある．これは，GPS などのセンサデータに基づく瞬間的イベン

た複合イベント仕様を CEP マネジャに与えることで自動的にトで，ある時刻 (Instant) において，あるユーザ (Person) がコンパイル生成される仕組みを想定しており，その方式を今後ある地点 (Point) に存在することを表す．図 5 は，2013 年 12の研究で検討していく．

月 5 日 11 時 15 分に User178 が座標 (139.87795 35.63307) に存在していることを表している．
Exists1115 a lbsn:Exists;
lbsn:hasGeometry ExPoint1115;
lbsn:hasInstant ExInst1115;
lbsn:hasEnactor User178.
ExPoint1115 a geo:Point;
geo:asWKT "POINT(139.87795

6. 実 装 の 例
ここでは，LBSN サービスとして千葉県内にあるアミューズ
メントパークの案内アプリケーションを想定し，図 6 に示した問合せがどのように実装されるかについて述べる．図 7 に，ここで述べる実装の全体像を示した．情報源として，イベントス
トリームが 1 つ，RDF トリプルストアが２つ存在している．イ

35.63307)"^^sf:wktLiteral .

ベントストリームは，ユーザの存在イベント (lbsn:Exists) のExInst1115 a time:Instant ;time:inXSDDateTime "2013-12-05T11:15"^^xsd:dateTime .

ストリームである．トリプルストアは，人物の友人関係などが図 5 2013-12-05T11:15 における User178 の位置

設の情報やイベントのスケジュールなどが格納されている RDF

5. CEP 問合せのための SPARQL の拡張
CEP マネジャに登録されている CEP クエリは，イベントス
トリームや静的なデータに対する問合せを RDF のマッチングで行う．そこで，本システムでは，RDF のための問合せ言語
である SPARQL を拡張して CEP クエリに利用する．

格納されている RDF ストア 1 とアミューズメントパークの施
ストア 2 の 2 つである．前者は Java で RDF を扱うためのラ
イブラリである Jena（ 5）の機能を利用してメモリ展開で実装されている．後者については，GeoSPARQL を実行可能なトリプ
ルストアである必要があるため，Parliament を選択した．複数個のトリプルストアを用意した理由は，LOD の利用を想定しているためである．

必要な拡張は，地理空間の位相関係および時間のセマンティ
クスに対する問合せ機能と，RDF ストリームに対する連続的問合せの機能である．
図 6 は，過去 45 分の間に友人が見たショーの一覧を返す問合せである．ここでは，ショーの開催期間中にショーが行われる
建物の内側に存在しているかどうかを判断することで，ショーを見たユーザを発見している．ユーザの位置情報は FROMSTREAM 句を用いて，イベントストリームから取得する．
RANGE 45min は，過去 45 分のデータを対象とする時間窓(window) の指定である．これは，C-SPARQL の機能である．
また，同様の C-SPARQL の機能で，REGISTER QUERY 句があり，これは 5 分ごとに問合せを実行することを示している．建物に入っているかどうかという判断は GeoSPARQL の「sfWithin」という述語で，存在イベントが開催期間中かどう

図 7 サンプル実装におけるアーキテクチャ

かという判断は Time Ontology の「inside」という述語で行っ

図 7 の中央には，ユーザによって記述された CEP 問合せがている．これらの述語で表される関係は，CEP エンジンまたある．問合せはその処理対象に応じて複数個に分解される．こは RDF リポジトリの推論機能によって実装される．

の章では図 6 に示した「過去 45 分以内に友人が観覧したショーの一覧」を 5 分ごとに問い合わせる例の実装について述べる．

1:REGISTER QUERY FriendsWatchedShow COMPUTE EVERY 5min AS
2:SELECT ?friend ?show
3:FROM STREAM <http://lbsn.com/exists.trdf>[RANGE 45min]
4:WHERE{
5:?friend foaf:knows ME.
6:?exsists a lbsn:Exists.
7:?exsists lbsn:hasEnactor ?friend.
8:?exsists lbsn:hasInstant ?einst.
9:?exsists geo:hasGeometry ?egeo.
10:?show a tdl:Show.
11:?show tdl:hasPlace ?place.
12:?show tdl:hasInterval ?sinter.
13:?place geo:hasGeomerty ?sgeo
14:?egeo geo:sfWithin ?sgeo.
15:?einst time:inside ?sinter.
16:}
図 6 過去 45 分以内に友人が観覧したショーの一覧の問合せ

この問合せには，ユーザの位置情報を利用するので，3 行目の FROM STREAM 句で Exists イベントのストリームを指定している．そのストリーム中の RDF に対するマッチングは

WHERE 句内の 6〜9 行目である．一方，5 行目は，自分と友人関係かどうかのマッチングであるが，これは人物情報が格納されている「RDF ストア 1」に問合せをしなければならない．
さらに 10〜15 行目は，アミューズメントパークに関する地理空間的実体，時間的実体に対するマッチングなので「RDF ス
トア 2」に問い合わせる必要がある．

（ 5）：http://jena.apache.org/

6. 1 各データの説明
ここでは，図 7 中の各データソースがどのような情報を保持しているのかについて簡単に説明する．
まず，中央下段の RDF ストア 2 には，アミューズメントパー
クの情報がストアされている．
建物の Geometry 情報は，Open Street Map (OSM)（ 6） から取得する．OSM では，Web ブラウザで指定した範囲内の地図
データを独自形式の XML ファイルとしてダウンロードすることが可能である．独自に作成した専用の XMLParser を用いて，OSM から入手できる XML を図 2 のような WKT 形式の地理情報を持つ RDF に変換する．
ショーのスケージュールなど，アミューズメントパークについてのその他の情報は，公式 Web サイトやファンサイトに掲載されている情報に基づいて手書きで RDF を作成する．
右上の RDF ストア 1 は，人物の情報が格納された RDF である．FOAF の語彙を用いて，ユーザの情報や，友人関係がストアされている．
イベントストリームについては，図 4 に示したようなイベン
トとタイムスタンプをひとつの組とする XML データとする．
図 7 中の左にあるイベントストリーム 1 は，全てのユーザによって発生させられた「lbsn:Exists」のストリームである．
（ 7）

Google Map

上で線のデータを作成し，xml 形式でダウンロードしたものを手書きで RDF に変換することによって用意する．

6. 2 問合せの実行システムに登録された CEP 問合せは，対象データの所在に応じて，いくつかの部分に分解されて，コンパイルされる．図6 では，Exists イベントストリームを対象とする部分，人物の情報について問い合わせる部分，アミューズメントパークの静的な情報について問合せる部分の 3 つである．本節では，それらがどのように処理されるのかを述べる．
まず，1 行目の REGISTER QUERY の記述から，この問合せは 5 分ごとに実行されるようにプログラムされる．
次に，3 行目の FROM STREAM 句に関連するマッチングを行う部分が Window（時間窓）問合せに変換され，イベントス
リーム 1 を監視する．本論文で紹介する例において，時間窓は，Jena のグラフ機能を利用して再現している．必要なデータをメルとマッチする述語と目的語を記述することになる．
1:PREFIX lbsn: <http://www.lbsn.com/>
2:PREFIX time: <http://www.w3.org/2006/time#>
3:
4:DELETE{
5: ?event** .
6: ?geo** .
7: ?inst** .
8:}
9:WHERE{
10: ?event a lbsn:Exisits.
11: ?event lbsn:hasPoint ?geo.
12: ?event lbsn:hasInstant ?inst.
13: ?inst a time:Instant.
14: ?inst time:inXSDDateTime ?xsd.
15: FILTER( ?xsd < VTIME)
16:}
図 8 必要なくなったイベントを削除する問合せ

この実装例では，情報源が複数存在している．そのため，各情報源ごとに複数の SPARQL を実行することで，全体の CEP
問合せを実現する．人物の情報を問い合わせる部分は，図 9の SPARQL 問合せに変換される．Exists イベントストリー
ムの時間窓から，友人が行為者である Exists イベントの時刻(Instant) の xsd:dateTime 表現と，場所 (Geometry) の WKT
表現を返す問合せは，図 10 となる．ここで，FRIEND は，図9 で取り出した友人を表す．アミューズメントパークの情報を問い合わせる部分は，図 11 の SPARQL 問合せに変換される．
ここで，GEOWKT，INSTXSD は，それぞれ，図 10 で取り出した場所と時刻を表す．場所については，GeoSPARQL で用意されたプロパティ関数を利用して，「Within（内部にある）」
かどうかを判断している．また，時刻については，Instant（瞬間）が Interval（時間間隔）の内側にあるかどうかを判断する「inside」という独自の関数で仮の表現としている．連続的クエリが実行されるたびにそれぞれが対象の RDF ストアに問合せを行い，プログラム内でその情報を連携させる．
1:PREFIX foaf: <http://xmlns.com/foaf/0.1/>
2:
3:SELECT ?friend
4:WHERE{
5: ?friend foaf:knows ME
6:}
図 9 自分の友人を返す問合せ

モリ上の RDF グラフに挿入し，必要なくなった時点で削除す
る．具体的には，前回の問合せ実行時刻以降に発生したイベン
トの RDF は，グラフにそのまま挿入し，図 8 の DELETE オ
ペレーションによってグラフから不必要なデータを削除している．ここで，VTIME はマクロで，現在の時刻から RANGE で指定された時間を引いたもの（図 6 の例では現在時刻の 45 分
前の時刻）を表す．WHERE 句内で，FILTER 関数を利用して，VTIME より前に発生したイベントに対するマッチングを行い，DELETE オペレーションを実行する．図 8，DELETE
句中の*は，ここでは，任意のマッチングを表している．実際にはこのような正規表現は使用できないので，削除するトリプ

1:PREFIX geo: <http://www.opengis.net/ont/geosparql#>
2:PREFIX lbsn: <http://www.lbsn.com/>
3:PREFIX tdl: <http://www.tokyodisneyresort.co.jp/tdl#>
4:PREFIX time: <http://www.w3.org/2006/time#>
5:
6:SELECT ?instxsd ?geowkt
7:WHERE{
8:?exsists a lbsn:Exists.
9:?exsists lbsn:hasEnactor FRIEND.
10:?exsists lbsn:hasInstant ?inst.
11:?inst time:inXSDDateTime ?xsdinst.
12:?exsists geo:hasGeometry ?geo.
13:?geo geo:asWKT ?geowkt.
14:}
図 10 Exists イベントストリームから友人のイベントの時刻と場所を返す問合せ（ 6）：http://www.openstreetmap.org/（ 7）：https://maps.google.co.jp/

1:PREFIX geo: <http://www.opengis.net/ont/geosparql#>
2:PREFIX lbsn: <http://www.lbsn.com/>
3:PREFIX tdl: <http://www.tokyodisneyresort.co.jp/tdl#>
4:PREFIX time: <http://www.w3.org/2006/time#>
5:PREFIX geof: <http://www.opengis.net/def/:function/geosparql/>
6:
7:SELECT ?show
8:WHERE{
9:?show a tdl:Show.
10:?show tdl:hasPlace ?place.
11:?show tdl:hasInterval ?sinter.
12:?place geo:hasGeomerty ?sgeo
13:
FILTER( geof:sfWithin(GEOWKT, ?sgeo) ).
14:
FILTER( inside(INSTXSD, ?sinter) )15:}

7. ま と め
本研究は，複合イベント処理の考え方を取り入れ，LOD を情報源として活用できる LBSN 基盤システムを提案した．本
稿では，そういったシステムが Semantic Web 周辺技術である

RDF やオントロジーを用いて記述できる可能性を示した．
本論文における実装例や Semantic Web 技術の拡張は，最終的に RDF のマッチングによってイベント処理を実現しているが，構想しているツールキットの目標は，オントロジーを利用してイベントの明示的な定義を目指しているところである．イ
ベントをより抽象度の高い記述法によって定義する手法につい

図 11 与えられた時刻と場所で開催されているショーを返す問合せては，我々の研究グループにおいて考察中であり，今後はその図 11 において，「geof:sfWithin 関数」は，Parliament におい

手法の詳細化に取り組む予定である．

て実装されているため，そのまま実行可能である．一方，時間の関係を示した「inside 関数」は，実装されていない．そのため，この行は図 12 のように xsd:dateTime に対する FILTER関数を利用したマッチングに変換されて問い合わせる．Time謝辞研究の経費の一部は科学研究費（25280039）および文部科学
省 COI STREAM による．

Ontology に示されたその他の時間的な関係も xsd:dateTimteに対する FILTER 処理で実装できる．将来的には，Parliament
で地理空間の位相幾何関係の推論のために地理空間インデックスを利用しているのと同じような方法で，RDF ストア内に時間軸のインデックスを構築し，時間的な関係を推論できる機能が実装されることが望ましい．
?sinter time:hasBegnning ?begin.
?sinter time:hasEnd ?end.
?begin time:inXSDDateTime ?beginxsd.
?end
time:inXSDDateTime ?endxsd.
FILTER ( ?endxsd > INSTXSD && ?beginxsd < INSTXSD)
図 12「time:inside」を FILTER 関数によるマッチングへ変換した
結果

最後に，複数の SPARQL による結果をプログラム内で連携させて，問合せ結果を提示する．

6. 3 実装について
本節では，図 6 がどのように実装されるかを示した．実用のためには，このようなコンパイルが自動で行われる仕組みを構築する必要があり，そのために解決すべき課題は，いくつか存在する．まずは，分散したデータベースにおける必要なデー
タの所在の判断とエンティティ一致の問題がある．これらについて本実装では考慮していない．また，今回のような複数の

SPARQL 問合せによる実装の実用化のためには，問合せの順
番の変更や冗長性の削除によって，問合せの最適化を行うことが必要である．一方，SPARQL 1.1（ 9）においては，SERVICE
句で URI を指定することで，ひとつの SPARQL 記述中で複数の情報源にアクセスする方法が標準化されており，それを利用することで複数の SPARQL による実装を回避できる可能性がある．

（ 9）：http://www.w3.org/TR/sparql11-query/文

献[1] D. Anicic, et al. EP-SPARQL: a unified language for event
processing and stream reasoning. In Proceedings of the 20thIntl. Conference on World wide web(WWW’ 11), ACM, pp.
635-655, 2011.
[2] D. F. Barbieri, D. Braga, S. Ceri, E. D. Valle, and M. Grossniklaus. Querying RDF streams with C-SPARQL. ACM
SIGMOD Record, 39(1), pp.20-26, 2010.
[3] R. Battle and D. Kolas. Enabling the geospatial semantic web with Parliament and GeoSPARQL. Semantic Web,
3(4), pp. 355-370, 2012.
[4] D. Brickley and L. Miller. FOAF vocabulary specification
0.98, August 2010. http://xmlns.com/foaf/spec.
[5] C.-Y. Chow, J. Bao, and M. F. Mokbel. Towards locationbased social networking services. In 2nd Intl. Workshop on
Location Based Social Networks (LBSN’ 10), pp. 31-38,
2010.
[6] G. Cugola and A. Margara. Processing flows of information: From data stream to complex event processing. ACM
Computing Surveys, 44(3), 2012.
[7] Jerry R Hobbs and Feng Pan. Time Ontology in OWL. W3C
Working Draft, 27 September 2006. World Wide Web Consortium. http://www.w3.org/ TR/owl-time.
[8] M. Koubarakis and K. Kyzirakos. Modeling and Querying
Metadata in the Semantic Sensor Web: The Model stRDF
and the Query Language stSPARQL. The Semantic Web:
Research and Applications, LNCS 6088, Springer, pp. 425439, 2010.
[9] W.-S. Ku, H. Chen, C.-J. Wang, and C.-M. Liu. Geo-Store:
A framework for supporting semantics-enabled locationbased services. IEEE Internet Computing, 17(2):35-43,
2013.
[10] J. Lee, Y. Liu, and L. Yu. SGST: An open source semantic geostreaming toolkit. In 2nd ACM SIGSPATIAL Intl.
Workshop on GeoStreaming (IWGS’ 11), pp. 17-20, 2011.
[11] 長野, 萩野 (編). 特集:リンクするデータ (Linked Data)-広が り始めたデータのクラウド-. 情報処理, 52(3):282-333, 2011.
[12] 長野, 山口 (編). 特集:Linked Data とオントロジー. 人工知能
学会誌, 27(2):162-206, 2012.