Dear Andy, Sorry for the late reply. These days, I've been studying the source code of Jena pfunction, LARQ, jena-text and GeoARQ. Now I can understand all of them by every single code line :). This summer, I think I can take the concept of jena-text and make a similar one applied to geospatial information. I'd like to compose a project proposal when the GSoC website opens for the student applications. Before that, could you please help me with the following questions:
1) It seems LARQ and jena-text provide the same functions of text searching. If we have LARQ, why bother to use jena-text? What're the differences of the goals, the users, the use scenarios? I also have the same doubt with GeoARQ and the product of this GSoC project, since GeoARQ already provides the "near" and "within" functions. 2) For the integration with Fuseki. What do you mean by "a better Fuseki UI"? Does UI here mean client-side javascript/css work? Can you tell me more details about this part? 3) Is there a GSoC project proposal template for Jena? Basically, it should include self-introduction, project goal, project plan, etc, I think. What's your opinion? Best, Ying Jiang On Tue, Apr 16, 2013 at 8:32 PM, Andy Seaborne <a...@apache.org> wrote: > This is a potential GSoC project - I'd see it firstly being a separate > codebase as it develops, then get some people using it and providing > feedback and, if it's popular, it can move into Jena proper. The nice thing > is that doesn't (err "shouldn't") require modifications to the main modules > as it should use standard extension mechanisms. However, if the mechanisms > prove inadequate, we can fix the extension mechanisms. > > This is the very similar to the status of jena-text - it's in /Experimental > so anyone can look, use and contribute but it's not in the Jena > distribution. If and when it's considered stable, it could become part of > trunk. That's a group decision to be made. > > The project is also open ended depending on how "simple" it is. There are > some jumps in going from, say, points to polygons in the data that I think > are just too big for the GSoC timeframe but there are potential additional > query functions to just "near". > > At least look at GeoSPARQL [1] to see what a complete solution looks like. > I think that the sweet spot is something simpler (and less capable) because > the average web developer, even if writing SPARQL, isn't looking for a > complete solution to all geospatial use cases. They are looking for > something easier (= smaller). There is space for both approaches. > > Being able to use Lucene-spatial for the index, and have it instep with the > data, rather than an external rpcoess like PostGIS (c.f. Parliament) makes > it much more usable. > > It also avoids some licensing issues - some geo libraries are GPL,LGPL which > makes them unsuitable for Apache. > > Combine this with any work on a better Fuseki UI, and we have a nice, > easy-to-use SPARQL server that gets people up and running with interesting > features beyond basic RDF storage and query. > > Andy > > [1] http://www.opengeospatial.org/standards/geosparql > > > > On 15/04/13 22:52, Gyanasekaran Radhakrishnan wrote: >> >> This is an awesome idea which could be extensively used if implemented (I >> would!). Is this going to be a stand-alone project for GSoC? I would be >> interested in working in this. >> >> Thanks >> ~Gyan >> >> >> On Mon, Apr 15, 2013 at 9:37 AM, Andy Seaborne <a...@apache.org> wrote: >> >>> === Spatial query >>> JENA-10 >>> >>> Not all spatial queries are complicated. Many use case are covered by >>> provision of a single facility like get all objects within a given radius >>> or within a given bounding box. GeoSPARQL which is a complete approach >>> to >>> geospatial query but it is complicated and driected more towards the >>> specialist, not the average linked data developer with SPARQL knowledge. >>> >>> This project is to provide a one or two basic geospatial query functions. >>> >>> Example: return places within 10 kilometers of Bristol UK (which as >>> latitude/longitude of 51.46,2.6). >>> >>> SELECT ?placeName >>> { >>> ?place spatial:query (51.46 2.6 10) . >>> ?place rdfs:label ?placeName >>> } >>> >>> >>> We have a similar property function architecture in jena-text [0] so this >>> project is to take that concept and apply it to geospatial information. >>> >>> Lucene spatial could be used for the spatial index. There is a simple >>> vocabulary for expressing WGS80 information [1]; there is also the point >>> information in WKT [2]. >>> >>> This project is not primarily about geospatial processing; it is >>> concerned >>> with the indexing and querying simple, existing geospatial data and >>> integration with Fuseki. >>> >>> [0] >>> http://jena.staging.apache.**org/documentation/query/text-**query.html<http://jena.staging.apache.org/documentation/query/text-query.html> >>> [1] http://www.w3.org/2003/01/geo/ >>> [2] >>> http://en.wikipedia.org/wiki/**Well-known_text<http://en.wikipedia.org/wiki/Well-known_text> >>> >> >
