[Nepomuk] Re: A couple of things

[Sebastian Trüg]

On 06/06/2011 09:24 PM, Vishesh Handa wrote:
> /Hello List. Sebastian and I started talking about the current state of
> backup sync, and I send him a PDF (attached) of what the current
> problems are. I realize that this discussion should be more public,
> hence the CC. ( We are also discussing some internal stuff in the DMS )/
> 
> Hey Sebastian
> 
> On Tue, Jun 7, 2011 at 12:06 AM, Sebastian Trüg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
> 
>     Hi Vishesh,
> 
>     let me start at the end:
> 
>     3. ranges: having more than one range is indeed perfectly possible and
>     adding support should be fairly simple. But would you be ok if we put
>     that off until 4.8
> 
> 
> It's just something that occurred to me, so I brought it up. I'm in no
> hurry to fix it.
>  
> 
> 
>     2. properties without a domain default to their parent property's domain
>     or rdfs:Resource if there is no parent property. At least that is what I
>     always assumed. But I think the former is not implemented. SO that would
>     have to be fixed.
> 
> 
> I forgot that all properties would have a domain of rdfs:Resource. I'll
> get started on not allowing abstract properties in storeResource. 

Do you really need to? After all that check is already in
ClassAndPropertyTree::variantListToNodeSet which applies to all methods
including storeResources.

Ok, now I need to sleep. More tomorrow.

Cheers,
Sebastian

> 
> 
>     1. backupsync
>     * It seems to me although it is less nice and clean than introducing
>     something like DeletedResource logging the deleted resources in a
>     compressed file might be the simplest solution.
> 
> 
> How do we hook this up in time for 4.7? I'm hoping do re-write the
> backup system this week, and have a very stable version ready for RC1. (
> Yes, this qualifies as a bug fix. ) 
>  
> 
>     * Remember the backup of graphs and their metadata. Actually IMHO for
>     backup simple dump and restore would be sufficient.
> 
> 
> Of course. Now it would even be worth the effort. Dump and restore +
> some amount of user identification is sufficient. 
>  
> 
>     we do not really
>     need any syncing there. But if you want to keep the design then a very
>     cool feature would be to allow the user to restore specific resources
>     (which have been deleted or changed).
> 
> 
> No. I'm going to keep syncing and backup separate. They'll both depend
> on the nepomuksync library. But that could still be added.
>  
> 
>     * If you do backups that depend on another keep in mind that
>      1. users might delete them manually (this is a minor point though
>     since users should simply not do that)
> 
> 
> The problem with fresh backups are that they are time consuming and
> there is no way to avoid it. With incremental backups will mainly be
> done for automated backups. I don't think there will be a big problem
> with the user deleting the backups. 
>  
> 
>      2. If you delete older backups you might need to merge them into the
>     newer ones or design the whole thing in a way that removing one backup
>     file will simply mean that this data can no longer be restored. ie. data
>     older than N days is lost for real when deleted.
> 
> 
> I rather not have a system like that. I'm hoping for something like this -
> * User creates a backup - A - It's a fresh backup, which would be very
> similar to what is being done right now.
> * User creates an incremental backup - A is copied - B. And the changes
> since A, are merged into B. A remains unaffected.
> 
>     * I like the nxx:sameAs approach. But the practical problem with that is
>     that resources on two systems could have similar URIs although they are
>     completely different. Sad but true: QUUID is not even close to unique -
>     for now.
> 
> 
> I know the uuids are far from unique, that's why I proposed we have
> something like - nepomuk:/res/some-identifier/uuid
> 
> What do you think of having some way to identify each system? And do you
> have any thoughts on how the two machines which need to be synced will
> communicate?
> ---
> 
> You haven't made any objections nor have you said - Makes sense, go
> ahead. So, I'm going to assume your silence means "Yes! Vishesh, the new
> design is exactly what we need, and you're awesome for figuring it out!" :-P
>  
> 
> 
>     Cheers,
>     Sebastian
> 
>     On 06/02/2011 11:37 AM, Vishesh Handa wrote:
>     > Hey Sebastian
>     >
>     > I've written down about the new backup-sync framework. Please
>     could you
>     > read it and give me your comments. I would like to fix backup in time
>     > for 4.7.
>     >
>     > Apart from that, your definition of abstract properties are those
>     which
>     > do not have a range. I think we shouldn't allow properties which
>     have a
>     > domain as well. If you're okay with it, I'll make the necessary
>     changes,
>     > and implement blocking of abstract properties in storeResources.
>     >
>     > I was going through your ClassAndPropertyTree, and I noticed that it
>     > only gives one range and domain. A property could theoretically have
>     > many ranges and domain. Did you purposely avoid this? Or  is it
>     > something we should take care of?
>     >
>     > Thanks
>     > Vishesh Handa
> 
> 
> 
> 
> -- 
> Vishesh Handa