Internationalization Work Group 2020-04-07

Owned by Eric Jansson
Last updated: Apr 17, 2020
4 min read

Materials

Participants

  • Ed Comer
  • Gene Garcia
  • Linda Feng
  • German Freiwald
  • Don Hutchings
  • Gabrielle Garonzik
  • Stephen Fuqua
  • Eric Jansson

Meeting Notes

Meeting Context / Housekeeping

Going to hold off on Work Group goal setting  a bit given the COVID-19 pandemic, and general need to not make long term commitments to preserve agility.
Pivoting in tools to use Diagrams.net online drawing tool that is both easy to use and has some higher level options.
Support for this from members because of the collaboration capability as well.

Data Models - Organization

Removes abstract classes and simplified to EducationOrganization and School, andnd give the EdOrg a Type to define .G

  • 2 notes of agreeement: abstract classes add complexity that does not always pay off in the long run. Will need to explain the difference between any EdOrg versus School.
    • Yes. There is a lot in the model where we're trying to combine domain driven objects with flexibility.
  • Q: If you had a hierarchy of EdOrgs, how do you reference the parent? How do you represent the parent/child relationship.
    • A: Would be ParentEdOrg in the schema. Child is not usually used in Ed-Fi. These could be qualified if needed but this model is Parent.
  • Q: Is the EdOrgType an enumeration?
    • A: Yes.
  • Q: Can these have a language associated with them? If it is a string type, then strings can have a language to make it more international.
    • A: So right now, we have not addressed these issues but they are important to address. Currently, descriptors have Namespace, CodeValue, ShortDescription, and Description. Right now these look like 'ed-fi.org/AccountCode#abc'.
    • A: Being able to have international lists of enumerations is important and we should try to capture this need in a ticket. This could be additional columns for different languages. Would work if just using primary languages (and not 100's). The other option would be to have resource files to translate between languages. Perhaps be able to notate a namespace and a language and the CodeValue.
    • One model: a table for the enumerations and then a table 'rough translation' that includes the language and then the rough equivalent in that language.
    • Q: Some have said they want to do inline references (not just an id for a secondary retrieval). Has this come up in Ed-Fi's modeling? Any best practices?
      • A: Referring to the API binding. When you have a reference, it appears as an independent json object as a reference with key entities underneath. Is this common?

Data Model - Person

Very complex and compelling topic we've been working on. Trying to keep the model where the metadata is linked to the person-role, and not on a generic person.

All of the entities are concrete. Looking at API binding options that would allow the writers and managers of the Person entities to not be concerned with Person itself.

Q: This is fine. One question: Within each Person-Role, there could be groupings of attributes that might be re-usable. Is that a part of this?

A: Yes

Data Model - Demographics

Sharing Ed's slide in the TPDM work.

The idea is that you have common entities for identification, contact, and demographics so all Person-Roles could use the same structure and definition. Discussed thrashing. The two types we're dealing with is an Association with an EdOrg. As persons move between EdOrgs, the source systems may not be aligned and can overwrite each other during the period of transfer. So tagging with the EdOrg that wrote the data is a way to disambiguate that. The other thrashing is often the system of record is different for staff and students (in particular). So you have to worry about, even in the same EdOrg, that different systems could be writing their own version. As much as you'd want this to be the same, it often is not.

  • Q: See the need for complexity. But for downstream users, how do they know what data to use? Which set is the right set?
    • A: Even though a human person might have multiple entries for demographics, one of the thoughts for downstream was that at least they are all in the same table. So from an API standpoint, having an effective date would help a downstream application. So that could be a business rule. As could the Source.
    • Response: This is getting into some master data management of what system "owns" the data when there is competition. So "this system" owns "this entity".
  • Q: Would this 'win' be in business rules or would it define what data lands in the tables?
    • A: This speaks to the complexity of ingestion. The whole discipline of how you map this data in from the source systems.
    • Response: This makes sense. A lot of internal decisions in Ed-Fi as far as separation into different entities is often motivated by different source systems. Maybe we should tag the fact that we are expecting this type of system to manage this collection of data?
    • Response: Can be clarified by what is the underlying goal of the data store. You can want to capture data from every system or you can be targeted and want to centralize a representation that is not as comprehensive. Trying to hit the sweet spot of delivering the value.
    •  Ed-Fi's current priority is about capturing the data and opening the flow for interoperability. Accepts this kind of complexity as a precondition of letting everyone write data that wants to. And then punting the conflicts downstream. So down to business rules.
  • Concerns with the EdOrg tag for Demographics, Contacts, Identification. Lots of conversation about the pros/cons of a system-based system or an organization-based system.
    • Q: Could you have the StudentEdOrg or StaffEdOrg associations be the driving factor in who 'wins' on demographics, contacts, and so forth.

Data Model - Student Membership

Idea is to combine a model for generic Membership and domain-driven membership associations. And then even more generic, StudentGroups. Athletics, Counselor groups, etc.

  • Q: Student groups are very important for access and equity. Use case is learning platforms, comparing the idea of student groups.
    • A: We were thinking of student groups as campus activity groups rather than classifiers of students. We're not sold on the name.
  • Consider using the term "Affiliation". Affiliation is a better term when describing a generic relationship with an EdOrg. And membership is when the person is a part of the group.
  • Q: Would this include 504 groups?
    • A: Probably not: that is tracked that in Ed-Fi via the program model. So that may be more an enrollment and a status. Program domain is a good one to do next time.

Action items

  • Work up Program domain models
  • Update Demographics model
  • Update Membership to Affiliation