Alignment for Solid Chat apps using different schemas

[pbonte]

Pitch

As we cannot enforce one specific schema in a decentralised environment, Solid apps will often encounter pods with data stored according to different schemas. These schemas need to be aligned automatically, such that app developers do not need to worry about these details.

In decentralised chat application, pods could store their chat history using Activity streams, SIOC or custom tailored ontologies.

App developers should not need to worry which schema has been used on a specific pod, thus this complexity should be abstracted.

Desired solution

There should be an alignment module that hides the heterogeneity of data serialisation towards app developers. We assume that the alignment itself is available, perhaps in a certain catalog. Schema alignment is typically evaluated using reasoning, however, evaluation of many alignment rules can result in a drastic increase in dataset size.

The solution for the alignment module for the decentralized chat app would need to be capable of:

• be completely hidden for the app developers
• investigate which schemas need to be aligned
• fetch the alignment rules
• decide if its better to either rewrite the current query or materialize the the data in the pod according to the original schema
• provide answers as if the same schemas were used
• when writing data, the schema that was originally used on the pod needs to be utilized

Acceptance criteria

A demo that fulfils these need would need to be able to show:

• Two chat apps that store data using different schemas
• The users can change chat apps without any modification to the code/data, noting that the pods have data stored in different formats
• Show that data is written to each of the pods in their original schema and results are shown in the schema used by the app

Pointers

Two Solid chat applications are already available that each use their own schema:

• https://github.com/SolidLabResearch/SolidChatApp

[pbonte]

Tagging @jeswr so he's aware of this as well.

[jeswr]

Also to give a timeline on my Honours work - my thesis is due at the end of May so I'll need to have a reasonable amount of the work I mentioned I'd be doing done by then.

[RubenVerborgh]

@pbonte Thanks! Can we apply this (currently generic) challenge to a specific use case, such that the demo becomes a very specific and concrete target to reach? For instance, by picking the first example as the case? That would align with #1.

We could either adjust the current challenge text, or create a new issue that is basically an applied version of this bigger challenge, and link back to here?

[doerthe]

Some input here: https://paul.ti.rw.fau.de/~ec69etyl/2022/dkg-22/DKG-22_paper_7.pdf https://docs.google.com/presentation/d/1Ve5VCx7pG3kTOo8d2GNEJ9N0c8lCI7SCvE_dbsx8NlE/edit?usp=sharing

Note that we implemented a small example: http://ppr.cs.dal.ca:3002/n3/editor/s/CjUiEimP

[pheyvaer]

@pbonte @fongenae @jeswr Did you have the chance to look into making the necessary changes?

[pbonte]

@pheyvaer updated the text and made it more concrete. Let me know if any changes are still required.

[pheyvaer]

Looks good to me, but what is the difference with #1?

[pbonte]

This one is specifically for the reasoning part on schema level, while the other one is more on document layout

[pheyvaer]

I see. #1 says in the acceptance criteria that "The logic for reading chats should be in a separate library/component that can be used by others". Is that then this challenge? Or in other words, this challenge is a subchallenge of #1?

[pbonte]

@pheyvaer, not really. In #1 it refers to the logic for handling different document layouts, while here we specifically focus on aligning the schemas through reasoning. The term logic in #1 is (I think) not really related to reasoning but more like the application logic should be modular such that it can be reused.

[pheyvaer]

@RubenVerborgh Can this challenge be approved or those something still need to change?