Open pbonte opened 2 years ago
Tagging @jeswr so he's aware of this as well.
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.
@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?
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
@pbonte @fongenae @jeswr Did you have the chance to look into making the necessary changes?
@pheyvaer updated the text and made it more concrete. Let me know if any changes are still required.
Looks good to me, but what is the difference with #1?
This one is specifically for the reasoning part on schema level, while the other one is more on document layout
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?
@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.
@RubenVerborgh Can this challenge be approved or those something still need to change?
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:
Acceptance criteria
A demo that fulfils these need would need to be able to show:
Pointers
Two Solid chat applications are already available that each use their own schema: