# 「公平透明、动态渐进」——建言《上海市公共数据和一网通办管理办法草案》

8月31日，上海市人民政府正式发布了《上海市公共数据和一网通办管理办法》（草案），面向全社会征集反馈意见。开放数据中国针对其中「数据开放」相关的条款，提出以下建议：

## **1.    关于数据开放的定义**

**修改（新增）：**&#x5EFA;议于办法草案「第三条（定义）」处增补数据开放的定义，文本建议为：

**「第三条（定义）**

**…**

**本办法所指数据开放指的是公共管理和服务机构向自然人、法人和非法人组织提供数据资源或数据服务以满足加工利用需要的行为。」**

**观点：**&#x6839;据国际通行的一般定义，「数据开放」指的是向自然人、法人及其他组织无歧视性提供免费、可机读的、可自由利用与传播的原始数据的行为。从政府角度来说，数据开放一般指的是政府数据开放。

针对办法草案，数据开放的范畴，显然已不局限于传统的政府或政务数据的开放，而是扩展至「公共数据」的范畴，且根据「第九章 附则」适用于提供公共服务的公用事业运营单位（含企业）和其他财政款项支撑的机构。在此基础上，我们所需考量的是国际通行的「数据开放」定义是否适用于中国现有的经济、社会、法律环境，是否适用于公共数据的各责任主体、以及是否符合中国社会对「数据开放」的现有认知。

事实上，国务院发布的《促进大数据发展行动纲要》，以及国家网信办、发改委和工信部联合印发的《公共信息资源开放试点工作方案》都未对「数据开放」做明确的定义，但在地方层面，部分城市在出台相关规定时对此做了定义，例如《贵阳市政府数据共享开放条例》的「第二条」指出「本条例所称政府数据开放，是指行政机关面向公民、法人和其他组织提供政府数据的行为。」，又例如《银川市城市数据共享开放管理办法》中「第二条」指出「本办法所称数据开放，是指政府部门、事业单位、国有企业等机构向公民、法人和其他组织提供数据的行为，……」。显然，从地方政府视角，对数据开放的认知是广义的。

进一步，考虑到公共数据范畴下，数据开放责任单位的性质多样化，并不局限在政府机构，因而数据开放的激励机制、成本负担方式、收益方式都需重新探索，由此无法轻易采用国际定义的免费、无限制授权、原始数据的特性去界定办法草案中的「数据开放」。同时，考虑到中国国情下，公共数据开放的目的有别于西方国家主要推动政府透明监管的诉求，因此我们建议办法草案采用类似贵阳、银川对「数据开放」的泛化定义，从而便于概念的落地与后续执行。

而针对贵阳、银川等地的数据开放定义，我们建议对其做必要的改动。其一是，将其中「提供数据」这一行为的目的明确，强调「为了满足第三方加工利用需要」，而不是简单的「满足第三方获取信息」。从而将提供封装数据的信息化应用（例如信用中国提供的查询系统，实质封装了信用数据，也可被理解为「提供数据」）方式排除在「数据开放」之外，避免使用者需要通过爬虫、轮询查询等方式间接透过信息化应用才能获取数据资源用于加工利用。其二是，考虑到实际数据利用场景中，数据的使用者并非是必须访问到最原始的数据，在一些情况下数据的抽象模型或计算结果作为一种数据服务即可满足使用者的诉求。例如，运营商的基站定位数据，原始数据规模大、复杂性高，从提供数据资源角度而言，传输和计算处理难度都较高。而在区域客流预测场景中，数据利用者往往需要的实际是宏观的、抽象至特定网格大小、特定时间窗口范围的计算结果数据，因此如果责任单位能够提供数据模型/抽象数据即可满足需要，并能服务化提供的话，也应当视作是满足使用者加工利用需要的一种可接受的「数据开放」行为。

## **2.    关于数据开放的要求**

**原文：**&#x529E;法草案中「第三十五条（数据开放要求）」指出「市经济信息化部门应当以需求为导向，遵循统一标准、便捷高效、安全可控的原则，有序推进面向自然人、法人和非法人组织的公共数据以可机读标准格式开放。」

