关于主题社区的一点点设想

2011-06-12 22:22:08 +08:00
 lychee
从早期的bbs(比较有代表性的就是discuz论坛系统,千千万万的网站通过它搭建了自己的论坛),

到现在的豆瓣、微博、各种问答社区、图片社区、基于地理位置的社区。

各种各样的社区,各种各样的形式,其都是为了分享内容而存在。

“有人的地方就有江湖”

这句话在互联网时代或许就该改成

“有人的地方就有社区”

所以说,社区是永恒不变的主题,也是互联网的精神所在。

因为社区如此重要,所以如何构建一个优秀的社区系统,该构建一个什么样的社区就是我现在在想的东西。

目前脑袋中的雏形是这样的:

社区中的几个基本元素

人 ———— 当然就是注册会员

节点 ———— 这个我也不知道应该准确的叫什么,节点是一个词,而这个词代表了某件事物。

主题 ———— 这个好懂,就像一篇帖子,任何人都可以发布。但是我希望它可以承载多种类型的内容,不仅仅是有标题有正文的文章,可以是没有标题,只有一段话的一条推、甚至可以是没有标题、没有正文、而只有图片、音频或者视频的多媒体内容。或者你全部可以填上。希望可以自由的组合内容,而并没有哪一部分是必须的。

wiki ———— 无须讨论的、知识性的东西,当然也是由所有人撰写。


各个元素之间的关系

人和节点下面可以都有无限多的主题和wiki。

主题和wiki可以从属于多个节点。

主题的作者只有一个,wiki只保存历史编撰者。



人下面有一个默认wiki 这就是个人资料。

当然,人的wiki只能自己来编写,所以也可以拿来当blog写。

而人下面的主题则像是个留言板。




节点下面也有一个默认wiki,这就是关于此节点所代表事物的介绍。

例如有个 “咖啡” 节点

那么默认wiki就是 “什么是咖啡”
还可以有 “咖啡有哪几种口味” 之类的wiki,等等等等,需要注意的是,传统论坛某些帖子加精的概念,在这里则是 将它整理至wiki。

节点下面的主题当然就是所有有关此节点的讨论。



各元素之间可以发生任意关联
例如
某人 喝过了 咖啡(节点) 或者 想品尝 咖啡(节点) {-3- 像豆瓣吧}

某人 关注 某主题

某主题 引用了 咖啡有哪几种口味(wiki)




除了以上这些 我还想引入一个时间的维度

主题最后回复的时间如果超过了一个设定的值 例如一个月或三个月 会自动关闭

可以查看上周、上上周、上上上周、上个月... 最热门的前一百个主题是什么




其他的就是根据元素之间的关系进行聚合和过滤
最平常的 显示某节点下的主题
显示某人发表的主题
只显示某人关注节点的主题
某主题有新回复会通知所有关注者
等等等等....



大概就是这么多了 自己认为这四种基本元素可以自给自足形成一个内容社区 不需要引入其他的东西 (群组什么的,觉得水分太大,容易滋生无意义的主题,节点完全够用)


各位觉得这有可能性么

这有程序上实现的可能性么 (如此灵活的系统 架构设计起来很伤脑筋)
5626 次点击
所在节点    随想
29 条回复
chloerei
2011-06-13 00:28:34 +08:00
@lychee 单单用数据库也能做,很多时候会用表单模拟另外一个东西。类似where().desc()的查询就是每次重复生成一个队列。

最近在做一个订阅列表,一开始想省事用mongodb储存,后来发现mongodb对列表的支持只能从列表尾部插入,而且不能限制列表长度,如果在应用层中实现想要的效果(比如一个timeline)会费很大劲,于是就加上redis了。

当然做着做着,发现部署的门槛是高了。不过我想就算stackoverflow开源,也不如让人们直接泡在他的网站上好。
fengluo
2011-06-13 00:35:29 +08:00
@chloerei 在学习mongodb的时候发现,很多人也只是把它作为一个补充而已。mongodb和redis混搭这种场景,也被经常提起过。可能得社区真正跑起来的时候,才知道问题所在。

facebook也开源的,却不会有第二个facebook出现啊⋯⋯估计我的代码不好意思开源,见不了人的。我想法是快速开发上线,然后再慢慢修改了~
reus
2011-06-13 00:51:03 +08:00
关系比较多的话可以考虑用graph database
如此一来,用户,节点,主题,wiki,其实都可以简化成图中的一个结点,差别只在结点的属性。
结点间的关系,比如某主题的作者,所属节点,相关主题,某用户的wiki,它的所有评论,都可以用边来表达。用图来表达这个模型是最好的了
http://en.wikipedia.org/wiki/Graph_database
chloerei
2011-06-13 09:03:24 +08:00
@reus 哟,这个屌
chloerei
2011-06-13 09:04:41 +08:00
@fengluo 关系数据库把太多责任赋予了数据库,熟悉关系数据库的人经常会用SQL的思维写出很苦涩的逻辑。该让数据库还原它“储存”的基本职责了。
reus
2011-06-13 09:06:44 +08:00
发觉很多都是用java写的,难不成都是受neo4j影响吗……
https://github.com/stevedekorte/vertexdb
比较了一圈只发现它比较合个人口味,不过似乎已经很久没commit了……
lychee
2011-06-13 14:41:35 +08:00
@reus 貌似你这样抽象过头了 其实我觉得四种元素不多不少刚好 还有 评论是否可以也看作是一个主题?

@chloerei 同意 数据库应该还原存储的本质

我想 现在的数据库设计中 关系和数据混在一起 那么是否可以将关系剥离成独立的一层?

这样的话查询数据库的流程就是这样的

从某一点构建关系树

用实际数据填充 当然 根据其在树中的位置和角色 填充前会做一些处理

完成
caomu
2012-03-02 20:36:16 +08:00
看到 云风的《主题论坛的一些想法》 http://www.v2ex.com/t/28407 http://blog.codingnow.com/2012/02/forum.html 想起这个讨论,不知道楼上各位怎么样了。

确实,像 reddit 和 StackOverflow 那样的社区,条理更加清晰,信息流动更加方便,同时数据挖掘的潜力也非常高。但是,究竟一般的上网用户会喜欢/习惯这种设计吗?在中国,大多数人去weibo去qzone去人人去贴吧,在美国大多数人去FB去各种论坛去irc去4chan(不过后两者相对也比较“高级”),而 reddit 和 StackOverflow ,更像是 geeks 的聚集地,依照geek的喜欢建造,也基本只有geek喜欢,那些去贴吧灌水,去李毅吧看/发一些肾上腺激素的帖子的大多数网民,会进驻吗?当然,像V2EX一样,可能忠实用户会认为,正应该小众,只吸引geek刚刚好。小众和一定技术水平的要求,是优点也是缺点。当然,我是非常非常希望出现这样子的社区的,因为有价值的信息的顺畅流通,是一件令人非常愉悦的事情。
jmy
2012-03-03 16:48:40 +08:00
这样的社会 有没有考虑易用性呢? 让用户的使用门槛降低的

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/14352

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX