README

用于从官方网站自动生成开放数据的微服务；需要启用 OpenPA 或其任何微服务。

安装 opendata_dataset-1.0-1.ezpkg 包

在激活扩展之前

cd lib; git clone https://github.com/Opencontent/Ckan_client-PHP.git;

更多信息，请参阅： https://www.opencontent.it/Per-la-PA

文档

本组件的文档正在发布中。

您是程序员并需要帮助吗？

• 请使用此存储库的 GitHub Issues 功能报告故障。
• 如需开发者支持，请发送电子邮件至 info@opencontent.it

许可权所有者

Opencontent SCARL Via Galilei Galilei 24 - Trento (意大利) 税务登记号和增值税号：02190640223 https://www.opencontent.it/

技术负责人

Opencontent SCARL https://www.opencontent.it/ Opencontent 负责设计、实现和维护 OpenPA

许可和用法

OpenPA 以开源许可证发布，GNU 通用公共许可证 v2.0，您可以在以下链接中完整阅读： https://gnu.ac.cn/licenses/gpl-2.0.txt

本许可证使任何用户都享有四个基本自由

• 自由 0：按您希望的方式执行程序，用于任何目的。
• 自由 1：研究程序如何工作并对其进行修改以适应您的需求。访问源代码是前提。
• 自由 2：重新分发副本以帮助他人。
• 自由 3：改进程序并将您所做的改进公开分发，以便整个社区都能从中受益。访问源代码是前提。

道德规范

OpenPA 是一个开源应用程序。源代码以 GNU 通用公共许可证 v2.0 发布，原因如下

• Opencontent 的商业模式及其企业道德规范，将知识共享视为不断提高企业质量和竞争力的决定性因素
• 保护用户，尤其是公共机构，使其更容易遵守第 68 条（如下所示）和公共行政信息化三年计划（特别是第 4、7 和 13 章）。

主要参考规范

数字行政法 - 第 68 条。解决方案比较分析

生效

1. 政府机构在符合经济性和效率、投资保护、重用和技术中立性原则的基础上，通过在市场上可用的以下解决方案之间进行技术经济比较评估，获取计算机程序或其部分：a) 为政府机构开发的软件；b) 重用为政府机构开发的软件或其部分；c) 自由软件或开源代码；d) 云计算模式可用的软件；e) 通过使用许可获取的专有软件；f) 结合上述解决方案的软件。

1-bis) 为此，在根据2016年第50号法律令规定的程序进行采购之前，政府机构根据以下标准对市场上可用的不同解决方案进行比较评估：a) 程序或解决方案的总成本，包括购买、实施、维护和支持的成本；b) 开放数据格式和接口的使用水平以及确保不同政府信息系统之间应用互操作性和协作的标准；c) 供应商在安全级别、符合数据保护法规、服务级别方面的保证，考虑到获取的软件类型。

1-ter) 如果根据第1-bis款规定的标准进行的技术和经济比较评估表明，有合理理由认为无法获得政府机构内部已有的或适合满足需求的自由软件或开源代码等解决方案，则允许通过使用许可获取专有软件。本款的评估按AgID规定的模式和标准进行。

三年计划：4. 无形基础设施

4.1. 政府数据

公共部门信息化资产的增值是公共部门的一个战略目标。为了利用公共部门收集和管理的海量数据潜力，有必要在管理上进行范式转变，以克服“孤岛逻辑”，实现系统性的视野。数据应被视为公共财富，免费共享于公共机构之间用于机构目的，除非有文件证明并适当说明，否则可用于民间。

为实现这一范式，计划确定了三个领域

• 国家数据库，即可靠、类型和内容统一、对公共机构履行职能和进行分析相关的基础数据库。它们构成信息化公共资产的基础结构，应为所有公共机构提供，以促进数据交换，避免多次向公民或企业请求相同信息（一次性原则）；
• 开放数据，即“开放数据”。它们涉及一个旨在使公共部门数据对任何人都可以自由使用、重用和再分发的流程，用于任何目的，包括商业目的，只要不受到特殊限制（例如：国家机密、统计数据机密、个人隐私保护监管机构规定的数据保护限制）；
• 受控词汇和数据模型，它们构成一种共同和共享的方式，以标准化和规范化地组织常用代码和命名法（受控词汇）以及在数据域范围内的详尽和严格的概述（本体或共享数据模型）。

公共财产的价值化需要精心编排的指导，以规划数据标准化、生成、保存和再利用的过程。这种增强将带来更多行政效率、为公民提供数据再利用的好处（从而避免再次提供公共行政部门已经拥有的数据），以及扩展分析的可能性，包括对社会现象的理解和预测，以支持政策制定和公民服务的发展。

