From kde-core-devel Thu Dec 12 11:34:40 2013 From: Ivan =?utf-8?B?xIx1a2nEhw==?= Date: Thu, 12 Dec 2013 11:34:40 +0000 To: kde-core-devel Subject: Re: Nepomuk in 4.13 and beyond Message-Id: <1582772.F0TcDPS1MW () drako> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=138684810617166 Aloha, > - Resource Description Framework (RDF) > The biggest problem with RDF is that it raises the knowledge needed to I'm not sure this was *the* problem with nepomuk adoption, but lets ignore that for a moment :) So, nepomuk was based on rdf and sparql. Essentially, a simple and standardized yet really slow (and overly academic) technology that (in our case) introduced quite a few issues, as you already stated. What is a replacement for sparql in baloo? (the wiki page is quite underwhelming) Things here seem to be quite separated. Are the different 'stores' at least sharing a same instance of a database? (aka, are akonadi, and other stores going to share a single instance of **sql) How are the following things going to be implemented (some use-cases that come to mind): - telepathy and akonadi contacts (kpeople implementation) - linking a contact (kpeople vs akonadi) to an activity - linking a file to an activity - linking an application to an activity - getting emails of contacts that are linked to an activity - getting emails with attachments of contacts that are linked to an activity > Additionally, RDF is a very flexible way to store data, it is however not > the most efficient way. Data is generally completely normalized even though Agreed. RDF stores are usually slow because they focus on flexibility as a most common use-case which it is not. > you've read the basic ideas behind Baloo [2] As I said, the basic ideas are overly basic when you come from outside world and don't know what is written between the lines. :) Ch! -- There are no such things as applied sciences, only applications of science. -- Louis Pasteur