Innhold
1 Oversikt
ABC Enterprise er definisjonen av et standardisert grensesnitt mellom skole - og studieadministrative systemer (SAS) og brukeradministrative systemer (BAS). Dette skjemaet definerer hvordan datastrukturen vil se ut, men er ennå relativt åpen i forhold til innholdet og overføringsmetode.
2 Data
Grovt sagt uttrykkes alle tilknytninger/forhold i ABC gjennom en <relation>. En relation er en binær relasjon med en <subject> og et uendelig antall <object>. N-ære relasjoner må splittes for å passe inn i denne oppdelingen.
Per i dag generer ABC-eksporten en fil som inneholder:
OU-liste. For hver OU publiseres det relativt lite -- navn og unik identifikator (for tiden stedkode).
Personliste. For hver person, publiseres det:
- ID-liste (for tiden studentnummer og fødselsnummer)
- Forskjellige navn
- Fødselsdato
- Brukernavn (personens primære brukernavn) og e-postadressen knyttet brukernavnet
Selv om flere id-typer for personer er tilgjengelig (student#, ansatt#, osv.), brukes fnr for å uttrykke alle forhold mellom personer og noe annet (dette fordi fnr er en id-type som alle personer har).
Liste av kull (en gruppering av studenter under en OU). Hvert kull representeres som tre elementer -- kull, kull-ou forbindelse og kull-person forbindelse:
- Først defineres kullet vha. et <group>-element. Kull-id'en som identifiserer det gitte kullet er på formen "studieprogramkode:semester:år", fx. "ALU:HØST:2003".
- OU'en og kullet knytes sammen vha et <relationship>-element. Et slikt <relationship> har OU som <subject> (identifisert av en stedkode listet opp tidligere), og kullet som <object> (identifisert slik beskrevet over. <relation> i dette tilfellet har relationshiptypen "kull-ou".
- Så lister man opp studentene på det aktuelle kullet, også vha. et <relationship>-element. Denne gangen er kullet en <subject> (identifisert som før), og alle studentene (identifisert av fødselsnummer) ligger under <object>. Relationshiptypen heter "kull-people".
Liste av undervisningsenhetene (en inkarnasjon av et emne, helst med studenter i). Hver undervisningsenhet representeres temmelig lik et kull:
- Man definerer et <group> element som betegner undervisningsenheten. ID'en
til denne gruppen er på formen "institusjon:emne:versjon:terminkode:årstall:terminnr", fx. "201:NO-119:1:HØST:2006:1".
- Man knytter sammen en OU og undervisningsenheten vha. en <relation>.
OU'en er <subject> og identifisert av stedskoden, selve undervisningsenheten er <object> og er identifisert slik beskrevet over. relationtype vil i dette tilfellet være "ue-ou".
- Man knytter sammen studenter og undervisningsenheten vha en
<relation>. Undervisningsenheten er en <subject> og alle studentene er listet opp under <object> (identifisert typisk vha. fødselsnummer). relationtype i dette tilfellet er "ue-people".
Informasjon om betalt semesteravgift. Igjen, uttrykkt via et <group>-element, dog noe enklere:
- Man definerer et <group> element som betegner gruppen av de menneskene
som har betalt semesteravgift. Gruppen har groupidtype "paid-gruop" og heter også "paid-group".
- Man definerer så en <relation> med "paid-group" som <subject> og listen
av personer som har betalt semesteravgift som <object>. Denne <relation> har relationtype "paid-people".
Liste av alle affiliations (folk assosiert med en OU på en bestemt måte). Her har vi gjort en liten forenkling. Hver affiliation representeres som en relation. relationtype'en til denne er navnet på affiliation + et lite løpenummer for å sikre entydigheten.
- <subject> i <relation> er OU'en som folk er knyttet til. OU'en
identifiseres (som ellers) med en sko.
- <object> i <relation> er listen av personer (identifisert av fnr) som har
denne affiliation.
Strengt tatt er det snakk om en liste av affiliation/status. Dette betyr at vi for hvert gitt par (affiliation, status) gjør som bekrevet over slik at resultatet blir "Student, aktiv", "Student, evu", "Student, privatist" osv.