Hi Andy, I agree with you. A consistent style of would be better. In the project proposal, I just listed the features that we could do. As to the property function names, the arguments and the styles, they can be discussed and adjusted.
Best regards, Ying Jiang On Thu, May 2, 2013 at 7:30 PM, Andy Seaborne <a...@apache.org> wrote: > On 30/04/13 16:44, Ying Jiang wrote: >> >> Hi Andy, >> >> I'm grateful to your advice. I think withinCircle and withinBox are >> both possible to be made. I've composed and submitted the project >> proposal to Apache GSoC 2013 here: >> >> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jpz6311whu/7003 >> >> Any comments are welcome! > > > Well - it has made it in the system and is in the Apache area. > > Nothing I can see needs changing. > > > > One minor comment: > > 2.2 could be folded into the style of 2.1. This is the sort of detail that > chnages as we gain experience with usage of the system. > > If the query can be > > ?point :withinCircle (?X radius) > > and ?X a literal of datatype point 2.1 and 2.2 are very similar. > > It's a bit weird to change the operation just on the fixed syntax of 2 or 3 > arguments so maybe two property functions > > ?point :withinDistance (point radius) > > ?point :withinCircle (?X radius) > > is clear to the user and the two property functions go to much the same > code. But this is a minor change. > > Generally a consistent style of > > ?output :property (arguments.) > > As stated, 2.2 puts the output on the right. > > RDF lists don't have comma in - eventually, the brain reprograms eventually > to cope, but not sure mime has. Ditto SELECT lists. :-) > > > Andy > >> >> Best regards, >> Ying Jiang >> >> On Mon, Apr 29, 2013 at 9:08 PM, Andy Seaborne <a...@apache.org> wrote: >>> >>> On 28/04/13 11:25, Ying Jiang wrote: >>>> >>>> >>>> Hi Andy, >>>> >>>> The link about the spatial relationships you provided is very >>>> interesting. I've tried to study Lucene to figure out whether they are >>>> possible to be implemented. Shall we use Lucene 4.x or 3.x? >>> >>> >>> >>> 4.x, unless there is some good reason for needing 3.x; currently, I >>> don't >>> see one. When starting a new piece of work, starting with legacy is just >>> overhead. >>> >>> >>>> For the >>>> current release of Lucene 4.2.1, it provides a high level abstraction >>>> for spatial query usage. >>>> - SpatialOperation [1]: compares a stored geometry to a supplied >>>> geometry. such as "IsWithin" and "Intersects". Actually, all of them >>>> are not supported. >>>> - SpatialStrategy [2]: encapsulates an approach to indexing and >>>> searching based on shapes. Different implementations will support >>>> different features. There're 3 implementations [3] now: >>>> PointVectorStrategy, RecursivePrefixTreeStrategy and >>>> TermQueryPrefixTreeStrategy. For example, PointVectorStrategy supports >>>> only "IsWithin" for Rectangle or Circle, while >>>> RecursivePrefixTreeStrategy can caculate "Intersects" of any kinds of >>>> Shapes. I'd like to make full use of Lucene to make jena-text support >>>> as many spatial relationships as possible. On the other hand, I can >>>> also make new SpatialOperations like "Northing/Westing" mentioned in >>>> [4] that are not available in Lucene. To wrap things up, here're the >>>> jena-spatial features that I can do this summer: >>> >>> >>> >>> For all these, framing a use case would be good. Maybe that's a >>> documentation matter :-) >>> >>> >>>> >>>> 1) ?A -> within -> B >>>> A: Point Var >>>> B: Rectangle or Circle >>>> Approach: PointVectorStrategy directly supports this >>> >>> >>> >>> Can a circle be specified in the query as (point, radius)? >>> >>> The use case I can think of is wanting all places with a box or circle >>> centred on a given point. Maybe its what this does with "B" being >>> >>> ?point :withinCircle ( x,y,r ) . >>> >>> ?point :withinBox ( x1,y1,x2,y2) . >>> >>> SPARQL isn't going to be particularly pretty specifying boxes and circles >>> but probably better than a WKT/GML literal! >>> >>> >>>> 2) A -> nearby ->?B, C >>>> A: Point >>>> B: Point Var >>>> C: radius >>>> Approach: RecursivePrefixTreeStrategy makes >>>> SpatialOperation.Intersects for the Circle with the center of A and >>>> the radius of C >>> >>> >>>> >>>> >>>> 3) A -> intersects -> ?B >>>> A: any Shape >>>> B: non-Point Shape Var >>>> Approach: RecursivePrefixTreeStrategy directly supports this (note: not >>>> tested) >>>> >>>> 4) A -> intersects -> ?B >>>> A: any Shape >>>> B: Point Var >>>> Approach: TermQueryPrefixTreeStrategy directly supports this >>>> >>>> 5) A -> northing/southing/easting/westing -> B >>>> A: Point >>>> B: Point >>>> Approach: use rangeQuery, or RecursivePrefixTreeStrategy makes >>>> SpatialOperation.Intersects of north/south/east/west Rectangle >>> >>> >>> >>> >>> >>>> >>>> 6) A -> disjoint ->B >>>> A: Rectangle >>>> B: Rectangle >>>> Approach: PointVectorStrategy directly supports this (note: it >>>> doesn't handle dateline cross) >>>> >>>> They are from a developer's view of whether it's possible to be >>>> implemented. It's grateful to hear any comments from users' opinions. >>>> Are they enough or useless for basic spatial queries? >>>> >>>> For the Fuseki task, I don't think it's suitable for me to work on >>>> this summer. Just like I mentioned in the first e-mail, I'm not a web >>>> application development guy. It would take some time for me to study >>>> Apache Velocity. I'm not very familiar with the client-side stuff of >>>> javascript/css. In this 3-month GSoC project, I'd like to be more >>>> focused on the jena-spatial design and development. If more spatial >>>> relationships are required to be implemented, I would be happy to work >>>> on. I'll come up with a project proposal if it's basically OK. Thanks >>>> for your consideration! >>> >>> >>> >>> (treat the fuseki task as a completely project - it can be 3m on its own >>> - >>> don't mix it with spatial work - they are orthogonal). >>> >>> The next step is to write+submit the proposal. >>> >>> Andy >>> >>> >>>> >>>> Best regards, >>>> Ying Jiang >>>> >>>> >>>> [1] >>>> >>>> http://lucene.apache.org/core/4_2_1/spatial/org/apache/lucene/spatial/query/SpatialOperation.html >>>> [2] >>>> >>>> http://lucene.apache.org/core/4_2_1/spatial/org/apache/lucene/spatial/SpatialStrategy.html >>>> [3] http://lucene.apache.org/core/4_2_1/spatial/overview-tree.html >>>> [4] http://beta.data.ordnancesurvey.co.uk/ontology/spatialrelations/ >>>> >>>> >>>> On Fri, Apr 26, 2013 at 8:07 PM, Andy Seaborne <a...@apache.org> wrote: >>>>> >>>>> >>>>> On 26/04/13 04:34, Ying Jiang wrote: >>>>>> >>>>>> >>>>>> >>>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> This is interesting: >>>>> >>>>> http://beta.data.ordnancesurvey.co.uk/ontology/spatialrelations/ >>>>> >>>>> other spatial relationships (regions not just points) but less that >>>>> full >>>>> GeoSPARQL. >>>>> >>>>> >>>>>> >>>>>> 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"? >>>>> >>>>> >>>>> >>>>> >>>>> No - the Fuseki tasks are not jena-spatial related. It should be >>>>> possible >>>>> to have a Fuseki server with spatial support by simply adding it to the >>>>> build/classpath. >>>>> >>>>> The .tpl files are Apache Velocity. Usually that's .vm but I thought >>>>> making the external name tied to the internal technology was a bad idea >>>>> for >>>>> a server side technology (may, in theory, want to change the templating >>>>> system - they were JSPs). >>>>> >>>>> Andy >>>>> >>>>> >>>>>> >>>>>> [1] https://issues.apache.org/jira/browse/JENA-420 >>>>>> [2] https://issues.apache.org/jira/browse/JENA-427 >>>>>> >>>>>> Best regards, >>>>>> Ying Jiang >>>>> >>>>> >>>>> >>>>> >>> >
