[Nepomuk] Loads of Questions

[Artem Serebriyskiy]

On Mon, Sep 6, 2010 at 11:10 PM, Vishesh Handa <handa.vish at gmail.com> wrote:

> This is a rather large mail that I've written to Sebastian. I'm posting
> this on the mailing list because some people might want to know what's going
> on and maybe participate in the discussion.
>
> ---------------------------------
>
> Hey Sebastian
>
> I've got a couple of questions regarding different things. I was hoping you
> could answer some of them. Ideally I would have liked to catch you online
> but my college hours are quite absurd. :-/
>
> Sync Library
> =========
>
> 1. *Design question -* Generally when syncing something, it is done in 2
> steps -> Identification and Merging. During the Identification all the
> resources that could not be identified and are NOT of type
> nfo:FileDataObject are created. This is done *during the Identification
> process*. However Artem made me realize that this might not be ideal. In
> his case he likes to check if the identification was successful and
> according merge the resources. In that case the IdentificationRequest would
> land up creating some Resources which would be ignored if he chooses not to
> merge.
>
> One solution to this is to have some kind of placeholder uri which the
> IdentificationRequest maps the resources to when creating a new Resources,
> and the actual creation is done during the merge process. Do you approve? Or
> should I just let it be the way it is?
>
> 2. *The addition of vital properties and required properties for
> identification -* I still haven't gotten around to doing this, mainly
> because it would be a huge change that would break everything ( The existing
> syncfile format, and the internals of IR ). Do you think it is required? I
> didn't feel like starting it during the gsoc period as if I broke too many
> things I wouldn't have anything proper to submit. I'm CCing Artem.
>
> Btw, in case you don't remember - Vital properties would be those
> properties without which the identification would fail. And optional would
> be those which are nice if they get identified but don't contribute to the
> actual score (How would that be useful?)
>

optional properties are properties that contribute to the actul score if
they match, but their absence or mismatch don't decrease the actual store

> Nepomuk Syncing
> ==============
>
> Backup kinda works ( I don't know why it doesn't work for you, some stuff
> with KArchive internals :-( I still have to look into it ) but I still need
> to do some work for Syncing to work properly. Here are a couple of things I
> need -
>
> *1. Nepomuk database identifier -*  Syncing works pretty well when you do
> it once, but if you do it multiple times ( as most people would ) you have
> to perform the identification every time. This is not acceptable if the
> identification fails and the user has to do it manually. I was hoping to
> have some kind of identifier which could be used to uniquely identify a
> Nepomuk database. That way I could save the resource mappings after the
> initial identification are avoid re-identifying the same resources each
> time.
>
> *2. Some way to store the last sync date - *Initially I was going to store
> the date in some config file, but that wouldn't be appropriate as I need to
> store the last sync date to each Nepomuk database. So we probably need some
> kind of ontology which could help us represent this internally.
>
> *3. Communication Medium - *The Nepomuk enabled machines need to
> communicate with each other in order to generate the correct sync files, and
> transfer them to each other. How do I go about doing that? Telepathy? I was
> looking into Avahi, but I thought I'll just ask before I start trying
> something.
>
> *4. The GUI - *Any ideas or anything you can think of would be great!
>
> After GSoC
> =========
>
> Now that gsoc is over I would ideally like to start the process of
> polishing the Sync Library so that it can be moved to kdelibs. That way I
> could start using it in all the places it should be used, namely,
> Strigi, Removable Media stuff and the Akonadi Feeders. I was hoping you
> could go through the library API, and just help out.
>
> *KUrls - *I know how you prefer KUrls over QUrls ( rightly so! ), and I
> think I should use KUrls everywhere in the library. It would however break
> the current API, which isn't a big deal since Artem and I are the only ones
> using it. Do you think we should go for it? Or should we just use KUrl
> internally?
>

Sebastian, why do you prefer KUrl over QUrl ?

>
> Metadata Sharing
> ==============
>
> Our meeting during Akademy was cut short, and there are still many things
> that need to be finalized. The main thing that needs to be taken care of is
> the new ontology for security and a couple of other things. Maybe we could
> set a date to discuss this?
> ----
>
> I think that's about it. :) Take your time. I don't expect you to answer
> everything immediately.
>
> - Vishesh Handa
>
>


-- 
Sincerely yours,
Artem Serebriyskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100907/d1abe975/attachment.htm