Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a StandardGraph-Based...")
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. (01)
Created one; will appear on the next Savannah update (in two hours or
so) at: (02)
http://mail.nongnu.org/mailman/listinfo/fenfire-rdf-discuss (03)
The purpose is to discuss RDF tools/references from a Hypermedia
(Fenfire, Open Hyperdocument System) perspective. (04)
>>Whoops, another thing I didn't know about. TM?
>
> Topic Maps (05)
Right. (06)
> (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...) (07)
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. (08)
OTOH, I obviously don't know topic maps very deeply, so I may be wrong.
But it sounds like the right approach. (09)
>>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 ? (010)
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.) (011)
>> 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? (012)
Java. For the graphics effects, C++ through JNI, but so far, Loom uses
only Java. (013)
If you want to see what's there so far, the code is in the Fenfire CVS: (014)
http://savannah.nongnu.org/cvs/?group=fenfire (015)
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 :-) (016)
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. (017)
Everything is LGPL so far. (018)
>>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 (019)
(Except of course that you don't know which of the two graphics:x and
which of the two graphics:y belong together.) (020)
> 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"
> } (021)
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...) (022)
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. (023)
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. (024)
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. (025)
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. (026)
In my proposal, you'd only have a single graph-- (027)
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 (028)
canvasB foo:containsNode refB2
refB2 foo:refersTo nodeB
... (029)
nodeA rdf:label "Foo"
nodeA isReasonFor nodeB (030)
canvasA isMoreDetailedVersionOf canvasB (031)
which seems to simplify matters considerably. (032)
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). (033)
By 'document' I mean some unit like an Ideagraph canvas (or, more
traditionally, a text with headings, paragraphs etc). (034)
> 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... (035)
Ok. (These considerations do seem relevant for the use of RDF in a
hyperdocument system, though-- therefore the reply's on-list.) (036)
- Benja (037)