【注意】 このドキュメントは、W3CのThe RDF Data Cube Vocabulary W3C Recommendation 16 January 2014の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2014年2月16日
公開後に発見されたこのドキュメントの課題のリストである、このドキュメントに対する正誤表を参照してください。
このドキュメントは、規範以外の形式でも入手できます: 前バージョンとの差分
この仕様の英語版が唯一の規範のバージョンです。非規範の翻訳版も入手可能かもしれません。
Copyright © 2012-2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
統計などの多次元のデータを、関係するデータセットと概念にリンクできるような方法でウェブで公開できることが有用な状況がたくさんあります。データ・キューブ語彙は、W3CのRDF(Resource Description Framework)標準を用いて、これを行う手段を提供します。データ・キューブ語彙を支えるモデルは、組織間で統計データとメタデータを交換・共有するためのISO標準であるSDMX(Statistical Data and Metadata eXchange)の基礎となっているキューブ・モデルと互換性があります。データ・キューブ語彙は、統計データ・フローやその他の多次元のデータセットの他の側面を公開可能とするための拡張語彙をサポートするコアとなる基礎です。
このオントロジーのすべての用語の名前空間はhttp://purl.org/linked-data/cube#です。
このドキュメントで定義している語彙は、非規範のフォーマットでも利用できます: Turtle
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。
このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3C の役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
この語彙は、元々W3Cの外部で開発され、公開されましたが、Government Linked Data Working Group内で拡張され、さらに開発されました。
このドキュメントは、Government Linked Data Working Groupによって勧告として公開されました。このドキュメントに関してコメントを行いたい場合には、[email protected](購読、アーカイブ)にお送りください。どのようなコメントでも歓迎します。
ワーキンググループの実装報告書を参照してください。
このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。 不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、 W3C特許方針の6項に従って情報を開示しなければなりません。
クラス: qb:Attachable qb:AttributeProperty qb:CodedProperty qb:ComponentProperty qb:ComponentSet qb:ComponentSpecification qb:DataSet qb:DataStructureDefinition qb:DimensionProperty qb:HierarchicalCodeList qb:MeasureProperty qb:Observation qb:Slice qb:ObservationGroup qb:SliceKey
プロパティー: qb:attribute qb:codeList qb:component qb:componentAttachment qb:componentProperty qb:componentRequired qb:concept qb:dataSet qb:dimension qb:hierarchyRoot qb:measure qb:measureDimension qb:measureType qb:observation qb:observationGroup qb:order qb:parentChildProperty qb:slice qb:sliceKey qb:sliceStructure qb:structure
この項は非規範的です。
統計データは、政策予測、計画や調整の基礎であり、ウェブ上で見られるマッシュアップやビジュアル化の多くを支えています。関連情報とリンクし組み合わせられるように、統計データをウェブに適したフォーマットで公開できることに強い関心が集まっています。
次元のグループでまとめられた統計データセットの中心となるのは、観測値と、関連するメタデータです。データ・キューブ語彙により、このような情報をW3CのRDF(Resource Description Framework)標準を用いて表し、リンクト・データの原則に従って公開できます。語彙は、統計データ交換のためのSDMX ISO標準で用いられるアプローチに基づきます。このキューブ・モデルは非常に一般的であるため、データ・キューブ語彙は、調査データ、スプレッドシート、OLAPデータ・キューブ[OLAP]などのその他のデータセットに使用できます。
データ・キューブ語彙は、ウェブ上の多次元データの公開に純粋に焦点を合わせています。我々は、開発中の一連のモジュール語彙がこのコアとなる基礎を拡張するだろうと予測しています。特に、統計データ(包括的なデータ・フローや関連する提供合意など)に対して付加的なコンテキストを公開できるようにサポートしてくれるSDMXの拡張語彙が必要であることを理解しています。その他の拡張では、調査用メタデータ(DDIに含まれるような、いわゆる「マイクロデータ」)や統計参照メタデータの公開をサポートできます。
データ・キューブは、次の既存のRDF語彙に基づいて構築されます。
リンクト・データは、ウェブでデータを公開するための方法の1つで、共通する概念に対する参照によりデータセットをリンク付けることが可能となります。この方法[LOD]では、データの利用者が、他の関連するURIへのリンクを含む、より多くの情報を得るためにURIを調べることができるように、HTTP URIを用いてエンティティーと概念を指定することが推奨されています。RDF[RDF-PRIMER]は、これらのエンティティーと概念を記述し、URIの逆参照により返される情報を表現するための標準を提供します。
RDFとリンクト・データのアプローチを用いて、統計などの多次元のデータを公開できることには多くの利点があります。
SDMX(The Statistical Data and Metadata Exchange)イニシアティブは、統計の実践においてより大きな効率を実現するために、7つの国際組織(BIS、ECB、Eurostat、IMF、OECD、世界銀行および国連)によって2001年に設立されました。これらの組織は、ほとんどが国家レベルであり、どの組織も、政策をサポートするために大量のデータを収集しています。さらに、国を超えた国際的なレベルでデータを広めています。
この作業から多くの重要な結果が得られました。それらは、技術仕様書-ISO:TS 17369(SDMX)-の2つのバージョンと、クロス・ドメインな統計の構造化と調和のためのいくつかの勧告の公表、SDMXコンテンツ指向ガイドラインです。成果はすべてwww.sdmx.orgで入手できます。標準は現在、集約された統計の収集、交換、処理および普及のために、公的な統計組織により世界中で広く採用されています。国連の統計委員会は、統計のために推奨される標準として、2007年にSDMXを勧告しました。
SDMX仕様は、SDMX-ML(XML構文)とSDMX-EDIという具象形式の2つの構文に反映されているコアな情報モデルを定義しています。
RDFデータ・キューブ語彙は、SDMX 2.0情報モデル[SDMX20]のコアの上に構築されています。
読者にとっては、SDMXユーザ・ガイド[SDMX-GUIDE]が有用な背景となるかもしれません。
SDMX標準パッケージの重要なコンポーネントは、SDMX実装[COG]の間で共有される用語を提供することにより、データセット間の比較可能性と相互運用性をサポートするコンテンツ指向ガイドライン(COG;Content oriented guidelines)、クロス・ドメインの概念の集合、コード・リスト、カテゴリーです。これらの用語のRDFバージョンは、データ・キューブ語彙と一緒に用いるために別途入手できます。詳細は、コンテンツ指向ガイドラインを参照してください。これらの外部資源は、データ・キューブ語彙仕様の規範部分となるものではありません。
このドキュメントは、データ・キューブ語彙を記述したものであり、RDFで統計やその他の多重次元データを公開したい人向けです。SDMX-MLなどの他のフォーマットからのクロス・フォーマットな変換方法については、ここではカバーしていません。
RDFエンティティー(クラス、述語、固体)の名前はURIです。これらは通常、名前がprefix:localname
であるコンパクトな表記法を用いて表され、その場合、prefix
は名前空間URIを識別します。接頭辞で識別される名前空間は、フルのURIを得るためにlocalname
の前に置かれます。
このドキュメントでは、次の名前空間を用います。
すべてのRDFの例は、Turtle構文[turtle]で記述しています。
非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。
この仕様の「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である/要求される(REQUIRED)」、「すべきである/する必要がある(SHOULD)」、「すべきでない/する必要がない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「することができる/してもよい(MAY)」、「選択できる/任意である(OPTIONAL)」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。
次の場合、どれだけ交換が生じたとしても、データ交換はデータ・キューブに準拠しています。
適合データ交換は次のとおりです。
この項は非規範的です。
この項は非規範的です。
DataSetは定義されている構造に対応した統計データの集合です。大ざっぱに言えば、データセット内のデータは、次の種類のうちの1つに属しています。
この項は非規範的です。
統計データ・セットは、ある論理空間内のある点で行われた観測データの集合で構成されます。その集合は、何が計測され(例えば、経済活動、人口)、それがどのように計測され、その観測データがどのように表されるか(例えば、単位、倍率、状況)を記述したメタデータに加え、観測の対象(例えば、時間、エリア、性別)を定義する次元の集合によって特徴付けられます。統計データセットは、それらの次元でインデックス付けされた多次元空間、すなわちハイパー・キューブと見なすことができます。この空間は一般的に、略してキューブと呼ばれます。名前を文字通りに受け取るべきではありませんが、それは、正確に三次元が存在することを示唆するものでも(それ以上も以下もありえる)、次元がすべて何かしら似たサイズであることを示唆するものでもありません。
キューブは、1組の次元(dimension)、属性(attribute)および測度(measure)によって構成されます。これらを集合的にコンポーネントを呼びます。
次元コンポーネントは、観測データを識別する役割を果たします。すべての次元コンポーネントの値の集合は、1つの観測データを識別するのに十分です。次元の例には、観測を適用する時間や観測がカバーする地理的な領域が含まれます。
測度コンポーネントは、観測される現象を表します。
属性コンポーネントは、観測値を限定し、解釈できるようにします。これによって、測度の単位、あらゆるスケーリング係数、観測状況(例えば、推測、暫定)などのメタデータの指定が可能となります。
この項は非規範的です。
データセット内の観測データのサブセットをグループ化することはしばしば有益です。特に、次元のうちの1つ(または、小さなサブセット)を除くすべてを固定し、それらの次元の値のすべての観測データを1つのエンティティーとして参照するために有益です。このような選択をキューブのスライスと呼びます。例えば、領域の業績指標に関するデータセットを与えられた場合、与えられた指標と与えられた領域に関するすべての観測データをグループ化したとします。すると、この個々のグループは、観測値の時系列を表すスライスになるでしょう。
データの公開者は、様々な目的でデータのスライスを識別できます。スライスは、例えば、特定の時間や領域に影響する計測プロセスの変化を記録する際に、メタデータを付与するのに有用なグルーピングでありえます。スライスにより、ユーザに提示すべきデータの特定のサブセットを公開者が識別してラベル付けすることも可能となります - データを利用するアプリケーションで、より容易にプレゼンテーションに適したグラフや図を構築できます。
統計アプリケーションでは、1つの次元が未指定のままスライスを扱うのが一般的です。具体的に言うと、1つの自由な次元が時間であるスライスを時系列といい、時間ではない次元に従ったスライスをセクションといいます。データ・キューブ語彙内では、任意の次元のスライスが可能で、特定の種類のスライスに異なる名前をつけません。このようなサブクラスのスライスは、拡張語彙に追加できます。
この項は非規範的です。
データ・キューブ語彙の使用方法を説明するために、領域(単一自治体(unitary authority))、年齢、時間別の平均寿命を記述したStatsWales報告書No.003311から抜粋した小さなデモンストレーション用データセットを使用します。使用する抜粋は次のとおりです。
2004-2006 | 2005-2007 | 2006-2008 | ||||
男性 | 女性 | 男性 | 女性 | 男性 | 女性 | |
ニューポート | 76.7 | 80.7 | 77.1 | 80.9 | 77.0 | 81.5 |
カーディフ | 78.7 | 83.3 | 78.6 | 83.7 | 78.7 | 83.4 |
モンマスシャー | 76.6 | 81.3 | 76.5 | 81.5 | 76.6 | 81.7 |
マーサーティドビル | 75.5 | 79.1 | 75.5 | 79.4 | 74.9 | 79.6 |
ご覧のように、期間(3年周期の平均)、地域、性別という、3つの次元があります。各観測データは、その人口の平均寿命(測度)を表し、計測値の単位(年)を定義するためには属性が必要です。
データのスライスの例として、時間と性別を固定したスライスを定義してみましょう。そのスライスは、異なる地域(つまり、上の表のレイアウトの列に対応)の平均寿命の違いを示すことになります。
このようなスライス構造を含む、このデータのデータ・キューブとしての完全なエンコーディングを付録Cで示しています。
qb:DataStructureDefinition
は、1つ以上のデータセットの構造を定義します。特に、次元の順序や属性が必須かオプションかなどの限定情報とともに、データセットで用いる次元、属性、測度を定義します。整形式のデータセットの場合、この情報の多くは、観測値のRDFコンポーネント・プロパティー内では明示的ではありません。しかし、構造の明示的な宣言には、次のようないくつかの利点があります。
統計データの公開時には、すべて同じ構造に従った、一連の定まった公開物を持っていることが一般的です。DSD(Data Structure Definition;データ構造定義)の概念により、その構造を一度定義し、をれを一連の公開物のそれぞれに再利用できます。その結果、利用者は、データの構造が変わっていないことを確信できます。
データ・キューブ語彙は、次元、属性、測度をRDFプロパティーとして表します。それぞれは、抽象的なqb:ComponentProperty
クラスのインスタンスで、順に、qb:DimensionProperty
、qb:AttributeProperty
およびqb:MeasureProperty
というサブクラスを持っています。
コンポーネント・プロパティーは、次のいくつかの情報をカプセル化します。
同じ概念が、異なるコンポーネントに出現可能です。例えば、通貨の概念は、次元として用いる(為替レートを扱うデータセットで)ことも、属性として用いる(観測されたトレードが行われた通貨を記述する場合)こともできます。時間の概念は通常、次元のみとして用いられますが、データ値(例えば、xsd:dateTime
)やシンボル値(例えば、data.gov.ukが開発した参照時間URIから得られたURI)としてもエンコード可能です。統計機関は通常、複数の異なるデータセットに使用できる、コンポーネントを支える統計概念の標準シソーラスを持っています。
この汎用的な統計概念の再利用をサポートするために、データ・キューブ語彙は、qb:ComponentProperty
をそれが表す概念にリンクするqb:concept
プロパティーを提供しています。我々は、そのような概念を表すためにSKOS語彙[SKOS-PRIMER]を用います。これは、概念が統制用語リストやシソーラスとして既に維持されている場合にはとても自然なことです。非公式のデータセットのデータ構造定義を開発する場合は、適切な概念はまだないかもしれません。その場合には、概念が他の形式で再利用できそうであれば、特定のqb:ComponentProperty
と一緒にskos:Concept
を公開することが推奨されます。しかし、そのような再利用が期待できない場合は、その必要はありません - qb:concept
リンクはオプションであり、qb:ComponentProperty
の適切なサブクラスのシンプルなインスタンスで十分です。
コンポーネントの可能な値の表現は、通常のRDFの手法でコンポーネントのrdfs:range
プロパティーを用いて記述します。したがって、例えば、時間次元の値は、xsd:dateTime
という型のリテラルを用いるか、時間参照サービスから得たURIとして表されるでしょう。
統計データセットでは、値は、何らかの(階層形式でありえる)コード・リストを用いてエンコードされるのが普通で、より構造的な形式でコード・リスト全体を容易に識別できると便利でしょう。これに対応するために、qb:codeList
を用いてオプションでコンポーネントにアノテーションを付与し、コードとして使用できるskos:Concept
の集合を示すこともできます。qb:codeList
の値はskos:ConceptScheme
、skos:Collection
またはqb:HierarchicalCodeList
でありえます。そのような場合には、コンポーネントのrdfs:range
は、単なるskos:Concept
のままでもかまいませんが、特定のスキーム内でメンバーがすべてskos:Concept
であるrdfs:Class
を定義する設計パターンも便利です。この方法により、rdfs:range
をより特化でき、汎用的なRDFツールで適切な値域チェックを実行できるようになります。
任意のSDMX拡張語彙には、コンポーネントに関してエンコードすべき情報がもう1つあることに注意してください。それは、コンポーネントが構造定義内で果たす役割です。特に、どれが時間次元なのか、どのコンポーネントが主要な測度なのかなどを利用者が容易に識別できると便利な場合があります。そのような役割が概念にとって本質的なものであることが判明したため、この情報はskos:Concept
のサブクラスを個々の役割に提供することによりエンコーディングできます。ここの役割の特定の選択は、SDMX標準に固有のものであるため、コアのデータ・キューブ語彙には含まれていません。
我々の実行例に必要なコンポーネントについて説明する前に、もう1つ紹介すべき仕組みがあります。それは、再利用可能な概念の集合とSDMXに基づくコンポーネントです。
この項は非規範的です。
SDMX標準には、データセットにまたがる再利用を目的とした共通の統計概念および関連するコード・リストを定義したコンテンツ指向ガイドライン(COG;content oriented guideline)[COG]が含まれています。コミュニティー・グループが、このガイドラインのRDFエンコーディングを開発しました。これらには、次のものが含まれます。
接頭辞 | 名前空間 | 説明 |
---|---|---|
sdmx-concept |
http://purl.org/linked-data/sdmx/2009/concept# | 各COG定義概念に対するSKOS概念 |
sdmx-code |
http://purl.org/linked-data/sdmx/2009/code# | 各COG定義コード・リストに対するSKOS概念および概念スキーム(ConceptSchemes) |
sdmx-dimension |
http://purl.org/linked-data/sdmx/2009/dimension# | 次元として使用できる各COG概念に対応するコンポーネント・プロパティー |
sdmx-attribute |
http://purl.org/linked-data/sdmx/2009/attribute# | 属性として使用できる各COG概念に対応するコンポーネント・プロパティー |
sdmx-measure |
http://purl.org/linked-data/sdmx/2009/measure# | 測度として使用できる各COG概念に対応するコンポーネント・プロパティー |
コミュニティーのこれらの資源は、便宜上提供しているものであり、データ・キューブ仕様の一部を成すものではありません。しかし、それらは多くの既存のデータ・キューブの公開物で利用されているため、我々は作業例においてそれらを参照しています。
この項は非規範的です。
我々のデータセットの例を見てみると、表現している次元が、期間、領域(単一自治体)、性別の3つあることが分かります。データセットのトピック(平均寿命)に相当する(主要な)測度が1つあり、年間の値をエンコードしています。したがって、以下のコンポーネントが必要です。
時間。 これには、SMDX-COGにREF_PERIODという適切な定義済み概念があります。したがって、対応するコンポーネント・プロパティーsdmx-dimension:refPeriod
を再利用できます。しかし、期間自体を表すためには、data.gov.uk参照時間サービスを用いて、データ構造定義内でこれを宣言すると便利でしょう。
eg:refPeriod a rdf:Property, qb:DimensionProperty; rdfs:label "reference period"@en; rdfs:subPropertyOf sdmx-dimension:refPeriod; rdfs:range interval:Interval; qb:concept sdmx-concept:refPeriod .
領域。この場合も、これに使用できる適切なCOG概念と関連コンポーネントがあり、再び、コンポーネントの値域をカスタマイズできます。この場合、Ordnance Survey Administrative Geography Ontology[OS-GEO]を使用できます。
eg:refArea a rdf:Property, qb:DimensionProperty; rdfs:label "reference area"@en; rdfs:subPropertyOf sdmx-dimension:refArea; rdfs:range admingeo:UnitaryAuthority; qb:concept sdmx-concept:refArea .
性別。この場合、デフォルトのコード・リストには必要な用語が含まれているため、対応するCOGコンポーネントsdmx-dimension:sex
を直接使用できます。
測度。このプロパティーは、個々の観測データの値を示します。これには、デフォルトのsmdx-measure:obsValue
を使用できます(メタデータを用いて観測されたトピックを定義)。しかし、観測された現象に対応する特定の測度を用いると、RDFデータセットの読みやすさと処理が向上します。
eg:lifeExpectancy a rdf:Property, qb:MeasureProperty; rdfs:label "life expectancy"@en; rdfs:subPropertyOf sdmx-measure:obsValue; rdfs:range xsd:decimal .
単位測度属性。主要な測度自体はプレーンな十進の値です。この値を正しく解釈するためには、それがどんな単位で計測されたのか(この場合は、年)を定義する必要があります。これは観測値の解釈を限定する属性を用いて定義します。具体的には、この例では、UNIT_MEASURE
の概念に相当する定義済みのsdmx-attribute:unitMeasure
を使用できます。一般的に、この属性の値を表すためには、測度の単位の共通シソーラスを用います。このシンプルな例では、「Years」に関するウィキペディア・ページのトピックに相当するDBpedia資源http://dbpedia.org/resource/Year
を用います。
これは、このデータセットの構造定義に必要な最小のコンポーネントをカバーします。
コンポーネントをこのデータセットの構造の仕様へと結合させるためには、qb:ComponentSpecification
資源の集合を参照するqb:DataStructureDefinition
資源を宣言する必要があります。qb:DataStructureDefinition
は同じ構造を持つ他のデータセットにも再利用できます。
最もシンプルなケースでは、qb:ComponentSpecification
は対応するqb:ComponentProperty
(通常、qb:dimension
、qb:measure
、qb:attribute
のサブプロパティーのうちの1つを用いて)を参照するだけです。しかし、いくつかの方法でコンポーネント仕様を限定することもできます。
qb:componentRequired
に設定すべきです。そのような宣言がなければ、属性はオプションであると仮定されます。qb:componentRequired
宣言は、属性のコンポーネント仕様にのみ適用でき、測度と次元は常に必須です。qb:order
に整数値を付与することにより順序付けできます。この順序にはセマンティクスはありませんが、データを利用するエージェントが適切なユーザ・インターフェースを生成するのに役立ちえます。公開連鎖において、観測データに対して適切なURIを合成可能にするのにも役立ちます。qb:componentAttachment
プロパティーは、付与レベルに対応したクラスを参照すべきです(例えば、データセット全体に付与する属性に対してはqb:DataSet
)。そのような付与レベルとして使用できるクラスは、すべてqb:Attachable
のサブクラスです。我々の実行例では、次元は有効に順序付けできます。属性は、単位測度という1つだけが存在しており、これは必須です。語彙の使用法を説明するために、この属性がデータセットのレベルで付与されていると宣言しますが、一般的に、正規表現のほうがクエリや結合が容易です。
したがって、我々の例のデータセット(そして、その他の同様のデータセット)の構造は、次のように宣言できます。
eg:dsd-le a qb:DataStructureDefinition; # The dimensions qb:component [ qb:dimension eg:refArea; qb:order 1 ]; qb:component [ qb:dimension eg:refPeriod; qb:order 2 ]; qb:component [ qb:dimension sdmx-dimension:sex; qb:order 3 ]; # The measure(s) qb:component [ qb:measure eg:lifeExpectancy]; # The attributes qb:component [ qb:attribute sdmx-attribute:unitMeasure; qb:componentRequired "true"^^xsd:boolean; qb:componentAttachment qb:DataSet; ] .
同じ構造を持つ異なるデータセットで再利用されるため、データ構造定義(DSD)にURIを付与したことに注意してください。同様に、コンポーネント・プロパティー自体も、異なるDSDで再利用できます。しかし、コンポーネントの仕様は、特定のDSDの範囲内でのみ有効であるため、空白ノードを用いてそれを表すことにしました。
我々のデータセットの例は、計測対象の観測値が1つ(この場合「平均寿命」)であるという点で比較的シンプルです。他のデータセットでは、複数の測度がありえます。これらの測度は、同様の性質(例えば、地方自治体の実績に関するデータセットは、地域ごとに複数の異なる実績指数を提供するかもしれない)を持っていることも、または全く異なる(例えば、トレードに関するデータセットは、トレードごとに量、値、重量を提供するかもしれない)こともありえます。
データ・キューブ語彙がサポートする複数の測度を表す方法は2つあります。
最初の方法では、個々の観測データは、1つの測度に対し1つの観測値を記録します。我々は、各観測データが伝える測度を示す値を持つ追加の次元を導入します。この測度次元という方法は、SDMX情報モデルがサポートしているものです。
2番目の方法では、1つの観測データは、複数の異なる測度に対して値を提供できます。これは、マルチスペクトル・センサ計測のように、複数の値がそれぞれ1つの観測イベントに関連付けられている場合に特に適しています。この複数測度という方法は、ビジネス・インテリジェンスやOLAPなどのアプリケーションでよく用いられます。
データ・キューブ語彙では、同じデータセット内でこれらの方法を混ぜて用いることはできませんが、どちらの表現方法を用いてもかまいません。
両方の表現方法は、観測値が存在する次元の空間のあらゆるポイントで、値がすべての測度に付与されていなければなりません。複数測度観測データの場合には、個々の観測データに個々の測度がなければなりません。測度次元を用いるキューブでは、キューブ内の密度の高いポイントごとに観測データの集合があり、それらの個々の集合内には、各測度が付与された観測データがなければなりません。
この方法により、個々の観測データに複数の観測値を付与できます。これはセンサ・データやOLAPキューブなどの表現に適しています。この表現を用いるためには、データ構造定義に複数のqb:MeasureProperty
コンポーネントを宣言し、各プロパティーのインスタンスをデータセット内の観測データに付与すればよいだけです。
例えば、出荷ごとのユニット数と総重量を含む出荷データの集合があれば、次のようなデータ構造定義になりえます。
eg:dsd1 a qb:DataStructureDefinition; rdfs:comment "shipments by time (multiple measures approach)"@en; qb:component [ qb:dimension sdmx-dimension:refTime; ], [ qb:measure eg-measure:quantity; ], [ qb:measure eg-measure:weight; ] .
これは、次のような個々の観測データに相当するでしょう。
eg:dataset1 a qb:DataSet; qb:structure eg:dsd1 . eg:obs1a a qb:Observation; qb:dataSet eg:dataset1; sdmx-dimension:refTime "2010-07-30"^^xsd:date; eg-measure:weight 1.3 ; eg-measure:quantity 42 ; .
複数測度のアプローチの1つの限界は、単一の観測値に属性を付与できないということであることに注意してください。観測データのインスタンスに付与される属性は、観測全体(例えば、誰が観測をしたかを示すなど)に適用されます。属性は、qb:MeasureProperty
自体に直接付与することもできます(例えば、その測度に対する測度単位を示すなど)が、その付与はデータセット全体(実際に、その測度プロパティーを用いるあらゆるデータセット)に適用され、観測ごとに異なるものであることができません。この限界が問題となるアプリケーションは、測度次元のアプローチを用いてください。
この方法は、観測は単一の計測値を有するものに限られますが、測度次元という次元を追加することで、データセットが複数の測度を持てるようになります。測度次元の値は、どの特定の測度が観測によって伝えられるかを示します。これはSDMX内で用いられる表現方法で、拡張語彙により、そのような単一の測度という制限を行うqb:DataStructureDefinition
のサブクラスを導入できます。
この表現を用いるためには、測度次元の役割を果たすように、データ構造定義内で追加の次元を宣言します。データ・キューブ語彙内での使用に関しては、この目的のために、qb:measureType
という1つのすぐれたコンポーネントを提供しています。拡張語彙では、測度の型として機能する概念を識別する役割を提供することでこれを一般化でき、他の測度次元を宣言できるようにします。
qb:measureType
を測度次元として用いるような特殊なケースでは、認められている測度の集合はDSD内で宣言された測度であると仮定されます。この情報を複製するために、別のコード・リストやクラスの列挙を定義する必要はありません。したがって、qb:measureType
は、暗黙のコード・リストを有する「魔法の」次元プロパティーです。qb:measureType
に対する暗黙のコード・リストというこの概念は、SDMXの使用法とは少し異なるものです。
上記の我々の例に対するデータ構造定義は、この表現方法を用いると、次のとおりになるでしょう。
eg:dsd2 a qb:DataStructureDefinition; rdfs:comment "shipments by time (measure dimension approach)"@en; qb:component [ qb:dimension sdmx-dimension:refTime; ], [ qb:measure eg-measure:quantity; ], [ qb:measure eg-measure:weight; ], [ qb:dimension qb:measureType; ] .
これは、次のような個々の観測データに相当するでしょう。
eg:dataset2 a qb:DataSet; qb:structure eg:dsd2 . eg:obs2a a qb:Observation; qb:dataSet eg:dataset2; sdmx-dimension:refTime "2010-07-30"^^xsd:date; qb:measureType eg-measure:weight ; eg-measure:weight 1.3 . eg:obs2b a qb:Observation; qb:dataSet eg:dataset2; sdmx-dimension:refTime "30-07-2010"^^xsd:date; qb:measureType eg-measure:quantity ; eg-measure:quantity 42 .
測度プロパティーが、計測値を伝えるプロパティーとしても、測度次元の値としても現われる重複に注意してください。我々は、統一的なキューブ/次元メカニズムと、すべての種類のデータセットに測度プロパティーを宣言し使用する統一的な方法を保証するために、この重複が必要であると受け止めています。
SDMXをよく知っている人は、RDF表現では、個々の測度をそれぞれ包含する、別個の「主要な測度」は必要ないことにも注意すべきです。それらの個々の測度は直接用いられます。拡張語彙は、データ構造定義に関して別のアノテーションを用いることで、SDMXの主要な測度の往復に対処できます。
全データセットを表す資源が作成され、qb:DataSet
として型付けされ、qb:structure
により対応するデータ構造定義にリンクされます。
落とし穴: qb:DataSet
という大文字法は、void:Datasetやdcat:Datasetなどの他の語彙の大文字法とは異なることに注意してください。この通常とは異なる大文字法は、SDMX標準との互換性のために選択されています。同じことが、関連するプロパティーqb:dataSet
にも当てはまります。
個々の観測データは、qb:Observation
という型のインスタンスとして表されます。基本的なケースでは、属性、次元、計測のそれぞれに対する値は、観測値データに直接付与されます(これらのコンポーネントがすべてRDFプロパティーであることを思い出してください)。その観測データは、qb:dataSet
プロパティーを用いて、それを含んでいるデータセットにリンクされます。
したがって、我々の実行例では、次のようになると思われます。
eg:dataset-le1 a qb:DataSet; rdfs:label "Life expectancy"@en; rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; qb:structure eg:dsd-le ; . eg:o1 a qb:Observation; qb:dataSet eg:dataset-le1 ; eg:refArea ex-geo:newport_00pr ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ; eg:lifeExpectancy 76.7 ; . eg:o2 a qb:Observation; qb:dataSet eg:dataset-le1 ; eg:refArea ex-geo:cardiff_00pt ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ; eg:lifeExpectancy 78.7 ; . eg:o3 a qb:Observation; qb:dataSet eg:dataset-le1 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ; eg:lifeExpectancy 76.6 ; . ...
この正規化された構造により、データセットのクエリや結合は容易になりますが、ここにはいくぶん冗長性があります。例えば、平均寿命の測度単位は、データセットの全体にわたって統一的であり、観測データによって変わりません。このような状況に対応するために、データ・キューブ語彙では、入れ子の構造でハイ・レベルにコンポーネントを付与できます。確かに、元のデータ構造宣言(Data Structure Declaration)を再度見てみると、測度単位をデータセット・レベルに付与するように宣言していることが分かります。したがって、短縮版の例は次のとおりです。
eg:dataset-le1 a qb:DataSet; rdfs:label "Life expectancy"@en; rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; qb:structure eg:dsd-le ; sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ; . eg:o1 a qb:Observation; qb:dataSet eg:dataset-le1 ; eg:refArea ex-geo:newport_00pr ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; eg:lifeExpectancy 76.7 ; . eg:o2 a qb:Observation; qb:dataSet eg:dataset-le1 ; eg:refArea ex-geo:cardiff_00pt ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; eg:lifeExpectancy 78.7 ; . eg:o3 a qb:Observation; qb:dataSet eg:dataset-le1 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; eg:lifeExpectancy 76.6 ; . ...
介在する構造のない単なる観測データを含んでいるデータセットでは、観測データはそれぞれ、すべての測度の値に加え、次元の値の完全な集合を持っていなければなりません。その集合がスライスを用いて構造化されていれば、次の項で論じているとおり、さらなる省略が可能です。
スライスにより、観測データのサブセットをまとめてグループ化できます。これは、観測データから任意に選択したものを表すことではなく、1つ以上の次元の値が固定されたキューブの統一的なスライスを表すことを目的としています。
スライスは、多くの理由で使用できます。
スライスの使用法を説明するために、サンプルデータの集合を一連の地理データへとグループ化してみます。それによって、例えば「2004年-2006年の男性の平均寿命観測データ」を参照し、地域にまたがる比較表を示すように、アプリケーションを誘導できるでしょう。
最初に、「スライス・キー」をデータ構造定義に関連付けて、望むスライス構造を定義します。qb:SliceKey
を作成して、スライスで固定するコンポーネント・プロパティー(次元でなければならない)をリストアップすることでこれを行います。キーは、qb:sliceKey
でDSDに付与します。例えば、次のとおりです。
eg:sliceByRegion a qb:SliceKey; rdfs:label "slice by region"@en; rdfs:comment "Slice by grouping regions together, fixing sex and time values"@en; qb:componentProperty eg:refPeriod, sdmx-dimension:sex . eg:dsd-le-slice1 a qb:DataStructureDefinition; qb:component [ qb:dimension eg:refArea; qb:order 1 ], [ qb:dimension eg:refPeriod; qb:order 2 ], [ qb:dimension sdmx-dimension:sex; qb:order 3 ], [ qb:measure eg:lifeExpectancy]; [qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet; ] ; qb:sliceKey eg:sliceByRegion .
次に、インスタンス・データでは、スライスはqb:Slice
のインスタンスで表され、それは、qb:observation
によってスライスの観測データにリンクされ、また、qb:sliceStructure
によってキーにリンクされます。データセットは、自身が含んでいるスライスをqb:slice
によって示します。したがって、我々の例では、次のようになるでしょう。
eg:dataset-le2 a qb:DataSet; rdfs:label "Life expectancy"@en; rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; qb:structure eg:dsd-le-slice2 ; sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ; qb:slice eg:slice2; . eg:slice2 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; qb:observation eg:o1b, eg:o2b, eg:o3b, ... . eg:o1b a qb:Observation; qb:dataSet eg:dataset-le2 ; eg:refArea ex-geo:newport_00pr ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; eg:lifeExpectancy 76.7 ; . eg:o2b a qb:Observation; qb:dataSet eg:dataset-le2 ; eg:refArea ex-geo:cardiff_00pt ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; eg:lifeExpectancy 78.7 ; . eg:o3b a qb:Observation; qb:dataSet eg:dataset-le2 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; eg:lifeExpectancy 76.6 ; . ...
ここで、個々の観測データに関する次元の値をまだ繰り返していることに注意してください。この正規表現は、データを利用するアプリケーションが、最初にデータ構造定義を解析してスライス定義を検索することなく、今までどおり観測値に統一的にクエリを行うことができることを意味します。望ましい場合には、この冗長性は、次元に異なる付与レベルを宣言することで減少させることができます。例えば次のとおりです。
eg:dsd-le-slice3 a qb:DataStructureDefinition; qb:component [ qb:dimension eg:refArea; qb:order 1 ]; [ qb:dimension eg:refPeriod; qb:order 2; qb:componentAttachment qb:Slice ]; [ qb:dimension sdmx-dimension:sex; qb:order 3; qb:componentAttachment qb:Slice ]; [ qb:measure eg:lifeExpectancy]; [ qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet; ] ; qb:sliceKey eg:sliceByRegion . eg:dataset-le3 a qb:DataSet; rdfs:label "Life expectancy"@en; rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; qb:structure eg:dsd-le-slice3 ; sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ; qb:slice eg:slice3 ; . eg:slice3 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; qb:observation eg:o1c, eg:o2c, eg:o3c, ... . eg:o1c a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:newport_00pr ; eg:lifeExpectancy 76.7 ; . eg:o2c a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:cardiff_00pt ; eg:lifeExpectancy 78.7 ; . eg:o3c a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:lifeExpectancy 76.6 ; . ...
アクセスのし易さや表示上の目的で、公開者は観測データの集合をグループ化したいと考えているけれども、次元の値の集合を固定するだけではその集合を定義できないというな状況もあります。例えば、気象観測データを表す際に、個々の観測データが異なる時間に取得されたものである可能性があったとしても、各局から入手できる最新の観測データをグループ化することが望ましい場合があります。これらの状況のために、データ・キューブ語彙はqb:ObservationGroup
をサポートしています。qb:ObservationGroup
には、任意の観測データの集合を含むことができます。qb:Slice
は、qb:ObservationGroup
の特殊なケースです。
データセット内の次元の値は、曖昧さなく定義されていなければなりません。それは、型付き値(例えば、時間インスタンスではxsd:dateTime
)でも、あるコード・リストから得たコードでもかまいません。同様に、データセットで用いられる多くの属性は、自由なテキストの記述ではなく、ある統制用語リストのコード値です。データ・キューブ語彙では、そのようなコードは通常のRDFのようにURI参照で表されます。
関連する次元に適したURIの集合が既に存在していることがあります(例えば、我々の実行例における、エリアと期間の表現)。また、変換されているデータセットが、まだ関連URIのない何らかのスキームの統制用語を用いているケースもありえます。そのような場合には、SKOSの使用をお勧めします。つまり、skos:Concept
を用いて個々のコード値を表し、skos:ConceptScheme
またはskos:Collection
を用いて許容可能な値の集合全体を表します。
我々の作業例で既に用いたように、性別をSDMX COGコード・リストの変換から抽出した例でこれを説明します。このコード・リストの関連するサブセットは次のとおりです。
sdmx-code:sex a skos:ConceptScheme; skos:prefLabel "Code list for Sex (SEX) - codelist scheme"@en; rdfs:label "Code list for Sex (SEX) - codelist scheme"@en; skos:notation "CL_SEX"; skos:note "This code list provides the gender."@en; skos:definition <http://sdmx.org/wp-content/uploads/2009/01/02_sdmx_cog_annex_2_cl_2009.pdf> ; rdfs:seeAlso sdmx-code:Sex ; sdmx-code:sex skos:hasTopConcept sdmx-code:sex-F ; sdmx-code:sex skos:hasTopConcept sdmx-code:sex-M . sdmx-code:Sex a rdfs:Class, owl:Class; rdfs:subClassOf skos:Concept ; rdfs:label "Code list for Sex (SEX) - codelist class"@en; rdfs:comment "This code list provides the gender."@en; rdfs:seeAlso sdmx-code:sex . sdmx-code:sex-F a skos:Concept, sdmx-code:Sex; skos:topConceptOf sdmx-code:sex; skos:prefLabel "Female"@en ; skos:notation "F" ; skos:inScheme sdmx-code:sex . sdmx-code:sex-M a skos:Concept, sdmx-code:Sex; skos:topConceptOf sdmx-code:sex; skos:prefLabel "Male"@en ; skos:notation "M" ; skos:inScheme sdmx-code:sex .
skos:prefLabel
を用いてコードに名前を与え、skos:note
で内容記述を提供し、skos:notation
を用いて他のシリアル化に現われるかもしれない短い形式のコードを記録できます。SKOS仕様[SKOS-REFERENCE]は、skos:notation
を用いる際に、それぞれにデータ型をカスタムで作成することを推薦していますが、ここでは、その表記法はRDFエンコーディングでの使用を意図しているのではなく、単に他の表現(そのようなデータ型を使用しない)で用いられる表記法を文書化しただけです。
コード・リストを開発する際に、階層構造に関係なく、コード・リスト内のコードをすべて表示するクラスも作成することは便利でよい実践です。これは、rdfs:range
を用いてqb:ComponentProperty
の値域を定義することを可能とし、それによって、DMX-RDFに対応したカスタム・ツールを必要とせずに、標準のRDF閉世界チェッカーを使ってコード・リストの使用を検証できます。上記の例では、クラス名が概念スキームのそれと同じだが先頭が大文字である共通規定を用いてこれを行っています。
このコード・リストは、次のような、次元などのコード化されたプロパティーに関連付けることができます。
eg:sex a qb:DimensionProperty, qb:CodedProperty; qb:codeList sdmx-code:sex ; rdfs:range sdmx-code:Sex .
qb:codeList
を用いて、明示的にコード・リストを宣言することは義務ではありませんが、概念スキームを定義する時には有用になりえます。
コード・リストが階層構造を持っている場合もあります。特にこれは、データ・キューブにデータ値の集約(例えば、地理的な領域にわたって測度を集約)が含まれている時にSDMXで用いられます。階層コード・リストは、子コードのツリー(tree)やラティス(lattice)によりskos:hasTopConcept
コードから下方へとリンクするために、skos:narrower
関係またはそのサブプロパティーを用いて表すべきです(SHOULD)。一部の公開用ツール連鎖では、対応する推移的なskos:narrowerTransitive
は自動的に推論されるでしょう。skos:narrower
を用いると、トップに集約層を追加することにより既存のスキームを拡張した新しい概念スキームを宣言できます。すべての項目はskos:inScheme
によってスキームにリンクされます。
SKOS関係skos:narrower
を用いる以外の方法で概念の階層的配列を指定できることが便利なことがあります。これが便利な状況はいくつかあります。例えば次のような場合です。
データ・キューブ語彙は、qb:HierarchicalCodeList
クラスによってこの状況をサポートします。qb:HierarchicalCodeList
のインスタンスは、階層内にルートの概念(qb:hierarchyRoot
)と、階層内の用語をその直近のサブ用語にリンクする親-子関係(qb:parentChildProperty
)を定義します。
したがって、qb:HierarchicalCodeList
は、qb:hierarchyRoot
がskos:hasTopConcept
と同じ役割を果たし、qb:parentChildProperty
の値はskos:narrower
と同じ役割を果たすという点でskos:ConceptScheme
に似ています。コード・リストがSKOS概念スキームやコレクションとして既に入手可能である場合、または、そのように合理的に作成可能な場合、)となっており誤記である可能性が高い。、それらを直接使用すべきです(SHOULD)。qb:HierarchicalCodeList
は、その用語はSKOSとして利用できないけれども、再利用に適した他の何らかのRDF表現で利用できる場合のために提供されています。
例えば、イギリスのOrdnance Surveyは、11のルート(ウェールズ、スコットランド、南西部のようなヨーロッパの地域)を持つ地理的な階層を公開しており、包含階層を定義するために空間関係オントロジーを用いています。これは、下記を用いて、qb:HierarchicalCodeList
として表すことができます。
@prefix spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> . eg:GBgeoHierarchy a qb:HierarchicalCodeList; rdfs:label "Geographic Hierarchy for Great Britain"@en; qb:hierarchyRoot <http://data.ordnancesurvey.co.uk/id/7000000000041427>, # South West <http://data.ordnancesurvey.co.uk/id/7000000000041426>, # West Midlands <http://data.ordnancesurvey.co.uk/id/7000000000041421>, # South East <http://data.ordnancesurvey.co.uk/id/7000000000041430>, # Yorkshire & the Humber <http://data.ordnancesurvey.co.uk/id/7000000000041423>, # East Midlands <http://data.ordnancesurvey.co.uk/id/7000000000041425>, # Eastern <http://data.ordnancesurvey.co.uk/id/7000000000041428>, # London <http://data.ordnancesurvey.co.uk/id/7000000000041431>, # North West <http://data.ordnancesurvey.co.uk/id/7000000000041422>, # North East <http://data.ordnancesurvey.co.uk/id/7000000000041424>, # Wales <http://data.ordnancesurvey.co.uk/id/7000000000041429>; # Scotland qb:parentChildProperty spatial:contains; . eg:geoDimension a qb:DimensionProperty ; qb:codeList eg:GBgeoHierarchy .
再利用する階層が、子の概念を親の概念に関連付けるプロパティーを持っているだけの場合があることに注意してください。この状況は、qb:parentChildProperty
がchild-to-parentプロパティーのowl:inverseOf
であると宣言することにより対応できます。例えば、次の通りです。
@prefix spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> . eg:GBgeoHierarchy a qb:HierarchicalCodeList; qb:parentChildProperty [owl:inverseOf spatial:within] .
データ・キューブの将来の拡張は、例えば、各親がその子どもの素の和集合である階層を宣言するために、qb:HierarchicalCodeList
のサブクラスの追加をサポートするかもしれません。
SKOS(または、非SKOS)の階層を用いることで、リーフではない(non-leaf)概念の集約統計を階層で公開できます。データ・キューブ語彙自体は、そのような集約がどのように行われるかを制約しません。確かに、統計アプリケーションでは、集約された値に対して統計を適切に修正することは簡単ではなく、データや正確な分析方法に依存するかもしれません。同様に、OLAPなどの他のアプリケーションでは、多くの様々な集約演算子がよく利用されます。
特定のデータセット内で用いられる集約オペレーションや、あるデータセットがどのように別のものから派生したのかを表す語彙用語は、データ・キューブ仕様のこのバージョンではサポートしていません。この分野は、データ・キューブの将来の拡張において対応されるかもしれません。
発見、表示、処理をサポートするために、データセットは、メタデータでマークアップすべきです。データセットに共通に必要な重要なメタデータのアノテーションを表すためにダブリン・コア用語[DC11]を使用すべきです(SHOULD)。表示ラベル用のRDFS用語(rdfs:label
)や記述コメント(rdfs:comment
)も、データ・キューブの初期のバージョンや共通のRDF実践との互換性のために付与すべきです(SHOULD)。
推奨されるメタデータ用語のコア集合は次のとおりです。
dct:title
rdfs:label
- dct:title
と同じでありえるdct:description
rdfs:comment
- dct:description
と同じでありえるdct:issued
dct:modified
dct:subject
dct:publisher
dct:license
この他にも、データ・キューブのデータセット記述に使用できるデータセットに対するメタデータ用語の勧告を追加提供するドキュメント(特に、[DCAT])があります。
統計の公開者はしばしば、自身のデータセットを、教育、労働、輸送などの様々な統計領域に分類します。このようなデータセット全体の分類を記録するためには、dct:subject
の使用をお勧めします。分類の用語には、SDMXコンテンツ指向ガイドラインの主題領域のリスト(List of Subject-matter Domains)などの粗い分類もあれば、データセットの発見をサポートするためのきめの細かい分類もあります。
一般的に、分類表は、SKOS語彙を用いて表されます。便宜上、SMDX主題領域は、http://purl.org/linked-data/sdmx/2009/subject#のSKOS概念スキームとしてコード化されました。
したがって、我々のデータセットの例は、次のようにマークアップされるでしょう。
eg:dataset1 a qb:DataSet; rdfs:label "Life expectancy"@en; dct:title "Life expectancy"@en; rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; dct:description "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; dct:issued "2010-08-11"^^xsd:date; dct:subject sdmx-subject:3.2 , # regional and small area statistics sdmx-subject:1.4 , # Health eg:Wales; # Wales ...
このとき、eg:Wales
は、場所のための適切な統制語から得られたskos:Concept
です。
データセットを公開する組織を、データセットのメタデータの一部として記録すべきです。これにも、ダブリン・コア用語dct:publisher
の使用をお勧めします。組織はfoaf:Agent
のインスタンスとして表すか、org:Organization
[ORG]などの何らかのより特定的なサブクラスとして表すべきです。
eg:dataset1 a qb:DataSet; dct:publisher <http://example.com/meta#organization> . <http://example.com/meta#organization> a org:Organization, foaf:Agent; rdfs:label "Example org" .
拡張語彙は追加のメタデータ・プロパティーを提供でき、どのメタデータを提供しなければならないかを制約できます。
正規形では、データ・キューブを形成するqb:Observation
には、関連するデータ構造定義で宣言されている必須の次元、属性、測度のそれぞれに対してプロパティー値があります。データ・キューブのこの形式は、正規化という用語で呼ばれています。これはデータにクエリを行うために便利なフォーマットで、これにより、複数のキューブのものを含む、観測データの集合を抽出する統一的なクエリを書くことが可能となります。しかし、完全な正規表現の冗長性は、一部の状況において問題となりえるデータ・キューブの送信や記憶装置のオーバーヘッドを引き起こします。オプションとして省略形式が提供されており、それを使用するという要件もあることに注意してください。多くの状況において、標準的な圧縮技術により、正規形のオーバーヘッドの多くを取り除くことができます。
これに対処するために、データ・キューブ語彙は、コンポーネント・プロパティーをデータ・キューブ内の他のレベルに付与できる、省略形の概念をサポートしています。具体的には、それらは、qb:DataSet
またはqb:Slice
に付与できます。これらの場合、付与されたプロパティは、その付与のポイントに関連するすべてのqb:Observation
インスタンスに適用されているとみなされます。説明に関しては、測度の単位がデータセット全体に付与されるように宣言されており、すべての観測データに対して繰り返す必要がない例4を参照してください。
qb:MeasureProperty
に属性を付与することもできます。その場合には、属性は、そのプロパティーが生じた観測データではなく、そのプロパティーにのみ適用されることになりす。
これらの概念は、省略形のデータ・キューブを標準化できる変換アルゴリズムで定義します。この変換は、SPARQL 1.1更新言語[sparql11-update]を用いて表現します。この表記法の使用は、変換をこのように実装しなければならないことを示唆しません。データ・キューブを用いた情報交換は、省略形のデータを保持し、アクセスを緩和するためのクエリの書き直しなどの他の技術を用いたり、他の手段で正規化アルゴリズムを実装したり、正規形またはこれらを任意に混ぜた形式ですべてのデータを処理したりできます。
正規化アルゴリズムには、2組のSPARQL更新オペレーションが含まれており、これらを正規化すべきデータ・キューブRDFグラフを含んでいるデフォルト・グラフのSPARQLデータセットに順番に適用すべきです。
最初の更新オペレーションは、選択的な型とプロパティー閉包のオペレーションを行ないます。これらは2つの目的を果たします。qb:Observation
とqb:Slice
のインスタンスに関するrdf:type
の言明が、省略形のデータ・キューブでは割愛できることを保障します。また、qb:componentProperty
(特に、qb:dimension
、qb:measure
、qb:attribute
)のサブプロパティーの拡張により、更新オペレーションの2番目の集合の単純化も行います。
フェーズ1: 型およびプロパティー閉包 |
---|
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX qb: <http://purl.org/linked-data/cube#> INSERT { ?o rdf:type qb:Observation . } WHERE { [] qb:observation ?o . }; INSERT { ?o rdf:type qb:Observation . ?ds rdf:type qb:DataSet . } WHERE { ?o qb:dataSet ?ds . }; INSERT { ?s rdf:type qb:Slice . } WHERE { [] qb:slice ?s. }; INSERT { ?cs qb:componentProperty ?p . ?p rdf:type qb:DimensionProperty . } WHERE { ?cs qb:dimension ?p . }; INSERT { ?cs qb:componentProperty ?p . ?p rdf:type qb:MeasureProperty . } WHERE { ?cs qb:measure ?p . }; INSERT { ?cs qb:componentProperty ?p . ?p rdf:type qb:AttributeProperty . } WHERE { ?cs qb:attribute ?p . } |
これらの閉包オペレーションは、データ・キューブ語彙のRDFSセマンティックスによって暗示されます。データ・キューブのプロセッサは、ここで定義している更新オペレーションの代わりに、フルのRDFS閉包を適用できます(MAY)。
2番目の更新オペレーションは、宣言された付与レベルに対するデータセットのデータ構造定義のコンポーネントをチェックします。可能な付与レベルごとに、対応する観測データまで引き下げてそのコンポーネントの発生を探します。
フェーズ2: 付与レベルの引き下げ |
---|
PREFIX qb: <http://purl.org/linked-data/cube#> # Dataset attachments INSERT { ?obs ?comp ?value } WHERE { ?spec qb:componentProperty ?comp ; qb:componentAttachment qb:DataSet . ?dataset qb:structure [qb:component ?spec]; ?comp ?value . ?obs qb:dataSet ?dataset. }; # Slice attachments INSERT { ?obs ?comp ?value } WHERE { ?spec qb:componentProperty ?comp; qb:componentAttachment qb:Slice . ?dataset qb:structure [qb:component ?spec]; qb:slice ?slice . ?slice ?comp ?value; qb:observation ?obs . }; # Dimension values on slices INSERT { ?obs ?comp ?value } WHERE { ?spec qb:componentProperty ?comp . ?comp a qb:DimensionProperty . ?dataset qb:structure [qb:component ?spec]; qb:slice ?slice . ?slice ?comp ?value; qb:observation ?obs . } |
RDFデータ・キューブのインスタンスは、この項で定義している完全性制約に準拠すべきです。
整形式のRDFデータ・キューブとは、ここで定義している個々の完全性チェックにパスした1つ以上のqb:DataSet
インスタンスを記述したRDFグラフです。
整形式省略形のRDFデータ・キューブとは、正規化アルゴリズムを用いて拡張した時に整形式のRDFデータ・キューブを生成するRDFグラフです。
個々の完全性制約は、話言葉の散文として、また、可能な場合には、SPARQL[sparql11-query]のASKクエリやクエリ・テンプレートとして表されます。ASKクエリがRDFグラフに適用され、対応する制約に違反する1つ以上のデータ・キューブのインスタンスがそのグラフに含まれていれば、真(true)を返すでしょう。
完全性制約を表すためにSPARQLクエリを用いることは、この方法で完全性チェックを行なわなければならいことを示唆するわけではありません。実装は、同等性チェックを行なうために、別のクエリ式や別の実装技術を自由に使用できます。
個々の完全性制約クエリは、次の接頭辞バインディングを仮定します。
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX qb: <http://purl.org/linked-data/cube#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX owl: <http://www.w3.org/2002/07/owl#>
完全な制約の集合を以下に挙げます。
RDFグラフは、グラフ内で用いられているすべてのデータ型を含んでいるデータ型マップを用いたRDF D-含意[RDF-MT]の下で整合性がなければなりません。
すべてのqb:Observation
には、きっかり1つの関連するqb:DataSet
があります。
ASK { { # Check observation has a data set ?obs a qb:Observation . FILTER NOT EXISTS { ?obs qb:dataSet ?dataset1 . } } UNION { # Check has just one data set ?obs a qb:Observation ; qb:dataSet ?dataset1, ?dataset2 . FILTER (?dataset1 != ?dataset2) } } |
すべてqb:DataSet
には、きっかり1つの関連するqb:DataStructureDefinition
があります。
ASK { { # Check dataset has a dsd ?dataset a qb:DataSet . FILTER NOT EXISTS { ?dataset qb:structure ?dsd . } } UNION { # Check has just one dsd ?dataset a qb:DataSet ; qb:structure ?dsd1, ?dsd2 . FILTER (?dsd1 != ?dsd2) } } |
すべてのqb:DataStructureDefinition
には少なくとも1つの宣言された測度が含まれていなければなりません。
ASK { ?dsd a qb:DataStructureDefinition . FILTER NOT EXISTS { ?dsd qb:component [qb:componentProperty [a qb:MeasureProperty]] } } |
qb:DataStructureDefinition
で宣言されたすべての次元には、宣言されたrdfs:range
がなければなりません。
ASK { ?dim a qb:DimensionProperty . FILTER NOT EXISTS { ?dim rdfs:range [] } } |
skos:Concept
の値域を有するすべての次元には、qb:codeList
がなければなりません。
ASK { ?dim a qb:DimensionProperty ; rdfs:range skos:Concept . FILTER NOT EXISTS { ?dim qb:codeList [] } } |
qb:componentRequired
を用いて、オプションと記すことができるqb:DataStructureDefinition
の唯一のコンポーネントは属性です。
ASK { ?dsd qb:component ?componentSpec . ?componentSpec qb:componentRequired "false"^^xsd:boolean ; qb:componentProperty ?component . FILTER NOT EXISTS { ?component a qb:AttributeProperty } } |
すべてのqb:SliceKey
はqb:DataStructureDefinition
に関連付けられていなければなりません。
ASK { ?sliceKey a qb:SliceKey . FILTER NOT EXISTS { [a qb:DataStructureDefinition] qb:sliceKey ?sliceKey } } |
qb:SliceKey
のすべてのqb:componentProperty
も、関連するqb:DataStructureDefinition
のqb:component
として宣言されなければなりません。
ASK { ?slicekey a qb:SliceKey; qb:componentProperty ?prop . ?dsd qb:sliceKey ?slicekey . FILTER NOT EXISTS { ?dsd qb:component [qb:componentProperty ?prop] } } |
個々のqb:Slice
には、きっかり1つの関連するqb:sliceStructure
がなければなりません。
ASK { { # Slice has a key ?slice a qb:Slice . FILTER NOT EXISTS { ?slice qb:sliceStructure ?key } } UNION { # Slice has just one key ?slice a qb:Slice ; qb:sliceStructure ?key1, ?key2; FILTER (?key1 != ?key2) } } |
すべてのqb:Slice
には、そのqb:sliceStructure
で宣言されたすべての次元に対する値がなければなりません。
ASK { ?slice qb:sliceStructure [qb:componentProperty ?dim] . FILTER NOT EXISTS { ?slice ?dim [] } } |
すべてのqb:Observation
には、その関連するqb:DataStructureDefinition
で宣言された個々の次元に対する値がなければなりません。
ASK { ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim . ?dim a qb:DimensionProperty; FILTER NOT EXISTS { ?obs ?dim [] } } |
同じqb:DataSet
内の2つのqb:Observation
は、すべての次元に対して同じ値を持つことができません。
ASK { FILTER( ?allEqual ) { # For each pair of observations test if all the dimension values are the same SELECT (MIN(?equal) AS ?allEqual) WHERE { ?obs1 qb:dataSet ?dataset . ?obs2 qb:dataSet ?dataset . FILTER (?obs1 != ?obs2) ?dataset qb:structure/qb:component/qb:componentProperty ?dim . ?dim a qb:DimensionProperty . ?obs1 ?dim ?value1 . ?obs2 ?dim ?value2 . BIND( ?value1 = ?value2 AS ?equal) } GROUP BY ?obs1 ?obs2 } } |
すべてのqb:Observation
には、必須と記されている個々の宣言された属性に対する値があります。
ASK { ?obs qb:dataSet/qb:structure/qb:component ?component . ?component qb:componentRequired "true"^^xsd:boolean ; qb:componentProperty ?attr . FILTER NOT EXISTS { ?obs ?attr [] } } |
測度次元を用いないqb:DataSet
においては、個々のqb:Observation
に、すべての宣言された測度に対して値がなければなりません。
ASK { # Observation in a non-measureType cube ?obs qb:dataSet/qb:structure ?dsd . FILTER NOT EXISTS { ?dsd qb:component/qb:componentProperty qb:measureType } # verify every measure is present ?dsd qb:component/qb:componentProperty ?measure . ?measure a qb:MeasureProperty; FILTER NOT EXISTS { ?obs ?measure [] } } |
測度次元を用いるqb:DataSet
においては、個々のqb:Observation
に、その与えられたqb:measureType
に対応する測度に対して値がなければなりません。
ASK { # Observation in a measureType-cube ?obs qb:dataSet/qb:structure ?dsd ; qb:measureType ?measure . ?dsd qb:component/qb:componentProperty qb:measureType . # Must have value for its measureType FILTER NOT EXISTS { ?obs ?measure [] } } |
測度次元を用いるqb:DataSet
においては、個々のqb:Observation
には、1つの測度に対する値のみがなければなりません(IC-15によって、これはそのqb:measureType
に対応する測度になるでしょう)。
ASK { # Observation with measureType ?obs qb:dataSet/qb:structure ?dsd ; qb:measureType ?measure ; ?omeasure [] . # Any measure on the observation ?dsd qb:component/qb:componentProperty qb:measureType ; qb:component/qb:componentProperty ?omeasure . ?omeasure a qb:MeasureProperty . # Must be the same as the measureType FILTER (?omeasure != ?measure) } |
測度次元を用いるqb:DataSet
においては、非測度次元のある組み合わせに対する観測データがあれば、個々の宣言された測度に対する同じ非測度次元の値を有する他の観測データがなければなりません。
ASK { { # Count number of other measures found at each point SELECT ?numMeasures (COUNT(?obs2) AS ?count) WHERE { { # Find the DSDs and check how many measures they have SELECT ?dsd (COUNT(?m) AS ?numMeasures) WHERE { ?dsd qb:component/qb:componentProperty ?m. ?m a qb:MeasureProperty . } GROUP BY ?dsd } # Observation in measureType cube ?obs1 qb:dataSet/qb:structure ?dsd; qb:dataSet ?dataset ; qb:measureType ?m1 . # Other observation at same dimension value ?obs2 qb:dataSet ?dataset ; qb:measureType ?m2 . FILTER NOT EXISTS { ?dsd qb:component/qb:componentProperty ?dim . FILTER (?dim != qb:measureType) ?dim a qb:DimensionProperty . ?obs1 ?dim ?v1 . ?obs2 ?dim ?v2. FILTER (?v1 != ?v2) } } GROUP BY ?obs1 ?numMeasures HAVING (?count != ?numMeasures) } } |
qb:DataSet
Dにqb:slice
Sがあり、Sにqb:observation
Oがあれば、Oに対応するqb:dataSet
はDでなければなりません。
ASK { ?dataset qb:slice ?slice . ?slice qb:observation ?obs . FILTER NOT EXISTS { ?obs qb:dataSet ?dataset . } } |
次元プロパティーにqb:codeList
があれば、すべてのqb:Observation
の次元プロパティーの値がコード・リストになければなりません。
次の完全性チェック・クエリは、チェックするデータ・キューブと、コード・リストの定義を含んでいるRDFグラフに適用されなければなりません。skos:ConceptScheme
の場合には、個々の概念はskos:inScheme
を用いてスキームにリンクされなければなりません。skos:Collection
の場合には、集合はskos:member
を用いて、個々の概念(または、入れ子の集合に)にリンクしなければなりません。集合がskos:memberList
を用いれば、[SKOS-REFERENCE]のS36によって定義されているskos:member
の値の含意は、このチェックが適用される前に、実現されなければなりません。
ASK { ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim . ?dim a qb:DimensionProperty ; qb:codeList ?list . ?list a skos:ConceptScheme . ?obs ?dim ?v . FILTER NOT EXISTS { ?v a skos:Concept ; skos:inScheme ?list } } ASK { ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim . ?dim a qb:DimensionProperty ; qb:codeList ?list . ?list a skos:Collection . ?obs ?dim ?v . FILTER NOT EXISTS { ?v a skos:Concept . ?list skos:member+ ?v } } |
次元プロパティーに非空白qb:parentChildProperty
を有するqb:HierarchicalCodeList
がある場合、すべてのqb:Observation
のその次元プロパティーの値は、qb:parentChildProperty
リンクに沿った0以上のホップ(hop)を用いて、階層のルートから到達できなければなりません。
このチェックは、シンプルな固定SPARQLクエリで行うことができません。その代わりに、クエリ・テンプレートが提供されています。テンプレートのインスタンスは、そのqb:parentChildProperty
に対してIRIの値を持っている個々のqb:HierarchicalCodeList
に対して生成されるべきです。それは、次のインスタンス化クエリ内の?p
の個々のバインディングに関するものです。
SELECT ?p WHERE { ?hierarchy a qb:HierarchicalCodeList ; qb:parentChildProperty ?p . FILTER ( isIRI(?p) ) }
その後、テンプレートは、文字列$p
を、インスタンス化クエリによって見つかったIRIと置換することによりインスタンス化されます。テンプレートは次のとおりです。
ASK { ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim . ?dim a qb:DimensionProperty ; qb:codeList ?list . ?list a qb:HierarchicalCodeList . ?obs ?dim ?v . FILTER NOT EXISTS { ?list qb:hierarchyRoot/<$p>* ?v } } |
次元プロパティーに逆のqb:parentChildProperty
を有するqb:HierarchicalCodeList
がある場合、すべてのqb:Observation
のその次元プロパティーの値は、逆のqb:parentChildProperty
リンクに沿った0以上のホップを用いて、階層のルートから到達できなければなりません。
このチェックは、シンプルな固定SPARQLクエリで行うことができません。その代わりに、クエリ・テンプレートが提供されています。テンプレートのインスタンスは、関連する逆のプロパティーで、そのqb:parentChildProperty
に対して空白ノードの値を持っている個々のqb:HierarchicalCodeList
に対して生成されるべきです。それは、次のインスタンス化クエリの?p
の個々のバインディングに関するものです。
SELECT ?p WHERE { ?hierarchy a qb:HierarchicalCodeList; qb:parentChildProperty ?pcp . FILTER( isBlank(?pcp) ) ?pcp owl:inverseOf ?p . FILTER( isIRI(?p) ) }
その後、テンプレートは、文字列$p
を、インスタンス化クエリによって見つかったIRIと置換することによりインスタンス化されます。テンプレートは次のとおりです。
ASK { ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim . ?dim a qb:DimensionProperty ; qb:codeList ?list . ?list a qb:HierarchicalCodeList . ?obs ?dim ?v . FILTER NOT EXISTS { ?list qb:hierarchyRoot/(^<$p>)* ?v } } |
データセットの表現の項を参照してください。
qb:DataSet
Sub class of:
qb:Attachable
Equivalent to:
scovo:Dataset
データセットの表現の項を参照してください。
qb:Observation
Sub class of:
qb:Attachable
Equivalent to:
scovo:Item
qb:dataSet
( Domain:
qb:Observation
-> Range:
qb:DataSet
)
qb:observation
( Domain:
qb:ObservationGroup
-> Range:
qb:Observation
)
スライスの項を参照してください。
qb:ObservationGroup
qb:Slice
Sub class of:
qb:Attachable
,
qb:ObservationGroup
qb:slice
( Domain:
qb:DataSet
-> Range:
qb:Slice
;
sub property of:
qb:observationGroup
)
qb:observationGroup
( Domain:
-> Range:
qb:ObservationGroup
)
次元、属性および測度の項を参照してください。
qb:Attachable
qb:ComponentProperty
Sub class of:
rdf:Property
qb:DimensionProperty
Sub class of:
qb:ComponentProperty
,
qb:CodedProperty
qb:AttributeProperty
Sub class of:
qb:ComponentProperty
qb:MeasureProperty
Sub class of:
qb:ComponentProperty
qb:CodedProperty
Sub class of:
qb:ComponentProperty
測度次元の項を参照してください。
qb:measureType
( Domain:
-> Range:
qb:MeasureProperty
)
コンポーネント仕様とデータ構造定義の項を参照してください。
qb:DataStructureDefinition
Sub class of:
qb:ComponentSet
qb:structure
( Domain:
qb:DataSet
-> Range:
qb:DataStructureDefinition
)
qb:component
( Domain:
qb:DataStructureDefinition
-> Range:
qb:ComponentSpecification
)
コンポーネント仕様とデータ構造定義の項を参照してください。
qb:ComponentSpecification
Sub class of:
qb:ComponentSet
qb:ComponentSet
qb:componentProperty
( Domain:
qb:ComponentSet
-> Range:
qb:ComponentProperty
)
qb:order
( Domain:
qb:ComponentSpecification
-> Range:
xsd:int
)
qb:componentRequired
( Domain:
qb:ComponentSpecification
-> Range:
xsd:boolean
)
qb:componentAttachment
( Domain:
qb:ComponentSpecification
-> Range:
rdfs:Class
)
qb:dimension
( Domain:
-> Range:
qb:DimensionProperty
; sub property of:
qb:componentProperty
)
qb:measure
( Domain:
-> Range:
qb:MeasureProperty
; sub property of:
qb:componentProperty
)
qb:attribute
( Domain:
-> Range:
qb:AttributeProperty
; sub property of:
qb:componentProperty
)
qb:measureDimension
( Domain:
-> Range:
qb:DimensionProperty
; sub property of:
qb:componentProperty
)
スライスの項を参照してください。
qb:SliceKey
Sub class of:
qb:ComponentSet
qb:sliceStructure
( Domain:
qb:Slice
-> Range:
qb:SliceKey
)
qb:sliceKey
( Domain:
qb:DataStructureDefinition
-> Range:
qb:SliceKey
)
概念スキームとコード・リストの項を参照してください。
qb:concept
( Domain:
qb:ComponentProperty
-> Range:
skos:Concept
)
qb:codeList
( Domain:
qb:CodedProperty
-> Range:
owl:unionOf(skos:ConceptScheme skos:Collection qb:HierarchicalCodeList)
)
非SKOSの階層の項を参照してください。
qb:HierarchicalCodeList
qb:hierarchyRoot
( Domain:
qb:HierarchicalCodeList
)
qb:parentChildProperty
( Domain:
qb:HierarchicalCodeList
-> Range:
rdf:Property
)
この作業は、2010年2月に英国サニングデールのONSが主催する、SDMXおよびセマンティック・ウェブにおける統計データセットの公開に関するワークショップで始められた共同作業に基づいており、それは、チルブルグのODaF 2010ワークショップで継続されました。著者は、この作業への情報提供に対し、これらのワークショップの参加者すべてに感謝していますが、特に、SDMXに関する我慢強い説明とコア・データ・キューブ表現に関する必要な洞察に対しArofan Gregoryに感謝申し上げます。
編集者は、John Sheridanの元の作業に対するコメント、提案、サポートに感謝したい。
W3Cのプロセスを通じた進行中で、多くの個人がこの仕様に関し価値のあるコメントを提供してくださいました。我々は、特にBenedikt Kaempgen、Sarven CapadisliおよびCurran Kelleherの貢献に謝意を表します。
W3C 2013年12月17日勧告案以後の変更: なし。
eg:Wales
への参照の誤植を訂正qb:Observation
におけるその使用からqb:DataSet
のrdf:type
を推論するために欠けている閉包規則を追加qb:sliceKey
の領域の誤ったステートメントを訂正W3C 2013年3月12日最終草案以後の変更:
qb:Slice
がqb:ObservationGroup
のサブクラスであると明確化するために図を修正qb:Attachable
の言及を追加(以前は語彙参照でのみ言及されていた)qb:measureType
の特殊な性質がSDMXとは異なると明確化skos:narrower
のサブプロパティーを使用できることを明確化qb:HierarchicalCodeList
の動機の3番目の黒点を削除(完全と相互排除)qb:observation
の定義域をqb:Slice
からqb:ObservationGroup
に修正。オントロジーとテキスト本文では正しく示されたが、参考文献の項では誤って述べられた。W3C 2012年4月5日草案以後の変更:
qb:componentRequired
が属性にのみ適用可能で、デフォルトがオプションであることを明確化qb:Slice
の一般化としてqb:ObservationGroup
を追加。ISSUE-33qb:subSlice
を削除。ISSUE-34skos:Collection
が可能なようにqb:codeList
の値域を一般化。ISSUE-39これは、5.4項で紹介した、実行例の完全なデータ・キューブのエンコーディングです。簡潔に示すことができるように、省略形を用いています。これは、すべての完全性チェック(sdmx-dimension:sex
の宣言がhttp://purl.org/linked-data/sdmx/2009/dimensionから含まれているとき)にパスし、したがって、整形式の省略されたデータ・キューブです。
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix void: <http://rdfs.org/ns/void#> . @prefix dct: <http://purl.org/dc/terms/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix org: <http://www.w3.org/ns/org#> . @prefix admingeo: <http://data.ordnancesurvey.co.uk/ontology/admingeo/> . @prefix interval: <http://reference.data.gov.uk/def/intervals/> . @prefix qb: <http://purl.org/linked-data/cube#> . @prefix sdmx-concept: <http://purl.org/linked-data/sdmx/2009/concept#> . @prefix sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#> . @prefix sdmx-attribute: <http://purl.org/linked-data/sdmx/2009/attribute#> . @prefix sdmx-measure: <http://purl.org/linked-data/sdmx/2009/measure#> . @prefix sdmx-metadata: <http://purl.org/linked-data/sdmx/2009/metadata#> . @prefix sdmx-code: <http://purl.org/linked-data/sdmx/2009/code#> . @prefix sdmx-subject: <http://purl.org/linked-data/sdmx/2009/subject#> . @prefix ex-geo: <http://example.org/geo#> . @prefix eg: <http://example.org/ns#> . # -- Data Set -------------------------------------------- eg:dataset-le3 a qb:DataSet; dct:title "Life expectancy"@en; rdfs:label "Life expectancy"@en; rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; dct:description "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en; dct:publisher eg:organization ; dct:issued "2010-08-11"^^xsd:date; dct:subject sdmx-subject:3.2 , # regional and small area statistics sdmx-subject:1.4 , # Health ex-geo:wales; # Wales qb:structure eg:dsd-le3 ; sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ; qb:slice eg:slice1, eg:slice2, eg:slice3, eg:slice4, eg:slice5, eg:slice6 ; . eg:organization a org:Organization, foaf:Agent; rdfs:label "Example org"@en . # -- Data structure definition ---------------------------- eg:dsd-le3 a qb:DataStructureDefinition; qb:component # The dimensions [ qb:dimension eg:refArea; qb:order 1 ], [ qb:dimension eg:refPeriod; qb:order 2; qb:componentAttachment qb:Slice ], [ qb:dimension sdmx-dimension:sex; qb:order 3; qb:componentAttachment qb:Slice ]; # The measure(s) qb:component [ qb:measure eg:lifeExpectancy]; # The attributes qb:component [ qb:attribute sdmx-attribute:unitMeasure; qb:componentRequired "true"^^xsd:boolean; qb:componentAttachment qb:DataSet; ] ; # slices qb:sliceKey eg:sliceByRegion ; . eg:sliceByRegion a qb:SliceKey; rdfs:label "slice by region"@en; rdfs:comment "Slice by grouping regions together, fixing sex and time values"@en; qb:componentProperty eg:refPeriod, sdmx-dimension:sex ; . # -- Dimensions and measures ---------------------------- eg:refPeriod a rdf:Property, qb:DimensionProperty; rdfs:label "reference period"@en; rdfs:subPropertyOf sdmx-dimension:refPeriod; rdfs:range interval:Interval; qb:concept sdmx-concept:refPeriod ; . eg:refArea a rdf:Property, qb:DimensionProperty; rdfs:label "reference area"@en; rdfs:subPropertyOf sdmx-dimension:refArea; rdfs:range admingeo:UnitaryAuthority; qb:concept sdmx-concept:refArea ; . eg:lifeExpectancy a rdf:Property, qb:MeasureProperty; rdfs:label "life expectancy"@en; rdfs:subPropertyOf sdmx-measure:obsValue; rdfs:range xsd:decimal ; . # -- Observations ----------------------------------------- # Column 1 eg:slice1 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; qb:observation eg:o11, eg:o12, eg:o13, eg:o14 ; . eg:o11 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:newport_00pr ; eg:lifeExpectancy 76.7 ; . eg:o12 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:cardiff_00pt ; eg:lifeExpectancy 78.7 ; . eg:o13 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:lifeExpectancy 76.6 ; . eg:o14 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:merthyr_tdfil_00ph ; eg:lifeExpectancy 75.5 ; . # Column 2 eg:slice2 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-F ; qb:observation eg:o21, eg:o22, eg:o23, eg:o24 ; . eg:o21 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:newport_00pr ; eg:lifeExpectancy 80.7 ; . eg:o22 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:cardiff_00pt ; eg:lifeExpectancy 83.3 ; . eg:o23 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:lifeExpectancy 81.3 ; . eg:o24 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:merthyr_tdfil_00ph ; eg:lifeExpectancy 79.1 ; . # Column 3 eg:slice3 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2005-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; qb:observation eg:o31, eg:o32, eg:o33, eg:o34 ; . eg:o31 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:newport_00pr ; eg:lifeExpectancy 77.1 ; . eg:o32 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:cardiff_00pt ; eg:lifeExpectancy 78.6 ; . eg:o33 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:lifeExpectancy 76.5 ; . eg:o34 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:merthyr_tdfil_00ph ; eg:lifeExpectancy 75.5 ; . # Column 4 eg:slice4 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2005-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-F ; qb:observation eg:o41, eg:o42, eg:o43, eg:o44 ; . eg:o41 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:newport_00pr ; eg:lifeExpectancy 80.9 ; . eg:o42 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:cardiff_00pt ; eg:lifeExpectancy 83.7 ; . eg:o43 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:lifeExpectancy 81.5 ; . eg:o44 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:merthyr_tdfil_00ph ; eg:lifeExpectancy 79.4 ; . # Column 5 eg:slice5 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2006-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-M ; qb:observation eg:o51, eg:o52, eg:o53, eg:o54 ; . eg:o51 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:newport_00pr ; eg:lifeExpectancy 77.0 ; . eg:o52 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:cardiff_00pt ; eg:lifeExpectancy 78.7 ; . eg:o53 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:lifeExpectancy 76.6 ; . eg:o54 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:merthyr_tdfil_00ph ; eg:lifeExpectancy 74.9 ; . # Column 6 eg:slice6 a qb:Slice; qb:sliceStructure eg:sliceByRegion ; eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2006-01-01T00:00:00/P3Y> ; sdmx-dimension:sex sdmx-code:sex-F ; qb:observation eg:o61, eg:o62, eg:o63, eg:o64 ; . eg:o61 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:newport_00pr ; eg:lifeExpectancy 81.5 ; . eg:o62 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:cardiff_00pt ; eg:lifeExpectancy 83.4 ; . eg:o63 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:monmouthshire_00pp ; eg:lifeExpectancy 81.7 ; . eg:o64 a qb:Observation; qb:dataSet eg:dataset-le3 ; eg:refArea ex-geo:merthyr_tdfil_00ph ; eg:lifeExpectancy 79.6 ; .