RDF GeoSpatial Ontologies
Juan Salas
Gary Berg-Cross
Juan Salas
Sean Gillies
Continuing the discussion from the pedantic web list ... I'd like to
use these relations between features without any blank intermediary
geometries. If I have feature geometries, I can (modulo the scale
issues you mention) calculate them explicitly.
Cheers,
On Wed, May 11, 2011 at 9:19 AM, Juan Salas <jms...@gmail.com> wrote:
> Hi Sean,
>
> Thanks for your email, you are right about the typo. However, this is
> also quite a tricky subject, so it's good that you point it out. We
> currently define spatial relations between features, but whether the
> spatial relations should be defined at the feature or geometry level
> is open to debate.
>
> The problem is that sometimes a feature may have many geometries, and
> a given spatial relation may not apply for all of them. By many
> geometries I don't mean a composite geometry (e.g a MultiPolygon), but
> different geometries such as different resolutions of the same
> polygon. In this case a point may or may not be within a geometry
> depending on which one you are looking at.
>
> However, if you decide to represent only spatial relations and not
> geometries, you would have to define empty geometry resources for the
> features, just to define the spatial relations between them, which is
> one of the reasons we currently define spatial relations between
> features.
>
> I think that this is an interesting topic, so it's good that you point
> it out.
>
> Best Regards,
> Juan
>
> On 9 mayo, 12:59, Sean Gillies <sean.gill...@gmail.com> wrote:
>> On Mon, May 9, 2011 at 9:28 AM, Juan Salas <jmsa...@gmail.com> wrote:
>> > Hi everyone,
>> > My name is Juan Salas (from the "Universidad Tecnológica Nacional" in
>> > Argentina) and I have recently been working on a vocabulary for representing
>> > GeoData in RDF along with Andreas Harth (Karlsruhe Institut für
>> > Technologie), Claus Stadler (LinkedGeoData.org, Universität Leipzig), Luis
>> > Vilches and Alexander De Leon (GeoLinkedData.es).
>> > We have finished a preliminary specification of a vocabulary for
>> > representing geometries [1] and spatial relations [2], there are also
>> > examples and explanations in this document [3] and at the main site [4]. We
>> > would really appreciate any kind of feedback you could provide us (we will
>> > provide corresponding acknowledgements in further publications, of course).
>> > Also if you are interested in contributing to the project, help is always
>> > welcome.
>> > Best wishes and thank you in advance,
>> > Juan
>> > [1] http://geovocab.org/geometry
>> > [2] http://geovocab.org/spatial
>> > [3] http://geovocab.org/doc/neogeo.html
>> > [4] http://geovocab.org/
>>
>> Hi Juan,
>>
>> Should the Spatial ontology description read "A vocabulary for
>> specifying relations between features"? It currently reads "...
>> between geometries".
>>
>> Regards,
>>
--
Sean Gillies
Programmer
Institute for the Study of the Ancient World
New York University
Juan Salas
Andreas Harth
On 05/11/2011 07:29 PM, Sean Gillies wrote:
> Continuing the discussion from the pedantic web list ... I'd like to
> use these relations between features without any blank intermediary
> geometries. If I have feature geometries, I can (modulo the scale
> issues you mention) calculate them explicitly.
I guess what you want could be achieved by setting domain and range
of the spatial relations to dcterms:Location (which is defined as
"A spatial region or named place."), assuming that satial:Feature
and ngeo:Geometry are subclasses of dcterms:Location.
How to automatically propagate the relations between Feature and
Geometry would be unspecified and should be implementation-specific
because of the scale issues that Juan mentioned.
Does such an approach sound ok?
Best regards,
Andreas.
Juan Salas
To everyone interested in our vocabulary, there is a demo
representation of the NUTS classification [1]. There we use our
vocabulary to represent the geometries and HTTP Content Negotiation to
provide alternative representations of them, such as GML and KML.
Some sample features are:
http://nuts.geovocab.org/id/DE
http://nuts.geovocab.org/id/DE4
Features and geometries are represented separately in RDF but are
shown together in HTML in order to make the representation more user-
friendly.
You can access the alternative representations by asking for its
corresponding MIME-Type. For example, if you want to get the KML
representation using cURL from the command line you could do:
curl -L http://nuts.geovocab.org/id/DE_geometry -H "Accept:
application/vnd.google-earth.kml+xml" -o DE_geometry.kml
Or if you want the GML file:
curl -L http://nuts.geovocab.org/id/DE_geometry -H "Accept:
application/vnd.ogc.gml" -o DE_geometry.gml
So any suggestions about it or the vocabulary are very welcome and if
you have any questions please don't hesitate to ask.
Best regards,
Juan
[1] http://nuts.geovocab.org/
Carsten Keßler
thanks for the update. I really like the content negotiation approach for geometries!
I was in a different group at geovocamp so I might have missed this discussion: How do you make sure that the order of the points in your polygon is preserved in the RDF representation of the geometry? Shouldn't there be some construct using rdf:first / rdf:rest to make sure that clients get the order of the points right?
Cheers,
Carsten