社交数据规范化

假定我们通过HTTP POST来处理广域网范围内的事件的方式——Web Hooks——解决了数据访问延迟问题。这种方式只是解决了通用的API访问问题，而不是数据本身的多样化特征问题。XML提供了数据的结构化特性，但是没有考虑到通用性。当今的社交数据聚集应用和它们要集成的各种类型的社交数据的API都碰上了“一次性理解”的难题。理解从一个特定API获取到的数据的结构需要付出的代价很高——太高了。虽然多路复用网关协议已经存在了很长时间，但是通常对于加强来自稀疏数据源的通用的、规范化的数据，只存在严格的XML转换翻译器。遗憾的是，严格的数据解析方式很少能够正常工作，因为实际上各种服务集创建的数据是非常多样化的。人们对标准、编码和转义序列的理解都是不同的。此外，创建XML用于消费的软件不可避免地存在bug，这导致输出格式简陋，对其使用变得进一步复杂化。

我们从严格的HTML解析Web浏览器中明白，遗憾的是，标准并不能使那些和标准保持一致的软件能够准确无误地解析这些非完美的数据格式。实际情况是标准有不同的解析方式，软件存在bug，而且最强大的事实标准是用户已经正在做的事。人类的强大永远都不能被否认。

如果你曾经花一些时间从各种社交数据源看这些数据，你会注意到这些数据变得看起来都差不多。虽然要解释的通用性对人类而言很明确，但对机器来说却很困难；需要人工编辑指南给出从数据集A到数据集B的映射。

从两种不同的“社交标签”服务考虑以下两个XML例子。虽然它们显然都是XML，但是其“书签”的表示方式差别迥异，而且它们都为终端用户提供相似的服务。

来自Delicious网站：

来自givealink.org网站：

当今，有成千上万的服务通过API和Feeds暴露其用户生成的内容(Uer-Generated Content,UGC)，对其结构和内容进行规范化，这样开发人员可以期望通用性优先级变得更高。DiSo项目是把整个API范围内相关成员引入该方面的主要催化剂，用于“净化”更多可使用的社交数据参见http：//diso-project.org/wiki/activity-streams。

作为数据生成者和数据使用者之间的媒体，Gnip处于一个得天独厚的地位来把社交数据的意义翻译和规范化到传统的理解和结构中。利用整个行业范围内需要更易于消费的社交数据提供集体输入和知识，Gnip作为“漏斗”，接收的是很多不同的协议和格式，而输出的是一致、异构的数据，并提供了对数据更便捷的访问方式。

数据的商业价值

关于开源软件是好是坏的争论基本结束。企业何时对其软件或者是部分软件进行开源，何时不能开源，有很清晰的界限。总体来说，如果你的软件享有“独一无二”的知识产权，把你和外界的其他方面分离开，你应该考虑不把它开源。否则，它就可以作为开源，这样开源社区可以在代码中涵盖其经验和专业知识，为全世界作出贡献。遗憾的是，软件开源而言的数据相对决策框架还不够成熟。API的爆炸使得数据发布商措手不及，因此，他们对数据价值的理解变得糊涂得一文不值。

一些传统的内容发布商已经强化了其数据的价值。提供免费的周刊来提供内容，包含广告商支持内容（评论）和产品（杂志）的生成。一些贸易杂志收取订阅金，不加入广告模式。Internet上的传统的媒体/内容发布商主要采取广告模式来支持他们的数据（内容）的分布。然而，通过API访问社交数据没有成熟的模型。提供商是否需要为数据本身的访问收费，还是一切都免费？除非你是一个“freegan”（反消费者），否则以上问题没有一个有明确的答案。除非谈及的数据存在内在价值，否则对其评价变得非常困难和曲折。如果你作为数据使用者，为了购买微博客消息，是否应该花费0.01美元？这个消息是否应该获得许可，或者访问方式是否应该被租用？数据项的价值和对它在转换处理之间的区别开始变得很明显。用户在发布商的服务上真正去生成内容，是否应该获得其中收益的一部分？从刚开始，谁是真正的数据拥有者？正如你所见的，这里充斥着很多这样的问题，它们没有明显的答案。

