Sluttrapport for prosjektet Elektronisk Standard for Utdanningsinformasjon. (esu) Dato: Universitetet i Oslo

Transkript

1 Sluttrapport for prosjektet Elektronisk Standard for Utdanningsinformasjon (esu) Dato: Universitetet i Oslo

2

3 Sluttrapport esu 1. Innledning 1.1 Bakgrunn Fagmiljøer innen ulike deler av norsk utdanning har over flere år drøftet behovet for standardisering av måten vi beskriver den informasjon som skal gjøre det mulig effektivt å sammenstille og presentere kataloger over utdanningstilbudet i Norge. Det vises bl.a. til referat fra et møte arrangert av Norgesuniversitetet den 25. juni 2002, der store deler av utdanningssektoren var representert. Det har imidlertid vært vanskelig å komme i gang med et standardiseringsprosjekt på området, noe som først og fremst skyldes manglende ressurser og usikkerhet om problemstillingen ville bli adressert i planlagte sentrale prosjekter av typen utdanningsportalen utdanning.no. Arbeidet med utdanning.no har igjen vist at det er nødvendig straks å komme videre med et slikt prosjekt for å kunne realisere målsettingen om å bygge opp en effektiv katalog over læringstilbud fra hele utdanningssektoren. Disse dataene er i dag ikke tilgjengelig på noe omforent format. Norgesuniversitetet (NU) har den mest omfattende katalog på nettet. Katalogen er bygd opp i et samarbeid med UH-sektoren, og gir et godt bilde av hva som er mulig å få til uten standardisering. NU forlot tidlig en strategi med å få de mange institusjonene til enkeltvis å legge inn data i en sentral database. Nå bygges deres katalog opp ved hjelp av såkalt vevboring (web mining) med teknologi som delvis benytter seg av mønstergjenkjenning. Det sier seg selv at en slik løsning har klare begrensninger når det gjelder nøyaktighet for treff. Utdanning.no har ambisjoner om å legge til rette tjenester som gjør det lett for brukerne å sammenligne tilbud. Men om man f.eks. ikke er sikker på om tallet 5 i katalogen uttrykker studiepoeng eller antall semestre, er det ingen mulighet for å bygge en slik tjeneste. Bare på grunnlag av en standardisert beskrivelse av kataloginformasjon kan man bygge de avanserte tjenestene som brukerne vil etterspørre på utdanning.no. Alle forsøk på å pålegge eller oppfordre institusjonene til å registrere og vedlikeholde data i sentrale databaser, er dømt til å møte motstand. Den løsningen som foreslås, må støtte opp under virksomhetenes eget arbeid med å framstille kataloger over sitt utdanningstilbud. Man må ta utgangspunkt i deres produksjonssystemer og sikre at dataene legges inn og eksporteres fra disse systemene på et format og ved hjelp av en teknologi som muliggjør en automatisk utveksling av oppdaterte data på tvers av aktørene i utdanningssektoren. 1.2 Igangsetting av esu-prosjektet 1.3 Formål 7. februar 2003 sendte Norgesuniversitetet en søknad til Utdannings- og forsknings- departementet om midler til å starte et prosjekt med mål å standardisere katalogdata med kursinformasjon. Søknaden ble innvilget, og USIT ved Universitetet i Oslo ble bedt om å stå for gjennomføringen av prosjektet. Prosjektet har som målsetting å lage en spesifikasjon for metadatabeskrivelse av kursinformasjon (dvs. all informasjon som ønskes gjort søkbart i kataloger over utdanningstilbud i hele utdanningssektoren i Norge). For at institusjonene skal være i stand esu , AFS, Dato: Side: 1

4 til å følge det som vil kunne bli en standard for utdanningsinformasjon i Norge, må prosjektet lage en spesifikasjon over hvilke metadata som skal beskrive kursinformasjonen. XML peker seg ut som et hensiktsmessig og etablert språk for å beskrive, strukturere og sørge for enhetlig utveksling av data. Når prosjektet har kommet fram til hvilke metadata som skal kunne brukes, uttrykkes disse ved hjelp av XML i dokumenttypedefinisjoner, dvs. såkalte DTD-er eller XML-skjema. Dermed kan ulike institusjoner bruke ulike verktøy for å vedlikeholde (oppdatere/validere) informasjon, samtidig som man sikrer at dataene som utveksles, er "konsistente". Systemer må kunne importere/eksportere data i henhold til DTD-ene eller XML-skjemaene. Prosjektet skal levere følgende: Spesifikasjon for metadatabeskrivelse av kursinformasjon Spesifikasjonen uttrykkes i en DTD eller et XML-skjema En forslag til implementasjonsstrategi for ulike typer institusjoner (UH-institusjuoner, institusjoner innen Norsk forbund for fjernundervisning osv.) Implementasjonsstrategien skal bygge på en utredning av aktuell teknologi for lagring og utveksling av data En referanseinstallasjon som er basert på teknologi som i størst mulig grad er basert på Open Source programvare Prosjektet skulle ta hensyn til behovene i hele utdanningssektoren. I arbeidet med spesifikasjonen skulle det tas hensyn til det arbeidet som er gjort internasjonalt med å utarbeide standarder for metadata på e-læringsområdet. Det skal ikke gjøres valg som i framtiden vil gjøre det vanskelig å utveksle data med institusjoner innen Norden eller EU. 1.4 Forutsetninger Det skulle i dette prosjektet lages spesifikasjoner for utveksling av kursinformasjon for hele undervisningssektoren bortsett fra ordinær grunnskole. Siden prosjektet er utført av USIT som først og fremst er kjent med utdanning på høyere nivå, var det en klar forutsetning at prosjektgruppen kunne trekke inn kompetansepersoner fra andre miljøer, spesielt de som representerer utdanning på videregående skoles nivå og voksnes læring. Styringsgruppens representanter med nettverk til de relevante miljøer har bistått med slike kontakter. esu , AFS, Dato: Side: 2

