Re: [Tracker] The quadruple, team conversations on IRC

[Ivan Frade <ivan frade gmail com>]

About the quad store,

On Fri, Jul 31, 2009 at 1:17 PM, Martyn Russell <martyn lanedo com> wrote:

On 29/07/09 13:53, Philip Van Hoof wrote:

o. We want to start having a quadruple alongside the decomposed sqlite
   tables.

   o. Such a quadruple will allow us to implement backup

   o. Such a quadruple will allow us to implement named graph support

I think we need some real world examples here. At least from what I have seen with 0.6. the problems come when we want to store data like LastPlayed or Tags and from multiple locations. For example, if there are 2 media players or perhaps a file can be used in a video player AND a music player and they both want to store LastPlayed independently or have Tags uniquely set by themselves not shown between all players.

Are there any others good examples I have missed here?

Named graph means to add a fourth element to the "triplets" (then are not triplets anymore, i guess). We can use that forth parameter for a lot of things or for none:

* we can use it to mark the "source" of the information (hard-disk, removable-device, flickr, facebook),
* we can use it for backup... (how? where is the logic to decide if something is ready for backup?... )
* we can use it for sync (again, how? a pseudo code from the application point of view)
* we can use it to differentiate the embedded and not embedded metadata

 BUT we cannot use it for the 4 things at the same time, unless we have the same triplet 4 times...

Besides in a lot of cases that 4th value can be simulated as a new property for the subject:

(graph A, subject, predicate, object) ==> (subject, predicate, object), (subject, "graph", A)

      o. Would make the KDE people interested in using Tracker for their
         mobile targets (according to discussions with them at the
         desktop summit conference earlier this month)

 Are they doing anything useful with those "named graphs"? Or it is used only to set the author of the ontologies? :P

o. The quadruple will store all metadata, also embedded metadata. This
   will create an overhead of about 10% during storage. It wont give any
   overhead for read queries.

This should still be faster than the 0.6 branch as far as I understand.

We are adding cholesterol to tracker without clear benefits. That is code to maintain, to fix, to answer queries about it, applications will abuse of it and we will need to fight with that.

We haven't explore completely the triplet thing and we are jumping into the fourth dimension!

o. We will check if we can win back some of that 10% (some ideas are
   floating around)

Well, we still have to spend some time polishing master ;)

This is no-no for the first 0.7.0 right?

o. If the embedded metadata can be left out of the quadruple then we
   should try to achieve that.

 Embedded/non-embedded is indeed the only case i see some utility to the quad.

People can followup development of the quadruple in the "quad" branch on
GNOME's git. This branch will likely soon be merged to "master".

 I hope not, until it is clear what can we do with it that we cannot do right now (fixing the ontology if necessary), with practical examples. I still dont see how will "sync" work with this store. Is the fourth parameter a "sequence-id" ? and what if that triplet is non-embedded at the same time?

Regards,

Ivan