思考 SoLiD 的优势:和 Github、Leancloud 怎么比?

其实 SoLiD 主要还是个 BaaS,关于 BaaS 的好处可以看 https://www.zhihu.com/question/27087120

现在有很多应用可以把数据存到 Github 上,它不仅有 REST API 还有 GraphQL API,更好用,比如 VSCode Setting Sync 等等应用都支持把你的个人数据存上去私有保存属于你自己,SoLiD 在这点上还比不过 Github,毕竟大家(指 SoLiD 的早期开发者)都有 Github 账号嘛,而且以后 Github 说不定也会支持 OIDC,相当于 WebID 了。

那么 SoLiD 最大的不同点应该在图搜索能力,对任何数据标注元信息(所谓资源描述框架嘛),然后多次探索( Faced Search )比如从一个带 ACL 的小圈子里搜索发现某一个隐晦资源的别称,然后再到另一个小圈子里用这个别称加上一些描述再次搜索从而得到隐晦的资源。

可能优势在于免费可内部部署,但又同时保留互操作性吧,可自己部署的 gitlab 就没什么互操作性,比如 vscode setting sync,虽然能保存到 GitHub 这个 baas,但是就没法保存到自己部署的 gitlab 上。
这是因为 Github gist 用的不是 W3C 标准的接口,让程序没法一次编写,到处存储。

现在的GitHub、Dropbox、leancloud还不方便联动,应用要每个都支持的话得各个适配,有了solid这个参考,估计以后BaaS都这么搞了,一次开发到处存储。

最大的优势其实就是关联数据啦,和 BaaS 等 Serverless 产品相比劣势还挺多的。
比如难用的技术栈,firebase 这些都是常用的后端技术(MySQL、MongoDB)等,SoLiD 的技术较为冷门。别说研究生要学「语义网」,现在研究生还是少数群体。

优势较少,还是想想怎么解决劣势问题比较好。比如怎么让 RDF 变得更为大众一些,包括图的搜索能力也比不上关系型数据库,要想办法看能不能融合 DGraph,感觉 Graphql-LD 是个非常好的方向呢。