**修改（补充、修正）：**&#x5EFA;议「第三十五条」相应文本修改为：

**「第三十五条 （数据开放要求）**

**市经济信息化部门应当以问题和需求为导向，遵循统一标准、动态渐进、便捷高效、安全可控、公平透明的原则，有序推进面向自然人、法人和非法人组织的公共数据以可机读方式开放。」**

**观点：**&#x20;

* **增加「问题导向」：**

对于需求为导向，推进公共数据开放，我们持以赞同的态度，但除响应式的需求导向之外，我们建议增加主动引导式的「问题导向」，两者可形成互补。

事实上，「国际开放数据宪章」（opendatacharter.net）在2018年的年度战略中指出全球数据开放逐步进入瓶颈期，没有目的地开放各类数据对于进一步解决社会问题和刺激数据利用均无价值，因此应当「以问题为导向驱动数据开放(Publishing with Purpose)」。

问题导向，意味着鼓励管理公共数据的责任单位更为主动地思考数据的应用场景，并通过构建场景，策略性地批量、有关联得协调自身的以及相关的公共数据共同开放。

同时，问题导向也意味着鼓励责任单位能够思考如何通过开放与「问题」相关的数据，引入外部的创新力量，协同解决问题。特别地，当「问题」和「需求」两者相互有碰撞契合时，也能收获最佳的「数据开放」的效益。例如，在上海市经信委所主办的上海市开放数据创新应用大赛（SODA）（2017赛事）中，上海市工商局围绕如何精细化治理消费者投诉热线开放了12345热线电话数据供赛事使用，而有需求此数据的外部创新团队就能围绕工商局抛出的问题进行解答，从而产出有助于政府应用大数据和人工智能精细化治理的应用。

* **增加「动态渐进」的原则：**

我们认为公共数据开放的开放方式是可以随着发展环境的变化而动态调整的，并始终以国际通行的、标准的「数据开放」为终极目标，渐进趋向于它。

对于公共数据开放的责任单位而言，外部因素例如数据所有权的界定不清、隐私保护政策不明等、内部因素例如领导决策体系的变化、成本收益机制的调整等都将影响其如何确定何种数据资源可以通过何种方式对外提供。因此，一个机构可以选择在一开始通过物理沙箱形式（即建设安全计算环境，邀请数据利用者驻场通过指定计算设备利用数据）对外提供数据，而当各种环境因素有所变化，且其对数据利用者使用需求有更多了解后，其可以考虑将部分数据资源建设为数据服务，以数据接口方式对外提供数据。而这就是一种动态渐进的调整过程。

我们建议，在实际开展工作中，应当能够结合第三方对公共数据开放评估的工作，推进并鼓励责任单位能够定期重新检视其公共数据开放的方法，在条件成熟情况下，对数据开放的方法做必要的动态调整。

* **增加「公平透明」的原则：**

结合上述「关于数据开放的定义」的观点内容，当「数据开放」作为一个泛化的概念时，数据开放的行为扩展为了可囊括限定条件、限定对象、收取费用等不同流通特性组合的对外流通行为，一方面泛化的数据开放有利于概念的快速落地、降低难度并基于现有数据流通基础有序推进开放、加速释放数据红利，但另一方面，其也可能在发展过程中，滋生出「垄断式数据提供」、「权力寻租」等隐患，因此我们建议管理办法中，应当对此予以防范。

我们建议的方法是，增加「公平透明」的原则。「公平透明」既符合《上海市大数据发展实施意见》中「推动政府数据稳妥有序开放和社会数据公开透明流通」的相关原则要求，也符合数字经济发展下，数据作为新型生产要素（公共数据作为公共资源），其流通应当符合公平、透明市场规则的大原则的要求。（我们认为《中共中央关于全面深化改革若干重大问题的决定》、《关于推进公共资源配置领域政府信息公开的意见》中关于建立公平、透明市场规则的改革要求对于数据流通/开放问题具有一定的指导和参考价值）。而所谓「公平透明」，我们认为，其概括性地涵盖了三点内容：

1） 无歧视性：对于任何有条件开放的数据，如果一项数据面向任意机构或个人予以开放，则其应当对任何符合相应条件的机构和个人开放。

2） 条件公平性：对于有条件开放的数据，在设定其相应的申请资格、费用框架等「条件」时，应当充分考虑市场公平性，面对不同的使用对象、使用目的，设定符合实际的、公平的、分层级的「条件」。

3） 流通透明性：任何有条件或无条件开放的数据，都应当公开列入公共数据开放清单，并对社会公布。特别地，对于有条件开放的数据，应当建立数据开放主动披露机制，对于每一项数据有条件开放给谁，如何开放做公开的记录和发布。（注：关于披露机制我们将在后文详细说明）

* **修正「可机读标准格式」用语**

原文中「可机读标准格式」的说法通常适用于数据以「文件」形式提供下载或物理拷贝流通的情况。考虑到各种数据开放情况下，数据可以通过接口（无论是数据序列化后返回数据内容的接口或是数据模型化后返回计算结果的接口）开放，将其准确表述为「可机读方式」更贴近实际用语习惯。

另一方面，「可机读方式」也可同时隐性包含对数据元数据、数据接口文档等数据相关上下文内容应当尽可能以可机读格式发布的要求，使得相关条款在未来有一定解释和实践上的扩展性。

## **3.    关于数据开放的分类界定**

**原文：**&#x7B2C;三十六条（数据分类开放）「公共数据资源目录中的数据按照开放属性分为无条件开放类、有条件开放类和非开放类。涉及商业秘密或者个人隐私，以及法律法规规定不得开放的，列入非开放类；对数据安全和处理能力要求较高、实时性强或者需持续获取的公共数据，列入有条件开放类；其他数据列入无条件开放类。

对无条件开放类的公共数据，公共管理和服务机构应当通过开放子平台主动向社会开放。

对有条件开放类的公共数据，公共管理和服务机构对数据请求进行审核后，通过开放子平台以接口等方式开放。」

**修改（修正、删除、增补）：**&#x5EFA;议第三十六条修改如下

**「第三十六条（数据分类开放）**

**公共数据资源目录中的数据按照开放属性分为开放类和非开放类。涉及商业秘密或者个人隐私且经过脱敏加工无法满足外部加工利用需要的，以及法律法规规定不得开放的，应当列入非开放类；其他数据列入开放类。**

**开放类的公共数据资源，按照开放方式分为有条件开放和无条件开放。公共管理和服务机构需要设定「审核」流程提供的数据资源，归为有条件开放；无需「审核」流程即可提供的数据资源，归为无条件开放。**

**……**

**对有条件开放的公共数据，公共管理和服务机构对数据请求审核后，通过开放子平台以接口等方式开放。」**

**观点：**

* **区分「数据开放属性分类」与「数据开放方式分类」：**

我们认为，目前第三十六条混淆了「开放属性分类」和「开放方式分类」两个概念。

所谓「开放属性分类」，我们理解的是根据数据自身的内容特性，关于「是否能开放」而形成的分类：即「开放类」和「非开放类」。开放类的数据未必以其原始数据形式开放给社会使用，其应当包括原始数据以及基于原始数据抽象、计算得到的加工数据。即「开放类」的公共数据资源，在「数据开放清单」中应当能够一对多映射多个加工数据或一对一映射原始数据。（可参考案例是前述关于「数据开放定义」中提及的运营商对基站定位数据的对外供给规则处理。我们在数据开放清单的修改中将展开论述公共数据资源目录和数据开放清单间的映射方式。）

所谓「开放方式分类」，应当是对「数据如何开放」做出的界定。其应当是针对「开放类」的数据，按照实际情况，确定「是否要加予条件」，形成「有条件」和「无条件」两类。结合上述「动态渐进」原则，数据资源的开放方式分类是可动态调整的，而非确定后即固定不变的。

* **调整「非开放类」定义：**