三年计划：7. 数字服务生成和推广工具

7.2. 战略目标

• 促进开源范例的推广，通过便利化构建一个为公共行政部门提供应用程序和软件组件的开发者社区。
• 通过实施和推广开发工具包、验证和测试环境、每个项目的透明度沟通以及异常的通报和讨论，激励采用启用平台（例如SPID、PagoPA、ANPR）。
• 提供遵循的指南和实用的工具包，以开发具有适当设计、用户体验、安全和可用性的应用程序和服务。
• 促进基于公共行政部门提供的数据、API和信息的数字产品和服务的发展（例如公共数据库查询应用程序）。
• 共享指示和软件组件，以降低新数字产品的实施成本，促进再利用和互操作性。
• 支持行政部门推广和传播实施三年计划的必要服务和工具。

三年计划：13. 数字项目开发原则

本章包含的原则在此被重申并推荐，因为它们被认为是实现计划中项目的基本要素。这些注意事项既涉及实践性质的项目管理，也涉及合同和行政性质的项目撰写、目标定义和资源采购。

最后，为了实现新的系统或现有系统的演进，需要制定一个清晰的实现计划：

• 明确想要获得的结果（设计）；
• 构建它的计划（实施）；
• 将产品带到最终用户面前的战略（发布）；
• 维护系统更新、安全、有用的计划，同时确保在故障或灾难发生时也能持续运行（演进和维护）。

下文将更详细地描述这些要点。

13.1. 项目设计

设计阶段对项目的成功至关重要。关于这一点，请参考《公共行政部门网络服务设计指南》中的服务设计章节。特别是，在服务设计阶段，建议

• 始终涉及公民，从理解他们的需求（指南的第一项战略）开始。这意味着想象公民（或最终用户）将如何使用系统，并确保所有功能都围绕他们的需求设计，使他们能够轻松快速地获得所需内容——无需不必要的步骤，并提供易于理解的操作说明。
• 学习以理解，记录以避免重复（指南第3条策略）。了解项目将运作的背景，确定其目标，遵守标准，以及研究国内外有效的替代方案，同时还要调查已成功试验并可重复使用的工具和流程。项目的每个开发阶段都必须记录并公开，一方面为保证其未来的完整性和可持续性，另一方面为允许可能的合作，从而为项目增加新的价值。
• 应用“一次只做一次”原则（指南第6条策略）。避免让公民多次提供相同的信息。每个流程都应尽可能简单易用，必要时替换旧程序。
• 确定目标和指标。因此，需要确定要实现的目标，包括功能和流程，以及能够评估项目成功和满意度的指标。例如，在一个电子发票系统中，一个目标可能是“有一个不需要打印发票的流程”。当可能时，建议使用客观指标而不是问卷或调查得出的数据。例如，将“传统打印发票的数量”视为系统不足的指标，或“电子发送发票的数量”作为成功的因素。
• 从数据开始（指南第4条策略）。为了基于真实行为和数据做出决策，需要创建完全数字化的服务和流程，而不仅仅是将传统流程简单地搬到网上。
• 任命产品负责人，即一个能够代表服务最终用户的期望和需求的人，最好是在公共行政机构内部，但无论如何也不能与将实现该产品的主体有联系。这个人应具备对希望数字化的流程和预期结果有清晰的专业知识。例如，在一个电子发票项目中，产品负责人将是了解发票流程并能指导项目执行者如何发送和处理发票、这些发票应包含哪些数据等的人。

13.2. 项目实施

[...]

从技术角度来看，还需要

• 公开数据，共享流程和工具（指南第8条策略）。共享每个数据、每个流程、每段代码、每个想法、每个失败、每条信息对于所有服务都是必要的，并有利于促进透明度和质量发展。公共行政机构实施的每个服务的代码和文档都应以适当的许可证公开发布，以降低成本和时间；如果不可能，应适当说明障碍。
• 优先考虑自由或开源组件，即源代码可用的软件组件，如果可能，可自由修改和适应公共行政机构的需求，如CAD第68条规定。商业产品或源代码封闭的产品必须详细说明其理由，并且仅当项目所需的成本和功能与开源替代方案相比更有利时才允许使用。
• 根据经济性和效率选择硬件解决方案，特别是评估迁移到替代解决方案的成本（退出锁定）并确保技术中立。
• 使用公共行政机构的云服务。除非有证明的技术理由，否则软件和项目必须设计成可以在公共行政机构的云上使用，如第3.1段“数据中心和云”所述。

最后，实现的软件必须

• 采用微服务架构，即由执行少量明确功能的组件（例如，验证身份证号码，用户在数据库中的存在性）组成，通过API进行控制，易于重用，以便通过开发者社区提供给其他政府部门（参见第7章“数字服务的生成和推广工具”）。
• 暴露API，即创建允许系统之间轻松自动通信和交互的接口。用户界面和产品的所有功能都必须通过使用这些API构建（参见第5章“互操作性模型”）。
• 使用符合第4.1节“政府数据”中所述规则设计的数据库，特别是将关于所执行操作的性质及其随时间变化的信息插入到数据与分析框架（DAF）中。
• 根据AgID规定的互操作性和合作规则维护数据、服务和流程的互操作性，同时遵守确保用户隐私所需的准则。数据应以开放数据的形式提供，并附有对字段及其含义的详尽描述（元数据）。
• 使用可靠的测试和质量保证策略，即使用单元测试、功能测试和模糊测试来验证代码，并执行压力测试以验证产品将能够承受的负载。还建议使用代码静态分析策略，并对结果进行审计，以应对与安全相关的问题。
• 使用最佳安全实践，例如加密密码和网络通信。
• 包括所有必要的文档，即包括关于使用的数据结构（字段、表等）的文档、软件的功能和用法，以及关于产品功能、维护、更新和监控的文档。
• 属于政府部门，即合同必须明确指出，从代码到文档，从域名到许可、第三方库或产品上注册的专利，所有关于实现的权利都属于政府部门。这样，政府部门可以继续产品的演进，即使是通过与原始开发者不同的供应商。
• 提供给其他政府部门，即注册在Consip的市场中，并在可能的情况下，免费提供完整源代码和文档，附带开放许可，允许第三方使用、修改或演进。

当项目与第三方软件或现有系统集成很重要时，建议

• 提供测试工具和基础设施，即提供可以测试自己的软件的环境、测试账户或模拟器，供第三方自由使用，以验证组件之间的集成。
• 使用和记录协调软件更新的流程，这些流程应包括宣布即将发布新版本（新闻通讯、论坛等）、在测试环境中发布，并且仅在经过与系统用户和第三方软件在测试环境中的功能性验证后，才在生产环境中发布。
• 提供 库和开发工具包，即示例代码和软件组件，供第三方在其产品中使用，以集成到您的系统中。这有助于重用、提高代码质量、降低维护和更新成本、显著降低不兼容性和不符合规范的实现风险，并降低每个第三方的开发成本。

13.3. 项目启动

在确定实施项目的路径时，政府部门必须

• 确定最小阻力策略，即找到最简单、最快、影响最小的产品推广方法，即使是以有限的或未完成的形式开始推广。与其一次性引入重大变革，不如分步渐进——每一步都更简单、风险更低——最终实现最终目标。
• 确定增量使用策略，即找到那些能够先由少数用户使用，然后是更广泛的用户群体，最终由所有用户使用的机制。重要的是要强调，面向所有用户的服务的推出不应导致开发活动停止或产品的完成。相反，当可能时，建议采用在产品完成之前就能使用产品的策略，以便发现问题、重新组织优先级并开始提供创新带来的利益，即使产品是部分的。
• 确定产品全面上市计划，即停止旧产品。对于大型项目，重要的是要强调，上市策略不仅需要产品的实现，还需要针对用户的推广活动、沟通机制（邮件列表、Twitter、建立展示网站）以及任何被认为对产品推广重要的事项。
• 有效沟通，经常、无处不在（指南第5条）。政府部门必须清晰地传达服务的效用和先决条件，以及所有有关个人信息保护、隐私保护和网络安全的信息，通过最常用和普及的沟通渠道与公民沟通，让他们有机会访问自己的数据、控制它们并更正它们，保持持续的对话，甚至在服务推出之后。

13.4. 项目演变和维护

在定义项目演变和维护策略时，建议政府部门

• 确保定期维护和更新所有软件和系统，以预防安全问题的出现，确保软件与新技术兼容，并符合法规的演变。
• 确保一个持续的产品演变计划，即在产品推出后建立或拥有一个改进产品的策略，添加功能、修复问题，以及更一般地，允许产品更新。
• 确保一个灾难恢复和业务连续性策略，即确保在出现故障或灾难时，关键数据不会丢失，并且可以继续以减小的模式提供服务。
• 确保对运行参数的持续检查，例如，监控软件（错误、请求、延迟）、定期的审计以确保其安全性等。
• 准备所有必要的避免锁定程序，保持从一家供应商切换到另一家的可能性。使用多个供应商进行产品的实施、维护和推出通常可以保证更好地迁移到其他供应商的能力。