Skip to content

Daily Call 2018-04-16

Frode Hegland: Something happened to my thinking since the last call. In Author, one feature is supposed to be (not done yet) a mechanism to only show headings, not the body of some text, in order to draw lines between those headers, basically a concept map. By going through use cases, I realized that this feature is probably most useful in the context of collaboration, therefore on the web. Copying such a node would include all subnodes, which would get deeply copied to the local computer.
Marc-Antoine: It emerged from the discussion of graph + document: to look at headers as nodes is very natural to me, the attached body is just an attribute.
Frode: Moving around nodes is incredibly useful. What about extending Gyuri Lajos’ work into this Virtual Reality direction?
Gyuri: Well, if everything is nodes…
Marc-Antoine: To copy means to fork, with the same origin of course, but diverging.
Gyuri: Then that becomes a new version in the node.
Marc-Antoine + Gyuri: Agreement that there’s the need for both, origin ID and a local copy/fork version ID.
Marc-Antoine: I only want remote nodes, because there might be not enough storage space locally.
Gyuri: Similar to WikiData, it might be temporary, throwaway data.
Marc-Antoine: Then there’s the need for a distributed event bus. Propagation might be implemented via WebSockets to other clients. IdeaLoom has it, it’s a little bit slow, but works. I looked at collaborative editors some time ago and there’s many of them, so I made a list.
Gyuri: To make it collaborative, only a communication channel or database is needed. Only the node modifications need to be shared among peers, the editor doesn’t matter that much.
Frode: So what are we going to do, into which direction?
Marc-Antoine: My action plan was to add history to my nodes, as Marmotta is now implemented. I still need to specify the format for knowledge graph. But with this new idea, a format for both, graph and documents? Question to Frode: what is needed by documents? What format to use? There are many internal ones, HTML would be fine, but some editors have their own, so HTML would not necessarily be the best.
Gyuri: I support 70% of DocBook to import to graph.
Frode: Those are very good questions, but also very detailed. What I’m talking about is just writing down two names and connecting them with a line.
Marc-Antoine: First question: can such a node be translated to HTML, round trip?
Robert Cunningham: During the HyPerform presentation, outlines in the outline editor were seen as a problem to do by Marc-Antoine, where only structure implicitly conveys meaning, but introducing semantics will solve that?
Frode: Talked with Christopher Gutteridge briefly, and Christopher should talk to Gyuri. Marc-Antoine’s system should link into documents, I will design my component to make it fit.
Robert: How to make multiple uses of the same text? How to do that in HTML? To dynamically show and hide portions?
Gyuri: I looked at everything done and published by Frode, so what’s needed is that the editor must manipulate an underlying graph model.
Marc-Antoine: I said that with HyPerform, it is hard to do it via transformation, but in HTML it becomes easy, semantics will do that. So here we come back to the document as a graph. Intelligent <div>s – one has to have very well designed HTML, which isn’t difficult, but needs to be implemented.
Stephan Kreutzer: So here we come back to xFiles, generic semantics, at which point we don’t care about HTML semantics any more.
Marc-Antoine: Another question towards Robert: where to draw the line between node and body, at the title level, at the section level?
Robert: Is that also relevant for ViewSpecs?
Marc-Antoine: It’s important that Gyuri makes the node model work.
Robert: And thenI don’t need a separate reader or code, everything is self-contained, everything is there for it to start its stuff.
Frode: Gyuri, how much effort would it be to make a new view in your system for the graph?
Gyuri: In Roberts presentation, the view was customizable.
Stephan: So do we want to do collaborative interactive navigating/editing in realtime? That’s another game – doable, but we don’t have a lot of experience or time. Co-browsing comes to mind.
Robert: Something like Apache Wave?
Marc-Antoine: There’s now new technology, for example Quill and slate.js.
Robert: It’s also a nice thing to do it with yourself, to synchronize text between devices.
Frode: Agreement reached that we also do interactive capabilities. Now, who does what?
Marc-Antoine: I know that Gyuri is already very advanced, so that can be used, I don’t need to redo it.

Published inWeekly Meetings

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *