[Nepomuk] Loads of Questions

[Vishesh Handa]

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?)

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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100907/9f99c012/attachment.htm