Re: [Gzz] RE: [ba-ohs-talk] Fenfire, RDF (re "Towards a StandardGraph-Based...")
Hi Danny, (01)
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... (02)
Toni's pointed to it-- http://www.eekim.com/ohs/papers/graphmodel/#hid5B (03)
> 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]), (04)
Cool. I have had a short look at your blog before, but need to look deeper. (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)
> 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) (07)
Whoops, another thing I didn't know about. TM? (08)
> 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. (09)
Agree completely. (010)
> 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. (011)
To give you a rough overview, there's a short-term and a long-term
subproject, called Fenfire Loom and Buoyoing. (012)
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. (013)
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. (014)
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. (015)
>>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? (016)
Sounds like a good possibility. At least it will be a subclass of
foaf:Person. (017)
>> 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? (018)
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. (019)
> Anyhow it should be pretty straightforward to achieve - e.g. alphabetically
> sorted nTriples (020)
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. (021)
>> ...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 ;-) (022)
Very cool to see that you're interested in OHS stuff, btw. (023)
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:: (024)
node rdf:label "Foo"
node graphics:x "17"
node graphics:y "44"
node graphics:width "50"
node graphics:height "20" (025)
I would do this:: (026)
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" (027)
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. (028)
- Benja (029)