Spike - Define Student Information System API

stichtingsem / pilot-phase

All work documentation for the pilot phase of the SEM ecosystem project

3 stars 3 forks source link

Spike - Define Student Information System API #4

Open eliashassing154 opened 3 years ago

eliashassing154 commented 3 years ago

Is group structure available for all roles? Yes, since all roles have valid reasons to use group information. Do we need to confirm this in Technical Advisory Board? @cliftonc @MarcelUntied

In various issues questions on doubling of data elements arise (e.g. product name in multiple API's). We need guidance from the Technical Advisory Board on doing so.

MarcelUntied commented 3 years ago

https://stichtingsem.stoplight.io/docs/sem-technology-prototype/reference/sisdata.v1.yaml

MarcelUntied commented 3 years ago

Plotten op proces

Technische analyse op dubbele elementen Technische objecten zijn groot

School moet eigenaar zijn en controle/inzicht hebben over eigen data. Vragende partij heeft verantwoordelijkheid om aan te geven welke data nodig is en waarom

edwinverwoerd commented 3 years ago

We use the Edukoppeling standard for the exchange of personal data.

eliashassing154 commented 3 years ago

"School moet eigenaar zijn en controle/inzicht hebben over eigen data. Vragende partij heeft verantwoordelijkheid om aan te geven welke data nodig is en waarom"

The school is owner regardless of the system used, and is also the requester (e.g. when connecting MP to SIS, the school administers both systems). So who is explaining what to whom here @MarcelUntied?

MarcelUntied commented 3 years ago

@eliashassing154 I think we should add this main principle to the decisions and remove it from here

MarcelUntied commented 3 years ago

@eliashassing154 Let's discuss and decide on "Is group structure available for all roles?" in the preparation group. I don't think the technical advisory board has to be involved.

eliashassing154 commented 3 years ago

I think as long as any role can clarify the request for usage, it is in line with the founding principles to share information as long as there is a valid reason. The question is how to determine validity.

Jorimvdw commented 3 years ago

Few questions from our side regarding the SIS API:

Which id do we use for students? Is that our UUID?
In the API-specs I only see getById methods, how does one know the id's in the first place? Don't we need a getAllStudents, getAllTeachers and a GetAllGroups?
For the enrollments, I can't find the enrollment-id's in the response from getStudentByID, I think it should be there or otherwise you will never know the enrollments-id's to ask for in the getEnrollmentByID.
Regarding get Student Delivery Information by ID, Isn't adress a bit more complex than how it is written down right know? How about foreign adresses for example?
Should we add BRIN to the school object?
I also noted some infinite loops in response objects. The response on get Student information by ID contains groups, which contain students, which contain groups, etc. Can someone check where this should be replaced with object references and update the stoplight.io?

mcginkel commented 3 years ago

@Jorimvdw Great Questions. I face the same issues.

The definitions of the objects are not proper yet. they are recursive indeed.
The bootstrap process is not defined anywhere.

Edwin verwoerd will setup a meeting on this.

Jorimvdw commented 3 years ago

Hello. still waiting for an invitation to a meeting about my questions. 1 more that popped my mind: which enrollments should we deliver? For now I'm assuming current and future enrollments, not past.

MarcelUntied commented 3 years ago

@Jorimvdw @edwinverwoerd Edwin will arrange the meeting next week. I think that current and future enrollments is a good starting point