5 2. Organisering Prosjektet har vært organisert med følgende grupper/personer 2.1 Prosjektansvarlig Norgesuniversitetet 2.2 Styringsgruppe William Evans, Voksenopplæringsforbundet Geir Inge Barsnes og Lisbeth Pedersen, Læringssenteret Dag Rune Ramstad, Norgesuniversitetet Lasse Barstad, Norsk Forbund for Fjernundervisning Tore Hoel, estandard-prosjektet Tor Jørgensen, Statistisk sentralbyrå Kjell Arne Karlsen, IST AS/MSTAS 2.3 Leder av styringsgruppen Dag Rune Ramstad, Norgesuniversitetet 2.4 Prosjektleder Andora Sjøgren, USIT 2.5 Personressurser i prosjektgruppen Personer Andora Sjøgren, USIT, FS Astrid Jenssen, USIT, XML Dagfinn Bergsager, USIT, XML Geir Vangen, USIT, FS Grethe Christina Lingjærde, USIT, FS Einar Løvdal, USIT, SO Morten Erlandsen, USIT, XML esu , AFS, Dato: Side: 3

6 3. Gjennomføring Prosjektperioden var i prosjektplanen satt fra til Resultatene og sluttrapporten ble overlevert leder av styringsgruppen 2 uker senere, 30. september. Styringsgruppen hadde møte 10. oktober 2003 der sluttrapporten ble behandlet. Prosjektgruppen har hatt god kjennskap til høyere utdanning. Kunnskapene om utdanning på videregående nivå har vært mindre. Einar Løvdal, utviklingsleder i SO, representerer en del av denne kunnskapen. Prosjektgruppen har derfor konsentrert seg om de inputdokumenter som vi har fått som beskriver denne utdanningen. Møte med Danuta Ciemska (Læringssenteret) bekreftet at resultatet ser ut til å stemme. 3.1 Aktiviteter og timeforbruk Prosjektet ble gjennomført med følgende aktiviteter. Antall budsjetterte timer og virkelig forbrukte timer er satt opp for hver aktivitet. Aktivitet Timer budsjettert Timer brukt 1. Administrasjon og prosjektledelse Avklaring av begreper som skal med i spesifikasjonen Gjennomgang av internasjonale standarder Informasjonsanalyse Utarbeide forslag til implementasjonsstrategi Totalt Møter/seminarer I gjennomføringen av prosjektet har flere miljøer deltatt. Det har vært avholdt følgende møter /seminarer Styringsgruppen har avholdt 4 møter: 11. april, 6. juni, 29. september og 10. oktober Seminar ble avholdt 12. mai 2003 med deltakere fra styringsgruppen, prosjektgruppen, BI, Læringssenteret og UFD (utdanning.no). Hensikten med seminaret var å avklare hvilke begrep som skulle med i analysen. Deltakelse på nettverksmøte i Bergen Astrid Jenssen fra prosjektgruppen deltok 13. juni på et nettverksmøte i Bergen i regi av estandard-prosjektet. Se for øvrig Møte om internasjonale standarder Mandag 26. mai esu , AFS, Dato: Side: 4

7 - Tore Hoel, Morten Erlandsen og Astrid Jenssen diskuterte input på aktuelle internasjonale standarder - Tirsdag 2. september (Se møtebeskrivelse under informasjonsanalysen) - Tirsdag 9. september (Se møtebeskrivelse under informasjonsanalysen) Møter om informasjonsanalysen Informasjonsanalysen er gjennomgått i følgende møter: Onsdag 20. august gjennomgang av analysen med BI (Merete Henriksen) og MSTAS (Hans Martin Graedler) Forslag til endringer ble diskutert på møtet og analysen rettet opp. Det var kun mindre endringer som ble gjort. Merete Henriksen har senere meldt tilbake at hun sammen med flere andre ved BI har gått gjennom forslaget, og at de ikke har flere kommentarer på nåværende tidspunkt. Tirsdag 2. september gjennomgang av analysen med Læringssenteret (Danuta Ciemska) og IfI, UiO (Kjell Åge Bringsrud) Forslag til endringer ble diskutert på møtet og analysen rettet opp. Kun mindre endringer til analysen. XML-skjemaet ble på dette møtet også diskutert i forhold til standardisering. Bringsrud ga oss opplysninger om navn på person som burde kontaktes i forhold til standardisering. Tirsdag 9. september gjennomgang av analysen med Erlend Øverby (Conduct) og Kjell Åge Bringsrud (UiO) Prosjektgruppen I tillegg har prosjektgruppen avholdt en rekke interne møter. 3.3 Skriftlig inputdokumenter Prosjektgruppen har fått tilsendt en mengde dokumenter til hjelp i utviklingen av en standard. Dette er for eksempel beskrivelse av tabeller som brukes i dag i diverse systemer, kataloger, søkerhåndbok etc. Alle disse dokumentene er gått gjennom spesielt i forbindelse med aktiviteten Informasjonsanalyse. Noen av dokumentene er også brukt i aktiviteten Avklaring av begreper som skal med i analysen. Nedenfor følger en oversikt over hvilke dokumenter vi har gått gjennom: esu , AFS, Dato: Side: 5

