• linonetwo

    https://www.rubensworks.net/blog/2019/03/13/streaming-rdf-parsers/

    我觉得对于理解 JSON-LD 的各种符号还有 turtle 中的空节点很有帮助。

    posted in 综合讨论 read more
  • linonetwo

    https://mementodatabase.com/
    Flexible and easy to use database manager ,存储和格式化你生活中的任何数据

    posted in Solid 应用 read more
  • linonetwo

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

    posted in 综合讨论 read more
  • linonetwo

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

    posted in 综合讨论 read more
  • linonetwo

    其实 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 的小圈子里搜索发现某一个隐晦资源的别称,然后再到另一个小圈子里用这个别称加上一些描述再次搜索从而得到隐晦的资源。

    posted in 综合讨论 read more
  • linonetwo

    软件定义存储怎么盈利?SoLiD 可以从中受益吗?

    posted in 综合讨论 read more
  • linonetwo

    https://nmalcev.github.io/pod-explorer

    注意登录的时候用户名密码别填错了,有多个 WebID 的人要注意密码管理器有没有自动填写别的账号的密码。

    还有打开之后是 https://nmalcev.github.io/pod-explorer/#url=https://linonetwo.solid.authing.cn/ 的样子,注意后面接的地址是不是你的 WebID 对应的地址,不然会说没有权限。

    posted in Solid 应用 read more
  • linonetwo

    https://solid.github.io/ldflex-playground/#['https%3A%2F%2Fruben.verborgh.org%2Fprofile%2F%23me'].friends.lastName

    可以试着把 lastName 改成 firstName

    LDFlex 通过 ES6 Proxy 把链式调用转换为 SPARQL。
    最底下有编译出来的 SPARQL,可以看看自己哪里写错了 debug。

    posted in 综合讨论 read more
  • linonetwo

    自从 React Hooks 发布以后,把逻辑从组件里抽出来就变得容易了。

    这也是为什么现在写自己的 SoLiD 逻辑变得很简单了,用 React Hooks!然后写 LDFlex,完全不需要 SPARQL 知识,几乎不需要 JSON-LD 知识~

    Ruben Verborgh 在 https://github.com/solid/react-components 里发布了大量的 Hooks,比如我下面介绍的用 Socket 监听服务器上文件更新的 Hooks:


    注意,以下内容包含大量到源码的链接,请配合源码食用。


    useLatestUpdate 里面使用了 UpdateTracker 这个类,传给 useLatestUpdate 的 URL 都会和一个 React.Dispatch(就是从 useState 里拿到的第二个变量 setLatestUpdate)一起传给 UpdateTracker。

    它们被放进一个 Set() 里,类似:

    {
     xxxURL: setLatestUpdate
    }
    

    然后 UpdateTracker 建立起一个到该 URL 的 host 部分(也就是 SoLiD 服务器的地址)的 WebSocket,一旦 onmessage (传来的 data 只是更新的文件的 URL,没有实际的文件内容)就看看拿到的这个 URL 在 Set() 里有没有对应的 React.Dispatch,如果有,就把一个 { timestamp: new Date(), url } 这样的对象丢进 React.Dispatch 里。

    这样 useLatestUpdate 里的 latestUpdate 就会在我们订阅的 URL 对应的文件发生更新的时候也一起更新了。接着 useLatestUpdate 把 latestUpdate 返回。

    <LiveUpdate /> 使用了 useLatestUpdate, 并把返回的值放进一个 React.Context 里面。

    之后我们可能会把 <List /> 作为 <LiveUpdate /> 的子组件,List 辗转调用了 useLDflex,在 useLDflex 里面用 useLiveUpdate 来读取之前 <LiveUpdate /> 里面的那个 Context 里的值,并在每次值有更新的时候用 useEffect 来重新从服务器上取得文档的具体内容。


    总结一下,我们是这样拿到推送的:

    <LiveUpdate /> --[use]--> useLatestUpdate --[useEffect]--> UpdateTracker

    React.Context

    useLiveUpdate
    Where
    <List /> --[use]--> useLDflexList --[use]--> useLDflex --[useEffect]--> useLiveUpdate

    posted in 综合讨论 read more
  • linonetwo

    我感觉可以把它用在认证工厂的身份和偿付能力上,基于 SoLiD 的 B2B 社区会需要这样一个信任验证,类似于1688的诚信通。
    不过诚信通好像并没有取得很大的作用,原因我还没搞清楚。

    posted in 综合讨论 read more
  • linonetwo

    最近我也在思考如何让企业、制造商建立围绕自己的商业服务。
    现有的商业对接平台商业模式在于营造信息壁垒收取会员费(1688)、营造数据壁垒的同时直接对接产方和需方成为每家工厂最大的经销商(找钢网等等)。

    但这些在线平台(称为 B2B1.0 和 2.0)虽然都吸引了很多供给方入住,都暂时只能服务好小的需方,大的需方采购流程中人的因素还很重,在线平台无法打败供方传统销售流程中要面对的那些「关键人物」,好处费等等没到位还是拿不下大的需求方。

    所以 B2B 3.0 最大的难点是把交易市场接入MES(制造执行系统)和 OA,让需方企业内部在采购问题上不再有导致腐败的信息壁垒。
    SoLiD 提供的良好互操作性让这个接入的动作能低成本地发生,不过目前的挑战在于如何劝说和实际地帮助企业更新原有的信息系统,转换为 SoLiD 等高互操作性的技术栈,并与一个基于 SoLiD 技术栈和支付宝等支付伙伴的 B2B 交易社区对接起来。

    posted in 综合讨论 read more
  • linonetwo

    @qing 保持健康,再等30年!

    posted in 综合讨论 read more
  • linonetwo

    有人用 git 做了一个 POC,SoLiD 可以参考一下
    https://github.com/opersys/gitgeist-poc

    posted in Solid 应用 read more
  • linonetwo

    https://forum.solidproject.org/t/on-datashapes-as-a-complement-to-vocab/1298

    可以用 http://www.w3.org/ns/shacl 来约束数据格式,然后想办法让做相似业务的 app 都用这套 schema,用户如果要用文件编辑器手动修改数据,也应该遵从这个 schema。

    posted in 综合讨论 read more
  • linonetwo

    @next-era聊一个协同共建的去中心化的平台愿景 中说:

    我理解这个世界的基本构成:交易(价值置换)、元素连接、贴近现实生活的连接逻辑。我想了很多,最终发现线上的本质就是富文本+连接。你可以做一个非常轻巧的MVP,立足于真实的、现实的生活中,以这种非常简单的可拓的产品逻辑迅速的铺满市场,从最基本的作用开始发挥

    你可以解释一下互联的富文本为什么这么有威力吗?

    可拓学我没细究过,我以前拿到过一本带可拓学文章的杂志,看里面写着物元事元关系元,我觉得和语义网络没啥区别就没太在意,觉得是民科在重新造轮子。

    posted in 综合讨论 read more
  • linonetwo

    我想起来我家里还有一块 ruff 板,过年了我回家拿出来装个 SoLiD 试试,那时候估计 solid 6.0 都出了……

    posted in 综合讨论 read more
  • linonetwo

    https://forum.solidproject.org/t/business-opportunities-using-solid-pod-servers-without-using-advertising/1301

    国内有一家做 nodejs 开发板的,蛮适合跑 SoLiD,他们售价 300 一个,要是买来加上域名再出售作个人网盘不知道有没有人买账。
    主要是文件管理应用开发得花钱,目前也没有做够作为 NAS 管理应用的 SoLiD 应用出现。

    posted in 综合讨论 read more
  • linonetwo

    我感觉 Anki 也是。SoLiD 其实很适合做这类知识管理应用。

    我分析了一下 Anki 的原理,它是先创建知识库(有多个字段),然后 Anki 会把知识库用模板渲染出来变成卡片。

    比如一个待记忆的知识点:

    问题:死海的特点是什么?
    答案:位于以色列和约旦交界。它的海岸线是世界最低点,平均海拔-396米。它的长度为74公里,相当于大海盐度的7倍。它的密度能将人浮在水面。只有简单有机体能在水中存活。

    一般是手动拆解成成这样的知识库,含有 7 个 item 的数据库(每个 item 只有问题和答案两个字段):

    问题:死海位于哪?
    答案: 位于以色列和约旦交界。

    问题:地球表面最低点是哪?
    答案: 死海海岸线。

    问题:死海平均海拔是多少?
    答案:-400m

    问题:死海有多长?
    答案:70km

    问题:死海中盐的含量是多少?
    答案:30%

    问题:为什么人能浮在死海海面?
    答案:因为高度含盐量

    问题:为什么叫做死海?
    答案:因为只是简单有机体能生存

    然后 Anki 把数据库中的 7 个 item 自动变成 7 张卡片,卡片模板是:

    正面:{{问题}}
    反面:{{答案}}
    

    从而渲染出我们在复习时看到的卡片。

    在 SoLiD 里面可以通过划词的方式标注出三元组

    死海 位于 以色列和约旦交界它的海岸线 世界最低点平均海拔 -396米。......

    标粗的是主语或宾语,可以用 wikidata 本体表示。
    斜体的是谓语,可以用W3C 标准本体来表示。

    这样就构建出一个知识点的知识图谱,是一个三元组构成的图状数据库。
    然后我们的 SoLiD Anki 在生成卡片的时候就可以用这样的几种模板:

    正面:{{主语}} - {{谓语}} - ?
    反面:{{宾语}} - {{主语的知识图谱可视化}} - {{主语的其他谓语宾语组合}}
    
    正面:{{主语}}  - ? - {{宾语}}
    反面:{{谓语}} - {{主语的知识图谱可视化}}
    

    自动生成图文并茂的识记卡片,并用 SM2 算法帮你定期复习。

    posted in Solid 应用 read more
  • linonetwo

    不过 SoLiD 上面的可信声明主要是用于在 Web3.0 中溯源某个声明,它与分布式账本技术的不同之处在于,分布式账本技术用很高的成本来保证所有数据都不可删除,但 SoLiD 让用户有删除自己不想要的数据的自由。
    所以 SoLiDVC 适合证明对用户有利的数据的存在性,而分布式账本依然可以用来存储对用户不利的数据(例如车辆维修记录)的存在性,两者并不是竞争关系,可以并存。


    我下面简要翻译一下 https://forum.solidproject.org/t/solidvc-a-decentralized-framework-for-verifiable-credentials-on-the-web/1260/3 中的讨论:

    (linonetwo 分享了本体项目区块链的文档 https://github.com/ontio/ontology-DID/blob/master/README_cn.md

    你分享的工作确实和 SoLiDVC 相关,因为它也在尝试实现可验证的凭证规范。正如您所提到的,主要区别在于它利用了分布式账本技术(DLT)的一致性和持久性保证。实际上,有一段时间,我也在考虑引入账本结构,该结构涉及通过在一个 POD 中存储凭证或打包的凭证块来模仿区块链这样的账本,并且每个凭证会引用它的前置凭证块。这样做的好处是可以在系统中强制保证凭证有一个全局排序,主要用于存储时间戳和有序事件(也就是说,要知道最后一次撤销凭证的事件是在最近发生的一次续订凭证事件的之前还是之后)。在花了一些时间挖掘这个无底洞之后,我意识到这不是一个非常有建设性的方法来在 SoLiD 的背景下实现凭证这个概念。首先,POD 所有者可以随时删除凭证,这会立即导致验证链条的中断。二,我可以使用 W3C 标准本体定义的术语,例如xsd:dateTime 来表示时间段和到期时间。

    SolidVC 有很好的去中心化特性,因为每个用户都可以对他自己的凭据进行很大程度的控制。但是,如果每个用户都可以对他自己的凭据进行很大程度的控制,这也会导致一个很大的限制!你可能已经想到了,当接收者(subject)不再依赖签发者(issuer)存储他们的证书时,有一些商业模式就不好做了,因为这些商业模式中,过去事件的不可篡改的详细历史是至关重要的。例如,房地产经纪人有兴趣知道潜在租户的信用记录。接收者(subject)从一个签发者(issuer)偷偷切换到另一个签发者(issuer)以获得新的信用评分的自由,可能使得 SoLiDVC 难以真正评估个人真正的偿付能力(除非签发者(issuer)在凭证中明确表明他们与该接收者(subject)来往了多久时间了,从而「为他们背书」,有了这个说法,才可能有空间为某些类型的凭证引入某种持久化机制。)。

    关于持久化的另一点,我现在可以说的是,其实还有更好的方案可以使凭证文件持久化。就是做一个关于凭据的凭据(元凭据),也就是说我维护一个权威的撤销列表。每个凭证都附带上这种文档,该文档描述了一些信息,例如此凭证是否处于激活状态,是否已过期或已撤销等等,以及与这些状态相关的相关元数据。目前,此文档可以存在于签发者(issuer)的 POD 中,这意味着如果签发者(issuer)选择以任何方式篡改此文档,则验证方(verifier)可能无法访问曾经对凭证做出的一些历史声明。为了对付这一种情况,我们可以利用 Web Ledger 互联网账本协议加上其他 W3C Web 规范来维护这些特殊文档。

    最后,为了回答你关于我是否认为这个工具可以完全取代区块链技术的问题,我不得不说。我可以看到这个框架在 Web 3.0 中发挥了重要作用,目的是可靠地对某个声明溯源(获得声明的源谱 provenance),通过使用可信声明 Verifiable Credentials,但我认为如上所述,这些技术的细微差别使 SoLiDVC 和区块链技术更像兄弟技术而不是竞争对手:它们是相关的,共存的,但互相不会是威胁性的。

    posted in 综合讨论 read more