Re: Interoperability/Integration through schema migration

On Thu, 20 Aug 2020 at 16:05, Brent Shambaugh <brent.shambaugh@gmail.com>
wrote:

> This is the question I am musing:
>
> Is interoperability/integration between various ledgers a schema migration
> problem? (at least in part?)
>
> -Brent
>
> also
>

In the first step of interoperability/ingetration between different ledgers
is done by giving each entity a URI

You then can join on that URI and pull in the data that is associated with
each entity, merge that data, store it, display it, remix it, augment it

You can take this one step further by giving the key/value pairs
(particularly the key) URIs too in order to merge unambiguously.  With big
data this is helpful, but for some ledgers that might be overkill.  For
example block height can fairly easily be understood across entities
without creating a schema.  Otherwise you can just match on a string for
the key normally unambiguously or you can turn things into a urn: to be
linked data friendly

Schemas give that extra benefit of being able to merge more easily, but it
comes with an overhead ie that the vast majority doesnt come with a schema
and one must be created and maintained.  Tho some may be ready made.

Schemas can also have other benefits such as self documenting data,
describing a "shape", or adding some rules and sub classes

It's a trade off based on your use case, and how big your eco system is.

Step 1, give the entities a URI/UUID so they can be joined.  Step 2, give
the keys tied those entities a URI/UUID so they can be joined.


>
> Bjorn Hamel mentions shapes;
> https://www.youtube.com/watch?v=Uu651GJ5YY0
> (Adventures in Self-Sovereign Identity: From...- June 28 | Identiverse
> 2019)
>
> maybe he means in this light?: https://www.w3.org/TR/shacl/
>