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

[Benja Fallenstein]

Hi Danny,

Danny Ayers wrote:
> > Toni Alatalo pointed me to your paper, `Towards a Standard Graph-Based
> > Data Model for the Open Hyperdocument System`__. You make the point that
> > a standard graph-based model could allow different applications to be
> > integrated into a single whole. You say that RDF is one possible choice
> > for a modeling language, but reject it because of its complicated syntax.
> >
> > __ http://www.eekim.com/ohs/papers/graphmodel/
>
>
> I couldn't find the 'rejection' bit on a skim of Eugene's paper...

Toni's pointed to it-- http://www.eekim.com/ohs/papers/graphmodel/#hid5B

> but whatever, I'm getting the impression that an implementation of an OHS is
> actually well on its way, primarily using the RDF model. Pretty much dail
> I'm coming across new RDF-based systems that focus on different aspects of
> the general problem (many blogged at [1]),

Cool. I have had a short look  at your blog before, but need to look deeper.

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.

> and these may considered as a
> whole thanks to the shared language - there are obviously other models in
> use for this kind of thing (notably TM)

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

> but I think RDF is likely to emerge
> as the common language, largely thanks to its lowest-common-denominator
> statement representation. In other words, the development itself is
> distributed - which seems quite natural really.

Agree completely.

> I can't remember seeing anyone taking the zigzag idea specifically and
> putting it in RDF, so it'll be interesting what happens with Gzz/Fenfire
> along these lines. I note that Fenfire is described as a hyperstructured
> UI - this will be good to see, as UI development is lagging behind in RDF
> developments.

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. 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.

Buoyoing ("Buoy-oriented interface, next generation") is our scheme for 
integrating data from different applications. This, too, is a 
focus+context interface. In the middle of a window, you see e.g. an 
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.

Buoyoing will allow anything in any view to be connected to anything in 
any other view, allowing you to see 'what's related.' We have basically 
implemented this and demoed it for a specific application-- browsing 
articles in ps/pdf format, creating connections between them (which are 
then shown in the margin) and taking notes about them (also connected in 
the margin). What's missing is the interfaces that allow anybody to 
write a new view which can be connected to any other view.

> > Our aim is very close to what you describe; we want information from any
> > application on a computer system (or network) to be available for
> > linking with information from any other application, in any linking
> > structure (for example IBIS discussion). For a person I'm in contact
> > with, there should be a single node on my computer, connected to their
> > address, their birthday, my appointments with them, emails I received
> > from them, photos of them, and so on.
>
> That would be a foaf:Person [2] I take it?

Sounds like a good possibility. At least it will be a subclass of 
foaf:Person.

> > For Fenfire, we need a canonical format for RDF graphs, so that
> > equal RDF graphs are always serialized to the same byte sequence; we
> > might invent our own serialization language for that.
>
> 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 
way.

> Anyhow it should be pretty straightforward to achieve - e.g. alphabetically
> sorted nTriples

Yes, I've been thinking that. The thing that bugs me is that I would 
really like to use a Unicode encoding-- nTriples uses escaping to 
represent Unicode characters. Maybe a Unicode version of nTriples.

> > ...all structures should be viewable in a
> > single 'structure editor' (even though we'll have all sorts of different
> > views for application-specific data which you can switch forth and back
> > between-- we share the OHS's vision here).
>
> Ideagraph [3] is my own take on this, and I agree absolutely with your
> reasoning behind the use of RDF (though am too lazy to express it myself ;-)

Very cool to see that you're interested in OHS stuff, btw.

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 
that really stood out was that I'd recommend a layer of indirection in 
the RDF vocabulary. Instead of this::

    node  rdf:label        "Foo"
    node  graphics:x       "17"
    node  graphics:y       "44"
    node  graphics:width   "50"
    node  graphics:height  "20"

I would do this::

    canvas  foo:containsNode  ref
    ref     graphics:x        "17"
    ref     graphics:y        "44"
    ref     graphics:width    "50"
    ref     graphics:height   "20"
    ref     foo:refersTo      node
    node    rdf:label         "Foo"

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.

- Benja