Re: RDF merge (Re: [Gzz] PR)

[Tuomas Lukka]

On Tue, Apr 01, 2003 at 01:10:42AM +0200, Benja Fallenstein wrote:
> Tuukka Hastrup wrote:
> >On Mon, 31 Mar 2003, Tuomas Lukka wrote:
> >
> >>>Hmm... could this be possible after we have Loom working also as RDF 
> >>>editor? How much the final xml-file would change between loading, 
> >>>editing and saving? I mean, is it at any way possible to have a CVS 
> >>>shared RDF files for our project management?
> >
> >If we save as alphabetically sorted triples or such, CVS would notice the 
> >smallest change set. But there could still be CVS merge problems, and we 
> >don't want to deal with them. Or maybe if the conflict remover proves to 
> >be a simple sed-script that removes the duplicated parts of CVS conflict 
> >syntax...
> 
> I think with simple NTriples syntax it could actually be reasonable to 
> resolve these manually in the infrequent cases where they occur...

I agree - the really important thing here is that we *CAN* do that since
thing would be rather more comprehensible than with the earlier gzz stuff.

> >>Hmm... actually, with RDF, the first way of merging changes would be to 
> >>just
> >>take the space to be the set of triples. 
> >>
> >>CVS wouldn't do it right, but it wouldn't be too hard to make a real
> >>merge tool that you could trust enough to know what it would do in a
> >>given situation.
> >
> >As long as we save into CVS, we will have some kind of conflict problems, 
> >I think. But how far are we from using Mediaserver architecture again?
> 
> That wouldn't solve the problem: we'd still have conflicts and would 
> still have to deal with them!

Indeed.

> To tell you the truth, I'd be much more comfortable with putting 
> NTriples files in CVS than with using Storm. It's so much more 
> accessible with simple tools, and for outsiders who don't know about all 
> the different parts of our project...

Well, of course it should be accessible from elsewhere using HTTP, CVS,
whatever someone wants to use.

> I think it's better if we start using our tools, but independently of 
> each other: not move from CVS to Loom+Alph+RDF+Fenfire+Storm+X in one 
> hop, but start using the different tools for different things 
> one-by-one. 

Yes! This is what made Gzz so difficult to get up to release 0.8.

Now that we have the subprojects, we should try to work this to our advantage.

> >If our append-only format for RDF is simply additions and deletions of 
> >triples, could we load the document as all blocks some pointer has ever 
> >pointed to, sorted by date (ie. don't care about multiple "current" 
> >blocks, and use obsoleting only to determine loading order)?
> 
> That would mean that a conflicting commit would 'destroy' (render 
> invisible) the data of the person who saved first. Do you really think 
> that overwriting is less annoying than resolving conflicts, even if the 
> latter is annoying?

No, I think tuukka meant "merge by set union". While this has its good
points, it could make for really messy structures as well.

> OTOH, there are of course triples that conflict in RDF-- not on the 
> syntactic, but the semantic level. If we both change a string, the net 
> result of having two different strings isn't very useful probably-- it 
> should be pointed out to the users to fix.

Yes.

Actually, the reification in RDF might be useful there: when you have
semantically conflicting triples, you'd annotate them with the source version 
id.

        Tuomas