Fenfire vs. Gzz (was: Re: [Gzz] Re: Gzz-dev Digest, Vol 4, Issue 46)

[Benja Fallenstein]

Dear Jack,

to reply to the last question first--

Jack Seay wrote:
> Why were the changes made?

Because of Ted's US patent on zzstructure. We wanted our project to be 
Free Software, which would have required Ted to grant a license to all 
GPL-covered code or so, or us to disallow use and distribution in the 
US. Ted wouldn't grant us such a license because he wants to form a 
business based on ZigZag, and we did not want to restrict distribution.

> How will fenfire differ from and be the same as gzz?

Fenfire will use the RDF model <http://w3.org/RDF/>. Structurally, the 
two big differences are:

1. Properties/dimensions are not restricted to one neighbour in each 
direction. (In other words, RDF is simply a directed, labelled graph.)

2. Resources (which correspond to cells) do not have content. Instead, 
connections can not only be from resource to resource, but also from 
resource to *literal*-- basically, just a text string.

More subtly, properties are thought of as semantic relationships; in 
zzstructure, dimensions often do not map to semantic relationships 
directly, even though zzstructure may be used to *represent* semantic 
relationships.

Example: If I represent a poem in zzstructure, I may create a row on d.1 
with cells containing the title, text, date, and so on. I may take the 
cell containing the title to represent the poem in many cases (for 
example, when cloning).

In RDF, I would create a *resource* representing the poem. As noted 
above, this doesn't 'contain' anything. Rather, it has a set of 
properties; on dc:title it is connected to a literal containing the 
title, on poem:text to a literal with the text, on dc:date to the date 
it was written.

Fenfire will be the same as Gzz in that--

- The goal hasn't changed: We want to build a computing environment 
where everything can be connected to everything else at a fine-grained 
level, without the need for hierarchies or files.

- We're still building a 'basic editor' for exploration and editing the 
structure, usable for many structural applitudes and for notetaking.

- We still provide our own implementation of Xanalogical storage.

- We still provide a cryptographic hash- and p2p-based alternative to 
file storage (at the level below zzstructure/RDF), called Storm.

- We still use the Vob system for animating between independently 
programmed views.

- We still use novel OpenGL-based user interface technologies for 
visualizing the connections between data from different applitudes.

(This list isn't meant to be exhaustive.)

Fenfire will be different in that it will be more modular. We're 
separating out a number of already-independent packages from Gzz into 
independent projects, which Fenfire will depend on.

> What data structures will replace the xanadu-zigzag structure in fenfire?

RDF, as described above, will replace zzstructure (zigzag).

We will continue to provide our own implementation of Xanalogical 
storage, since this does not seem to be patented.

> Will it support the same feature set? (infinite dimensions, 
> transclusions, simple royalty payments, versioning, etc.)

It will support an infinite set of properties (properties are resources, 
which are named by URIs). Xanalogical transclusions will be supported. 
Likely, we won't have a 1:1 mapping of d.clone; instead of cloning a 
resource, you will more likely refer to it from two different places 
(both work1 and work2 have dc:author person:Niki).

Versioning will still be supported. No work on simple royalty payments 
has been done in this project so far, neither in Fenfire nor Gzz nor 
GZigZag.

Hope this helps,
- Benja