我们建议，对于涉及商业秘密或者个人隐私的数据，不应该一刀切的将涉及商业秘密或者个人隐私的数据全部纳入非开放类，而应当要求责任单位必须首先尝试采用脱敏、抽象等方式对数据予以加工，在检验「加工后的数据」是否能满足外部加工利用需要的基础上，才确定数据是否归入非开放类。当且仅当一项数据资源，在脱敏抽象后，实际无法满足进一步加工利用需求的情况下，其才应当被归类为「非开放类」。

* **调整「有条件开放」和「无条件开放」的定义：**

数据有条件、无条件开放的分类决策应当是责任单位结合实际情况和需要，自由做出的数据对外提供时是否需要「审核」的选择。

虽然「数据安全和处理能力要求较高、实时性强或者需持续获取」是影响决策的一类因素，但其与「是否需审核」（即「有条件」）之间不构成必然的因果关系。责任单位应有权利自由选择「无条件」开放此类数据（即使大多数情况下，的确因为成本等原因会更偏向选择「有条件」，但无法排除「无条件」提供的可能），管理办法不应当人为设定「如果…就…」的单一选择去限制责任单位的决定。

因此我们建议定义仅仅对「有条件」和「无条件」需要「审核」与否做出界定，而不对「审核」与否背后的决策原因做出过多细分的描述，给与责任单位充分的自由，和动态渐进调整的空间。

* **去除「以接口等方式开放」的表述：**

针对「有条件开放」的公共数据，原文中特别指出了其「通过开放子平台以接口等方式开放」。我们认为这里与「无条件开放」的「主动向社会开放」相比，特殊的指出「接口等方式」是没有必要的。因为无论是「有条件」还是「无条件」，其与责任单位选择「以文件下载」、「以接口提供」、「以沙箱提供」等具体提供数据的形式是无关的，两者并无关联关系，因此不应当特殊地在「有条件」分类下特别指出「接口等方式」，容易对责任单位形成误导。（或者如保留「以接口等方式」，则其前应当加上「优先」）

## **4.    关于数据开放的清单**

**原文：**&#x7B2C;三十七条（数据开放清单）「公共管理和服务机构应当按照国家及地方相关标准，根据公共数据资源目录制定本机构数据开放清单，向社会公布，并动态更新。通过共享、购买、协商等方式获取的数据不纳入本机构数据开放清单。」

**修改（增补）：**&#x6211;们建议对第三十七条做如下修改

**「第三十七条（数据开放清单）**

**公共管理和服务机构应当按照国家及地方相关标准，根据公共数据资源目录制定本机构数据开放清单，以可机读方式通过开放子平台向社会公布，动态更新并保留历史记录。通过共享、购买、协商等方式获取的数据不纳入本机构数据开放清单。**

**公共管理和服务机构应当在数据开放清单基础上，结合实际情况，制定年度开放计划并向社会公布。」**

**观点：**

**1）梳理「公共数据资源目录」、「数据开放清单」、「年度开放计划」间的关系**

我们认为公共数据的责任单位根据自身的信息系统建设，可以梳理出「公共数据资源目录」，其记录的应当是责任单位原始的、未经加工整合的数据资源，并在梳理时确定其开放属性（即开放与否：开放类 v.s. 非开放类）。

针对公共数据资源目录中的「开放类」数据资源，责任单位应当根据实际情况，梳理数据开放清单。「开放清单」中的每项记录可称为「数据开放产品」，其包括数据资源和数据服务，并和公共数据资源目录中的数据资源一对一或多对一映射：对于直接原始可开放的数据（包括通过删除特定记录、字段方式等的脱敏原始数据），其应当可以一对一映射入开放清单。而对于需经过抽象、计算后仅能开放加工后数据的，则可能一对一或一对多（即可能数据按需求分级抽象）映射入开放清单。开放清单中的「数据开放产品」应当映射覆盖责任单位公共数据资源目录中「开放类」的所有数据资源，无论其对应的「数据开放产品」在现阶段是否实质性已经完成准备、具备对外服务提供的基础。数据开放清单可通过设置「开放状态」（例如计划中、已开放、未开放等）、「开放日期」等字段，记录下对应「数据开放产品」的当前状态，并按照工作节奏更新开放清单、对外发布，使得数据利用者始终能够通过开放子平台查询到相应「数据开放产品」，对于「已开放」的可直接获取或申请，对于「计划中」或「未开放」的可以进一步通过交流、沟通、反馈等方式提出「需求」，加速开放。

