地理情報に関わるLODを書こうとしたときに、語彙がいくつかあって、どれをどのように使うかという選択に迫られる。Spatial Data on the Web Best Practices にそのベストプラクティスが書いてあるのだけれど、いくつか補足をしようと思う。
Feature と Geometry を区別する
この区別は上の箇所に書かれている。緯度経度を直接持つような情報は Geometry クラスが期待され、人のような空間位置が一定でないものは Feature クラスが期待される。w3cgeo:SpatialThing はそのどちらもになりうるためセマンティクスに混乱があること、それゆえ、この文書では "SpatialThings" として geosparql:Feature のセマンティクスを想定しているということが書かれている。
例として、都道府県の例を考えてみる。都道府県は空間位置が一定だからGeometryだろうか？そうではない。Polygonで領域を描いたもの、都道府県庁の位置を代表点としてPointで表現したものなど、複数のGeometryを持つ Feature として定義でき、rdfs:subPropertyOf geosparql:hasGeometry となる defaultGeometry という述語で、領域表現を特別扱いすることができる（ schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf では "It is Usually the most detailed geometry." と書かれている、この例は私が仕事で使う際に考えたもの）。
文書内には、他に灯台の例が "6. Spatial Things, Features and Geometry" に書かれている。灯台は、ヘリの操縦者からは「高い障害物」として高さと正確な位置が重要になり、水兵からすれば「航路標識」として光の種類とだいたいの位置が重要になる。そういう個々の観点での特徴のまとまりが Feature なのである。
A. Applicability of common formats to implementation of best practicesの２つめの表。dcterms は緯度経度を書くような Geometry を扱えず、他は Feature と Geometry それを結ぶ述語は上図のようになっている。但し、すでにみたように、w3cgeo にはセマンティクスの混乱が見られるので、ちゃんと書きたい場合には vcard 以下の語彙を使うことになる。
それにも関わらず、w3cgeo を最もよく見かけるのは、Feature に対して、単一の緯度経度標高のみの属性を書きたいことが圧倒的に多く、その目的で使う分には便利だからだ。文書内ではセマンティクスの混乱についての指摘以外でw3cgeo は２つの例で使われている。
<http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587> a geosparql:Feature, bag:Pand ; rdfs:label "Pand 0363100012169587"@nl; # Detailed geometry geosparql:hasGeometry <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ; bag:geometriePand <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ; # Centroid w3cgeo:lat "52.37509"^^xsd:float ; w3cgeo:long "4.88412"^^xsd:float ; # Bounding box georss:box "52.3749,4.8838 52.3753,4.8845"^^xsd:string .
詳細な Geometry を書く geosparql:hasGeometry と並置して、w3cgeo:lat と w3cgeo:long を代表点として書いている。
:myPointOfInterest a w3cgeo:SpatialThing ;
dcterms:description "Anne Frank's House, Amsterdam."
w3cgeo:lat "52.37514"^^xsd:float ;
w3cgeo:long "4.88412"^^xsd:float ;
.
これは w3cgeo を使えば測地系がWGS 84であることが前提できるという話で書かれているだけだが、上と同様に代表点を記述している。
w3cgeo を使うもう一つの理由は、vcard、georss、geosparql、locn は主に次に説明するgeo URI と呼ばれるものや、Well-known text Literal を使うことが多く、LODとして構造化できないという問題があるため、構造化して書きたければ w3cgeo か schema.org の２つになるということである。これは、
As part of the vocabulary, an RDFS datatype is defined for encoding detailed geometry information as a literal value. A literal representation of a geometry is needed so that geometric values may be treated as a single unit. Such a representation allows geometries to be passed to external functions for computations and to be returned from a query.
という事情でそうなっている（GeoSPARQL - A Geographic Query Language for RDF Data | OGC）
緯度経度情報をつかって何をしたいかというと、計算して絞り込んで可視化するといったことになるのだが、計算の部分では領域の被覆をチェックするなどgeosparqlなどの発展的なSPARQLを使いたくなる（＝WKT Literal とかで表現しておきたい）一方、可視化の部分では緯度と経度に切り分けて取り出したかったりするのだが、GitHub - mapbox/wellknown: GeoJSON-emitting WKT parser for browsers and node とかでパースすることと組み合わせれば、それで問題は無いはず。
geo URI と geohash
vcard では geo URI をつかうと書かれているが、それでは1D～3Dは使えない。
RFC 5870 - A Uniform Resource Identifier for Geographic Locations ('geo' URI)
7.3. GML 'Circle' とか 7.4. GML 'Sphere' って項目があるからてっきりそのくらいの形は扱えるのかと思いきや、geo:%lat%,%lon%;u=%unc% という表現形式で、緯度経度とメートルで範囲を表したuncertaintyが指定できるだけなので、基本点しか表現できないと思ったほうが良い。
vcard が元々名刺のような情報を書くことを考えれば当然かもしれない。自宅や会社の位置を書くのに Polygon で書ける必要があるだろうか？
似たように点でしか表現できないが緯度経度をidentifier化できるものに
がある。あまり使いどころが多いように思えないが、リンクになっていることで、それぞれのフォーマットに dereferenceable になるのは良いかもね。
- osm: open the location in OpenStreetMaps
- gmaps: open the location in Google Maps
- gc: go to the nearest geocaches in Geocaching.com
- gpx: go directly to GPX download page
- garmin: go directly to Garmin download page
- text: show coordinates as plain text
- url: show Geohash URL as plain text
- maxlen: maximum length of the Geohash
次に述べるような「フォーマット」じゃないけれど、よくあるサービス用のURLを生成してくれるのは嬉しい。
データフォーマット
（A. Applicability of common formats to implementation of best practices の１つめの表から抜粋）
Well-known text フォーマットは既に述べたとおりで、Supported by most triple storesそしてGeoJSONに変換できる強みがあるので、今の文脈だと最も利便性が高いだろう。3Dサポートが必要になった時には、GMLを使う。この２つで十分じゃないかな。他にHTMLはウェブでの発見性という利便性が強調されていたけど、LODの Content negotiation 使えばそれで問題ないわけだし。
結局語彙はどれを使うべきか
- データフォーマットでWKTとGML使うなら、語彙はgeosparqlを中心につかえばよい。
- ウェブでの表示は GeoJSON に変換して表示する
- WKT は多くのtriple storeで演算がサポートされているようだ。
- 構造化で簡単に緯度経度だけ付記したければw3cgeoでの記載を伴わせる。
- GeoCoordinates - schema.org schema.org でもよい。ここは好みの問題
- ISA Programme Location Core Vocabulary locn は何でも使えるようにしてあるが、逆にわざわざ使う場面は少ないかも。多様な形式で書かれたデータを変換など事前にせず雑多なままデータ化したいときに便利かもしれない。
- vcard と georss は名刺情報や更新される地理情報を書くときなど、用途次第では周辺ツールの対応があって有効かも。
