Experimental IRC log fenfire-2009-06-04

Available formats: content-negotiated html turtle (see SIOC for the vocabulary)

Back to channel and daily index: content-negotiated html turtle

These logs are provided as an experiment in indexing discussions using IRCHub.py, Irc2RDF.hs, and SIOC.

04:41:22<mudyc>tuukkah: what do you think of the future of the google wave?
07:28:38<tuukkah>mudyc, the future of google wave looks bright to me: i know people like etherpad when they try it, and they naturally start to chat in it too
07:31:59<tuukkah>to get a user base, google can add wave capabilities to all gmail accounts
07:35:55<tuukkah>and to get people to try, they can advertise: "in wave, you can keep correcting a message after you sent it - and if a message you've read gets revised, you'll receive the changes as a message in your inbox
07:35:59<tuukkah>"
10:05:49<mudyc>tuukkah: well, i was thinking that if wave comes something big it might be useful to "ride on" with it, e.g. p2p, xanalogical media protocol extensions etc.
10:06:17<mudyc>"you already have this feature but if you install this extension you also get this and that"
10:06:55<tuukkah>yes indeed
10:09:04<tuukkah>"if you build on this new platform, what new can you feasibly create?"
10:10:45<tuukkah>the first thing that comes to mind is a wave gadget for rdf editing (mindmaps)
10:11:57<mudyc>collaborative mind map
10:12:08<tuukkah>yup
10:12:36<tuukkah>the second thing could be better visualisations for links between waves
10:12:57<mudyc>if there is this timeline feature, it makes sense to add xanalogical adapter too -> having links between texts is doable
10:13:40<tuukkah>hmm, do you mean how we can get every key press?
10:14:22<tuukkah>btw, etherpad advertises "every key press is saved" :-)
10:14:29<mudyc>we don't need every keypress, the difference between versions is enough, if we can identify a certain span of the difference
10:14:48<mudyc>and versions are same as timeline
10:15:09<mudyc>or can be calculated from
10:15:41<tuukkah>but the calculation problem here is the same as in generic diffing?
10:17:18<mudyc>you might be right that it's not actually same
10:18:10<mudyc>let's see when we have the source available
10:19:15<tuukkah>well, we know every key press can be handled individually
10:20:04<mudyc>"conversation id + keypress" would be the xanalogical identifier
10:20:21<tuukkah>but i dunno how that works together with clipboard
10:21:11<mudyc>there might be different user interfaces :)
10:21:14<tuukkah>or if the user goes in the "draft mode"
10:25:14<tuukkah>"We think that Wave's additions are neat and could imagine an EtherPad/Wave integration being quite powerful for certain use cases. However, when it comes to the kind of written work that most knowledge workers need to produce, we think that less is more." http://etherpad.com/ep/blog/posts/google-wave-joins-etherpad
10:40:38<datakurre>Do you know, what kind of linking wave does support?
10:40:55<datakurre>E.g. bi-directional links within parts in waves and between waves.
10:46:43<tuukkah>i'd expect uni-directional
10:50:04<tuukkah>"Note that the base grammar has no notion of links, that’s something that is layered on in terms of annotations. -- textView.setAnnotation(range, "link/manual", uri);" http://intertwingly.net/blog/2009/05/31/Google-Wave
10:53:36<tuukkah>by the way, this reminds me of how ted's been advocating annotations to be used instead of markup :-)
10:55:23<tuukkah>it's also a bit scary to think that client software needs to support this content type which is seems to be very different from html
11:02:58<tuukkah>"An annotation is some meta-data associated with an item range, i.e. a start position and an end position. This is particularly useful for describing text formatting and spelling suggestions, as it does not unecessarily complicate the underlying XML document format."
11:15:22<datakurre>Promising?
11:17:32<tuukkah>suppose so

Back to channel and daily index: content-negotiated html turtle