Re: GeoSPARQL draft spec now publically available

[Claus Stadler]

Hi,

>> Sorry for not having contributed anything since the geovocamp.

Same goes for me so far.
However, at the vocamp in Southampton, at one time I said, that it would be cool to have a sparql-sql rewriter for LinkedGeoData.
And someone (I think Andreas?) said that I should do that.
So that's what I have been working on ;)

I recently had a first success of querying the OSM simple schema by rewriting a sparql query with geo predicates to a postgres query making use of postgis predicates via view definitions.
However, I need to implement some optimizations first, before it gets really useable - for example, right now rewriting a sparql query on 5 sparql-sql-views results in an almost 200KB long query *g*. (Fortunately, in this example almost all join- and where conditions evaluate to false and can therefore be pruned; actually my work makes use of some ideas presented in the publication "Rewriting queries on sparql views", where they already present solutions to such problems.)

Anyway, I hope that I can set up a very experimental endpoint with limited features at the end of next month.
So just wanted to let you know that I am still alive, and working on something, but in the moment its at a too early stage for a presentation.
Eventually I have see how far I can get towards GeoSparql, but right now I am focussing on postgis' geo-predicates.

Cheers,
Claus



On 07/13/2011 06:29 PM, Dominic Harries wrote:

Hi all,

Sorry for not having contributed anything since the geovocamp - I have not been doing so much mapping stuff lately, though am still interested.

If anyone wasn't aware, the GeoSPARQL draft spec is now available for public feedback at the following URL:

http://www.opengeospatial.org/standards/requests/80

Haven't had time to fully digest but it looks good.  One of the concerns that I remember having was that it wouldn't work for linked data - i.e. you could use a SPARQL query to see whether something was in something else:

SELECT * {
       ?x a geo:Geometry.
        ?y a geo:Geometry.
        FILTER(geof:sf-within(?x, ?y))
}

But not this:

SELECT *  {
        ?x a geo:Feature.
        ?y a geo:Feature.
        ?x geo:sf-within ?y
}

This relation could be (a) precaculated or (b) worked out using some magic.  I think req 4 and the topology vocabulary extension (section 7) does allow this.  Furthermore it looks like the magic in case (b) would actually be something like the RIF rule described in section 10.

The one major thing that we discussed that I haven't seen is the idea of describing geometry as an rdf:List.  If you have:

?x a geo:Feature.

Then maybe you would say

?x geo:hasGeometry ?g.
?g geo:asRdfList ([The rdf:List])

Or maybe:

?x geo:hasGeometry ([The rdf:List])

Would be interested to hear if anyone has had a play with GeoSPARQL.  Does anyone know if there are any implementations available?

Don't know if I should have addressed this to a mailing list rather than reply all, the link in the email I'm replying to seems to be broken.


Regards

 
Dominic Harries
Emerging Technologies Specialist

Phone: 44-1962-81-8589 | Tie-Line: 248589 E-mail: dhar...@uk.ibm.com	Hursley Park Hursley, SO212JN United Kingdom

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU



From:        Juan Salas <jms...@gmail.com>
To:        Claus Stadler <csta...@informatik.uni-leipzig.de>
Cc:        Alexander De Leon <m...@alexdeleon.name>, Dominic Harries/UK/IBM@IBMGB, Andreas Harth <ha...@kit.edu>, lmvi...@fi.upm.es, jeremy...@nottingham.ac.uk
Date:        25/04/2011 15:27
Subject:        Re: Geometry Ontology

---

Hi Claus,

Nice to hear from you, hope that everything went fine with those tasks
:). Sorry I can't help you with the RDF-wrappers, I have also no
experience with those services either.

I'm glad that you are interested in investigating alternative mappings
for OSM and the geometry ontology. We have created a mailing list [1]
so we can stay in touch and colaborate on this topic. There's also a
Google Code project [2] if you want to contribute to the vocabulary,
and a "soon-to-be-improved" website [3]. For the Google Code project
I'll need a Google Account from you, in order to add you as a member.

Cheers,
Juan

[1] http://groups.google.com/group/neogeo-vocabulary
[2] http://code.google.com/p/neogeovocab/
[3] http://geovocab.org/



2011/4/24 Claus Stadler <csta...@informatik.uni-leipzig.de>:
> Hi all,
>
>>>  Claus, please count with me if you need a hand with the OSM RDFizer.
>
> Thank you for the offer. I might come back to it :)
> After a paper deadline at the beginning of May I want to investigate
> alternative mapping approaches for the OSM data. I also want to investigate
> the discussed usage or RDF lists and the geometry ontology.
> However up to now I didn't really advance on this subject.
>
> This was very busy month for me with a lots of tasks running in parallel,
> and each of them making troubles at some point :)
> One of them is the following question which maybe someone of you already
> knows the answer to:
>
> Do RDF-wrappers for the OGC Web Map Service, Web Feature Service and Web
> Catalog Service exist?
>
> I was asked whether such thing existed. Unfortunately I don't have much
> experience with these services.
>
> If the following example I found is representative, then it seems like you
> put in an URI and get XML back. So it might something that URI rewriting and
> XSLT could accomplish?
> http://www.snowflakesoftware.com/webservices/OWS7_AIXM51_WFS20.htm
>
>
> Best regards and happy easter,
> Claus
>
>
>
> On 03/25/2011 11:19 AM, Alexander De Leon wrote:
>>
>> Hi everyone,
>> It was a very positive experience to work with all of you these past
>> couple of days. I hope we can continue this great work and deliver some
>> useful results to the community.
>>
>> Juan, you said you could setup a googlecode or github project to work on
>> the ontology. I think that will be very useful so we can all contribute and
>> provide reviews/feedback for the changes.
>>
>> Claus, please count with me if you need a hand with the OSM RDFizer.
>>
>> Hope to see you soon in the next event.
>>
>> Cheers,
>> Alex
>>
>> On 23/03/2011, at 17:06, Juan Salas wrote:
>>
>>> Hi Everyone,
>>>
>>> I attach the emails from everyone so we can stay in contact and keep the
>>> fun going. I will upload the ontology into Google Code and let you know.
>>>
>>> Best Regards,
>>> Juan
>
>

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[gjdev]

There is a GeoSparql implementation that is being used/developed in
the Open Sahara project. It's (at least not yet) not compatible with
the draft from opengeospatial, but based on the same principles. Thus
geometry objects are stored in literals and can be queried using
filters based on the simple features specification. See
https://dev.opensahara.com/projects/os/wiki/IndexingSail for more
info. A simple example query would be:

PREFIX search: <http://rdf.opensahara.com/search#>
PREFIX geo: <http://rdf.opensahara.com/type/geo/>
SELECT DISTINCT ?result WHERE {
?result <http://example.org/geometry> ?geometry.
FILTER(search:within(?geometry, "POLYGON((0 0, 0 1, 2 1, 1 0, 0
0))"^^geo:wkt)
}

This IndexingSail is supposed to work with any semantic database that
offers a Sesame Sail layer to program against. We are using it with
Sesame Native and Bigdata at the moment (and we are currently
optimizing the query engine to take advantage of some Bigdata specific
features). The open-source version uses a Postgis (R-Tree-over-GiST)
index to index the geometry statements.

We (Open Sahara team) are currently looking at the opengeospatial
standard to see if it makes sense to implement that. So far I have a
couple of issues with the standard:
- There is going to be a lot of redundant data in a triple store if
the standard is followed because every geometry literal defines its
geometry type (point, line, polygon, etc.), and then also needs to be
wrapped inside an rdf object instance that again needs to define the
type. Imho forcing redundancy in data via a standard is really bad
practice.
- It is really unclear to me why some spatial functions work on the
literals, some on the geometry rdf objects, some on both, and then
some properties are only avaliable as linked data on the rdf objects,
etc.
- The standard is layered (good), but imho the lowest layer should
focus on functionality that works without RDFS reasoning. A lot of the
described functionality would work really well without RDFS, and in
projects were scalability is an issue RDFS should not be mandatory for
geospatial query functionality.

Just my 2cnts...

On Jul 14, 3:32 pm, Claus Stadler <ravenarka...@googlemail.com>
wrote:

> I recently had a first success of querying the OSM simple schema by
> rewriting a sparql query with geo predicates to a postgres query making
> use of postgis predicates via view definitions.

...

> > If anyone wasn't aware, the GeoSPARQL draft spec is now available for
> > public feedback at the following URL:
>
> >http://www.opengeospatial.org/standards/requests/80
>