{"action":"created","issue":{"url":"https://api.github.com/repos/DigitalPlatform/dp3/issues/1","repository_url":"https://api.github.com/repos/DigitalPlatform/dp3","labels_url":"https://api.github.com/repos/DigitalPlatform/dp3/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/DigitalPlatform/dp3/issues/1/comments","events_url":"https://api.github.com/repos/DigitalPlatform/dp3/issues/1/events","html_url":"https://github.com/DigitalPlatform/dp3/issues/1","id":318659546,"number":1,"title":"dp3初期讨论","user":{"login":"renyh","id":13568719,"avatar_url":"https://avatars3.githubusercontent.com/u/13568719?v=4","gravatar_id":"","url":"https://api.github.com/users/renyh","html_url":"https://github.com/renyh","followers_url":"https://api.github.com/users/renyh/followers","following_url":"https://api.github.com/users/renyh/following{/other_user}","gists_url":"https://api.github.com/users/renyh/gists{/gist_id}","starred_url":"https://api.github.com/users/renyh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/renyh/subscriptions","organizations_url":"https://api.github.com/users/renyh/orgs","repos_url":"https://api.github.com/users/renyh/repos","events_url":"https://api.github.com/users/renyh/events{/privacy}","received_events_url":"https://api.github.com/users/renyh/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-04-28T18:43:39Z","updated_at":"2018-05-02T22:38:18Z","closed_at":null,"author_association":"COLLABORATOR","body":"dp3是数字平台第三代图书馆系统，继续坚持开源思想。\r\n\r\n## dp3初创人员\r\n谢老师顾问，任**初期开发主管，公司开发人员（包括兼职），合作伙伴开发人员和测试人员，编目专家。\r\n\r\n## 协作开发流程\r\n各位开发者Fork dp3，编写代码，提交PR，初期暂时由任**合并。\r\nhttps://github.com/DigitalPlatform/chord/wiki/Github%e5%8d%8f%e4%bd%9c%e5%bc%80%e5%8f%91\r\n\r\n\r\n## 服务器模块\r\n包括数据库底层和系统接口。\r\n服务器模块用.NET Core开发，支持跨平台\r\n数据库选用MongoDB。\r\nMARC存储采用中间格式，同时保存原来的unimarc或usmarc。\r\n服务器模块出来，用一个简单的工具把dp2系统的数据导入导出。\r\n服务器模块是dp3的基础核心模块，优先开发。\r\n\r\n希望在五一期间，把程序框架搭起来。  \r\n先建一个.NET Core访问MongoDB的实验程序\r\n![image](https://user-images.githubusercontent.com/13568719/39399834-a6d12f58-4b57-11e8-9f10-61abcf3192a7.png)\r\n\r\n## 阅读分析模块\r\n在新服务器模块的基础上，实现读者借阅统计报告。\r\n\r\ndp3 开发进程到阅读分析模块出来以后，其实阅读分析的报表不是全部，应该还包含现在内务的报表模块的所有报表。而且这个阅读分析和报表模块应该是能在阿里云服务器上独立自动运行的，到时候就可以省掉人工去创建和上传报表的操作了。\r\n"},"comment":{"url":"https://api.github.com/repos/DigitalPlatform/dp3/issues/comments/386143110","html_url":"https://github.com/DigitalPlatform/dp3/issues/1#issuecomment-386143110","issue_url":"https://api.github.com/repos/DigitalPlatform/dp3/issues/1","id":386143110,"user":{"login":"renyh","id":13568719,"avatar_url":"https://avatars3.githubusercontent.com/u/13568719?v=4","gravatar_id":"","url":"https://api.github.com/users/renyh","html_url":"https://github.com/renyh","followers_url":"https://api.github.com/users/renyh/followers","following_url":"https://api.github.com/users/renyh/following{/other_user}","gists_url":"https://api.github.com/users/renyh/gists{/gist_id}","starred_url":"https://api.github.com/users/renyh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/renyh/subscriptions","organizations_url":"https://api.github.com/users/renyh/orgs","repos_url":"https://api.github.com/users/renyh/repos","events_url":"https://api.github.com/users/renyh/events{/privacy}","received_events_url":"https://api.github.com/users/renyh/received_events","type":"User","site_admin":false},"created_at":"2018-05-02T22:38:18Z","updated_at":"2018-05-02T22:38:18Z","author_association":"COLLABORATOR","body":"## 关于长期保存的业务中立格式\r\n\r\nJason.Liao(271095962) 17:18:09\r\n@数字平台谢* dp3的架构会考虑从业务去驱动吗？DDD\r\n\r\n数字平台谢*(2820725526) 18:34:49\r\n@Jason.Liao  DDD 的概念了解过一点，但没有经过系统培训。也许我们的系统里面有一些原始的领域驱动的思想。\r\n\r\n数字平台谢*(2820725526) 18:36:19\r\ndp2 系统设计的时候，是比较看重“图书馆业务数据”的。数据是按照方便业务来设计、组织、安排的。比如读者记录是 XML 格式，里面存储了很多状态或者流程信息，而不是把各种信息切碎了放到各种 SQL 表中。这个思想是优先业务的，不是优先数据库的。\r\n\r\n数字平台谢*(2820725526) 18:37:30\r\n有了业务和 XML 数据之间的关系模型以后，再想办法去把 XML 剖开对应到 SQL 的概念。但后面这一层是隔离的，不会影响到前者的设计。也就是说后者不影响前者实现即可，后者可以有多种处理方法，不是唯一的方法。\r\n\r\n数字平台谢*(2820725526) 18:40:03\r\n图书馆界有一种数据\"长期保存\"的研究领域。它主要是关注几十年上百年之间，系统不断升级迁移的时候，数据能长期保持稳定，而不会出现数据跟着系统被埋葬的情况。所以这种数据一定是非常豁达和超前的，不受所谓 SQL Server 的局限，基本上是按照图书馆业务术语来书写的数据格式，多半是半结构化的数据。\r\n\r\n我们设计系统时候也受到这种影响。所以设计数据结构时候，希望数据结构保持中立。能几十年保持不变。或者虽然变了但很容易映射和迁移。\r\n\r\n## 关于书目中立格式\r\n\r\n\r\n其实 ISO2709 格式保存的书目数据就是个好例子。在各行各业中，图书馆行业的标准化是做得比较好的。\r\n\r\n前几天和任**聊到，dp3 我希望设计一种中立格式，给 mongodb 使用。同时也基本上是系统的内部重要格式，比如我们提取书目信息的时候，优先用这种中立格式，就非常方便，可以大大节省开发成本。\r\n\r\n对比起来，dp2 系统是直接存储 UNIMARC 和 USMARC 两种具体的 MARC 方言格式的。比如 UNIMARC 200 是题名与责任者字段，而 USMARC 是 245。那么 dp2 前端很多时候拿到两种 MARC，需要用两种处理模块去装配为可以显示的书目摘要格式，感觉很累。\r\n\r\n如果把相关 API 中，获取一种好用的数目摘要的格式，也就是说 UNIMARC 和 USMARC 都通用的共同格式，比如 ISBD 格式，这个过程推给 dp2library 来做，那就减轻了前端的负担。这时候其实已经有一种中立格式的萌芽思想了。\r\n\r\ndp3 打算进一步发展这个思想。干脆在系统里面给这种中立格式一个合法体面的地位。这样，在 mongodb 数据库存储每一条书目记录的时候，同时存储具体的 MARC 记录原始信息，和转换为中立格式的信息。这个动作是一个原子操作，可以认为两类格式是二位一体的。作为一种基础的设计。\r\n\r\n从使用频率来说，可能 99% 情况下会提取中立格式去满足图书馆业务，1% 情况下去提取原始 MARC 格式。\r\n\r\n我们考虑一下有些小型的图书馆系统，它们不是很严格要求使用 MARC。所以我们这个设计，可以产生一种副产品用法，就是可以让小型图书馆系统，直接让用户输入中立格式，保存中立格式，完成图书馆业务，中间任何一环都不涉及到原始 MARC 格式。要给这种用法一个名分的话，我们可以认为这个中立格式是兼容 DC 元数据格式的一种格式，这样就具有某种合法性了。\r\n\r\nJason.Liao(271095962) 18:59:53\r\n每个行业都有自己的数据格式，可能就跟EDI一样，我看到marc.iso文件的时候第一感觉这是个flatfie，然后要考虑去怎么解析他，甚至怀念了一把微软的BizTalk。做一个中立格式或者说canonical的document是很有必要的。\r\n"}}
{"actor":{"display_login":"renyh"}}