界面生成方案构想

laotao

1.        项目背景
        a.总体需求：根据特定的（医学）知识本体生成可配置的、动态的数据录入界面，即界面既可以在使用之前利用知识本体进行配置，又可以在使用的过程中随输入的不同而改变。
        b.系统使用流程：（编辑知识本体）->（配置界面方案）-> 录入数据 -> 保存/输出数据
        c.项目重用性：项目开发过程中产生的知识本体和DOM OWL应该可以用于未来新系统的开发。
2.        解决方案1 - XML + XSL
        a.编辑内容知识本体 -> 生成内容OWL(XML)。这一步可以使用现有工具如Protégé。
        b.用户为a中的每个对象选择输出方式，配置结果保存为XSL Stylesheet。这就需要开发一个配置程序，程序所需的输出选项可以根据DOM OWL（也需要开发）生成。
        c.系统利用a中生成的本体XML和b中生成的Stylesheet构建一个初始的数据录入界面。
        d.用户录入一项数据，系统根据录入的数据和a中生成的OWL对界面进行必要的改变
        e.重复d直到用户录入所有必需内容
        f.保存数据并通知工作流引擎
3.        解决方案2 - Intellisense
        a.同2a
        b.用户以类似编程的方式录入数据，录入的过程中允许使用的语法、关键字、提示信息和自动完成功能由a中生成的知识库获得
        c.数据保存以类似程序编译的方式进行，即根据知识库对用户录入的文本内容进行解析，如果录入合法则生成xml
4.        两种方案的比较及其它方案分析
        a.方案1：这显然是一个结构化录入的方案，实现难度较方案2小。麻烦的地方就是需要另外开发一套DOM的OWL。其实也可以根据OWL知识库中各元素所在的层次生成一个固定的Stylesheet，这样就不用专门写DOM OWL了。
        b.方案2：以类似纯文本的方式实现结构化录入，录入效率会很高，但显然实现难度很大（简直是在做一个编译器了），而且对用户的要求也会很高（最好是程序员）。
        c.其它方案：XML page generator不太了解，但因为是第三方的软件，就算可以生成html表单，恐怕也很难与本系统进行集成和交互，而我们需要的又是一个动态的界面。

[ 本帖最后由 laotao 于 2007-5-11 14:38 编辑 ]

南京猿人

呵呵，写得很好的初稿。我来补充一些自己的看法。常规的数据采集过程from data to information，一般是两种系统设计，自然语言处理（NLP），知识驱动型结构化数据录入（Knlowledge-driven SDE）。NLP大多在自然语言数据的基础上，
1. Load free text， 读入文本
2.Search and tag concepts (synonyms)， 查找术语词汇
3.Validate tagged concept( negation)， 确认词汇的正确性
4.Map concept onto ontology and save，把词汇映射到onology,并且以符合ontology结构的方式保存
5. run Inference，进行推理，现在多种新的推理机制都在开发。
6. other functions， like real time decision support实现其他功能，比如基于推理结果的即时决策支持等

南京猿人

在SDE方面，我们要先考虑到现有SDE的缺陷，从而理解为什么需要引入ontology,ontology能够实现那些提高，才能有针对性的选择最佳方案。

传统的SDE系统大都分为两层设计，模板设计层，或者大家称之为form, template, domain model,界面展现层，或者大家称之为view, interface.

优点在Bemmel 在handbook of medical informatics书中提到

模板层：
1.模板可以自定义，可以修改，扩展，从而实现模板的共享和重用
2.可以遵循一种可控制的词汇表，实现用语的标准化，从而有利于未来的数据分类和集成

缺点（目前一些文章的总结）：

模板层：
缺乏一个广泛的词汇表和富有逻辑的结构作为基础（OWL）
1.不容易扩张,模板设计者往往基于个人对该领域的理解设计模板，缺乏一个知识的参照物，受到个人局限性的影响。
2.不连贯或内容残缺，比如，问了过敏史，却忘了设计手术史的模板
3.缺乏兼容性，很多公司都设计了不同的模板，可是这些模板格式各异，数据集成还是问题。比如，甲公司的现病史数据如何和乙公司的进程记录整合在一起，产生新而准确的决策。

界面展现层：
1.不能根据前面的录入调整后面录入的问题和答案。比如，前面问了性别，答复是男性，可是后面还是机械僵化地问，是否怀孕过？

为了委屈求全，部分SDE把模板设计的很粗略，实现通用性（Generability），而把很多特别的（specificity），上下文相关的（context dependent）内容都忽略掉。这样的数据采集，必然失去细节（granularity）。影响最后数据使用的准确性。

或者把模板设计得很细，然后出现上千个和这个病人不相关的问题，导致用户必须浏览，跳过很多内容，才能完成录入。勉强维持了数据的准确性，牺牲了用户的时间。

由于不尊重用户体验，而且用户并没有看到后期SDE在数据分析上的长处。从而导致最后SDE反而被free-text淘汰。

[ 本帖最后由 南京猿人 于 2007-5-9 06:37 编辑 ]

semtek

目前的SDE还有什么具体的问题呢？
我看到了一个：
--”前文问到病人性别，答复是男性，后文还有月经史的病史询问”。
希望能看到更多的具体的问题。

南京猿人

个人觉得，这个问题可以从两个角度去分析。从科研设计的角度，我们找出dependent variable and independent variable,然后找找看联系和局限性。一种是逆向分析法，从OWL的特性和优势着手，然后反观没有OWL的当前SDE的局限性。

待续

mouse

构思很不错,在目前基于.net的B/S结构下,实现起来并不很难,呵呵,关键在于模型的建立,是否具有充分的合理性和良好的可扩展性,动态的目的是为了什么?显然是为了应用扩展,遵循这个思路去设计,必须要结合行业经验和设计经验,行业专家和软件系统分析架构专家缺一不可.

smallpotato

如果要生成界面，我觉得可以参照XHTML的schema来建立OWL，作为和内容绑定咚咚比较好。
DOM是解析XML用的模型，本身不涉及用户界面的外观。但是作为界面生成工具的一个中心技术是不可缺的。
目前w3c的网站有三种xhtml schema 可以提供下载。

还有想提到的一点是，如果不讨厌微软的技术的话，目前微软为界面显示开发了一套XAML，也就是带了很多自定义属性的XML文件。
XAML不仅可以作为makeup语句来定义web界面，也可以定义一般应用程序界面，从而模糊了bs cs界面开发。同时XAML也可以用来定义工作流。
如果有可能的话，可以参照一下此标准。

还有想提到的一点是目前微软和其他一些公司提供了另外一个设计方案，就是sliverlight。
http://www.asp.net/silverlight/default.aspx?tabid=62
是用来表现界面丰富的web界面，也是可以关注的一个新的技术。此新技术可以兼容与苹果机的浏览器，和firefox的浏览器。同时动态语言比如
ruby也可以用于编程。