# Re: Geo in RDF (was Re: Censorship?)

From: Boris Villazón Terrazas <bvillazon@fi.upm.es>
Date: Thu, 18 Nov 2010 01:54:14 +0100
Message-ID: <4CE47936.8020409@fi.upm.es>
To: Stuart Williams <skw@epimorphics.com>

```Hi Stuart

On 16/11/2010 12:21, Stuart Williams wrote:
> Hello Boris,
>
> On 15/11/2010 23:51, Boris Villazón Terrazas wrote:
>> Hi Stuart, all
>>
>> On 15/11/2010 15:26, Stuart Williams wrote:
>>> Hello Boris,
>>>
>>> On 13/11/2010 15:11, Boris Villazón Terrazas wrote:
>>>> I only want to point out our ongoing work in the context of the
>>>> GeoLinkedData [1], in which  we are working with geospatial data.
>>>> Basically, we are using geo:lat/geo:long style of giving position
>>>> in WGS84 coordinates. A geospatial resource, for example a
>>>> geoes:Provincia, has a geo:geometry, and this geo:geometry consists
>>>> of a set of geo:points , and each geo:point consists of geo:lat and
>>>> geo:long. You can find a figure describing this at [2].
>>> I've got a minor question wrt to the use of geoes:order in the
>>> diagram at [2]. It seems to be giving the ordinal position of a
>>> Point in a LineString. It seems to me that there isn't a single
>>> value of geoes:order which applies to a given point... it depends on
>>> what LineString the point is being included in.
>> We use the order for drawing the lines on the map, and we need to do
>> it in the right order. So, first, line from Point(x1,y1) to Point
>> (x2,y2), then line from Point(x2,y2) to Point(x3,y3) and so on.
>> That's why we use the geoes:order
> I think I understand the intention. My question really is how you use
> the same point in multiple curves - for example where two regions
> touch and share a common segment of their respective boundaries. For
> example reveals a number of points with more than one value for
> geoes:order:
>
>     select distinct ?point ?order1 ?order2  where
>     { ?point a <http://www.w3.org/2003/01/geo/wgs84_pos#Point>;
>       FILTER(?order1 < ?order2)
>     } ORDER BY ?point ?order1 ?order2
>
> e.g.:
>
> Maybe that's intentional, its just that order within a linestring
> doesn't seem to me to be an invariant property of a point, more of its
> 'use' in defining a curve.

Very good point, we realized this issue in the last few weeks.
We need to restructure the model.
>
>>>> A specific example, the resource Albacete Provincia at [3].
>>>> Also, we have a browser at [4].
>>>>
>>>> I think this is related with the discussion.
>>>> We can provide further information regarding the conversion from
>>>> GML to RDF we performed.
>>>
>>> I think that the details of your conversion are fairly clear in your
>>> presentation at http://www.slideshare.net/boricles/geo-upmv14boris
>> Basically, the information from the Spanish Geographical Institute
>> are stored in Oracle 11 databases, and the geometry information in a
>> blob column.
>> We use the Oracle STO Util package [X]  for transforming the blob
>> column value into GML.
>> Then, we use GeoTools [Y] and Jena [Z] for converting GML into RDF
>> following the model described in the diagram at [2]
>>>
>>> What I am looking for is a *widely* adopted practice, perferably
>>> backed/endorsed by a defacto or de-jure standards organisation. I
>>> don't think I have found such a beast except for the case of Point
>>> positions expressed as WGS 84 lat/long in which case there is
>>> widespread community practice in the use of the "Basic Geo (WGS84
>>> lat/long) Vocabulary" [a].
>>> [a] http://www.w3.org/2003/01/geo/
>>>
>> Our geometry points are compliant to geo:
>> http://www.w3.org/2003/01/geo/wgs84_pos#
> Yes, I can see that for points expressed in WGS 84. I happen to have
> some data that expresses points as ETRS89 lat/long(i.e. with a datum
> fixed to continental Europe). In truth for my application the
> difference between ETRS89 and WGS 84 doesn't really matter - ~2.5cm
> per year continental drift. However, ideally I would like to express
> them as being ETRS89 which conveys (at least some level of) invariance
> over time within Europe. Yes, being pragmatic, I can express them as
> WGS 84 and maybe be as much as 25cm adrift by now - and in this
> particular case that's good enough for most/all practical purposes...
> but...
>>> For curves (LineStrings), surfaces(Polygons) and  Boxes (Envelopes),
>>> the Geo OWL vocabulary at [b,c] which mirrors GeoRSS GML [d] seems
>>> to me to come close to being something that a common practice might
>>> develop around, however it does 'camp' in an opengis.org namespace
>>> without obvious endorsement from the OGC (unless I missed finding
>>> that, which is perfectly possible).
>>>
>>> [b] http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/#owl
>>> [c]
>>> http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/W3C_XGR_Geo_files/geo_2007.owl
>>>
>> We have checked them, but at that time we prefer to follow the
>> gml:LineString, however we can extend our model to include them.
> It looks to me like you are using WKT encodings form [1]
Yes, you are right.
>>
>>> I think Gannon was making a point about localized re-invention of
>>> vocabulary either being inevitable or maybe accidental - either way
>>> and potentially linits the reuse of data assets published using a
>>> particular local practice. It also mitigates against tooling,
>>> developing to support such things as spatial-indexes in SPARQL
>>> stores, because without the use of common vocabularies you loose the
>>> triggers that would induce index building - and responsive UIs
>>> seeking to display artefacts within spatial bounding boxes could
>>> well do with the help a spatial index could give.
>> Why don't all of us  start to collect the experiences we have to
>> publish and consume geoespatial linked data?
> Where I am at is that  I have data that I want to publish as RDF.
> Currently its only point data, but in general I'd expect to have line
> segments and polygons. The coordinates systems being used in the data
> are ETRS89 and UK National Grid. Yes... I can convert to WGS 84 (in
> some cases that is a time dependent conversion) - but I'd like to
> respect the data's original form.

Ok, I see. So, you are suggesting do not convert the data from the
original reference system, and keep the original one.

>
> What I don't see is firm guidance on how to publish anything other
> than WGS84 point positions as RDF. Yes... I could follow one of a
> number of [previously mentioned] emerging patterns and
> 'it-would-be-nice' (tm) for there to be some convergence of practice.
> I could make up my own scheme, but that would kind of miss the point
> and only add to the problem.
I agree with you there is a clear need of best or common practices to
publish geospatial information.

>
>> Thoughts? suggestions?
> I guess my ideal would be for guidance to emerge from OGC, ISO TC 211
> and/or W3C.  That may be happening... but I don't have a good handle
> on what activity (if any) is focussed on this topic.

Boris

>> Best
>>
>> Boris
>>
> BR
>
> Stuart
> --
>>
>> [X] SELECTTO_CHAR(SDO_UTIL.TO_GML311GEOMETRY(geometryColumn))
>>
>> AS Gml311Geometry
>>
>>       FROM "DB"."TABLE" c
>>
>>       WHEREc.Name='Arroyo'
>>
>> [Y] http://www.geotools.org/
>> [Z] http://jena.sourceforge.net/
>>>>
>>>>
>>>> geo: http://www.w3.org/2003/01/geo/wgs84_pos#
>>>> [2]: http://mccarthy.dia.fi.upm.es/challenge/example1.png
>>>>
>>>
>>> BR
>>>
>>> Stuart
>> --
>> Boris Villazón-Terrazas
>> Ontology Engineering Group (OEG)
>> http://www.oeg-upm.net
>>
>> Departamento de Inteligencia Artificial
>> Campus de Montegancedo, s/n