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>
