[Nepomuk] How to config virtuoso-t?

Vishesh Handa me at vhanda.in
Wed Jan 8 12:08:30 UTC 2014


On Sunday 05 Jan 2014 05:57:23 Michael Jerger wrote:
> Hi,
> 
> maybe it's good to giv u a short intro of myself?
> My name is Michael and I attend the semantic enterprise service for an
> international company as architect. Also I'm kde user for more than 10 
years
> - so thanks for your good work :-).
> 
> Since I started to use kmail again, one old virtuoso-t problem raised 
again
> - virtuoso-t grabs all my free memory - in my case 16G - so there is no 
ram
> left for my beloved development ide vms (the versions I use: 
ubuntu10.13 /
> nepomuk4.11.3).
> 

The next version of KMail is not going to be using Nepomuk. We're moving 
away from virtuoso and the whole "semantic web".

So you should have a better KMail experience with 4.13

> I've seen, that my virtuoso-t get's its config out of
> /tmp/virtuoso_dT2859.ini at the moment  (NumberOfBuffers=2000 
indicates its
> configured for 2Gb) - so my question is: Can u tell me, where this config
> comes from? Is there the posibility to limit the memory usage manually 
(the
> nepomuk frontend for limiting virtuosos memory has gone)?
> 

I removed it in the latest version because virtuoso does not really respect 
those settings (as you have noticed).

> There is on more question - I've seen your privicy thougths at
> http://userbase.kde.org/Nepomuk#Sharing_and_privacy. So at my 
semantic
> enterprise service I've similar problems - so do you have made any brain
> work for this topic allready? May I be interested in your ideas and
> experiance?
> 

Most of the Nepomuk developers had grand ideas about sharing the 
Nepomuk data. In fact I once prototyped a distributed nepomuk service 
which would register itself on the local network and allow sparql queries to 
be run on all the systems in a local network.

That was terribly impractical because of the issue of privacy. We then 
thought about implementing some sort of an ACL for the rdf data, but the 
more we tried to plan it out, the more complex it got. Eventually, nothing 
got done.

> 
> Best regards,
> Michael

-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20140108/5294a5fe/attachment.html>


More information about the Nepomuk mailing list