SOLID's linked data and Blockstack


#1

As SOLID is now pushed by a startup, I think it is good to review it again.

In particular, the linked data part is something that blockstack needs to adapt or communicate:
https://solid.inrupt.com/docs/intro-to-linked-data

It is the way developers need to think about how to bring data from different users together.

Are there any blockstack apps using linked data already?


#2

I think for any app developer, something like this is inevitable to create for someting akin to a social media where user interaction is used.

That being said, I don’t see how this needs to become a core part of Blockstack(.js). This is something implemented by the developer, not by the library, and thus should probably be regulated to a tutorial or FAQ.


As for implementing shared app data (as advertised in SOLID), this has been discussed before but without work being done so far on these “cross-app data buckets,” though I know Stealthy has been working on having cross-app reads/writes via multi-app authentication.


On a side note, it could be possible to use a SOLID Pod as a Gaia Storage backend (i.e. use blockstack sign-in for one pod folder, for all blockstack apps).


#3

The typed links is interesting as is the structural relationship to indicate how the comment targets the image.

As @MichaelFedora points out, we’ve done some early work with Graphite and Travelstack to begin the process of sharing data between Apps. Namely a way of describing resources and how to access them. Eventually we hope to extend that for an experience that is like Jabber but with Apps (for example an improbable centralized example might be accessing your Instagram photos directly in a Google Doc ).

edit:

We’ve also created some structures and ideas to help users manage the crossing of App cryptographic boundaries for improved inter-operability.


#4

I am heavily researching this. I am curious how I can integrate the rdflib.js with blockstack.js and gaia storage. https://github.com/solid/solid-tutorial-rdflib.js


#5

Actually json-ld looks more interesting and they have a javascript lib https://json-ld.org/

This looks pretty cool here: https://github.com/digitalbazaar/jsonld.js

The syntax does not require many applications to change their JSON, but easily add meaning by adding context in a way that is either in-band or out-of-band. The syntax is designed to not disturb already deployed systems running on JSON, but provide a smooth migration path from JSON to JSON with added semantics. Finally, the format is intended to be fast to parse, fast to generate, stream-based and document-based processing compatible, and require a very small memory footprint in order to operate.

Maybe something like this =, the url could be your Gaia bucket url ( not valid code below just an idea )

var doc = {
  "http://schema.org/name": "nicktee.id", // maybe blockstack has a schema
  "http://schema.org/someSchema": "SomeBlockstackAppDataScheme" // maybe each app can make a data schema or borrow one from https://schema.org/docs/full.html
};


#6

I just discovered this tool https://search.google.com/structured-data/testing-tool"

<script type="application/ld+json">
 {
 	"@context": "https://schema.org",
 	"@type" : "DigitalDocument",
 	"url": "https://gaia.blockstack.org/hub/1FqX63G6pZ54wD97FbW1XvtXEmwgYLEsha/aba3baaa-008d-8cdc-08c9-b20621176add.pdf",
 	"name": "MyFile.pdf"
}
</script>


#7

This site helps you visualize how your piece of data and its schema relates to the linked data graph.

https://json-ld.org/playground/

I think i am going to change my schema in Blockusign to support this open standard, so I don’t have to create my own proprietary standard. It will make integrating with other apps easier and would allow an app that has public data to be a part of the global linked data graph Tim Berner’s Lee has envisioned. Not to mention you get the benefit of SEO out of the box!

Blockusign Schema

Let’s say my data schema looks like this represented in json-ld: (noticed i used the gaia url as the id since i believe the id makes this the subject in RDF)

 {
 	"@context": "https://schema.org",
 	"@type" : "DigitalDocument",
    "@id" : "https://gaia.blockstack.org/hub/1FqX63G6pZ54wD97FbW1XvtXEmwgYLEsha/aba3baaa-008d-8cdc-08c9-b20621176add.pdf",
 	"url": "https://gaia.blockstack.org/hub/1FqX63G6pZ54wD97FbW1XvtXEmwgYLEsha/aba3baaa-008d-8cdc-08c9-b20621176add.pdf",
 	"name": "MyFile.pdf"
}

Triples (subject -> predicate -> object)

Then you can see how the triples print out: subject -> predicate -> object

So for my use case in Blockusign the first triple would read like this:

The document with the id aba3baaa-008d-8cdc-08c9-b20621176add.pdf (subject) -> hasName -> MyFile.pdf

and the N-Quads printout looks like:

<https://gaia.blockstack.org/hub/1FqX63G6pZ54wD97FbW1XvtXEmwgYLEsha/aba3baaa-008d-8cdc-08c9-b20621176add.pdf> <http://schema.org/name> "MyFile.pdf" .
<https://gaia.blockstack.org/hub/1FqX63G6pZ54wD97FbW1XvtXEmwgYLEsha/aba3baaa-008d-8cdc-08c9-b20621176add.pdf> <http://schema.org/url> <https://gaia.blockstack.org/hub/1FqX63G6pZ54wD97FbW1XvtXEmwgYLEsha/aba3baaa-008d-8cdc-08c9-b20621176add.pdf> .
<https://gaia.blockstack.org/hub/1FqX63G6pZ54wD97FbW1XvtXEmwgYLEsha/aba3baaa-008d-8cdc-08c9-b20621176add.pdf> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/DigitalDocument> .

Viz

Here is the viz from the playground:

Digital Signatures

They even have example on how to sign that data with bitcoin (ECDSA Koblitz, i think Blockstack uses a diff one). I think I am going to adopt this standard when i save a document hash to bitcoin via Blockstack subdomains.


#8

I am absolutely in favour of getting the Blockstack community on board with JSON-LD, as it makes so much sense in terms of re-using data in various apps.

I agree the library of Digital Bazar - being an authority on all thins JSON-ID and particularly the identity specs, https://github.com/digitalbazaar/jsonld.js - is really helpful.


#9

Gaia does not have any opinions about how data is formatted, and likely never will. However, applications and libraries can and should agree on a set of common data formats like JSON-LD if they want to share data. I personally leave it up to them to decide what those will be.