Re: Interoperability/Integration through schema migration

Thanks Melvin,

I'll have to try rolling it in with "Intro to Functorial Data Migration"
https://www.youtube.com/watch?v=GizBg4M3bII . It is interesting thinking
with databases and schema migration with category theory that I have never
seen in the database space before. There is also some joint work with Josh
Shivaner on property graphs. Interesting stuff.
I'm trying to get enough math under my belt to understand all of this.

-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me


On Thu, Aug 20, 2020 at 9:37 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> 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/
>>
>