03.01.13 1 Kap. 6 – Cases of Formalization Level How Information Technology Is Conquering the World: Workplace, Private Life, and Society Professor Kai.

Presentasjon om: "03.01.13 1 Kap. 6 – Cases of Formalization Level How Information Technology Is Conquering the World: Workplace, Private Life, and Society Professor Kai."— Utskrift av presentasjonen:

1 03.01.13 1 Kap. 6 – Cases of Formalization Level How Information Technology Is Conquering the World: Workplace, Private Life, and Society Professor Kai A. Olsen, Universitetet i Bergen og Høgskolen i Molde

2 Kai A. Olsen, 22.08.2015 2 ID Engang var et enkelt navn, gjerne fornavn, eventuelt navn + sted/yrke (Per i Åsen, John Baker), tilstrekkelig. I dag trenger vi et personnummer: Entydig identifikator Kan ”frigi” navn Andre entydige identifikatorer: Brukernavn (unikt i et system) E-postadresse (i verden) URL - Web adresse (i verden) Organisasjonsnummer (i Norge) Bilnummer (innen et land) EAN - varenummer Med slike identifikatorer løfter vi formaliseringsnivået. Det gir en betydelig forenkling ved framhenting, kopling av data, m.m. http://kursinfo.himolde.no/in- kurs/inf111/ kai.olsen@himolde.no

3 Kai A. Olsen, 22.08.2015 3 ID i en dataverden Tradisjonelt har vært beregnet på å leses av mennesker. I en IT verden trenger vi: Pass med magnetstripe ID kort med chip Strekkoder på varer, pasienter, containere… RFID brikker i alt fra plastkort til fiskekasser Køfri-brikker Kanskje også elektroniske avlesbare bilnummer

4 Kai A. Olsen, 22.08.2015 4 Høynivå: Formalisert e-post Idé: Istedenfor at en e-post er et ”blankt ark” kan en formalisere dette til høyere nivåer, f.eks. formularer for: møter (innkalling, flytting i tid/sted, avlysning) F.eks. kunne alle endringer i forelesninger gis på slike formularer Fordelen er at data da kan brukes direkte i mange systemer (personlige kalendere, romdisponering…) Men hvorfor har ikke denne ideen slått gjennom? Endring av rom for forelesning. Fag: INF111 Dato: 01.01.13 Tid: 1015:1200 Nytt rom: Lille Aud. HIB. Endring av rom for forelesning. Fag: INF111 Dato: 01.01.13 Tid: 1015:1200 Nytt rom: Lille Aud. HIB.

5 Kai A. Olsen, 22.08.2015 5 Høynivå: Kalender (Outlook) Mer formalisert enn e-post SAS kan legge inn min bestillingsreferanse rett i kalenderen Andre kan se min kalender Andre kan legge inn poster i min kalender. Kalender er formalisert godt nok til å «automatiseres» på høyt nivå. Hvorfor?

6 Kai A. Olsen, 22.08.2015 6 Lavnivå:HTML – standard WWW format Den grunnleggende ideen bak www er at alt er åpent, kun formalisert i HTML format Fordelene: Alt er tilgjengelig Vi kan søke i alt (Google ser dette) Enkelt Kan forstås av alle browsere Ulempen: Formalisering på lavt nivå (tegn og layout).

7 Kai A. Olsen, 22.08.2015 7 Høynivå: Databaser på nett I dag finnes det mange databaser med høyere formaliseringsnivå (billettbestilling, musikk, bank…) Noen av disse er lukket med passord, noen sees av søkemotorene andre ikke. Fordelen med databasene er at vi har en høyere formalisering og kan da gjøre mer avanserte operasjoner. Men databasene har egne formater og vil som regel ikke bli sett av søkemotorene.

8 Kai A. Olsen, 22.08.2015 8 Case - bokbestilling Vi har en nettside der vi selger bøker og har definert forskjellige typer av bestillingsmuligheter: 1. E-post 2. Web skjema 2.1 Data på epost 2.2 Data på XML-format -> Web server 3. API (Application programming interface) – direkte programinngang.

