「OPEN DATA EXPO」で勢いに任せて「WordCampKansai2015までに使えるようにする」と言っちゃったので、TODO的な覚書です。

オープンデータ化だけなら簡単そう

オープンデータの定義に「リンク可能性」は含まれていないので、

1. CORSを設定して、SOPを回避する
2. データ全体にライセンス表記を追加する

この２つに対応すれば、WP-APIで出力されたものを「オープンデータ」と主張できるかなと思います。

ライセンスが地味にややこしい予感で、極論を書くと「WordPressの投稿全てをCC byで公開すること」が必要ということになります。

尤もフックか管理画面でその辺りの設定をできるようにすれば大丈夫かなとも思いますが。

LODにするための懸念点

で、WP-APIをLOD（JSON-LD）にするにはここに加えて更に対応が必要そうです。

１：コンテンツタイプが違う

JSON-LDはjson+ldというコンテンツタイプになるので、headerを書き換える必要がありそう。

JSONのままで構わないなら楽で良いけども、まぁそんなことは無いでしょうし・・・

２：カスタムフィールド対応

カスタムフィールドへの対応はマストかなと思います。

というのもデフォルトの投稿データだけでは出せる情報に限りがありますし、schema.orgなどにある膨大な量の語彙をベタ打ちで設定するのも大変です。

そうなると「カスタムフィールドをWP-APIで出力するようにする機能」と、「カスタムフィールドに語彙を設定する機能」が必要になってきそうです。

３：語彙の設定

JSON-LDにするには@contextでの語彙設定が必要です。

で、その語彙をどう設定するかというのも管理画面から設定できる必要がありそうです。

設定画面が無いとオリジナルの語彙を作られた時などにそれが使えないという問題が発生しますし、その辺りを設定できる画面が必要です。

あと「@contextを外部ファイル化するとSPAQRLで取り出すことが困難だ」という話もありましたので、外部化はしないほうが良さそうです。

多言語対応

公式に上げるには最低限英語圏の人が使えるようにしないとNGです。

ヘタするとこれが一番心理的ハードルが高い予感がします・・・

最低限必要そうな機能

ということで、このあたりの機能は備えている必要がありそうです。

1. CORS設定機能
2. ライセンス設定機能
3. カスタムフィールドのインポート機能
4. 語彙設定画面
5. 語彙とカスタムフィールドラベルの照合機能
6. 英語対応

あとはWP-APIのフックを使ってどこまでできるか・・・ですね。