Hi Andy, Thanks for your explanations! I've got the idea of jena-spatial. I can create it following the way of jena-text, with 2 implementations of "nearby" and "within" at least. It's OK for this part.
As to the Fuseki task, it does not aim at jena-spatial, is it? Do you mean the other Jena GSoC projects [1] [2]? I've checked the source code of Fuseki UI pages. Could you tell me what's the technology, e.g. "sparql.tpl"? What's "tpl"? [1] https://issues.apache.org/jira/browse/JENA-420 [2] https://issues.apache.org/jira/browse/JENA-427 Best regards, Ying Jiang On Tue, Apr 23, 2013 at 8:26 PM, Andy Seaborne <a...@apache.org> wrote: > On 22/04/13 13:50, Ying Jiang wrote: >> >> 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. > > > LARQ / jena-text: > > Think of jena-text as "LARQ v2". The LARQ 1 internal design is quite old > and does not play so well with RDF datasets and update, as well as adding > assembler capabilities because currently LARQ 1 needs some coding work to > integrate with Fuseki. > > GeoARQ is not specifically related to the formal Jena project. > > What I had in mind for jena-spatial is exploiting the spatial capabilities > of Lucene to create a fully integrated capability that we can add to the > main download when it's stable. As many of the "nearby" or "bounding box" > queries for point spatial data. Geospatial stretched to much more > complicated relationships but I believe that a lot of useful things can be > done with less than the full geospatial model which is too complicated for > the average web developer to take on board with their limited time. > > >> 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? > > > (My take - others may have a different view) > > A management/admin interface to running a Fuseki server. Add and remove > datasets to a running engine, report statistics (see e.g. Solr's web > interface and stats page). > > An orthogonal matter is improved query and update forms. Those are good - > it is the admin and control that I think will really help people in > deploying data publishing systems for real use. > > >> 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? > > > All those things! > > There isn't a official proposal form for Jena but all those things you have > on the list are good. > > (Stephen - any more that needs to be done?) > > Do ask more questions for anything you need, > > Andy > > > >> >> 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> >>>>> >>>> >>> >
