Hello everyone, so let's just start a little bit early with Michele D'Nyong.
Yes.
Sorry, the local first and the ultimate bookkeeping system.
Welcome.
Thank you.
Is it running yet?
Yeah, a little talk about some thoughts I've had in the last few years working with data and
data portability and interoperability.
Links data and how you separate data from applications.
It all started with, it started here at first, I'm actually in 2011.
I was working on apps that running your browser and some people told me,
I should quit your day job and crowdfund that.
And I crowdfund it and I got an outnet support and then an outnet has been supporting me.
I've been working a lot on the unhocet project, apps that running your browser,
and you connect your personal data store at runtime.
We have a lot of fun.
We were very young as you can see in this photo.
We went to a village called Unhosh.
And near Prague, just because it was a village with a funny name.
And we offered a bottle of clook, mutted to the mayor.
That's a sort of thing that we were doing.
I think I received 12 an outnets grants.
So if you have an outnets source project, ask for an outnets grant.
It only costs you a few hours to apply.
And maybe you can quit your day job like I did.
So one of the things that I was looking at more recently,
for synchronization of data among systems,
so that we can liberate our data from the look-in,
is, for instance, how you could federate a GitHub issue tracker with a
JIRA issue tracker.
And both GitHub and JIRA have APIs.
So you can run a little process that bridges between those APIs.
And they send web hooks.
So you can say, oh, if there's a new thing in JIRA, send me a web hook.
And I'll do a post to the API of GitHub.
And the issue will get created there.
And the other way around as well.
So all the issues that are in JIRA are in GitHub.
And if there's a comment, you think that as well.
But there's a problem.
Because both these APIs use URLs as universal resource locators.
But they use their own URLs.
So this URL at the top is this is issue number 181.
I did a lot of testing on this wrapper.
And this is one that was synced from JIRA,
but then assigned this identifier.
You still have to map these identifiers between the system.
So even if you want to liberate the data,
you need to make sure that the local identifiers stay in sync.
Now, JIRA has custom fields in the API.
So I could just, when I send an issue from the GitHub tracker to the JIRA tracker,
I would just add a field saying, by the way, this is the GitHub URL.
GitHub doesn't offer that.
So what I did in the end, in this issue,
you can actually look it up in GitHub.
And I'm not sure if you can click Add it,
but when I click Add it on this comment,
I see this.
There's an HTML comment inside the description
from Bridgebot saying the identifier that it has in JIRA.
And that's how you can link these things together.
So that's one of the basic things about the federated bookkeeping
resource that we did.
How do you keep these identifiers in track?
Another way we could have done it is just keep a table in this box,
just remember which issue go with which.
But then if there are multiple bots at the same time,
they would not know about each other's actions.
So by having the annotation right there in the data,
you can keep track of those things.
And when you do these little tricks,
this is a very simple trick.
But it really changes everything with regards to where the data lives.
Because now this no longer is really a GitHub issue.
It's just an issue in general that GitHub has a view on.
And JIRA has another view on it.
So there are many systems of record for this data.
Well in this case, our two systems of record.
And that is a fundamentally different view on software engineering
than the web of data and the web of data.
It's only one system of record for each piece of data.
And I've been trying to build interoperable software with that.
And we always run into, yeah, but now you haven't synced it.
Also, so solid is a personal data store with linked data.
And local first is the concept of having a local copy of your data
that you edit locally.
And then asynchronously, you synchronize with the personal data store.
And those two that match with each other,
because in solid everything has a URL.
But you have a local data store that might be an issue light with a primary key,
which is also an identifier for the same data.
So you have two systems of record,
and they both have their own identifiers for the same piece of data.
So in each system of record, you have a copy of the data.
You have many universal resource locators,
and as you saw, yeah, a URL is a universal visual locator,
which you can always find it.
But it's not a universal identifier of the data,
because it's a dearer specific URL of the independent issue,
or a GitHub specific one.
So that took me years to realize that,
and you know, actually you realize it's feel simple,
but it is a fundamental different way to design software,
I think.
Another thing about, so another thing we worked on this year
is solid data modules, which are little pieces of code
that help app developers to work with data in different data formats,
because you know, maybe there was a bookmarking app already,
and you're also creating a book argument,
that works with solid, even though you both use RDF,
you might be using different ontologies.
So these code snippets is solid data modules,
know all the vocabulary that people have used,
that it knows for instance,
that your name on your WebID profile might be written down
with a friend of a friend for vocabulary,
or maybe with a V-card for vocabulary,
but it extracts that.
So these bits of code make these different apps
interpretable.
But you know, just like software developers like to
pick their own data schemas when they start to develop an app.
They also like to have their own code base,
because it's not just different programming languages,
but also different frameworks and different approaches.
So in theory, you know, you could make that worse.
Like, so I'll use the same code,
and then we'll have a happy software piece around the world.
But in practice, we live in a polygod world with
many code bases at many different formats.
And apart from many code bases, many data formats,
and many identifiers for the same piece of data,
the data that we work on in these apps,
especially when they are local first apps,
will be versions.
So there are many versions even of the same document
that you might get confused about.
So the realization is that just like in RDF,
you have different representations of the same triple,
right?
The data consists of triple in RDF framework.
You can write it down as JSONLD,
or as turtle, it doesn't matter.
You cannot say this triple is in turtle.
You can look at it in a turtle representation,
or in a JSONLD representation.
But none of them are really like the real representation of that data.
And I think we should do that not only for the representation,
but also for the locators and for the location,
and for like different code bases accessing the same data.
Just consider these all like different views on the same piece of data.
Just like, you know,
if you look at a truck from different sides, it looks different.
But we don't see three trucks here.
We just see three views of the same truck.
And if you think of data that exists in software in that way,
then you cannot really say like,
this data is in that system,
or this data is in that system and now I synchronize it.
If the sync is fast enough,
you have two ways sync with on the fly translations of data formats,
then it's really, it becomes one system.
So that's why I think the,
how we always decide software,
like you say you have a database,
and then you have application on top of it,
and then you have representation.
That's a limited way to design software.
It works well if you have VC funding and they say,
well, you need to build a system where you're going to lock people in.
But if you want to build open software,
where your aim is to allow people to liberate their data,
then you should become part of one big bootkeeping system.
In the same way as the web is woven of different web servers,
that all make part of the same web.
You don't pay a lot of attention when a hyperling goes to the same site,
or a different site.
Now, I showed how to do the local identifiers.
That's what we did some research on.
What we still haven't done a lot with
is how to translate on the fly between these data formats.
So we wrote these solid data modules
that read code in different vocabularies and translated.
That's, and we also have documentation about which data formats are used.
But something that is in between documentation and code
is declarative codes, such as shapes
in the solid project we use data shape that the fine,
just like a JSON schema, the fine, what kind of fields could be there and what they mean.
There's a project from InconSwitch called the Cambria project,
which is very promising.
It worked for the small example that they gave,
where they have lenses on the data.
They do it two way translation,
and they actually integrate with TypeScript generation.
And the only thing is that they've worked on it for a few months
and then they went on to work for also.
So I think we should evolve the Cambria project more,
especially not just in the local first community,
but also towards interoperability and freedom of data.
And I want to plug two more projects,
a friend of mine, one is Arrogel from Noelle,
which is a way to view,
and have a view on the data,
and we were just talking here in the whole ways
about doing schema migrations in Arrogel.
So I think that's super promising.
Another one is next graph.
I don't know if you saw the presentation yesterday,
and what next graph does, it's Combines,
local first, with RDF.
So it says, yeah, everything is triples,
but the identifiers used in these triples are not URLs,
but they are universal locators.
So evolving this software with the ground architecture
of saying there's only one bookkeeping system,
every system of record is just a part of a bigger system,
is what I call the ultimate bookkeeping system.
And that's a bit tongue-in-cheek.
Now we don't need any other bookkeeping system here.
Here a bookkeeping is used in sort of a generic way.
It could be, like, the data that accounts work with,
but it could also be bookkeeping your calendars,
calendars that are simply, each other,
just part of the ultimate bookkeeping system.
And yeah, that's what I want to be working on.
So far, I only had the logo.
It's luckily at the existing unicode,
so you can type it lots of times.
Thank you.
If you would do questions or, yeah,
if there are any questions, we have a few minutes left.
Thank you for the presentation.
I love all the ideas.
It seems like you have a lot of ideas for a lot of high-level concepts.
Are there any, like, simple demo type apps that you've worked on?
There's not so many really usable apps that I've worked on.
There are small things, but they're really just demos.
So yeah, there's, for instance, light-dried is a text editing app.
Light-dried.net, and it allows you to use your own personal data store.
I didn't write that, but some people in the unhased the project did.
And so that is an actual, but actual, at least five or six people use it for their real notes.
And in the solid projects, there are a few demo apps.
And I don't know they're used that much, but they do work.
I think Media Cracken is one where you can say through movies, through your poll.
But we haven't shown a second movies app that is compatible with it.
We do have, there is a bookmarking app called Mark Book,
and then there's another book app called Potted, and those two are compatible with each other.
So I wrote a little demo last week of how those,
how you can switch between those applications through co-existence.
They call it, and that's an all-term in data engineering.
So co-existence is where you have two systems.
When, for instance, one company buys another company.
This company, they buy has a calendar system.
But they want to migrate into the new calendar system.
And first, they let the two systems co-exist together with two waysync.
And then at some point, when everybody switched over, they switched off the old one.
That's a really nice way to do a data migration.
And I was talking about that with migration experts.
They said, well, yeah, that's really two idealistic in general, the real way to do it is you just,
migrate to data's, okay, now you're on the new system.
Also psychologically, because, you know, it's hard for people to then actually switch if there's no deadline.
So these are the access. And of course, local first is, you know, local first movement.
There are a lot of apps that actually get used.
They use the local first replication.
But not so much yet, data portability between those apps.
So that's what we were still working on.
Thank you.