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

[Benja Fallenstein]

Danny Ayers wrote:
> > 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.
>
> Sure, that'd be good. Also when I get the blog moved over to MT it'll easy
> to allow other people to blog to it.

Created one; will appear on the next Savannah update (in two hours or 
so) at:

http://mail.nongnu.org/mailman/listinfo/fenfire-rdf-discuss

The purpose is to discuss RDF tools/references from a Hypermedia 
(Fenfire, Open Hyperdocument System) perspective.

> > Whoops, another thing I didn't know about. TM?
>
> Topic Maps

Right.

> (also notice the difference between model & syntax - XTM's the
> usual, but Jack & others have discussed expressing them in RDF - layer on
> layer on layer...)

That sounds exactly right to me. Skimming the "TAO of Topic Maps" a 
second time, it seems like an RDF-like model (topics and associations) 
with some properties being expressed in a special-cased way (resources 
aren't topics; the relationship between resources and topics, 
'occurence', is not an 'association'). It seems like it should be 
possible to express topic maps in RDF and allow them to be 
interconnected with other RDF data in the go.

OTOH, I obviously don't know topic maps very deeply, so I may be wrong. 
But it sounds like the right approach.

> > To give you a rough overview, there's a short-term and a long-term
> > subproject, called Fenfire Loom and Buoyoing.
> >
> > 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.
>
> Sounds cool - kinda like
> http://www.ideagraph.net/unleashed/#Squirrel ?

Yup. (Unforch the servlet didn't work for me-- on Konqueror (KDE 3.1); I 
tried copying the URL from the servlet-generated <object> tag into my 
browser and got a traceback.)

> > 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.
>
> What programming language(s) are you using?

Java. For the graphics effects, C++ through JNI, but so far, Loom uses 
only Java.

If you want to see what's there so far, the code is in the Fenfire CVS:

    http://savannah.nongnu.org/cvs/?group=fenfire

To run, you need to check out the 'fenfire' and 'fenfire-depends' module 
in the same directory; install Ant; run 'ant fenfire' in the fenfire/ 
directory; and then run 'ant run -Drdffile=/some/rdf/file' in the same 
dir. README forthcoming :-)

We're still working on refactoring the old Gzz code in several 
independent projects. Currently, Loom uses a Jar containing .class files 
built from the old Gzz code (http://gzz.info). It'll be checked out 
along with the rest.

Everything is LGPL so far.

> > This way, the same node (e.g. person, blog item, ...) can be placed in
> > multiple spatial locations on multiple canvases. This is something I
> > learned from Ted Nelson: One thing should always be able to be in
> > 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.
>
> Very good point (& thanks for the suggestion), though I'm not sure I'd
> approach it in this way - I don't think the indirection is needed. There's
> nothing in the RDF model stopping the coexistence of
>
> nodeA  graphics:x       "17"
> nodeA  graphics:x       "18"
>
> even if nodeA is a URI

(Except of course that you don't know which of the two graphics:x and 
which of the two graphics:y belong together.)

> so some kind of contextualization is needed anyway. So the lines along which
> I was thinking were more like :
>
> canvasX{
> nodeA  graphics:x       "17"
> }
>
> canvasY{
> nodeA  graphics:x       "18"
> }

So that would amount to having two different RDF graphs, canvasX and 
canvasY. (Or you'd have to reify the graphics:x statements-- I don't 
think that's what you're saying...)

I wouldn't recommend that path, but I'm having problems expressing 
*why*... Basically, I believe RDF plays its strengths much better if you 
don't have to think about different contexts (graphs) most of the time. 
You only need to maintain a single graph (which can internally be the 
autogenerated union of several other graphs) for all the views/apps in 
your system.

If I want to add that 'nodeA isReasonFor nodeB', that information is 
orthogonal to the placement of nodeA on any canvas. Maybe I want to show 
reasons in green; then both of the canvas contexts would have to contain 
the isReasonFor triple, otherwise they wouldn't know the node is green.

What if I want to say that canvasA isMoreDetailedVersionOf canvasB? Of 
course, if canvases are RDF graphs, I can use the URIs of either graph 
to express the connection. But a view that shows this information as a 
connection between the two canvases would then have to make the 
connection between each canvas's URI and the in-memory graph object and 
the view... it all seems very complex.

If you wanted to send all this to a mailing list, you would have to send 
three RDF files-- the two canvas graphs plus the third graph relating 
the canvases.

In my proposal, you'd only have a single graph--

    canvasA foo:containsNode  refA
    canvasA foo:containsNode  refB1
    refA    graphics:x        "17"
    refA    graphics:y        "44"
    refA    graphics:width    "50"
    refA    graphics:height   "20"
    refA    foo:refersTo      nodeA
    refB1   graphics:x        "112"
    ...
    refB2   foo:refersTo      nodeB

    canvasB foo:containsNode  refB2
    refB2   foo:refersTo      nodeB
    ...

    nodeA   rdf:label         "Foo"
    nodeA   isReasonFor       nodeB

    canvasA isMoreDetailedVersionOf canvasB

which seems to simplify matters considerably.

Of course, I'm looking from the Fenfire perspective-- many different 
applications and many different 'documents' inside a single graph, 
connected and overlapping (same node in different apps/docs).

By 'document' I mean some unit like an Ideagraph canvas (or, more 
traditionally, a text with headings, paragraphs etc).

> Though I've not worked much of this out yet - looking at a containership
> vocab. Anyhow, I'm still tinkering with much cruder stuff at present though,
> plenty of time to think about this...

Ok. (These considerations do seem relevant for the use of RDF in a 
hyperdocument system, though-- therefore the reply's on-list.)

- Benja