Experimental IRC log sioc-2009-05-29

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.

14:16:31<CaptSolo>hi again
14:17:18<CaptSolo>Shepard: that was what my DERI colleagues said about SIOC
14:17:34<CaptSolo>that it is very useful when building collaborative / social apps
14:17:53<CaptSolo>when you could easily use the same model to represent blogs, wikis, etc.
14:18:04<CaptSolo>and switch between these "views" if needed
14:18:28<CaptSolo>(that is a comment from ppl who work with actual companies or real business cases. as opposed to us researchers ;)
14:18:46<Shepard>:)
14:18:53<CaptSolo>Shepard: agreed re. Google Wave
14:19:00<CaptSolo>should explore it
14:19:45<CaptSolo>would be great if someone could write a summary re. Google Wave to the mailing list
14:20:13<CaptSolo>Shepard: re. each form of communication having uniq areas:
14:20:20<Shepard>I watched the demonstration video now. what is interesting is that it's both kind of a wiki and a conversation. so every participant can edit a wave and you can add replies right in the middle of a paragraph. quite challenging to translate that to SIOC.
14:20:37<CaptSolo> - sometimes you want same communication to span different systems
14:20:51<CaptSolo>in situations when some people don't use the web, and some don't read email
14:21:22<Shepard>yes
14:21:33<CaptSolo>(well, that is a bit extreme, the example given was when you have a blog but there are some people who are used to receiving info in email and would not use anything else)
14:21:55<CaptSolo>or someone might prefer to keep up to date with everthing via IRC :)
14:22:51<Shepard>or like many people read mailing lists through an NNTP proxy
14:22:52<CaptSolo>(that's my example, don't think IRC is of mainstream use apart from a small group of people)
14:22:59<CaptSolo>indeed
14:23:14<CaptSolo>so you end up with the main thing being the conversation / communication
14:23:24<CaptSolo>but different tools for interacting with it
14:23:45<CaptSolo>ideally it should not matter what tools a person uses
14:23:49<CaptSolo>as long as they are talking
14:25:46<Shepard>yes. conversations always have common attributes, like author, recipient, date etc. but I think not only the tools are different but the conversations on different systems can have different attributes as well. like on mailing lists, boards, usenet you can use threads, on IRC you can't
14:26:04<Shepard>but with a generic data model like SIOC you can still transform the important bits
14:33:31<CaptSolo>if it was important enough to provide a good bridge to another system (e.g. IRC), it can be done
14:33:52<CaptSolo>threads rely on having an archive of messages (which you can assemble in a thread)
14:34:11<CaptSolo>in order to realise that in IRC, you would need some kind of interaction
14:34:26<CaptSolo>e.g., a bot which acts similar to a text-based mail client
14:34:34<CaptSolo>which you can ask to show the current thread
14:34:41<CaptSolo>of course, IRC was an extreme example
14:35:02<CaptSolo>and you would only need to bridge, say, 3 most popular services used in an organisation
14:35:13<CaptSolo>and the service that the boss is using :)
14:35:49<CaptSolo>sure, w. a generic model like SIOC you keep all important information
14:36:17<CaptSolo>and access to it is then just a question of capabilities of the particular tool
14:36:19<CaptSolo>---
14:36:45<CaptSolo>BTW, there was a time when SIOC-Dev mailing list was bridged to a forum on the SIOC (Drupal-based) site
14:36:56<CaptSolo>with 2-way synch
14:43:36<Shepard>the musicbrainz community traditionally only had mailing lists. lots of users requested forums because they liked that form of communication more.
14:43:48<CaptSolo>it was cool from the point of view of "web can do this" but ther was not a pressing need for it
14:43:58<CaptSolo>hence it was short-lived
14:44:05<Shepard>it became apparent that both systems were needed but we didn't want to split discussions too much
14:44:20<CaptSolo>how did you solve that?
14:44:31<Shepard>so building a 2-way bridge between forums and mailing lists was considered (or rather using existing tools to do it)
14:44:54<Shepard>but people said that this doesn't really work very well
14:45:01<Shepard>at least not with the existing systems
14:45:17<Shepard>so now they have both mailing lists and forums. still seems to work for them :)
14:46:10<Shepard>(oh, I'm switching between "us" and "them" here - at some point inbetween I left the community ;) )
14:47:33<Shepard>I guess in the end conventions emerge which things get discussed on which system
14:48:04<CaptSolo>it worked well with Google Groups and Drupal
14:48:33<CaptSolo>there was not high usage on the forum side so can't say how it'd behave under stress
14:48:36<CaptSolo>but it worked all right
14:48:59<CaptSolo>here - funny re " so now they have both mailing lists and forums. still seems to work for them :) "
14:49:30<CaptSolo>guess that is a difference b/w bridging one community b/w mediums
14:49:45<CaptSolo>and having different communities in different mediums
14:50:01<CaptSolo>like here in IRC we have slightly different crowd than on SIOC-Dev
14:50:25<Shepard>the underlying communication model of forums and mailing lists is the same anyway, so yeah, it should work. just some technical quirks I guess. like when someone posts on a forum then who appears as the sender of the e-mail on the list?
14:50:26<CaptSolo>Shepard: oh, you are not involved with musicbrains any more?
14:51:17<CaptSolo>Shepard: one could look in SIOC-Dev ML. but i don't have time now to do this kind of information archeology
14:51:33<CaptSolo>(re. who appears as the sender)
14:51:37<Shepard>nope, I was strongly involved with it at some point but then I just got annoyed with them and left it and now I seem to have lost interest in it :)
14:55:15<CaptSolo>interests change
14:55:32<CaptSolo>and personalities play a role in keeping the community together as well (i guess)
14:56:08<CaptSolo>ACTION feels bad that not much is happening re. WishList followup
14:56:48<CaptSolo>(and i shouldn't do much else now than writing the thesis)
14:57:26<CaptSolo>we'll get sioc:User issue sorted, but then there are all those other things on the list
14:57:47<CaptSolo>- sorry for switching the subject :)
14:58:34<Shepard>yeah, you're right
14:58:57<CaptSolo>blx`: thanks for the link
15:00:26<blx>CaptSolo: np, it's still ugly/undecided in some ways. what do you recommend for adding/deleting content from a librdf model?
15:02:17<CaptSolo>blx: i have not done much adding/deleting of content - most of the time i just load a file or a URI into a datastore
15:02:52<CaptSolo>blx: in what form do you have the information that you want to add to the model?
15:03:24<blx>python datastructures
15:06:24<CaptSolo>either you create and add triples one-by-one or perhaps there is a way to "batch load" statements into the triple-store
15:07:04<CaptSolo>you may end up with a "transformer" service that takes a datastructure and puts it into the triple-store
15:07:21<CaptSolo>but i can't say more w/o exploring the project in detail
15:07:24<blx>i've been thinking about that
15:07:28<CaptSolo>s/project/question/
15:07:44<blx>python is not a great language for that kind of stuff though.
15:07:46<CaptSolo>build it one way and change in case if that way proves to have deficiences
15:07:55<CaptSolo>python's ok
15:08:00<CaptSolo>what you would use instead?
15:08:09<CaptSolo>(write a C extension? ;)
15:08:27<CaptSolo>as in - wat is a better language for that?
15:08:31<blx>lisp is great for query-sublanguages
15:09:47<CaptSolo>noticed you have another project on github that is in lisp
15:12:22<blx>yep, it's an interesting language
15:14:57<CaptSolo>have not explored it (apart from learning basics ages ago at the Univ.)
15:15:29<CaptSolo>but any languages should be ok ofr most of the stuff
15:15:31<blx>the standards and implementations kind of suck though.
15:15:37<CaptSolo>as long as the programmer is comfortable w. it
15:15:54<blx>python has a huge advantage in implementation and ease of install/use
15:16:15<CaptSolo>i don't think python is the worst language to implement it
15:16:21<CaptSolo>should not be difficult at all
15:16:36<CaptSolo>XSLT could be worse ;)
15:16:59<blx>i'm just tinking of python xhtml-tree building stuff that looks like it desperately wants to be lisp :)
15:17:25<blx>http://codespeak.net/lxml/tutorial.html#the-e-factory
15:20:45<CaptSolo>why would you need xml for pushing something into the datastore?
15:22:06<blx>ah, no this was just an example, i was using this for the web-interface
15:30:47<CaptSolo>what about templating libraries?
15:31:09<CaptSolo>wouldn't that remote a need for hand-building xml?
15:33:43<blx>CaptSolo: do you know any good for python? i will rewrite that section
15:33:59<CaptSolo>blx: maybe ask on #python
15:34:09<CaptSolo>i know people use some but don't know which are any good
15:34:33<blx>ah i remember. web.py has one
15:34:48<blx>which i'm using for serving. really nice and tiny
15:35:27<CaptSolo>ACTION has heard web.py is quite lightweight
15:46:13<CaptSolo>then perhaps its template language is good for you too

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