gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] org/fenfire/util/RDFList.java


From: Tuomas Lukka
Subject: Re: [Gzz] org/fenfire/util/RDFList.java
Date: Mon, 14 Jul 2003 20:01:05 +0300
User-agent: Mutt/1.5.4i

On Mon, Jul 14, 2003 at 04:01:29PM +0200, Benja Fallenstein wrote:
> 
> Tuomas Lukka wrote:
> >On Mon, Jul 14, 2003 at 01:58:01PM +0200, Benja Fallenstein wrote:
> >>You're thinking of bags. Read the documentation above.
> >
> >Well, the versioning of lists is very intricate, and also depends
> >very much on the internal representation.
> >
> >For linked lists, two sets of incompatible changes can get you
> >a loop, if not dealt with properly (see the 
> >gzz/Documentation/VersioningMerge).
> 
> Ok, true, for merge it's a problem.
> 
> Last time you raised this, you were talking about--
> 
> >For the RDF _1, _2, ... types of lists, it's worse: an insertion
> >maps to O(n) tuple changes.
> 
> which is bags, not "collections" (lists); this is about diff/patch, and 
> I assumed again you were talking about problems when doing diff/patch, 
> not merge.
> 
> In CVS, we can probably represent lists through the special RDF syntax:
> 
>     <hasAuthors rdf:parseType="Collection">
>         <rdf:Description rdf:about="http://ex.org/foo"/>
>         <rdf:Description rdf:about="http://ex.org/bar"/>
>     </hasAuthors>
> 
> (This is a list with two elements.) CVS will then handle merge just fine.

Well, fine for some definitions of fine - at least you'll get a conflict
if two people reorganize the list.

However, what I'd like is some ability to go by the IDs, i.e. do merge
based on sets of triples.

The atoms and molecules stuff I did has bearing on this: it essentially
solved the diff-merge problem for linked lists, I think.

> When doing a triple-wise diff, the merge will indeed have to handle 
> lists specially. I think the partial order stuff would probably be fine.

Yes. And that's one reason I wouldn't like to take in lists 
before we have a clear picture of merge; I'd prefer to first have merge
and then add lists and add support for them to merge at the same time,
so as to not make merge even more difficult at first ;)

> [other mail]
> >Let's talk first about *for what* is it going to be used.
> >
> >Different types of lists need different versioning constraints.
> 
> Ok, how so? (Which types of lists need different merge handling?)

It depends on how important order is.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]