8 Fra Høgskolen i Oslo Avdeling for helsefag: Kompetanseutvikling , Videreutdanning, etterutdanning/kurs Avdeling for lærerutdanning, Videreutdanning , Allmennlærer, førskolelærer Helse og sosialfag, studietilbud Estetiske fag, drama, formgiving, kunst og håndverk, studietilbud Avdeling for økonomi- kommunal- og sosialfag Videreutdaninger NKI Fjernundervisning: Studiekatalog 2002/2003 Læringssenteret: Studiekatalogen fjernundervisning i Norge 2000 Søkerhåndboka 2003, Søknad om opptak til universiteter og høgskoler Nasjonalt læremiddelsenter, Norsk database for fjernundervisning, Skolenettet Referansehåndbok med vedlegg Fjernundervisning (tabellbeskrivelse) Læringssenteret: Informasjon om You og fjernundervisningsdatabasen Norgesuniversitetet: Forslag til et felles kursoppsett for høgre utdanning Norsk Forbund for Fjernundervisning Skjema for kursbase UiO: Kategorier for beskrivelse av studieinformasjon (emner, studieprogram med mer) i StudInfo. Inkluderer også ECTS-informasjon. Dokumenter og maler fra KOST-prosjektet ved UiO er også vurdert. Voksenopplæringsstatistikk til Statistisk sentralbyrå, emneinndeling Filbeskrivelse, fjernundervisningsstatistikken FS: Datamodell og tabellbeskrivelse ECTS guidelines 3.4 Arbeidsformen i prosjektgruppen Prosjektgruppa ved USIT er satt sammen med folk fra både FS-gruppa og fra XML-gruppa. Disse gruppene kommer fra to seksjoner ved USIT. XML- gruppa har god kompetanse på XML, studieinformasjon generelt og publiseringssystemer. FS-gruppa har god kompetanse på databaser og studieadministrative system. Den samlede kunnskap disse to gruppene representerer, har vært helt avgjørende for å kunne gjennomføre esu-prosjektet. 3.5 De enkelte aktiviteter i prosjektplanen Administrasjon Aktiviteten har fulgt den oppsatte planen. Timeforbruket er noe høyere: 148 timer Avklaring av begreper som skal med i spesifikasjonen Prosessen med å komme fram til hvilke begreper som det skal lages en utvekslingsstandard for, ble noe annerledes enn planlagt. Opprinnelig satte vi opp en liste med begrep som emne, kurs (ikke kompetansegivende), kurs (slik BI bruker dem), fag (fra esu , AFS, Dato: Side: 6

9 videregående skole), studieprogram, løp osv. og tenkte å lage XML-beskrivelser for hver av disse. Etter hvert så vi at opplysningene ble de samme for begrep som emne, kurs og fag. Likedan for studieprogram og diverse løp. En forutsetning for at den standard som utvikles i esu-prosjektet skal kunne benyttes internasjonalt, er at vi har gitt begrepene engelske navn. Engelske navn ville faktisk også være en forenkling for den norske utgaven da de engelske navnene på begrep da kunne brukes som fellesbetegnelser. Følgende hovedbegrep er derfor med i standarden: 1) Course: Dekker følgende begrep i videregående og høyere utdanning: Emne brukes i høyere utdanning (minus private høgskoler) for den minste enhet det kan avlegges en eksamen i med et endelig resultat Kurs brukes ved private høgskoler for den minste enhet det kan avlegges en eksamen i med et endelig resultat Kurs brukes i forbindelse med etterutdanning som et ikke kompetansegivende kurs Fag brukes i videregående utdanning som den enhet det kan avlegges en eksamen i 2) Program: En samling av Course med mer eller mindre definerte regler rundt 3) Institution: Institusjonen som er ansvarlig for et annonsert Course eller Program. Resultatet av aktiviteten er en HTML-rapport som beskriver de elementer som er med i skjemaet. Denne beskrivelsen vedlegges sluttrapporten, og leveres i tillegg på en CD til oppdragsgiver Gjennomgang av internasjonale standarder Prosjektgruppen har undersøkt ulike internasjonale standarder for å sørge for at resultatene fra esu er i samsvar med arbeid som foregår internasjonalt. Fra personer som jobber i fora for internasjonale standarder og ut fra egne undersøkelser har vi fått input på hvilke standarder som er mest relevante for esu. Av kapasitetshensyn har vi valgt først og fremst å fokusere på disse i prosjektet. Det foregår også arbeid innenfor andre områder som kan være relevant for esu. Eksempel på et slikt område er kompetanseprofil. Prosjektgruppen anbefaler at det etter prosjektet jobbes med å presentere og videreføre arbeidet i internasjonale fora. IMS IMS Global Learning Consortium ( er et verdensomspennende konsortium. I følge nettstedet: The IMS Global Learning Consortium develops and promotes the adoption of open technical specifications for interoperable learning technology. En rekke IMS spesifikasjoner har fått stor internasjonal esu , AFS, Dato: Side: 7

10 utbredelse og er de facto standarder knyttet til e-læringsteknologi og tjenester. Spesifikasjonene er tilgjengelig via I esu har vi integrert IMS Enterprise Specification ( for å beskrive person- og adresseopplysninger. Standarden er definert i XML og er omfattende. Vi bruker store deler av denne standarden i alle person- og adresseopplysninger. I tillegg er det noen elementer som vi har lagt til for å passe inn i behovene til esu (for eksempel referanse til enhet). Standarden er definert som forklaringer til oppsett av forskjellige felter. Alle elementnavn som skal ha likt innhold som det som finnes i IMS, har samme navn. IMS benyttes i mange tilfeller for utveksling av data mellom LMSer og andre systemer. Et eksempel er utveksling av informasjon mellom Classfronter og FS. vcard Vi vurderte også vcard for beskrivelse av person- og adresseopplysninger. Ut fra beskrivelsen ( hos Internet Mail Consortium ( benyttes vcard for elektronisk beskrivelse av informasjon som typisk finnes på visittkort. Dette er nyttig for overføring av personopplysninger med mer mellom ulike typer enheter, omtalt som PDI (Personal Data Interchange). Den brukes i applikasjoner slik som e-post, nettlesere, PDAer og andre enheter med programvare som støtter vcard. Et eksempel på bruk i Norge er telefonkatalogen online hvor det er mulig å klikke på et ikon for å få overført opplysninger om person og/eller firma. Informasjonen er beskrevet i henhold til vcard. I mars 2002 ga IETF (The Internet Engineering Task Force) ut spesifikasjonen for vcard versjon 3. Den er delt inn i to deler, hhv RFC 2425, MIME Content-Type for Directory Information ( og RFC 2426, vcard MIME Directory Profile ( vcard er i utgangspunktet ikke definert som en XML DTD eller som et XML Skjema. W3C har begynt å se på muligheten for å presentere vcard som XML eller RDF ( m en de har ikke kommet frem til noen definisjon. De har et forslag om å bruke vcards navnekonvensjoner og legge de som XML- elementer. Ettersom de ikke lager noen total oversikt over anbefalte navnekonvensjoner for dette, har det liten hensikt å ta i bruk deres første forslag. Grunnen til dette, er at det da uansett må lages en egen konvertering for esu for å kunne representere slike opplysninger som vcard. Ettersom navnekonvensjonene i IMS og vcard er ganske like, vil esus definisjoner for person- og adresseopplysninger lett kunne representeres som vcard. ISO 8601:2000 Det finnes standarder for hvordan dato og tid skal beskrives. Knut Lindelien ved Norsk Teknologisenter (NTS) anbefaler oss å benytte ISO 8601: Dato og tidsangivelse. Norsk Teknologisenter (NTS) er et kompetanse- og servicesenter for standardisering og teknologiformidling rettet mot norsk teknologiindustri, IT-industri samt olje- og gassindustri. ISO 8601:2000 ble etablert av ISO (International Organization for Standardization), i forbindelse med år 2000 problematikken. Denne anbefales brukt for alle dato- og tidsdefinisjoner. Les mer om ISO 8601:2000 på ISOs sider: I esu anbefaler vi bruk av standarden i elementene hvor dato og klokkeslett skal angis. Dette står skrevet som kommentar til alle elementene det gjelder. I praksis vil det si at innholdet i elementene skal være på formen: - Dato: YYYY-MM-DD. - Klokkeslett: hh:mm:ss esu , AFS, Dato: Side: 8

11 LOM LOM er den første standarden som er etablert innen e-læringsområdet. LOM brukes for å beskrive læringsobjekter/læringsressurser (vedtatt av IEEE juni 2002). LOMs oppgave er å le gge til rette for å search, evaluate, acquire and utilize Learning Objects. I esu refererer vi til læringsobjekter under <course-presentation>. Her er det lagt opp til at man kan legge inn URL til læringsobjekter, slik det er vist i følgende illustrasjon fra esu: Mer detaljer om hvordan læringsobjektet beskrives, ligger utenfor esu. Internasjonalisering etter esu I prosjektet har vi hatt møter med personer som er involvert i arbeid med standarder knyttet til e-læring internasjonalt. Vi har presentert forslagene og diskutert hvordan vi skal forholde oss til internasjonale standarder i esu. I prosjektet har vi undersøkt de mest relevante standardene. Det er samtidig lagt til rette for esu skal kunne fremmes i internasjonale fora. Et eksempel er å bruke esu som et utgangspunkt for en mal til bruk for europeisk ECTS-beskrivelse, og at esu bør presenteres i fora der ECTS-beskrivelsen diskuteres. Et annet eksempel er NORFA (Nordiske forskerakademi) som skal utarbeide beskrivelse av doktorgradskurs Informasjonsanalyse Dette har vært den mest arbeidskrevende aktiviteten i prosjektet. Hele prosjektgruppen eller deler av gruppen har hatt flere møter i perioden fra juni og til prosjektslutt. Det meste av arbeidet har foregått i disse møtene. I tillegg til prosjektgruppen har andre miljøer deltatt på noen av disse møtene (se møteoversikter). Timeforbruket har vært ca 219 timer. Det var satt av 210 timer, og 180 timer på aktivitet 2 - avklaring av hvilke begreper som skal med i standarden. Det har ikke vært lett å fordele timer på disse to aktivitetene, og de bør derfor ses i sammenheng. Resultatet av aktiviteten er en metadatabeskrivelse av begrepene i form av XML-skjema. Denne beskrivelsen vedlegges sluttrapporten, og leveres i tillegg på en CD til oppdrags- giver Utarbeide forslag til implementasjonsstrategi Dette kapittelet gir forslag til hvordan institusjonene kan nyttiggjøre seg av resultatene fra esu-prosjektet. Dette omfatter både produksjon, utveksling og bruk av XML-data i henhold til esu. esu , AFS, Dato: Side: 9

12 Produksjon av XML Data som skal beskrives i henhold til esu, skal være kodet i XML. Det er flere måter å produsere XML-dataene på: - Data kan eksporteres fra databaser, eksempelvis FS og MSTAS. - Data kan eksporteres fra LMSer, eksempelvis Classfronter og Its:learning. - Data kan redigeres manuelt i en XML-editor, eksempelvis XMetaL og FrameMaker. - Data kan redigeres manuelt i en annen teksteditor, eksempelvis Textpad og Notepad. - Data kan produseres ved en kombinasjon av punktene over, eksempelvis ved at noe eksporteres fra en database og tilleggsinformasjon redigeres manuelt. I de fleste tilfeller vil nok XML-dataene eksporteres fra en database. Da er det opp til de som utvikler databasesystemet, å sørge for at dataene som eksporteres, er valid i henhold til esu. Det kan lages en eksport som inneholder all informasjon knyttet til en institusjon. Dersom denne eksporten tar lang tid å prosessere, kan det være hensiktsmessig å la de tte skje om natten. Dette er imidlertid avhengig av flere ting, slik som kompleksiteten på systemet, omfanget av dataene, og hvor kraftige maskiner som er i bruk. Dersom databasen ikke er i stand til å lage all informasjonen som man ønsker å representere i fila, kan dette legges inn i etterkant. Dette kan for eksempel være presentasjonen av institusjonen. Sett da systemet opp slik at de endelige XML-dokumentet (eller dokumentene) er en sammenslåing av det som kommer fra databasen og det som er produsert utenom. Dersom en del av informasjonen blir levert fra en database og resten ligger i XML i et annet system, må sannsynligvis XML-dataene konverteres for å være i henhold til esu. Det er mulig å validere mot både hele og deler av esu. XSL og XSLT kan brukes for å konvertere XML fra ett XML-skjema til et annet. Dersom XML-dataene skal redigeres manuelt i en XML-editor, vil editoren skjønne esu og gi støtte slik at man slipper å skrive selve kodene manuelt. Validering vil skje underveis mens man skriver. De fleste XML-editorer har mulighet til å tilrettelegge maler som gir et grensesnitt som forenkler kodingen av informasjonen. Det er også mulig å redigere XML-dataene manuelt i eksempelvis Notepad. Da gjelder det å holde tunga rett i munnen. Både kodene og innholdet i kodene må da skrives manuelt. Uansett hvilke verktøy som benyttes for å XML-kodingen skal XML-dataene valideres før de leveres eller hentes til et annet system. Levering av XML All XML må være tilgjengelig for de forskjellige aktører som skal bruke den. Dette kunne vært gjort ved å sette opp en sentral server som alle leverte til. Denne felles databasen kunne da styrt tilgangen og formatet på dataene som ble levert til forskjellige aktører. Dette er ikke en løsning som det legges opp til i denne omgang. Alle aktører (leverandører av data) skal selv være ansvarlige for å ha sine XML-data tilgjengelig til rett tid. Det mest naturlige er at hver institusjon gjør sine XML-data tilgjengelig via HTTP eller FTP og selv oppdaterer den når det skjer forandringer. For mange aktører vil det være aktuelt å legge denne informasjonen på en server hos leverandøren av driften av deres studieadministrative system. Forskjellige aktører vil her ha forskjellige behov for hvordan dataene skal hentes inn og leveres. Dette betyr at hver aktør som skal bruke XML-data, må ha en avtale med hver institusjon om hvor de kan hente ut XML-dataene deres. Hvordan dette oppslagsverket for å hente XML lages, blir opp til den enkelte aktør å bestemme. esu , AFS, Dato: Side: 10

13 FS Et egendefinert oppslagsverk for hvordan aktuelle aktører kan hente XML slik de ønsker. F.eks. at SSB har en egen oversikt over hvilke URLer de finner den XMLen de skal bruke Utdanning.no MSTAS++ SSB Studieforb., voksenoppl. Leverer xml XMLdata definert etter felles schema Alle henter den XMLen de ønsker Timeplanverktøy++ Enkeltbruker Enhets websider VIGO, BI..++ Kursdatabase NorgesUniv Figur 1: Skissen over viser en oversikt over hvordan forskjellige aktører kan lage XML mens andre bruker den Det anbefales å ikke legge ut all XML-kodet informasjon om studier og enheter for en institusjon fritt tilgjengelig. Farene for misbruk av XML-dataene er tilstede. Et eksempel kan være at andre trykker brosjyrer med innhold plukket fra XML-dataene og bruker de kommersielt. Det er viktig at aktørene som skal levere og motta XML-data, avklarer seg i mellom hvor dataene skal legges/leveres og hviken tilgangskontroll som skal gjelde. Selv informasjon som er offentlig tilgjengelig, for eksempel på web, kan bli misbrukt dersom det er fritt tilgjengelig i XML. Vi anbefaler derfor at man passordbeskytter XML-dataene. Presentasjon av esu XML-dataene fra esu kan både brukes for presentasjon i Web og på papir (i tillegg til at de kan overføres til andre databaser). I begge tilfeller forutsetter det at det lages løsninger for å kunne presenteres dataene. esu beskriver innholdet i informasjonen, ikke hvordan informasjonen skal presenteres. En institusjon kan presenteres dataene på egne web-sider og med egen web-profil påført. En annen aktør kan samle informasjon fra en rekke institusjoner og presentere en oversikt over utdanningstilbud, eksempelvis utdanning.no. Aktørene vil ha ulike behov for presentasjon av dataene i Web. Det er opp til den enkelte aktør å sørge for presentasjon av dataene. Vi anbefaler at man bruker XSL (og XSLT som er en del av XSL) for å beskrive presentasjon av XML-dataene. XSL er en W3C-standard. Les mer om W3C og XSL på Dette er en av de tilhørende standardene til XML, og er utviklet spesielt for å lage løsninger for presentasjon og prosessering av XML-data. esu , AFS, Dato: Side: 11

14 Standarden er utbredt internasjonalt, er egnet for denne typen prosessering av XML-dataog det finnes en rekke gratis programvare tilgjengelig som støtter XSL. For å presentere XML-data for en institusjon, vil det i de aller fleste tilfeller være hensiktsmessig å dele informasjonen opp i flere mindre filer. Det finnes et tillegg til XSL 1.0 som heter document som har funksjonalitet for å kunne splitte en stor fil opp i flere enkeltfiler. Dette er også standard i XSL 2.0, men den versjonen er ikke særlig utbredt enda. For å presentere enkeltfiler som HTML fra XML, anbefaler vi bruk av XSL. Vi har testet ut og bruker det gratis programmet xsltlib på UiO ( for all behandling av XML med XSL. Referanseinstallasjon UiO kan ses på som en referanseinstallasjon for esu. UiO har i dag et publiseringssystem, StudInfo, som presenterer informasjon om studietilbudet i UiOs Web. Noe av informasjonene hentes fra FS. Øvrig informasjon hentes fra XML-filer. Noen av XML-filene redigeres med XML-editoren XMetaL. Andre deler av XML-filene Web-redigeres, dvs direkte via nettleseren. Dataene konverteres og sys sammen via programmer som er utviklet ved UiO. Programmene er i stor grad basert på åpne standarder slik som XSL (inkludert XSLT). I StudInfo blir informasjonen konvertert og splittet opp i mindre filer før den blir presentert på web. Alt dette blir gjort ved bruk av xsltlib. Inngangen til UiOs studieinformasjon kan ses på h ttp:// Eksempelvis er presentasjonen om hvert studieprogram presentert på samme måte ut fra felles maler. Tilsvarende gjelder for emner og mesteparten av den øvrige informasjonen. UiO benytter et egendefinert sett med koder. Deler av kodesettet er overlappende med esu. Eksempelvis er kodene for eksamen og undervisning tilnærmet lik den som er i esu, men UiO bruker norske navn på elementene. Det UiO trenger å gjøre for å omforme informasjon i henhold til esu, er å plukke ut og konvertere deler av den informasjonen som allerede finnes i StudInfo. I praksis vil noe av denne informasjonen være skrevet i FS og andre deler vil være skrevet via XMetaL eller Web-redigeringsgrensesnittet. Konverteringsløsningene utvikles sentral, og de som oppdaterer informasjonen trenger ikke forholde seg til om informasjonen publiseres i UiOs Web og/eller leveres i henhold til esu. En fordel med StudInfo er at all informasjon allerede finnes i XML, og det er enkelt å utvide løsningen med å lage en eksport i henhold til esu. esu , AFS, Dato: Side: 12

15 4. Vedlegg 1. Forklaring til strukturen 2. Oversikt over alle elementer og attributter 3. XML-skjema 4.1 Forklaring til strukturen Her følger en innledende beskrivelse av strukturen i XML-skjemaet (heretter kalt esu). Dette omfatter en beskrivelse av hovedstrukturen, generelle elementer og detaljer for enkelte av elementene. Dette er ikke en komplett beskrivelse av alle elementene i esu. Utfyllende og detaljerte kommentarer finnes i selve esu. ESUen er i henhold til XML-standarden. XML-standarden opererer med begrepene elementer, attributter og kommentarer. Elementer og attributter kan ses på som merkelapper. For enkelhets skyld bruker vi betegnelsen element for både element og attributt, med mindre det er nødvendig å spesifisere begge deler hver for seg. Elementnavn er skrevet på engelsk, og kommentarer og de fleste attributtverdier er skrevet på norsk. Engelske navn på elementene er valgt for å åpne for internasjonalisering av esu. For tilpasninger til norske forhold er kommentarene og de aller fleste attributtverdier skrevet på norsk. Å forandre disse på et senere tidspunkt, vil ikke ha store konsekvenser for esu. I denne beskrivelsen er alle navn på elementer skrevet med <haker> rundt seg. Enkelte elementer har tilleggsinformasjon i form av attributter. Attributtene er skrevet med gåseøyne rundt seg. Noen elementer har fastdefinerte lister over attributter, mens andre har attributtet user-defined der man selv kan velge hvilken attributtverdi som skal legges inn. Noen av elementene har også en kombinasjon av fastdefinerte attributter og user-defined. Bruken av user-defined skal dekke spesielle behov og tilpasninger for de enkelte institusjoner og aktører som skal benytte esu. Noen elementer kan brukes rekursivt; det vil si at et element kan brukes inni seg selv. Dette gir mulighet for bl.a. å beskrive at en institusjon kan ha mange underenheter (flere <unit> inni hverandre). De aller fleste elementer i esu er valgfrie. Dette gir god fleksibilitet i forhold til hvordan esu skal brukes, noe som igjen er avhengig av hvem som skal bruke den. De elementene som er påkrevd, er gjerne identifikatorer (Ider). I vedlagte skisser av esu, er valgfrie elementer stiplede bokser mens påkrevde elementer er hele bokser for elementene. Hovedelementet (rotelementet) i esu er <institution>. I noen tilfeller er det aktuelt å la andre elementer være rotelement. For eksempel kan det være nyttig å kunne levere en liste med <course> uten å måtte pakke informasjonen inn i informasjon om <institution>. En del av elementene er derfor definert som Schema Types. En slik definisjon gir blant annet mulighet for å bruke disse elementene som egne XML-filer. Et eksempel på et slikt element er <course>. Det vil da være mulig å lage valide XML-filer som ikke har <institution>. Schema Types er skissert med gul bakgrunn på vedlagte skisser. Modellen er delt inn i tre hoveddeler, hhv <institution>, <course> og <program>. Disse tre hoveddelene skal kunne beskrive all utdanningsinformasjon. esu , AFS, Dato: Side: 13

16 Et internt referansesystem for esu er basert på at institusjonen selv lager egne IDer på <unit>, <course>, <program> og <dicipline>. I <textblock> er det mulig å sette inn <ID- finnes det elementer som kan brukes til referanser mot de forskjellige ID-ene. Det ref>. Her vil da være opp til dem som skal bruke dataene, hvordan de setter opp et slikt referansesystem. < Generelle elementer> <textblock> er elementet for å sette inn et avsnitt. Inni dette elementet er det mulig å sette inn: <bo ld> for fet skrift < italic> for kursiv skrift <list> som er en liste med attributter bulleted og nummerert. <list> består av uendelig mange <list-item> som igjen kan inneholde de samme elementer som <textblock> <link> er en lenke til en webadresse. Denne består av en <href> som er adressen til hvor det skal lenkes, og <link-name> som er navnet på lenken. Det er kun <href> som er påkrevd, ettersom det i flere tilfeller kan være aktuelt å bruke <href> som <link-name>. < > skal brukes til epostadresser. < ID-ref> er et element som skal kunne brukes dersom man ønsker å lenke til andre elementer som har egen ID. Inni <ID-ref> ligger <course-id-ref>, <program-id-ref>, <diciplin-id-ref>, <unit-id-ref> og <institution-id-ref>. Disse referere til IDer med samme elementnavn uten ref. Her en oversikt over typen <textblock>: <header-and-text> består av uendelig mange <textblock>. I tillegg er det mulig å sette inn en overskrift øverst. <user-defined> og user-defined er et element og et attributt som brukes for informasjon som ikke hører hjemme i de øvrige forhåndsdefinerte kodene i esu. En institusjon kan for eksempel ha behov for å merke informasjonen med egne koder. esu er fleksibel slik at elementet <user-defined> kan settes inn på flere steder i strukturen. <user-defined> har esu , AFS, Dato: Side: 14

17 også et åpent attributt som heter user-defined. Attributtet user-defined finnes også i andre elementer med lister av attributter der vi ser at listene kan være utilstrekkelige, eller elementer der vi ser at det kan være behov en ekstra merkelapp. Dette er et åpent attributt, der institusjonen selv kan bestemme hva verdien skal være. På den måten vil det være mulig å trekke ut en mengde egendefinert elementer. <code> er et element som skal brukes til å angi koder som hovedsakelig er norske. Grunnen til at disse forskjellige kodene legges i samme element som attributtverdier, er for å internasjonalisere esu slik at alle elementnavn er generelle, og kun attributter som er spesielle for Norge. I dokumentasjonen under står det forklart hvilken type kode som skal presenteres på de forskjellige delene av modellen. <person> sine elementer er i hovedsak klassifisert etter IMS, se kapittel om internasjonale standarder. For å kunne klassifisere forskjellige grupper av <person>, er det mulig å selv gi attributt til <person>. Det er lagt inn <unitidref> inni person for mulighet til å referere til en <unit> som <person> hører til. I tillegg er det mulig å legge inn flere referanser og tekst i <textblock>. <person> har mulighet for flere <address>. Elementene <userid> og <name> er påkrevd. <person> har attributtet user-defined for å dekke spesialløsninger. <address> er illustrert til høyre Elementer som er satt inn i tillegg til det som direkte er hentet fra IMS, er <visit-hour> og <link>. I tillegg er det mulig å sette inn <headerand-text> i begynnelsen av elementet. Ingen elementer her påkrevd. <address> har også attributtet user-defined for å dekke spesialløsninger. <Institution> Dette er et rekursivt element. Det betyr at man kan sette inn en <institution> inni en <institution>. På den måten kan en stor institusjon levere all sin informasjon samlet, med uendelig mange underinstitusjoner. De aller fleste vil kunne beskrive sin struktur ved hjelp av <unit>, men for eksempel BI vil ha et behov for en slik rekursiv løsning for <institution>. <institusjon> identifiseres ved <institutionid>. For Norge er dette organisasjonsnummeret fra Brønnøysundregisteret. esu , AFS, Dato: Side: 15

18 <code>: Alternative identifikasjonskoder til <institutionid>. Dette vil her som oftest være SO-koden til institusjonen. I tillegg kan man legge til egne koder, ved å velge userdefined. <institutiontype>: Alternative attributter her er: "universitet", "vitenskapelig-hogskole", "kunsthogskoler, videregaende-fylke, folkehogskole, teknisk-fagskole, hogskoleprivat, hogskole-statlig, videregaende-privat, videregaende-statlig og studieforbud. Dersom ingen av disse passer, så kan man velge user-defined og skrive inn navnet på typen i elementet <institutiontype> <institution-acronym>: Forkortelse for institusjonen, eks UiB. < unit>: Kan brukes for å angi institusjonens indre struktur, f.eks. fakultet, institutt, avdelinger. Dette er et rekursivt element. <unitid> defineres etter organisasjonens egne behov. Den kan for eksempel være en stedkode. <institution-presentation>: Kort beskrivelse av institusjonen og evt. underenheter. Noen kategorier er forhåndsdefinert. I tillegg kan institusjonen legge til egen informasjon i <user- defined>. <Course> Dette er elementet som brukes for emner i høyere utdannelse, fag i videregående, kurs for de som bruker det begrepet (BI). <course> omfatter også kurs som ikke er kompetansegivende. Påkrevde elementer er kun <course-id> og <course-name>. <course-id>: brukes for å angi institusjonens ID for <course>. <code>: her skal det skrives inn kode til SSB (dette er NUS-koden eller andre koder definert av SSB) <level> har følgende attributter: " bachelor", "vgs", "master", "phd", user-defined. Velger man user-defined, kan man legge inn egen type. <credits>: her skal det skrives inn studiepoeng eller timer per år i videregående (Læreplanen bruker både per år og gjennomsnittlig uketimer). <course-presentation>: Her skal den formelle presentasjonen av <course> være. Elementene som er lagt inn her, er basert på elementer som er brukt i våre referanser. <syllabus> har et eget element for LOM objekter <form-of-teaching> kan fylles ut med informasjon om undervisningsform. Dersom formen er nettbasert eller brev kan dette velges som attributter. <teaching-semester> og <exam-sem ester> har begge attributter med følgende verdier: "vaar-og-hoest", hver-vaar", "hver-hoest", "annenhver-vaar", "annenhver-hoest", "user- det ikke er mulig å angi semester med noen defined". Sistnevnt element brukes dersom av de andre valgene. <teaching> beskriver alt som har med undervisningsaktiviteter for <course> å gjøre. Det er mulig å legge inn en del felles informasjon om all undervisning her i <textblock>. <admission-info> her er det mest interessant med av og -påmeldingsfrister. <teaching-activity> kan man sette inn så mange man vil av. I tillegg er dette et rekursivt element. <teaching-activity> har attributtene: feltarbeid, forelesning, fjernundervisning, gruppeundervisning eller elearning. Dersom ingen av disse passer inn, velger man ikke å angi attributter selv i user-defined. <timetable-element> brukes for underaktiviteter av <teaching-activity>, for eksempel gruppeundervisning. <person> kan legges inn på alle nivåer i <teaching>. Dette kan for eksempel være faglærer. esu , AFS, Dato: Side: 16

19 <exam> skulle dekke alle behov for presentasjon av tid og sted for eksamen. Alle hovedfeltene her har muligheten for <textblock>. Dette skal brukes dersom det ikke er tilstrekkelig med kun dato. <exam-structure> innholder alt om eksamensordningen. Det er mulig med uendelig mange <exam-structure> i <exam>. Dette vil det være behov for dersom man har for eksempel 2 alternativer for eksamen: skriftlig eller hjemmeoppgave i tilegg til muntlig. < exam-part> er de forskjellige eksmensdelene. Denne kan man ha uendelig mange av, for eksempel: en muntlig eksamensdel og en skriftlig. <text-block> brukes til å forklare andre detaljer om eksamen. <searchwords> skal brukes til å definere stikkord for søkemotorer, som for eksempel kan legges som metainformasjon i HTML-sider. Før et slikt element skal brukes, må de som skal bruke det lage retningslinjer for hvordan dette elementet skal fylles ut. <Program> <program> skal dekke alle typer samlinger av flere <course>. Det vil i høyere utdannelse hovedsakelig være studieprogram og i den videregående skole være løp. Kun <programname> og <program-id> er påkrevd. <program-id> skal identifisere <program>. Dette er en kode som kun trenger å være unik for institusjonen < duration> bør settes med attributtet aar eller semester her. Elementet godtar kun tall. <admission-info> inneholder en del forskjellige elementer for opptak. Dersom man ikke finner elementer for det som ønskes presentert, er det lagt inn mulighet for <header-and- text>. Ingen elementer er påkrevd. <admission-code> kan man sette inn opp til 2 stk av, ettersom man kan velge attributter for nom eller lokal kode. < program-presentation> er den største samlingen av informasjon. De elementene som er lagt inn her, er elementer som vi i våre undersøkelser har sett at det er ønskelig å trekke ut. Alle elementer her inneholder <header-and-text> ettersom det er store forskjeller fra institusjon til institusjon hvordan det er ønskelig å presentere disse elementene. Det er også mulig å legge inn <header-and-text> for annen informasjon i <programpresentation>. <discipline> er en underenhet av <program>. Dette er et rekursivt element som skal brukes til alle underenheter av <program>. Dette kan være spesialisering eller studieretninger. Denne skal presenteres på nesten samme måte som <program>. En av forskjellene er at man i <discipline-presentation> også kan legge inn <admission-info>, ettersom enkelte slike spesialiseringer har egne opptak. <code> skal her brukes med attributtet so-utdanningsomraadet. Dette er en kode som brukes for opptak via SO. <qualification> beskriver den graden man oppnår. Her angis både vekting man oppnår, <credits>, og kompetanse til yrke, <profession>, eller for videre studier, <studyqualification> / <degree>. Ingen elementer her er påkrevd. <locality> sier noe om geografisk studiested. Det er her lagt inn mulighet for å legge inn <postnumber> og <place>. Det vil da være mulig å lage oversikter basert på < postnumber>. esu , AFS, Dato: Side: 17

20 4.2 Oversikt over alle elementer og attributter Her følger en oversikt over alle elementer og tilhørende attributter. Elementnavn er uthevet og kommentarer fra skjemaet står etterpå. Attributter er listet opp under de elementer som har det. year Årstall building Navn på bygning date YYYY-MM-DD first-time YYYY-MM-DD time-from hh:mm:ss time-to hh:mm:ss room Romnavn, romnr last-time YYYY-MM-DD weekday eks.: mandag adr Address used to deliver physical objects to a person address mulighet for egendefinerte klassifiskasjon med userdefined recommended-prerequisites anbefalte-forkunnskaper textblock visit-address Besøksaddress exam-semester eksamenssemester vaar-og-hoest hver-vaar hver-hoest annenhver-vaar annenhver-hoest annet course-id Denne må være unik for institusjonen. eks. 2MX, AA6210, INF1000 course-name course-admission emne-fag-opptak institution ROTELEMENT supplerende kode som styres av attributter institutiontype her skal det inn flere verdier på attributtene universitet vitenskapelig-hogskole kunsthogskoler videregaende-fylke folkehogskole teknisk-fagskole hogskole-privat esu , AFS, Dato: Side: 18

21 hogskole-statlig videregaende-privat videregaende-statlig studieforbund institution-acronym Forkortelse for institusjonen institution-name gjelder som løp eller deler av løp i vgs. (GK, VK1 eller VK2) course emne, kurs, fag person mulighet for egendefinerte klassifiskasjon med userdefined epostaddress fax nummer til fax bold Uthevet tekst formal-prerequisites formelle-forkunnskapskrav closing-dates avmeldingsfrister - YYYY-MM-DD objectives hva-laerer-du, og mål content innhold transfer innpassing contact-infomation kontaktinformasjon program-ingress kort-om-programmet italic Uthevet tekst i kursiv country link-name Navn på lenke i URL list bulleted nummerert list-item structure-accomplishment oppbygging-gjennomforing header POBox Postoffice Box postnumber-place place program-id unik for institusjonen ID-ref Referanse til program, fordypning, emne-fag esu , AFS, Dato: Side: 19

22 program-id-ref discipline-id-ref course-id-ref programname programnavn program-admission programopptak gsk-so krav-master ingen student-places Antall studieplasser angitt i tall eller tekst credits Studiepoeng angitt i tal, eller vgs- timer per år uketimer studiepoeng program studieprogram eller som løp eller deler av løp i vgs. (GK, VK1 eller VK2) discipline-id fordypningskode telephone attributtes: mobil, home and office mobile office home form-of-teaching undervisningsform:nettbasert, grupper, forelesnigner, seminar etc velg attributter for spesialformer. nettbasert brev teaching-semester undervisningssemester. attributter vaar-og-hoest hver-vaar hver-hoest annenhver-vaar annenhver-hoest annet teaching-language undervisningsspraak norsk engelsk engelsk-ved-behov annet study-abroad utenlandsopphold form-of-assessment forklaring av hvordan studentene vuderes href URL, \... link webaddress header-and-text overskrift-avsnitt esu , AFS, Dato: Side: 20

23 price materialavgifer, semester/års- avgifter, andre atgifter teaching-activity undervisningsaktivitet, typeaatributter feltarbeid forelesning fjernundervisning gruppeundervisning elearning teaching-group-id undervisningsparti-id teaching-place undervisningssted date-from YYYY-MM-DD date-to YYYY-MM-DD exam eksamen ordinaer kontinuasjon utsatt exam-part eksamensdel exam-part-name eksamensdelnavn exam-form eksmensform date-start DD.MM.ÅÅ date-end DD.MM.ÅÅ skriftlig muntlig annet exam-structure eksamensordning exam-place eksamenssted registration-dates oppmeldingsfrist announcement Kunngjøring av eksamensresultater person Definer selv hvilken rolle personen har i role timetable-element timeplanelement exam-closing-dates dato og forklaring til eksamenstrekkfrist(er) searchwords Dette må være en egen aktivitet hvor flere er med på å bestemme hvilke oppslagsord (med synonymer etc) som er relevante. searchword search-synonyqualification Diploma supplement definerer det som "diplomas, degrees, certificates etc." Beskriver både studieprogram og kvalifikasjon. esu , AFS, Dato: Side: 21

24 qualification-name Fullt navn på kvalifikasjonen institution-id Ornanisasjonsnummer fra Brønnøysundregisteret level Attributter for nivå på leve bachelor vgs master phd course-presentation learning-target kort definisjon av hva kurset skal lære deg target-group maalgruppe, hvem du henvender deg til. farmasøyter, snekkere...etc. overlap faglig overlapp locality studiested, Geografisk sted, som kan brukes av søkemotorer. "avsnitt" kan f.eks inneholde Bali bokmaal nynorsk engelsk ExtAdd Extra address data street Street address locality example of locality is city pcode postal code vist-hour userid name given fornavn family etternavn title role personrolle. Her kan man legge inn foreleser, hovedansvarlig for programmet, gruppelærer, ClassFronter-ansvarlig etc. discipline eks. studieretning, spesialisering discipline-name admission-info krav til opptak, inpassning, opptaksprøver++ commencement studiestart appearance-place oppmotested oppmotested esu , AFS, Dato: Side: 22

25 appearance-date-time last-reg-date siste påmeldingsfrist grounding forkunnskapskrav universal-adjustment universell-tilrettelegging, tekst om generelle tilpassninger til funksjonshemmede, utenlendinger etc. unit organisasjonsenheter. definerer institusjonens struktur unit-id organisasjonsenhetsid, denne defineres etter organisasjonens behov unit-acronym organisasjonsenhetsacronym, forkortelse for enhet unit-name organisasjonsenhetsnavn duration varighet. velg attributter for type. timer dager uker maaneder aar terminer semester welfare velferd regulations reglementer og lover som gjelder spesielt for dette programmet institution-presentation her må det være en konkret spesifikasjon av hva som skal være innholdet. Anbefale å legge inn URLer ting informasjon på web welfare velferd semesterprice semesteravgift til samskipnader user-defined egendefinert element for spesiell informasjon. definer selv attributter code diverse koder course=nus. program=utd.omrade, inst.=so Finenr du ikke koden, velg user-defined og skriv inn ssb so-utdanningsomraadet so vigo admission-code opptakskode. Muli gå velge nom eller lokal som attributt nom lokal unitid-ref referanse til unit sin ID esu , AFS, Dato: Side: 23

26 degree akademisk-grad bachelor master phd hogskolekandidat utgaatte-koder study-qualification studiekompetanse, Gjelder for videregående opplæring. Kan også brukes i høyere utdanning. profession yrkeskompetanse, Legg inn fritekst teaching termin presentation teaching-description syllabus her kan det skrives noe om læremateriell, pensum for emne-kurset, litteratur etc. E-learning-objects Referanse til LOM-objekt Bruk Norsk applikasjonsprofil av LOM esu , AFS, Dato: Side: 24