Re: Interoperability/Integration through schema migration

Is anybody aware of work being done on this somewhere?

We regularly come across potential use cases for URIs/resolution, like for instance being able to point to other ledgers, transactions and/or data.
What I like about DIDs is that it completely hides the underlying infra/ledger and just relies on the URI, contract for resolution and schema.

I think it would be very beneficial if there would be something similar for resolution of data across ledgers.

Something simple we have used in the past internally to create a graph on top of a ledger:

    CONTEXT(BlockhainType.CONTEXT, "/%s"),
    CHAIN_ID(BlockhainType.CHAIN, "/%s/chains/%s", CONTEXT),
    ENTRY_ID(BlockhainType.ENTRY, "/%s/chains/%s/entries/%s", CHAIN_ID),
    EXTERNAL_ID(BlockhainType.EXTERNAL_ID, "/%s/chains/%s/entries/%s/externalids/%s", ENTRY_ID),
    CONTENT(BlockhainType.CONTENT, "/%s/chains/%s/entries/%s/content", ENTRY_ID);

Obviously very specific to the use case, but if we could have URIs that can be resolved to all kinds of blockchains using a common resolver similar to the Universal Resolver for DIDs.

The problem with schemas might be that it is hard to capture the ledger specific details. Although an approach like https://rosetta-api.org has taken by allowing metadata can help there.



Kind regards,


Niels Klomp



________________________________
Van: Melvin Carvalho <melvincarvalho@gmail.com>
Verzonden: donderdag 20 augustus 2020 16:36
Aan: Brent Shambaugh <brent.shambaugh@gmail.com>
CC: Credentials Community Group <public-credentials@w3.org>
Onderwerp: Re: Interoperability/Integration through schema migration



On Thu, 20 Aug 2020 at 16:05, Brent Shambaugh <brent.shambaugh@gmail.com<mailto: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/