Vad är en teknisk standard?
Tekniska standarder behövs för att olika tjänster och system ska kunna fungera tillsammans. Ett exempel på varför det behövs standarder är e-post. När e-posten först kom och användningen började sprida sig så var det inte alls självklart att använda standardiserade protokoll. Protokollet för e-post är det språk som e-postservrar ska prata för att skicka och ta emot e-post mellan varandra. Det gick därför ofta bara att skicka e-post inom det egna e-postsystemet och påpekade man att standarder var en bra sak möttes man ibland av kommentarer som, ”varför skulle vi vilja skicka e-post utanför vår organisation? Vi använder det bara internt”. Skolan var verkligen inget undantag från detta. E-post är därför ett bra exempel för att förstå vad standarder är och varför de behövs. Exemplet är givetvis en förenkling, men som princip fungerar det.
Ofta delas standarder in i två grupper. Dels så kallade de jure standarder som är standarder som är fastslagna av en ackrediterad standardiseringsorganisation, exempelvis ISO som kanske är den mest välkända standardiseringsorgansiationen. Dels så kallade de facto standarder, som avser teknik som blivit ”standard” på grund av sin spridning, men som egentligen inte är standarder per definition. Ett exempel på en sådan de facto standard är Microsoft Word och .doc-formatet för ordbehandling. Ofta misstas dessa för att vara standarder.
En standard fungerar sällan isolerat, utan för det ska fungera med standarder krävs flera ”lager” av standarder och det som ofta standardiseras är protokoll och dataformat. Dataformat beskriver hur information/data ska vara strukturerad och uttryckt (semantik) för att kunna tolkas och användas av andra system. Grovt kan dessa lager beskrivas i två huvudlager av generella tekniska standarder (i flera lager), till exempel standarder för nätverk (TCP/IP), internet och webb-standarder, som http (webbprotokollet) och html (data-formatet) och det första lagret och domänspecifika standarder, för exempelvis lärande och utbildning, som denna text handlar, om i det andra lagret. Alla dessa lager behövs för att ett system ska fungera som tänkt. Vissa standarder är mer eller mindre självklara, medan det är viktigt att tänka på och kräva användningen av andra standarder, inte minst domänspecifika sådana.
Standarder för lärande och utbildning
Utvecklingen av tekniska standarder för lärande har pågått under många år och det finns en rad olika standarder för olika användningsområden som är bra för olika saker och det gäller att ta hänsyn till detta då olika standarder ger olika bra förutsättningar för olika pedagogiska ansatser. Några av de vanligaste beskrivs kortfattat i denna text.
Ofta kommer standarder och specifikationer för lärande paketerade i mer eller mindre heltäckande paket. De två mest spridda ”standardpaketen” kommer från en organisation som heter IMS Global Learning Consortium (IMS GLC)[1] och en organisation som heter ADL[2], som står bakom SCORM Paketet[3]. Parallellt sker standardiseringsarbete i en rad andra organisationer, såsom ISO (internationellt)[4], CEN[5] (EU) och SIS[6] (Sverige). Det är dock inte nödvändigt att använda hela paketet, utan många gånger är det de enskilda specifikationerna (standarderna) som är mest intressanta. Ofta görs även lokala anpassningar, så kallade ”applikationsprofiler” av dessa för att passa specifika behov i ett land eller inom en viss organisation. Ett exempel på en sådan applikationsprofil är den svenska metadatastandarden för att beskriva digitala lärresurser som fastställts av SIS.
Några av de mest använda standarderna inom utbildning är standarder för metadata, som behövs för att beskriva saker på ett enhetligt sätt, standarder för att rapportera resultat och kommunicera mellan olika system och mellan system och digitalt innehåll (t.ex. ett läromedel) och standarder för att hantera elevinformation och inloggning.
Standarder för metadata
Metadata är sannolikt det område som det arbetats längst inom både i Sverige och internationellt. Det finns flera olika standarder för metadata för utbildning och dessa relaterar på olika sätt till andra generella standarder för metadata. Metadata behövs för att beskriva saker på ett enhetligt sätt så att beskrivningen ska kunna användas av både människor och system. Ett exempel på metadata som de flesta brukar känna till är bibliotekets katalog som består av metadata om böcker. Ett annat exempel på metadata är tjänsten studera.nu[7] som bygger på metadata om kurser och utbildningar. Det vanligaste sammanhanget där metadata diskuteras är för att beskriva digitala lärresurser och digitalt innehåll. Metadata består av två delar. Dels en standard (schema) för vilka fält, dataformat och struktur en beskrivning ska ha och dels (i bästa fall) en standard för vad som ska stoppas i dessa fält i form av vokabulärer och taxonomier som beskriver ord och dess semantiska betydelse i ett visst sammanhang. Tyvärr saknas det senare ofta, vilket skapar stora problem när beskrivningar från flera olika källor ska användas tillsammans.
Under 1990-talet och första halvan av 2000-talet var den dominerande metadatastandarden för utbildningsinnehåll Learning Object Metadata (LOM)[8]. Denna används av både IMS GLC och ADL SCORM som bas för deras metadata och det har även tagits fram en rad nationella applikationsprofiler av LOM, däribland en svensk (SWE-LOM). LOM är dock föråldrad och anses inte hålla måttet och uppfylla de krav som man bör kunna ställa på en modern metadatastandard. Under 2000-talet har en arbetsgrupp inom ISO (SC36)[9] tagit fram en alternativ standard som heter Metadata for Learning Resources (MLR)[10]. MLR uppfyller bättre kraven på en modern hantering av metadata och är bakåtkompatibel med LOM. År 2012 blev MLR svensk standard i och med att en svensk applikationsprofil togs fram och fastställdes av SIS TK450.[11] Parallellt har ett annat metadatainitiativ, Learning Resource Metadata Initiative (LRMI),[12] vuxit fram och blivit en del av schema.org som stöds och indexeras av Google, Bing och andra stora leverantörer av söktjänster. Det finns ingen motsättning mellan MLR och LRMI, utan de kan snarare ses som komplement till varandra och LRMI beskrivs ibland som en applikationsprofil av MLR.
Standarder för att rapportera resultat
När det gäller standarder för att rapportera resultat och kommunicera mellan olika system och mellan system och digitalt innehåll är bilden något mindre komplex. Där har länge SCORM fungerat som de facto standard, vilket ibland varit lite problematiskt då SCORM framförallt är avsedd för så kallad ”self contained learning” och därmed inte är så väl lämpad för den typ av kunskap som ofta är målet i skolan. De senaste tio åren har bilden dock förändrats och två alternativ har utkristalliserats. Dels är det IMS GLC och deras Learning Tools Interoperability[13], som ingår i ett större standardpaket från IMS som kallas IMS Common Cartridge[14] och som ibland ses som ett alternativ till SCORM, dels är det ThinCan och xAPI[15] som används av SCORM och kan ses som en delmängd av kommande versioner.
Förenklat så är IMS LTI en enklare specifikation med ett smalare fokus, medan ThinCan är mer omfattande och löser fler av de problem som finns i kommunikationen mellan system, och mellan system och utbildningsinnehåll. Som leverantör kan man dock vara tvungen att stödja flera liknande standarder för att täcka alla behov.
Standarder för elevinformation och inloggning
För elevinformation är standardsituationen ganska spretig och det finns olika specifikationer för olika ändamål, som exempel den svenska Elevinfo -standarden[16], som från början togs fram inom ramen för SIS TK450 för att hantera informationsöverföring vid gymnasieantagning. Det finns även mer generella specifikationer från bland annat IMS GLC, dock ingen tydlig sådan och detta är ett område där det finns mycket kvar att göra och där det krävs en hel del både nationellt och internationellt arbete.
När det gäller standarder för identitets-federation och Single Sign-On (SSO) så är bilden ganska tydlig. Här behövs ingen domän-specifik standard, utan det går att förlita sig på generella tekniska standarder, till exempel SAML2 som används av den svenska nationella tjänsten Skolfederation[17], tillsammans med överenskommelser om vilka s.k. användarattribut som ska tillhandahållas av skolhuvudmannen för att därmed kunna användas av leverantörer och andra för att hantera inloggning. På sätt och vis kan Skolfederationen ändå sägas vara en standard då den fastslagits av SIS och det finns en standard för de attribut som ska användas. Just Skolfederationen är ett bra exempel på en infrastrukturkomponent på nationell nivå som löser ett av de största problemen som finns i gränssnittet mellan systemleverantörer och skolan – att hantera användaridentiteter och gemensam inloggning. Rätt använd kan Skolfederationen spara stora pengar åt både skolan och systemleverantörer och det borde därför vara en självklarhet för alla använda Skolfederationen!
[3] https://en.wikipedia.org/wiki/Sharable_Content_Object_Reference_Model
[5] https://www.cen.eu/Pages/default.aspx
[7] https://studera.nu/
[8] https://en.wikipedia.org/wiki/Learning_object_metadata
[9] https://www.iso.org/committee/45392.html
[10] https://en.wikipedia.org/wiki/ISO/IEC_19788
[11] Swedish Standards Institute. https://www.sis.se/informationsteknik-kontorsutrustning/it-tillämpningar/sis-tk-450
[12] https://lrmi.dublincore.net
[13] https://www.imsglobal.org/activity/learning-tools-interoperability
[14] https://www.imsglobal.org/activity/common-cartridge
[16] https://www.sis.se/informationsteknik-kontorsutrustning/allmänt/ss-107012016