Hey,
I just saw https://issues.apache.org/jira/browse/JENA-1301
Should we not first officially deprecate it and gives any users of Solr a
chance to move to different Indexing technology?
BTW, I dont know yet how to login to apache JIRA.
Thanks,
Anuj Kumar
On Fri, Mar 3, 2017 at 1:23 PM, anuj ku
I Osma,
I briefly looked at the pull request. I beieve we need to upgrade Lucene
and Solr in one go, isnt it. The reason being Solr 4.9.1 depends on Lucene
4.9.1
Also how do i log into issues.apache.org and where to file this bug?
Thanks,
Anuj Kumar
On Fri, Mar 3, 2017 at 11:22 AM, Osma Suomin
Hi Anuj,
It's great that we found agreement over this!
I've restarted the Lucene upgrade effort (JENA-1250) that had stalled
and made a PR [1] that implements the upgrade up to version 6.4.1 (with
5.5.4 as an intermediate step). I'll wait for comments on the PR and if
people think it's OK I w
I second that. I am now finalising the integration of ES and should have a
good production quality implementation ready in a week's time. At that
time I would want you guys to have a look at the implementation and provide
feedback. Once you guys have upgraded Lucene to 6.4.1 , I can merge the
code
I do agree that trying to juggle different versions of Lucene libraries is
probably not a realistic option right now. Luckily (if I understand the
conversation thus far correctly) we have a solid alternative; getting our
current Lucene dependency upgraded should allow us to (eventually) merge An
Just FYI, I was able to index multiple fields in ElasticSearch using Jena
Text capability.
The issue was in my ElasticSearch code where I was doing insert every time
instead of an update :/
Cheers!
Anuj Kumar
On Wed, Mar 1, 2017 at 7:40 PM, anuj kumar wrote:
> Thanks Osma. I sent my previous em
Thanks Osma. I sent my previous email just a minute early. I will try your
suggestion and if it doesn't work will send you the entire example.
Thanks again.
Anuj
On 1 Mar 2017 19:36, "Osma Suominen" wrote:
> Hi Anuj!
>
> Generally I use assembler descriptions to configure the jena-text index.
>
I agree Osma. If Lucent is upgraded to 6.4.1 it would be much easier for me
to integrate the Elastic Search implementation.
But I am still waiting for someone to provide me a hint as to how I can
index multiple predicate values. This is the most pressing issue for me
currently.
Thanks,
Anuj Kumar
Hi Anuj!
Generally I use assembler descriptions to configure the jena-text index.
An example with multiple properties (SKOS label properties) is here:
https://github.com/NatLibFi/Skosmos/wiki/InstallTutorial#creating-a-text-index
For examples on how to use assembler descriptions from Java cod
Hi Anuj!
I have nothing against modularity in general. However, I cannot see how
your proposal could work in practice for the Fuseki build, due to the
reasons I mentioned in my previous message (and Adam seemed to concur).
In any case, I'll see what I can do to get the Lucene upgrade moving
> On Feb 28, 2017, at 11:23 AM, Osma Suominen wrote:
> 28.02.2017, 17:12, A. Soroka kirjoitti:
>> https://lists.apache.org/thread.html/dce0d502b11891c28e57bbcbb0cdef27d8374d58d9634076b8ef4cd7@1431107516@%3Cdev.jena.apache.org%3E
>> ? In other words, might it be better to factor out between -text a
BTW, I have one more question:
How do I add more than one field to be indexed in my Index?
Basically, if I want to index rdfs:label , rdfs:comment in the same index
document, how do I do it?
I tried :
EntityDefinition entDef = new EntityDefinition(DOC_TYPE, FIELD_TO_SEARCH);
entDef.setPrimaryPre
I personally have no preference as to how the code in Jena should be
structured, as long as I am able to use it :).
I have personal preference of doing it in a specific way because IMO, it is
modular which makes it much easier to maintain in the long run. But again
it may not be the quickest one.
Osma--
The short answer is that yes, given the right tools you _can_ have different
versions of code accessible in different ways. The longer answer is that it's
probably not a viable alternative for Jena for this problem, at least not
without a lot of other change.
You are right to point to t
Hi Anuj!
Thanks for the clarification.
However, I'm still not sure I understand the situation completely. I
know Maven can perform a lot of tricks, but Maven modules are just
convenient ways to structure a Java project. Maven cannot change the
fact that at runtime, module divisions don't real
Hi Osma,
I understand what you are saying. There are ways to mitigate risks and
balance the refactoring without affecting the existing modules. But I will
not delve into those now. I am not an expert in Jena to convincingly say
that it is possible, without any hiccups. But I can take a guess and s
Hi Anuj,
I understand your concerns. However, we also need to balance between the
needs of individual modules/features and the whole codebase. I'm willing
to put in the effort to keep the other modules up to date with newer
Lucene versions. Lucene upgrade requirements are well documented, the
Hi,
My 2 Cents :
The reason I proposed to have separate modules for Lucene, Solr and ES is
exactly for avoiding the "All or Nothing" approach we need to take if we
club them all together. If they stay together and if in the near future I
want to upgrade ES to another version, I also need to agai
28.02.2017, 17:12, A. Soroka kirjoitti:
https://lists.apache.org/thread.html/dce0d502b11891c28e57bbcbb0cdef27d8374d58d9634076b8ef4cd7@1431107516@%3Cdev.jena.apache.org%3E
? In other words, might it be better to factor out between -text and -spatial
and _then_ try to upgrade the Lucene version?
I second Osma's congrats!
Do we want to take this into account:
https://lists.apache.org/thread.html/dce0d502b11891c28e57bbcbb0cdef27d8374d58d9634076b8ef4cd7@1431107516@%3Cdev.jena.apache.org%3E
? In other words, might it be better to factor out between -text and -spatial
and _then_ try to upgr
Hi Anuj!
Congratulations for getting the PoC working!
I'm not sure I like the idea of having a separate jena-text-es module.
Am I right that your main concern with creating a separate module is
that the Elasticsearch client library requires a newer Lucene version
than what jena-text currently
Hi All,
*Apologies for the long email.*
As some of you know, I have been working on extending Jena to Support
ElasticSearch for Text Indexing (in addition to Lucene and Solr).
I have come to a point where I have a basic (read non-prod) code that can
index RDFS:label text data into ElasticSearch
My saviour Osma. It worked :)
Thanks for pointing that out. Really appreciate it.
I am now to my next task. Implementing the actual code for ElasticSearch
integration with Jena.
Thanks once again.
Anuj Kumar
On Tue, Feb 14, 2017 at 2:22 PM, Osma Suominen
wrote:
> 14.02.2017, 15:15, anuj kumar
14.02.2017, 15:15, anuj kumar kirjoitti:
I will do it. But I need to first get the simple test working in order to
move forward. I hope I someone here can help me.
Maybe you need to add an implementWith declaration to TextAssembler.java?
-Osma
--
Osma Suominen
D.Sc. (Tech), Information System
I will do it. But I need to first get the simple test working in order to
move forward. I hope I someone here can help me.
Thanks,
Anuj Kumar
On Tue, Feb 14, 2017 at 2:13 PM, Osma Suominen
wrote:
> 14.02.2017, 15:03, anuj kumar kirjoitti:
>
>> I was working on a local copy of Jena source code
14.02.2017, 15:03, anuj kumar kirjoitti:
I was working on a local copy of Jena source code initially.
I have now forked Jena and added my specific files as I specified in my
previous email to ease debugging by more experienced Jena developers.
The forked repo can be found here : https://github.c
Thanks Osma.
I was working on a local copy of Jena source code initially.
I have now forked Jena and added my specific files as I specified in my
previous email to ease debugging by more experienced Jena developers.
The forked repo can be found here : https://github.com/EaseTech/jena
You will see
Hi Anuj,
I'm not sure what the problem is - maybe others more familiar with the
assembler can help - but would it be helpful to work on a fork of the
Jena source tree instead of a separate project? Then all the scaffolding
to load the right classes etc. would already be in place. Maybe you are
Thanks Lorenz for the quick headsup. Here is the Github link to the listed
files : https://github.com/EaseTech/jena-text
Thanks,
Anuj Kumar
On Tue, Feb 14, 2017 at 12:46 PM, Lorenz B. <
buehm...@informatik.uni-leipzig.de> wrote:
> Attachments do not work on this mailing list, thus, it's better t
Attachments do not work on this mailing list, thus, it's better to share
resources via some service like Github etc.
> *Anuj Kumar*
--
Lorenz Bühmann
AKSW group, University of Leipzig
Group: http://aksw.org - semantic web research center
Hi,
I am working on an application where my data (in N-Triple format) is
stored in HBase and now we want to provide a Free Text search capability to
our end users and we have decided to use ElasticSearch (Not listing the
actual reasons here for keeping things simple but in jist using Lucene or
Sol
31 matches
Mail list logo
