Accessing DKPro LSR's instance of WordNet/GermaNet

[matlaj]

I think it's a common use case to utilize not only the functions exposed by DKPro LSR for GermaNet and WordNet, but also other functions provided only in the WordNet/GermaNet APIs. (One example missing in LSR is getIlirecords() from the GermaNet API.)
However, creating a LexicalSemanticResource object and also a WordNet/GermaNet object can require too much memory.
It should be possible to either access the WordNet/GermaNet object created by LSR, or to provide an existing GermaNet/WordNet object to LSR to construct the resource class with (through the ResourceFactory class or maybe directly to the relevant resource class?).

[logological]

I endorse this request. DKPro Similarity uses DKPro LSR to access GermaNet. It wouldn't be unusual for someone to be developing an application with the GermaNet API and wanting to use the similarity methods provided by DKPro Similarity. In such a scenario it wouldn't make sense for DKPro LSR (via DKPro Similarity) to create its own instance of the GermaNet database when the parent application already has one.

[reckart]

@logological would you like to/can you take care of the the request/PR?

[matlaj]

@reckart if you mean the actual implementation, I could also do that. Actually, I've already made the change locally. The question is, which implementation would you prefer: a method to get the the object from DKPro LSR (this is what I did, it's just a getter method inside GermaNetResource.java), or some way to provide a manually constructed object to either the ResourceFactory class or to GermaNetResource directly (the "nice" way is probably to adapt ResourceFactory, but this seems a bit more tricky).

[reckart]

@user-is-M I don't have a strong opinion on that. The code which is using the Spring XML file is quite old. It was a way of externalizing the configuration. If I would do this nowdays, I'd probably wrap the resources up in JARs and have some mechanism which scans the classpath for resource declarations and load them - in addition to a mechanism to provide hand-configured resources. I'd say it all depends on how involved one wants to get with the source code.

@logological WDYT?

[logological]

@reckart: When you say you'd "wrap the resources up in JARs", are you proposing that we do this ourselves and distribute the JARs along with (or alongside) DKPro LSR? If so, this isn't possible for GermaNet, which is proprietary, and it's probably not feasible for collaboratively edited LSRs like Wikipedia and Wiktionary and OpenThesaurus, where users will probably want the latest version.

We could provide some mechanism for users to produce their own JARs, but that isn't solving the problem of requiring manual configuration.