Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a StandardGraph-Based...")
On Sat, 8 Mar 2003, Benja Fallenstein wrote: (01)
> Hi Danny, (02)
yet, (03)
> > the general problem (many blogged at [1]),
> Cool. I have had a short look at your blog before, but need to look deeper. (04)
i guess i should too (05)
> 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. (06)
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) (07)
> > use for this kind of thing (notably TM)
> Whoops, another thing I didn't know about. TM? (08)
Topic Maps? i don't know them too deeply either.
but i guess you can do them with RDF..?-o (09)
> 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. (010)
right. and here we can explore the differences of zz and rdf in a way,
too. (011)
> Buoyoing ("Buoy-oriented interface, next generation") is our scheme for (012)
didn't know/remember the name, actually :) (013)
> integrating data from different applications. This, too, is a (014)
.. 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. (015)
> 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. (016)
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) (017)
> > 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 (018)
also, the same format (rdf) is used in-memory (019)
> represent Unicode characters. Maybe a Unicode version of nTriples. (020)
hm, don't know nTriples from before but perhaps that is a way (021)
> 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 (022)
oh, didn't realize you had this connection (023)
> that really stood out was that I'd recommend a layer of indirection in
> the RDF vocabulary. Instead of this:: (024)
dind't you talk about this today with mudyc or someone?
seems the right way to me for that purpose. (025)
and there are different vocabularies for different purposes, right? (026)
> 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 (027)
yep (028)
> learned from Ted Nelson: One thing should always be able to be in (029)
has he ever commented on graph-based structures, btw? (030)
> 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. (031)
a requirement for OHS (even the 1st step, HyperScope) is having multiple
views, iirc (032)
> - Benja (033)
~Toni (034)