帮助:项目文档的创建、归类、查询和管理

来自GIPRs
跳转至: 导航搜索
项目文档
项目主页 GIPRs语义维基
文档类型 问题
优先级
状 态 已完成
发布日期 2013/03/10
完成日期 2013/03/12
作 者 GIPRs语义维基项目团队
来 源 www.giprs.org
源语言 中文

目录

问题

GIPRs语义维基#项目文档虽然列出了项目全部文档类型,但根据该章节的说明,对于项目文档的创建、归类、查询和管理并没有一个清晰的框架。此外,GIPRs语义维基/文档 在查询/聚合项目文档方面也遇到了问题。

初步分析

该问题的解决方案实质就是要制定项目文档方针和指引,这就涉及到如何实现GIPRs语义维基项目简介中列出的3个目标,还需要进一步明确GIPRs的需求和规划,并且这些因素相互影响,可以说是“牵一发而动全身”。千头万绪,如何开始呢?就用 GIPRs语义维基 项目作为测试,看看是否能解决问题。

背景信息分析

为什么要办GIPRs

  • 兴趣爱好:最初尝试过论坛、博客和CMS,现在想了解维基、语义分析或数据挖掘
  • 之前是需要一个Web平台来管理和分享信息,现在希望GIPRs能作为一种工具解决某些问题
  • 朋友们的怂恿和支持


GIPRs之前遇到什么问题

  • 访问速度慢,无法解决一些技术问题,用户体验不好
  • 内容属于单向发布,对现下业务几乎没有什么帮助
  • 内容虽然不多,还是不容易搜索到所需要的信息


为什么要用MediaWiki

  • MW在知识积累、搜索以及系统负载和稳定性方面得到广泛的认可,比较喜欢Wiki先搜索再创建或编辑内容的模式,其他系统虽然也能做到,但Wiki做的比较有特色
  • Wiki特有的页面链接方式,能够显示全部链入页面,良好的版本控制机制,公开的页面源码(是指如何使用模板、变量、函数等方面的源码,可方便参照应用)


为什么要用Semantic MediaWiki

  • 其实是先关注SMW,然后再关注MW。原因是:之前用OneNote和思维导图做知识管理都遇到了问题,OneNote网络版太慢且有很多限制;思维导图并不适合管理或呈现一个庞大的、内容及其关系非常复杂的知识库,当一个Topic有上百个关联链接后,还不如用Word大纲模式来的更方便
  • 根据之前专利检索和分析的经验,这个免费的SMW对于数据结构化是很有帮助的;此外,假设有数百个链接关联到一个页面(法规、合同或者专利文献),用SMW可以对这些链接进行分类标引,然后以数据表格形式输出,这可以克服思维导图所遇到的瓶颈,而且要比导图更容易管理;
  • SMW的语义标引、复合查询、可自定义的查询结果格式,可能对我们做专利分和数据可视化析有所帮助


GIPRs用途分析

在讨论这个问题之前,我们可以先明确GIPRs不希望

  • 纯粹用作论坛、博客或CMS系统 (如果仍然是如此,我们就没有必要折腾Wiki和语义工具了)
  • 类似维基百科、百度知道、新浪爱问、互动百科的应用 (去创建一个帐号岂不更省事?)
  • 随意发布或转载文章 (即有侵权风险,又浪费我们并不充裕的服务器资源)


与以上相对应的,GIPRs希望

  • 能够作为一种工具解决或者有助于解决一些具体问题,例如:进入某个新的知识领域、更新维护现有知识领域,共同更新维护一些文档,等等。(在Wiki系统中设置了项目类型,一切以项目为起点,将目标分解成具体任务,其过程文档和记录就是知识积累的过程)
  • 从“内容发布”转型为“内容应用”(就现有系统状况来看,MW+SMW非常适合做网络笔记、多人协同文本编辑。在解决了所需的技术问题后,希望能够将语义标引、查询和分析应用到专利技术方面)


GIPRs应用场景分析

1)进入某个新的知识领域

  • “从零开始、由点到面”:从简单了解几个术语、概念开始进入新的知识领域
  • 范例:GIPRs语义维基项目,搜索 → 学习 → 记录 → 实践 → 总结 (知识积累 - 应用 -更新维护,三者同步进行,已初步成形)

2)更新维护现有知识领域

  • 使用语言标引、查询和输出,归纳整理现有知识/文档,或者“从面到点“,进行垂直纵深形的知识挖掘 (尚未启动,待基础构建完成后,以之前的专利法或技术进出口笔记和资料作试点,确立此种应用模式)