当出现了社交数据，在该行业中，一些发布商会声称他们的数据是无价的，而另一些则认为数据是免费的。数据使用者已经潜意识地相信绝大多数的数据是免费的。因此，如果真的对社交数据进行标价，他们便会发展成价值链切实的一部分。

公共的与私有的

有些数据被认为是公共的，而其他数据则被认为是私有的。公共和私有这二者之间的区别是通过提供数据的服务来定义的，而且通常是通过给定服务的《服务条款》来概括的。虽然对这二者的社会理解及其本身是很有意思的话题，但是我在这部分将考虑访问这二者的技术上的一些隐式问题。

让我们从两个当中更简单的公共数据说起。访问公共数据相对来说比较简单。今天绝大多数的数据API是通过未授权的REST接口来访问的。这意味着在网络上它们和其他的URL并没有什么区别，它们可以很容易被任意用户和应用程序利用。访问这些API终端需要很少的身份验证形式，如果有的话，而且对API用户的授权通常是通过不透明的方式在幕后实现处理的。两种更丰富的验证方式是使用HTTP Basic-Auth和嵌入在URL中的“API关键字”。这两种方式都允许API服务基于身份验证证书来控制对数据和API功能的访问。令人惊讶的是，这两种方式和HT TP都能工作很好。不考虑对公共数据的API访问是否需要任何身份验证，底层的社交数据在绝大多数情况下仍然是“公共的”。

私有数据带来了很多麻烦。由于越来越多的应用开始利用通常被认为“私有”的其他应用的数据，这需要控制终端用户的访问。数据提供商还使用各种技术，在访问权限控制中叠加上自己的观点意见。这些技术都使得私有数据的聚集访问方式变得异常复杂。

保证终端用户数据在存储角度是受到保护的，这仅仅是挑战的一部分。存储冗余和加密技术允许应用“蓬勃发展”，通常不需要考虑用户数据的丢失和折中方案。实际上，用户对应用程序很放心，为了允许更深层的API集成，他们免费提交用户名和密码到第三方应用程序。这种做法实际上非常不安全，但是它说明了用户为了获得他们期望的功能，甘愿牺牲其隐私信息。有两种有效可选的方案用于分享私人登录证书：OAuth和Blind URL。

OAuth(http：//oauth. net/）提供了简单的解决方案来允许各种服务之间进行交互，所有这些交互都给终端用户在他们的信息上提供了最终的权限控制权，而不需要和第三方透露他们的用户名和密码。交互程序把用户交给其期望的集成点，询问用户是否允许集成服务所请求的访问权限控制。如果终端用户赞成该交互，两个服务之间就共享一个令牌(Tken)，而且用户也可以选择撤销服务的访问权限许可。

Blind URL是在服务和用户之间共享信息的更简单的方式，但是它们在技术上还不够“安全”，因此它们通常都没有什么可信度。Flickr的“Guest Pass”共享功能能够巧妙地利用盲目的URL来允许用户和那些没有Flickr账号的用户分享“私有”的照片，因此，这些用户不属于Flickr用户的“朋友”或者“家族”。Blind URL为了使用服务来获取URL的使用许可，它不需要用户做出任何额外的工作，但是它们从技术上能够猜测出来，这会带来私有信息泄露的隐患。

Gnip当前只处理公共的数据。对于公共的和私有的边界访问控制必须提供给终端用户，而且当讨论中间基础设施时，它并非总是很清晰的。例如，你不知道也不关心公司采用什么样的通信路由服务信用卡来保证金融交易，而对于谁能够访问你的假期照片的访问权限的控制却是至关重要的。Gnip正在努力在公共数据和私有数据之间画线，以及它最终如何为私有数据提供如公有数据一样的服务支持。