Question on EntityCache

[agazzarini]

Hi,
this is more a question than an "issue".
I'm new to Silk, I'm just trying to change a bit the simple example in order to fit my use case (interlinking a file of triples with some external datasets).

Now, the very first time I run Silk.execute() with reload = true everything works and produces some links. I see two folders under $HOME/.silk/entityCache/Interlink@id

• source
• target

where, I suppose, Silk caches the source and target resource lists.
Now, after

• changing a bit my source file (i.e. changing some literals, adding some triples)
• running again Silk.execute() with reload = false (i.e. I don't want to reload the target dataset because it's huge)

I got the same exact results. My question are:

• if I want, for each invocation, change the source, do I have to run Silk with reload = true?
• Is there a way for retaining only the "target" entity cache?

Many many thanks
Andrea

[afeliachi]

Hi Andrea,
Unfortunately you have to reload if there is any changes in the source or the target, I had the same issue once, and yes by activiating the reload, both source and target are reloaded :(
But by looking into the code I think this can be easily changed

[agazzarini]

Hi @afeliachi,
many thanks for your response.

I'm not sure, as I'm a Silk newbie, if it makes sense to have that as a feature or not.

[afeliachi]

I think if it's really doable, it would be a great feature, especially in cases like yours when datasets are huge.

[afeliachi]

I suggest you add an "idea" flag (label) to this issue if possible.

[agazzarini]

I cannot edit the issue attributes. Are you able to do that?

[afeliachi]

me neither. I'm not sure but I think it's up to the members of the project only.

[agazzarini]

So that means we have to become members of the project :)

On 14/04/16 13:00, afeliachi wrote:

me neither. I'm not sure but I think it's up to the members of the
project only.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#61 (comment)

[afeliachi]

that would be better :)