项目文档的梳理

根据以上初步分析,GIPRs的用途及应用场景,其过程和结果重点都与“文档”有关。所以,“文档”在系统中的设置与安排事关整个系统的使用是否满足上述需求。

  • 以上提及的“文档”,主要是指Wiki“页面”,它可能是文字或图表,或者上传的文件(通常也是文本或图表,几乎不涉及其他文件类型,而系统、程序所产生的“数据”不属于本文讨论范围)
  • 文档可以分为“过程文档”(例如:“任务”类型页面)和“最终文档”(通常是指阶段性的最终文档,例如:GIPRs系统满足需求且运行正常后,选择全部或者部分过程文档汇编成一个完整的“GIPRs帮组文档”)
  • GIPRs语义维基 为了方便管理,将创建项目所用到的模板和表单归入到以该项目分类下且统称为“项目文档”,此类文档应与项目“内容文档”区别管理
  • 根据现有页面的创建方式,文档可以分为:用表单创建的文档,为用表单创建的文档
  • 根据页面是否使用语义标引的,文档可以分为:使用/未使用语义标引的文档(此处是指人工标引,不包括系统为页面自动创建的属性)
  • 根据页面是否链接到项目或者项目所属页面,文档可以分为:与项目有关/无关的文档
  • 根据链接到项目及项目文档的页面的内容或者链接属性,文档可以分类:直接“属于”项目的文档(例如:直接为完成项目任务而形成的文档),与项目“相关”的文档(例如:参考、引用或者具有其他相关性),此外还有与项目没有任何链接的文档
  • 根据页面是否包含嵌入式查询及查询结果,页面/文档可以分为:查询页面(设置了查询时,通常不允许用户编辑,仅供查看、排序或搜索),非查询页面(普通Wiki页面,不包含任何查询,文字可编辑),还有包含查询和文字内容的混合页面
  • 根据页面名字空间前缀的不同,页面/文档可以分为:分类、模板、表单、普通页面以及各类名字空间的讨论页面
  • 根据页面/文档是否公开,可分为:公开内容的文档,不公开内容的文档
  • 根据页面/文档是否允许全部或部分用户/用户组编辑,可以分为:受保护的页面/文档,允许编辑的页面/文档

以上可能未穷尽文档/页面的全部类型,但可以看出,目前“项目文档”是一个非常笼统的称谓,需要澄清其定义、属性或范围。


意见和建议

如何确定项目文档类型和范围:

  • 根据以上梳理,首先要明确,此处使用的“文档”和“页面”是等同且可以互换的称谓,以下统称为“文档”
  • 如果按上文提及的,“一切以项目为起点”,那么GIPRs的页文档就可以分为:项目文档,非项目文档
  • 非项目文档延续已有的分类:法律法规、文章、词条

可以从查询条件入手,确定需要设置的项目文档类型(系统已有的属性,可直接用于查询,无需事先设置,例如:名字空间,SMW已启用的一些特殊属性,等等):

  • 根据文档的作用分类,项目文档可以分为:项目管理文档(项目主页、模板、表单、分类、查询),项目内容文档(任务、为项目所创建的文档)
  • 根据是否使用表单创建来分类,设置约定项目文档全部使用表单创建(待处理)
  • 根据链接属性分类,可以分为:“直属项目文档”,“相关项目文档”

用语义属性标引的“相关项目文档”,因没有用表单统一数据结构,具有较大的随意性,也导致查询比较复杂,初步建议如下:

  • 项目主页、项目模板和表单、项目分类,这3种类型文档/页面是创建一个项目必不可少的文件,而且不易引起混淆,可以先予以确定
  • 目前“任务”页面实质上同时也是项目文档,可以考虑所有项目文档使用一张表单,可简化操作和查询
  • 可以暂时搁置“相关文档”查询,现行制定语义标引方针和指南,统一语义标引用法和数据结构后,查询就有头绪了


解决方案

GIPRs文档类型和结构的规划


  • 合并项目任务与文档,用项目属性标注文档类型,除项目设置文件外,统一使用一张表单
  • 若文档有特殊需要,可在此结构下另行制作表单,例如:合同文本,法律文书,等等;
  • 取消原“项目主页”下的两个字页面“任务”与“文档”,原任务主页(查询)并入“项目主页”
  • 在未统一语义标引用法和数据结构前,对“项目相关文档”作专门的查询

以上解决方案可简化文档结构和操作,但需要修订现有模板、表单、分类以及查询。