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

[Benja Fallenstein]

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...

> > 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!

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...

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. That gives us a safer platform to start from, and makes it 
easier for others to enter.

Especially because now that we use RDF, we *can* use the parts 
independently.

> 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?

> Nodes are never created or deleted. A triple cannot be deleted if it 
> wasn't there, so it can't be both deleted and created at the same time. Or 
> here's one problem: A triple exists in version O. In version A1(O) it's 
> deleted and further added back in version A2(A1). On the other hand, in 
> version B1(O) it's just deleted. When we load the set with all O, A1, A2, 
> B1; the triple might be deleted or be re-created.
>
> Anyway, I hope the conflicts should be easier to solve than previously.

Certainly. That's one of the reasons for RDF...

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.

CVS merge handling would do that on that level, btw... :-)

- Benja