Hi Francisco, any progress on this issue?
Since I do not see that much activity in the code level [1], honestly I'd prefer a more fluent communication here. Maybe weekly reports on your progress would work to keep us aligned with the working plan. In addition, according the program timeline [2] we're approaching the mid-term evaluation. So please, take it into account. Cheers, [1] https://github.com/cuent/marmotta/commits/MARMOTTA-584 [2] https://www.google-melange.com/gsoc/events/google/gsoc2015 On Fri, Jun 19, 2015 at 8:16 AM, Sergio Fernández <[email protected]> wrote: > Hi Xavier, > > On Fri, Jun 19, 2015 at 4:23 AM, FRANCISCO XAVIER SUMBA TORAL < > [email protected]> wrote: >> >> > It'd be great if you could point us the fork at github. Then I can >> closely >> > follow the development, checking the commits, giving feedback on the >> > patches, etc. >> >> I’ve created a new branch from develop and I add you as a contributor >> [1]. There is 10 functions implemented. > > > Perfect, thanks. I've just pointed it from our wiki. The ongoing patch > could be found at > https://github.com/apache/marmotta/compare/develop...cuent:MARMOTTA-584 > I'll try to follow the development from there. > > BTW, where are you writing the documentation we discussed earlier in the > project? As I said, I'd prefer our wiki; although markdown in your code > would be better than loosing such knowledge. > > >> My account of GitHub is from another email of Hotmail, is that a problem? > > > Not really. > > >> I worked with the implementation of NativeFunction. But here appeared a >> >> new problem. Some of the RDF files with GeoSPARQL model, not loaded to >> >> marmotta. >> >> >> >> ERROR: "Caused by: org.postgresql.util.PSQLException: ERROR: The >> string is >> >> too larg >> >> to to tsvector (1177006 bytes, m├íximo 1048575 bytes) " >> >> >> >> As I can solve this problem?. >> >> >> >> Some geometries (Multipolygons, MultiLineString) have large WKT >> > >> > Looks that module has some limitations, but I can only found old >> references >> > related with the issue, such as: >> > >> > http://requesttracker.wikia.com/wiki/PostgreSQLFullText >> > >> http://www.postgresql.org/message-id/[email protected] >> > >> > What version of PostgreSQL are you using? >> >> I keep having the same issue. I’m using the version 9.4, >> > > Then it's a serious issue. I found the current limitations at: > > http://www.postgresql.org/docs/9.4/static/textsearch-limitations.html > > Going into more detail, a text search vector is an array of distinct > lexemes (less any stopwords) and their positions. It looks like the > tsvector data consumes 2x the space required by the input text, but I think > it actually depends on your concrete configuration and input data. > > Why do we need to store the geometries in a vector? I guess we're not > gonna perform full-text search over them, right? Therefore we may need to > change how those concrete literals are stored in KiWi. > > Good progress! Please, continue working and discussing here. > > Cheers, > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: [email protected] > w: http://redlink.co > -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 6602747925 e: [email protected] w: http://redlink.co
