论文进度报告（2005.1.14)

今天开始试用blog，只听说blog是个笔记本和日记本的结合体，还不知道其他的用处，所以就暂时用它当日记本
今天继续对我的OERM算法进行测试，现在发现的问题是precise, recall和F-Measure(=1)的精度都提高不上去，分析原因可能出在TargetErs这个类上。
对于一个token序列，在定义了它的评估类型的时候，可能需要前后联系，可是，我在做评估的时候，已经充分考虑了关系，现在如果需要前后联系的话，是否意味着需要定义一个新的Ontology，象RAPIER那样记录某些规则呢？如果把我的结果应用到RAPIER，相信效果跟RAPIER的效果差不多，而且OWL记录规则的能力很差（不过应付RAPIER那样的规则描述应该是够用了）
刚刚看了一下测试过程，卡在第99个了，真TMD的慢，唉，想当初我的梦想是出一篇SCI呀，可惜呀可惜，这么好的想法，没有条件。
我的解决办法是：1.尝试用Rough set的知识约减技术进行约减（这个估计要在后边试了）
2.尝试在得到token序列中每个token的Evaluation type后，对Evaluation Type做进一步的处理，还有就是考虑TargetErs中的知识收集是否有不当之处。
唉，这个过程真是痛苦。
本来想写个程序自动调用，来缓解Jena的内存泄漏的，呵呵，TMD的Solaries的环境变量不知道怎么设置，还有命令行不允许java那么长的classpath，郁闷，还要钻研看看，苦于手头没资料。

呵呵呵，发现一个巨有趣的问题，原来是我的程序有问题了，呵呵，记录结果如下：
show statistics data:
08:49:27,058  INFO OerMain:635 - correct answers: 20
08:49:27,058  INFO OerMain:636 - answers produced: 106
08:49:27,059  INFO OerMain:637 - total possible corrects: 44
08:49:27,060  INFO OerMain:638 - precise: 0.18867925
08:49:27,060  INFO OerMain:639 - recall:0.45454547
08:49:27,061  INFO OerMain:640 - F-measuer:0.26666668
08:49:27,062  INFO OerMain:644 - write test record to testrecord.dat
08:49:27,196  INFO OerMain:676 - the error results are:
technical
needs
looking
Group, Inc.
systems
needed
.A.
Group, Inc.,
placement
Technical Search

08:49:27,199  INFO OerMain:154 - test spend time:1979s

结果结束
从这个结果分析，我竟然找了106个结果，要知道是在10个文档中呀。而且居然Correct answer还有20个，平均每个文档2个，而最搞的是total possible correct是44个，奶奶的，恐怖就恐怖吧，这个也太恐怖了，好好看看，赶快。
现在要做两件事：
1.把TrainProcess和TestProcess之间的关系割裂开来
2.查统计为什么查那么多。

9:29 发现问题了，呵呵，低级错误，原来是把旧的记录文件读进来导致的，疯了，这么恐怖的事情也会发生。呵呵，要小心了，写了一个新的testProcess_Indep（）,表示它是独立的测试过程，还是这样好。

 测试完成了，发现比预期的差很多
关键是先提高precise，找到了很多没有意义的东西
当计算某个token的评估值时，不能只根据一阶相关性为不为0的来确定，而应该根据所有的内容，综合的评定其相关性，根据关系确定其值，不过这样计算量会加大。