[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

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



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

Eurgh, can't look very deep at the moment, the archive templates are pretty
screwed up. They have been for a while, but I've been planning to transfer
over to Movable Type, it's easier to hack. Still googleable using site:
http://etc    (02)

> 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.    (03)

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.    (04)

> Whoops, another thing I didn't know about. TM?    (05)

Topic Maps (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...)    (06)

> 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.    (07)

Sounds cool - kinda like
http://www.ideagraph.net/unleashed/#Squirrel ?    (08)

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.    (09)

What programming language(s) are you using?    (010)

> 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.    (011)

That does sound very nice.    (012)

> > 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.    (013)

Hmm, I'm sure you have good reason to use something other than URIs for
identification...    (014)

> 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.    (015)

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    (016)

nodeA  graphics:x       "17"
nodeA  graphics:x       "18"    (017)

even if nodeA is a URI    (018)

so some kind of contextualization is needed anyway. So the lines along which
I was thinking were more like :    (019)

canvasX{
nodeA  graphics:x       "17"
}    (020)

canvasY{
nodeA  graphics:x       "18"
}    (021)

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...    (022)

Cheers,
Danny.    (023)