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

[Jürg Billeter <j bitron ch>]

On Fri, 2009-07-31 at 14:07 +0300, Ivan Frade wrote:
> 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... 

It is possible if you use a different graph URI for each SPARQL update
(=origin), and then describe that graph with an arbitrary amount of
statements (as in your list). However, it might increase the amount of
data quite a bit if used intensively. I don't know whether the overhead
is justified.

JÃrg