2018-12-05 - IMS EDU-API Task Force

• Review of Person API Analysis - For those that agreed to provide comparative analysis with various models, please be prepared to discuss your findings

• BYU and someone with eduPerson went over their “person” API’s and they were compared back to the LIS model in process.

Here are some random scribbled notes as I tried to understand:

Coversation led by BYU

Group Affiliation
BYU Puts Memberships/Affiliation directly in the Person Object
LIS Model has a separate Membership entity
--There should be a discussion on what direction to go.
LIS also has a "relationships" entity for family relationships such as dependents between people, parents etc...

BYU API -
Goal not to have 500 top level objects, but to have 50 or so

BYU API - Concept of the person API is “Here is everything we know about a person”

Person Object is a GIANT VIEW of the person, everything related to a person
It is an aggregate of multiple data sources, we aggregate it into a single API Entity

Authorizations are done at the "Field Set" level, which makes the larger data set easier to digest as applications only get access to what they have access to

Question about Relationships
LSI -- Concept of an "agent" -- Allows them to be a "parent", "Advisor","
BYU -- Concept of "Delegates"

Question regarding Demographics:
LSI -- Much more simple demographics compared to BYU
BYU: Concept of Field Sets that can be optional

Comment: There are cases where data when used together becomes more sensitive than any of the individual pieces of data alone. The example they gave was Combining Class Schedule with Course Enrollment.

Security: Concept of securing "Field Sets" instead of at the field level

Fields may appear in multiple field sets/duplicated

Vocabulary

LIS Model uses basic vocabulary to describe things whereas BYU uses specific vocabulary.

• For example: BYU calls a Building a Building with fields such as Building Name
  LSI calls the similar objects "Address Part" which is somewhat ambiguous, but may be more extensible.

Concept of Publishers/Subscribers to areas. Subs can/do get notified when a subject area has changed since they last received data. What changed is less clear, can result in "change messages" that are really not applicable to all subs.

Comment: Universities will always need "one more field" Having a standardized extension mechanism for adding extensions needs to be available and built into the process. "is this extension local (for one school) or something that should be pushed to the main.

Free For All approach to adding things Creates 5 different ways to define the something = Bad.

review of eduPerson model.
(I’m not sure what eduPerson is) It was brief and less comprehensive.

BYU has a credentials table, so that as credentials change the can handle it. Things that aren't global like NetID, ByuID become more global type of credentials, this is handled.

• Vetting of the process: Is this format/process working for the group? Different approaches

Not Covered

• Discussion of Proof of Concept

  • Goals and intentions

  • Call for participants

They asked for volunteer schools that may want to be in a Proof Of Concept for this project along with Oregon State. I was NOT sure if we were interested in this. Steven Maglio / Diana Antova

• Review of timelines for work going forward

Not Covered