而「年度计划」应当是责任单位根据实际情况，列举出的「开放清单」中本年度将从「未开放」状态转入「已开放」状态的「数据开放产品」。相应的，「开放清单」中应将纳入年度计划的这部分「数据开放产品」状态更新为「计划中」，直至完成上线后再更新为「已开放」。

**2）明确「数据开放清单」的公布和更新机制**

我们建议，数据开放清单作为责任单位目前以及将来将会对外提供的数据开放产品的完整目录，应当通过开放子平台，以可机读方式，对社会公布。

并且根据上述1）点的论述，其更新过程应当能够保留修改记录，以便必要的回溯和第三方评价。

## **5.    关于数据开放的信息披露机制**

**修改（增加）：**&#x5EFA;议在第三十八条 （开放数据利用）前增补一条关于信息披露的条款

**「第三十八条 （开放情况披露）**

**公共管理和服务机构应当主动、及时、持续地通过开放子平台以可机读方式披露每一次数据开放行为，内容至少应包含相应的数据名称、数据内容、数据开放对象、数据使用类型、数据授权方式、数据收费方式、开放日期等。」**

**观点：**&#x57FA;于前述「数据开放的要求」所讨论的「公平透明」的原则，我们建议在管理办法中加入相应条款，明确建立数据开放行为（特别是「有条件开放」）的主动信息披露机制，但具体的操作细则可以在未来逐步完善并设置在管理细则中。

要求责任单位主动披露每一次数据开放的行为，有着以下益处：

a.    有利于提升数据利用者，尤其是企业，对公共数据开放工作的了解和信任

b.    有助于社会各界对公共数据开放工作的监督，确保市场公平性和数据开放的无歧视性

c.     支撑第三方评估、数据开放应用成果追踪等工作

d.    有益于培育数据应用者标注公共数据来源（即「数据引用」）的数据文化

e.    提升数据利用的透明度、可追溯性、可监管性（尤其是 AI 算法应用、个人数据应用等）

我们在建议此信息披露机制时，参考了英国学者Tim Davies 等草拟的《数据共享信息披露标准（草案）》，并建议针对数据开放行为，可要求主动披露以下信息：

* 数据开放申请编号
* 数据名称
* 数据资源编号（开放子平台分配）
* 所开放数据资源详情
* 管理部门
* 开放对象类型（科研高校、企业等）
* 开放对象名称
* 应用目的类型（学术研究、产品应用等）
* 开放授权协议（附参考副本链接）
* 开放形式（物理拷贝、沙箱使用、API等）
* 申请日期
* 核准日期
* 开始开放日期
* 终止开放日期

而针对信息披露的渠道，我们建议，在开放子平台对应的数据资源页面上，应当设置有相应的数据开放信息披露板块，提供披露数据的直接预览，并提供披露数据的直接下载或接口访问。

**目前国际开放数据运动正面临理论和实践的重构和战略重定位，而中国环境下，「公共数据开放」究竟该如何定位、如何构架体系，如何区别于欧美的方式但又能够与其有所包容接轨，则是一个全新的问题。上述针对上海公共数据管理办法的建议尚有不成熟之处，仅是一个阶段的思考产出，**&#x56E0;此我们欢迎各界同仁留言或来信: <info@opendatachina.com> 同我们深入探讨「公共数据开放」理论与实践体系的重构问题。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://blog.opendatachina.org/blogs/gong-ping-tou-ming-dong-tai-jian-jin-jian-yan-shang-hai-shi-gong-gong-shu-ju-he-yi-wang-tong-ban-gua.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
