Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


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 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, 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. kurs/inf111/

3 Kai A. Olsen, 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, 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: Tid: 1015:1200 Nytt rom: Lille Aud. HIB. Endring av rom for forelesning. Fag: INF111 Dato: Tid: 1015:1200 Nytt rom: Lille Aud. HIB.

5 Kai A. Olsen, 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, 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, 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, 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, Bestilling over epost ”For bestilling av bøker send en epost til 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, 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, Script for kontroll Greit å lage slike script. Vi kan bruke Javascript (som her), PhP eller Visual Basic.

12 Kai A. Olsen, 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, 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, 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, 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, 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, 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, Case: Norli/Libris


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

Liknende presentasjoner


Annonser fra Google