Why OpenSaber only for slow moving data

[rushang7]

I am exploring OpenSaber and evaluating if we could leverage it for a new project at my organization.

I have come to know that OpenSaber should be used for storing:

1. Master Data
2. Registries - Slow-moving data

I am wondering, why shouldn't we use it for data like event logs? There won't be any updates on the event logs, but we will frequently generate new events. The encryption and digital signing features provided by OpenSaber would surely be useful for our use case.

Could you please explain why we are restricting its use for only slow-moving data?

It would be helpful if you could share the internal architecture of OpenSaber.
@pramodkvarma @dileepbapat @vrayulu

[pramodkvarma]

Immutable audit event logs are typically a time series data with no realtime search need and have other needs like "time to live" (managing retention policies) etc. So, while technically OpenSABER may work quite well, you may end up suppressing some features and also enhancing to add newer capabilities. Also many capabilities such as attribute visibility, consented access, attestations, etc are not really useful for a typical time series style read-only audit trail data. Btw, DIVOC has used OpenSABER for mostly read only credential store which is not a master data use case (neither a pure time series audit event data, somewhere in between).

An OpenSABER like declarative audit event log system would be nice to have!! Many projects we have ended up building such things again and again. So, I suggest you map OpenSABER in next level of details to an immutable audit trail system and see what comes up. We can discuss the idea with that level of mapping (may be at a presentation deck style) and then see what we can do.

@dileepbapat @vrayulu what do you think?

[dileepbapat]

I guess when you say event logs I assume:

1. Order of events/time window-based access is needed.
2. Older events might become not that important and might need to be archived or compacted.
3. Sharding strategy might be time based.

These are key areas where opensaber might not support out of the box time-series capabilities. However if the intent is to safe store immutable events open-saber fits the criteria.

[vrayulu]

+1 to what @pramodkvarma and @dileepbapat said. OpenSABER can be used to store immutable audit events. But the main question is what kind of queries we want to do on that data? based on how we intend to query and use that data, we can evaluate if OpenSABER is the best fit and what enhancements will be needed.

[rahul101001000]

Two use cases that come to mind -

1. Activity record of students (xAPI like - 'saw this video on Friday afternoon, took this test on Saturday morning, got an A grade'). This data may need to be shared with another provider that can suggest next learning steps for that student based on their activity history.
2. Report cards for students ('Student #456754, 2021, Semester 1, Grade 5, English 72, Maths 65, Hindi 88')

Would OpenSABER be well suited for either/both of these? Thanks! @vrayulu @dileepbapat @pramodkvarma

[pramodkvarma]

Use case 1 above is NOT a registry use case, rather a use case for personal transaction/interaction data access (what DEPA does in India Stack). We may have to implement some modules for it to happen, but it will be outside Sunbird RC.

Use case 2 above is for sure fits in well for Sunbird RC. In fact DIVOC does this for vaccination using Sunbird RC. We will use W3C VC along with domain specific schema to solve the specific use case you are mentioning.

[rahul101001000]

Very helpful, thanks for the clarity @pramodkvarma!