Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a Standard Graph-Based...")

[Alatalo Toni]

On Sat, 8 Mar 2003, Benja Fallenstein wrote:

> Hi Danny,

yet,

> > the general problem (many blogged at [1]),
> Cool. I have had a short look  at your blog before, but need to look deeper.

i guess i should too

> What do you think about having a mailing list where these get posted &
> we can discuss them? I think that would be valuable for me. If there is
> interest, I can set a publically logged one up under the Fenfire project
> at savannah.nongnu.org.

might be a good idea. (to not get these double, do x-postings work with
mail btw? prob. not. and anyhow, not to spam these lists with all this)

> > use for this kind of thing (notably TM)
> Whoops, another thing I didn't know about. TM?

Topic Maps? i don't know them too deeply either.
but i guess you can do them with RDF..?-o

> Loom is our RDF editor, based on lessons learned from zzstructure
> editor. It uses focus-and-context views: You see a 'focused' node in the
> middle of a window, and around it, the nodes it's connected to. It will
> be usable indepent from the rest of Fenfire. I hope to release a 0.1,
> which only supports browsing and no editing yet, next week.

right. and here we can explore the differences of zz and rdf in a way,
too.

> Buoyoing ("Buoy-oriented interface, next generation") is our scheme for

didn't know/remember the name, actually :)

> integrating data from different applications. This, too, is a

.. neither the purpose. OTOH you did not use that with the mail client,
but the plain client instead?  do you know how Augment handles e-mail,
btw? me neither.. but heard it does do that.

> html-like document. In the margins, you see pieces of other documents
> that are linked to this document, *buoys*, and there are lines
> connecting the buoys to the piece of the main document they're linked
> to. When you click on a buoy it becomes the focus (animated), and the
> formerly focused document moves into the margin, becoming a buoy.

screenshots of this are available in several places, in several submitted
articles i mean and of course in the cvs. there are copies of some of
those as e.g. http://an.org/fenfire/xupdf1.png and
http://an.org/fenfire/xupdf2.png which i believe demonstrate this (those
addresses only for the sake of shorter URLs)

> > Why do you need the same byte sequence?
> Um, in short: We identify versions of graphs by cryptographic hashes,
> and to get the hash of a version, we need to serialize it in a canonical

also, the same format (rdf) is used in-memory

> represent Unicode characters. Maybe a Unicode version of nTriples.

hm, don't know nTriples from before but perhaps that is a way

> Re Ideagraph, btw: You asked me for comments earlier following our urn-5
> discussion (I wasn't able to reply due to time constraints). The thing

oh, didn't realize you had this connection

> that really stood out was that I'd recommend a layer of indirection in
> the RDF vocabulary. Instead of this::

dind't you talk about this today with mudyc or someone?
seems the right way to me for that purpose.

and there are different vocabularies for different purposes, right?

>      canvas  foo:containsNode  ref
>      ref     foo:refersTo      node
> This way, the same node (e.g. person, blog item, ...) can be placed in
> multiple spatial locations on multiple canvases. This is something I

yep

> learned from Ted Nelson: One thing should always be able to be in

has he ever commented on graph-based structures, btw?

> multiple contexts. For example, this way you can experiment with
> different spatial arrangements and store the alternatives. Or you can
> arrange the same nodes in different ways to make different points.

a requirement for OHS (even the 1st step, HyperScope) is having multiple
views, iirc

> - Benja

~Toni