9 Kai A. Olsen, 22.08.2015 9 1. Bestilling over epost ”For bestilling av bøker send en epost til post@forlag.no”post@forlag.no Enkelt, kunden definerer formatet Fleksibelt (”jeg ser at frakt er inkludert i Norge, men hva vil det koste å få boken til Danmark?”) Må behandles manuelt (sending, betaling, sjekke betaling, statistikk) Kunden kan glemme å oppgi sentrale data Men vi har en toveis kanal (kan sende ”reply”)

10 Kai A. Olsen, 22.08.2015 10 2. Web-skjema Vi kan kontrollere at alle data er med Sendes som e-post Kan sendes uavhengig av om kunden har tilgang til sin e-post konto Vi har en grei ”reply” mulighet Men vi krever at kunden bruker vårt format (det kan medføre problemer)

11 Kai A. Olsen, 22.08.2015 11 Script for kontroll Greit å lage slike script. Vi kan bruke Javascript (som her), PhP eller Visual Basic.

12 Kai A. Olsen, 22.08.2015 12 2.1 Data på e-post fra skjemaet Enkelt, trenger kun en mottaksadresse for e-post Fleksibelt Vil stort sett behandles manuelt (sending, betaling, sjekke betaling, statistikk) Noe kan automatiseres (siden formatet er fast er det greit å plukke ut data automatisk)

13 Kai A. Olsen, 22.08.2015 13 2.2 Formalisert dataoverføring (XML) Kan mottas av en server. Mulighet for fullautomatisert behandling (men krever infrastruktur som automatisk pakking av bøker og adressering) Mindre fleksibelt? Jan Erik Hansen Skjongvika 30A Skibok for Romsdal Jan Erik Hansen Skjongvika 30A Skibok for Romsdal

14 Kai A. Olsen, 22.08.2015 14 3. API løsningen Her vil bestillingene gå direkte mellom kundens og forlagets datasystem. Kunden vil da i praksis være en bokhandler eller bokhandelkjede. Her får vi nye muligheter: Kundens system kan få fram tilgjengelighet, priser, leveringsbetingelser automatisk. Kundens system kan generere bestillinger automatisk ut fra salg Bestillingen kan gå direkte inn i forlagets system, og å gi direkte grunnlag for utsending og fakturering. I dag vil en ofte bruke XML format på disse meldingene.

15 Kai A. Olsen, 22.08.2015 15 Case: Bestillinger som e-post (fra ARK) Forlaget får automatisk genererte bestillinger fra ARK-kjeden (sendes på e-post men er generert ut fra en bestilling i ARK’s system, store forlag får bestillingen via API) Fordelen er at bestillingene alltid inneholder de data som trengs Og at dette kommer som e-post (som alle kan motta) Ulempen er at en mangler mulighet for å kommunisere med de som har lagt inn bestillingen

16 Kai A. Olsen, 22.08.2015 16 Nye muligheter Kanskje forlaget skulle ha direkte innsyn i salget av sine bøker i bokhandelen. Da kunne en sende bøker etter behov. Kanskje betaling kunne foretas pr bok når denne ble solgt? Da blir bokhandlerne utstillings pg salgslokaler for forlagene (en helt ny modell) Mindre risiko for bokhandlerne, kanskje også mindre risiko for forlagene?

17 Kai A. Olsen, 22.08.2015 17 Konklusjon Mange muligheter, også når det gjelder nye forretningsmodeller Alle har sine fordeler og ulemper Vær forsiktig med formaliserte løsninger i uformaliserte omgivelser, f.eks: Kontakt bokhandelkjede-forlag kan formaliseres Men neppe kontakten mellom vanlig bokkjøper og forlaget. Vanlig e-post eller et Web-skjema (bedre) er nok det vi kan bruke her.

18 Kai A. Olsen, 22.08.2015 18 Case: Norli/Libris