Beefsteak Is Thinking

我们组的乌托邦项目全称是“上海近现代文化名人数字图书馆 以下简称上名图”，旨在以人为线，收集、加工、保存、展现与文化名人相关的信息资源，资源类型包括手稿、照片、书信、录像等，所选择的资源都与人物有关。可惜组长离开上海了，百年之后她本也可以成为这里的资源。

上名图的mision是以人物为资源主线串联和揭示与之相关资源，好比是抬出“鲁迅”的蜡像，观众就能看见蜡像，还能看见蜡像后面拖油瓶样的带出一大串鲁迅遗物，毡帽，毛笔，烟斗，还有许广平，郭沫若等等一些与鲁迅爱恨交织的人物蜡像也跟了出来。项目的highlight是通过资源的共性来揭示人物。假设：鲁迅用的烟斗，郭沫若也用，那么就可以通过instance烟斗来揭示人物关系（这俩日本留学生再活一回会有共同语言吗）。
碰到一个难题：资源对象之间嵌套太复杂了，你中有我，我中有你。直接的后果就是对象排列组合数量庞大。猜测会发生以下的错乱，一是本体编制的头绪，二是元数据加工的程序。前者只要领域专家凭着愚公移山的精神应该能搞定，后者即使是“智公”也可能会累得吐血而亡的。譬如，鲁迅的work《阿Q正传》，它的表现形式可能是电影，小说，话剧，沪剧，它的manifestation也有很多，如XX出版社，XX电影公司。这样的情况不是一对一了，而是一对多、多对多、多对一。阿Q、革命党、钢鞭等concept、instance如果出现在别的文献里面，对象嵌套会非常复杂。关系怎么梳理？元数据的录入又怎么办？

其实，看了Encarta2008，就发现“人物”资源还是分类简单一些为妙。不然就是自己挖坑。这个上名馆我们组讨论得很热烈，项目几次迭代，没完蛋。组长真的下了功夫，她的设想没有任何错误，可是实现不了。技术拖了后退吗？

至于上名馆资源的长期保存，可以考虑用DOI，或者别的资源标识来解决。反正乌托邦项目不用考虑是否出红字。