Semantisk integrasjon

1,230 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Semantisk integrasjon

  1. 1. 1 Semantisk integrasjon og arkitektur Ut av siloene, 2010-11-17 Lars Marius Garshol
  2. 2. 2 Bakgrunn for presentasjonen • "A new approach to semantic integration" – publisert i Proceedings of TMRA 2010 http://tmra.de/2010/program http://www.garshol.priv.no/download/text/semantic-integration.pdf
  3. 3. 3 Agenda • Semantisk teknologi – rask innføring • Arkitektur – kort om utfordringer • Hva semantisk teknologi kan gi – et forslag • Oppsummering
  4. 4. 4 En kort innføring Semantisk teknologi
  5. 5. 5 Hva er semantisk teknologi? • Semantikk – studiet av betydning (og særlig ordenes betydning) • Semantisk teknologi – gjør det mulig å beskrive dataenes betydning – vanligvis ligger betydning kun i applikasjonskode og i menneskelig tolkning John Searle, "The Chinese Room"
  6. 6. 6 Ikke-semantiske data • Hva er dette? • Hvor mange ting er det her? • Hva er ting og hva er egenskaper?
  7. 7. 7 Skjemaet • Det er vanlig å hevde at semantikken ligger i skjemaet • Her ser vi tydelig hvor lite semantikk det er snakk om • XML er ikke en semantisk teknologi!
  8. 8. 8 Eksempel fra emnekart • Skiller ting/egenskaper • Relasjoner er lette å se • Vi vet navnene på alle ting • Kan spørre etter alle 人 og automatisk få med subtypene • Den egentlige betydningen forblir uklar源氏源氏 男性男性 人人 女性女性 夕顔 との 出会 い 夕顔 との 出会 い 夕顔夕顔 出来 事 出来 事 参加 参加 Typer subtypesubtype type-instance type-instance
  9. 9. 9 Logikk #1 • Bussjåfører er personer som kjører busser • Sjåfører er personer som kjører kjøretøy • Altså er bussjåfører sjåfører! ex:BusDriver owl:intersectionOf owl:restriction ex:Bus owl:on ex:drives owl:someValuesFrom ex:Person ex:Driver owl:intersectionOf owl:restriction owl:someValuesFrom ex:Vehicle owl:on owl:subClassOf http://owl.man.ac.uk/2003/why/latest/ owl:subClassOf
  10. 10. 10 ex2:Osloex2:Oslo Logikk #2 “no” ex1:contains ex1:contains ex1:isoCode ex2:borders owl:InverseFunctionalProperty owl:sameAs owl:TransitiveProperty ex1:contains owl:SymmetricProperty ex2:borders ex1:Europeex1:Europe ex1:Norwayex1:Norway ex2:Norgeex2:Norge ex2:Sverigeex2:Sverige
  11. 11. 11 Semantisk teknologi • Langt rikere modellering enn hva som er mulig med tradisjonell teknologi – vilkårlig kompleks beskrivelse av klasser og attributter • Gjenbruk av vokabular på tvers av løsninger • Automatisk fletting av informasjon • Mulighet for å modellere noe av informasjonens betydning
  12. 12. 12 Semantiske teknologier • Emnekart – ISO-standard, mye brukt i portaler – hovedvekt på "menneskelig" semantikk • RDF – W3C-standard, grunnlag for "semantic web" – tung bruk av logikk • Andre alternativer – enkelte andre teknologier blir av noen omtalt som semantiske; hvor riktig dette er er diskutabelt – noen eldre AI-standarder finnes, men er uinteressante – det finnes også proprietære løsninger – generelt er det de to teknologiene over som er viktige
  13. 13. 13 Viktigheten av standarder • En standard skal ha flere implementasjoner – slik at man kan velge mellom ulike løsninger • Implementasjonene skal være interoperable – dvs, de skal følge standarden – helst skal det finnes test-suiter som bekrefter dette • En standard skal ha et aktivt miljø – konferanser, blogger, bøker, kurs osv om standarden – brukes aktivt av forskjellige organisasjoner og firmaer • Én standard er ikke nok – det trengs som regel en hel familie av relaterte standarder
  14. 14. 14 Arkitekturutfordringer
  15. 15. 15 Virksomhetsarkitektur • Virksomhetsarkitektur er ikke det samme som systemarkitektur • Det som er et godt valg for et enkeltsystem er ikke nødvendigvis et godt valg for virksomheten over tid • Å sikre riktige valg krever sentral styring og føringer – dette skaper gjerne friksjon og forsinkelser
  16. 16. 16 Organisasjoner endres hele tiden • Conway's lov, 1968: – strukturen på IT-systemene speiler organisasjonens struktur • Reorganiseringer er en "fact of life" – skjer hele tiden – gjerne påtvunget av "høyere makter" • Reorganisering av organisasjonen krever reorganisering av IT-systemene – slik er det, og slik vil det være – derfor må IT-systemene bygges slik at de kan tilpasse seg organisasjoner i endring
  17. 17. 17 "Computer says no" • Bankene har ikke kontroll på kundedata – duplisert mange steder – pga dårlig arkitektur + restrukturering • Dette gjør dem mye mer tungrodde – så mye at kundene merker det • Nå kommer nystartede banker – "få konto, sjekkhefte, kredittkort osv på 15 minutter!" http://www.economist.com/node/16646044
  18. 18. 18 Lego! • Målet er ikke bare en arkitektur som er korrekt for dagens behov • Målet er en arkitektur som tåler endring – for endringene kommer • Hvordan kan semantisk teknologi hjelpe?
  19. 19. 19 Nye arkitekturmuligheter Semantisk integrasjon
  20. 20. 20 Skritt for skritt 1. Referansemodell1. Referansemodell 2. Master- data 2. Master- data 3. Referanse- data 3. Referanse- data 4. Generiske tjenester 4. Generiske tjenester 6. Søk6. Søk 7. Semantiske formater 7. Semantiske formater 5. Tilgangs- kontroll 5. Tilgangs- kontroll
  21. 21. 21 Kartlegging av systemer • Første skritt er å lage et semantisk kart over IT- landskapet – hvilke IT-systemer finnes? – hvilke entiteter har de? – hvilke egenskaper har disse? – hvilke web services finnes? – hvilken input/output produserer disse? AppApp EntitetEntitet EgenskapEgenskap TjenesteTjeneste FormatFormat Trinn #1
  22. 22. 22 Nytteverdi av kartet • Levende oversikt over systemer og tjeneste – navigering/søk/visualisering, – koble til relevant dokumentasjon, der den finnes, – langt bedre enn Powerpoint/Word-dokumentasjon • Alt dette er mulig fordi kartet er strukturert – dvs fordi det er en skikkelig semantisk modell • Det er ikke nødvendig å lage eller kjøpe programvare – alt kan gjøres med eksisterende open source- komponenter Trinn #1
  23. 23. 23 Problemer med kartet • Det er ingen kobling mellom systemene – man kan se at 7 systemer har begrepet "SAK" – men hva så? • Det som trengs er en kobling på tvers – man må kunne se i hvilken grad de 7 begrepene stemmer overens – kanskje finnes tilsvarende begreper i andre systemer under andre navn? Trinn #1
  24. 24. 24 Bygg en referansemodell! • Her modelleres sentrale begreper – entiteter og deres egenskaper – typehierarki for begge – helt uavhengig av system, men slik organisasjonen forstår begrepene • Dette er ikke en kanonisk datamodell – dette er ikke et format – ingen systemer tvinges til å faktisk bruke modellen – man kan bruke entiteter/felter som (foreløbig) ikke finnes i modellen Trinn #1
  25. 25. 25 Hva er samboerskap? • Lov om individuell pensjonsordning – LOV-2008-06-27-62, § 3-7 • Med samboer forstås her a) person som kunden har felles bolig og felles barn med, b) person som kunden lever sammen med i ekteskaps- eller partnerskapslignende forhold når det godtgjøres at forholdet har bestått uavbrutt i de siste fem år før kundens død, og det ikke forelå forhold som ville hindre at lovlig ekteskap eller registrert partnerskap ble inngått. • Forskrift om innhenting av opplysninger – FOR-2005-07-08-826, punkt 1 • samboere: personer som lever sammen og har felles barn. • Lov om vergemål – LOV-2010-03-26-9, § 2 • Med samboere menes i denne loven to personer som bor sammen i et ekteskapslignende forhold. • ... Trinn #1
  26. 26. 26 Modellering Trinn #1 SamboerskapSamboerskap Samboerskap PENSJON Samboerskap PENSJON Samboerskap INNH Samboerskap INNH Samboerskap VERGE Samboerskap VERGE Samboerskap XXX Samboerskap XXX Samboerskap YYY Samboerskap YYY
  27. 27. 27 Egenskaper også Trinn #1 SamboerskapSamboerskap PersonPerson samboer 1 samboer 2startdato sluttdato ...
  28. 28. 28 Knytt systemskjemaene sammen App #1App #1 App #2App #2 App #3App #3 SAMBOSAMBO SAMBOERESAMBOERE BPG_COHABBPG_COHAB Trinn #1 SamboerskapSamboerskap Samboerskap PENSJON Samboerskap PENSJON Samboerskap INNH Samboerskap INNH Samboerskap VERGE Samboerskap VERGE Samboerskap XXX Samboerskap XXX Samboerskap YYY Samboerskap YYY
  29. 29. 29 Grader av samsvar • Perfekt samsvar – ganske vanlig, men vil langtfra forekomme i alle tilfeller • Spesialisering – dvs: B er en slags A, men A omfatter mer enn B gjør • Overlapper med – noen A og B samvarer perfekt; andre gjør det ikke • Ligner på – A og B er relatert, men sammenhengen er uklar AA BB Trinn #1
  30. 30. 30 Anvendelser • Vi beskriver for å forstå – og vi vil forstå for å kunne forbedre • Analyse av arkitekturen – utgangspunkt for omstrukturering – opprydning i masterdata – osv • Oppslagsverk – brukes f.eks ved konvertering – ved feilretting/vedlikehold – avlaster heltene – osv Trinn #1
  31. 31. 31 Fra beslutninger til tjenester • Så langt kun dokumentasjon for mennesker – det er nyttig på en lang rekke måter – men det er bare begynnelsen • Oversikten er strukturert – derfor kan vi bruke den til å bygge nye og mer fleksible tjenester Trinn #1
  32. 32. 32 Kontroll på masterdata • Her må man velge ut systemene som skal ha kontroll på hver type data – der det er mulig å sentralisere dette • Andre systemer som trenger dataene må gjøres om til klienter av master – dette må gjøres gradvis • Vi trenger også en protokoll for å hente data Trinn #2
  33. 33. 33 En tjenestemegler • En tjeneste som kun ruter forespørsler • Sitter oppå ESB-en, som tar seg av transport – evt flere ESB-er • Bruker kunnskapen om data og tjenester • Løser opp koblingen mellom klienter og tjenere • Gjør arkitekturen langt mer fleksibel Broker Referanse- modell Referanse- modell ESBESB Trinn #2
  34. 34. 34 Kontroll på masterdata • Étt system må være master for én entitetstype • Da må andre systemer hente dataene derfra • Gjør det mulig å gradvis migrere • Master kan endres uten at klientene er klar over det Broker App #1App #1 App #2App #2 App #3App #3 App #4App #4 Sync-forespørsel: entitet + tidspunkt Referanse- modell Referanse- modell Oppslag Atom (SDshare) Trinn #2
  35. 35. 35 Samle referansedata • De fleste systemer deler en god del temmelig statiske lister – oversikt over land, norske fylker, ... • Det er ingen mening i å vedlikeholde dette i duplikat i mange forskjellige systemer – slike lister trenger også felles identifikatorer på tvers av virksomheten • Denne informasjonen kan like godt legges i referansemodellen – og hentes derfra av systemer som trenger den Trinn #3
  36. 36. 36 Generisk oppslagstjeneste • Virker ikke "ut av boksen" • Må settes opp slik at alle får svar • Forutsetter at data om X finnes på ett sted • Mulig fordi dette er kontrollert miljøBroker App #1App #1 App #2App #2 App #3App #3 App #4App #4 Tjeneste #1 Tjeneste #2 Tjeneste #3 Gi meg entitet av type X, med ID 341212! Hvem har data om X? Hvem har data om X? Trinn #4
  37. 37. 37 Generisk oversettertjeneste • Av og til ønsker klienten svar på format Y, mens leverandøren bare støtter X – megleren kan finne tjenesten som konverterer, og – sørge for at konverteringen blir gjort automatisk X->Y Y->Z X->Z Y->X Z->Y Z->X Broker Trinn #4
  38. 38. 38 Litt science fiction • Vi har – innholdet i XML-formatene X og Y beskrevet og – koblet til referansemodellen • I noen tilfeller er det da mulig å generere en oversetter automatisk – gjorde en prototyp i 2004 – fungerer nok ikke generelt, men noen ganger går det Trinn #4
  39. 39. 39 Kontroll på infrastrukturen • Hvis vi registrerer konsumentene i modellen får vi bedre kontroll • Det blir mulig å spørre hvem som bruker hvilke data i hvilke formater – kan besvare spørsmål som: "er det trygt å ta ned denne tjenesten?" "trenger vi dette formatet?" osv Trinn #4
  40. 40. 40 Tilgangskontroll • Reglene for dette er som regel – ikke dokumentert skikkelig noe sted, – bakt inn i kode en lang rekke steder • Dette kan også dokumenteres i referansemodellen – koble brukergrupper til hva de har tilgang til – ikke noe behov for å representere enkeltbrukere • Informasjon om tilgang hentes via web-service Trinn #5
  41. 41. 41 Generisk søk med SPARQL • På litt sikt kan man tenke seg mer avansert oppslag – basert på spørrespråket SPARQL – gjør mer enn å bare slå opp på ID – istedet kan man gjøre spørringer "inn i skyen" • Referansemodellen brukes til å tolke spørringen – denne deles så opp og fordeles til ulike systemer – spørretjenesten setter så sammen svarene • SPARQL er ikke et spesielt kraftig søkespråk – det er en av grunnene til at dette er mulig å få til Trinn #6
  42. 42. 42 Semantiske formater "on the wire" • Vanlige XML-formater er statiske – semantiske formater er dynamiske – eksempler: RDF/XML, XTM • Nye felter og entitetstyper kan trivielt legges til i semantiske formater – skaper ingen forvirring for mottakerne • Disse formatene støtter også spesialisering – dvs: transparent støtte for subtyping Trinn #7
  43. 43. 43 Semantiske formater (2) • Semantiske formater støtter fletting – data om samme entitet fra ulike kilder kan flettes sammen – flettingen er usynlig for mottaker Sak #1 Sak #1 Sak #1 Sak #1 Egenskap 1 Egenskap 2 Egenskap 3 Egenskap 4 Egenskap 5 Egenskap 4 Egenskap 5 Trinn #7
  44. 44. 44 Scenario App #1App #1 Trenger alle X som fyller et visst kriterium, i format Y. Broker SPARQL, formatY App #2App #2 DatabaseDatabase SPARQL XTM SPARQL XTM Flett og filtrér Flett og filtrér OversetterOversetter XTM formatY Trinn #7 Tjeneste #1 Tjeneste #2
  45. 45. 45 Oppsummering
  46. 46. 46 Ny arkitektur • Forbrukere trenger ikke vite hvem som har data – mye løsere kobling – langt lettere å omstrukturere • Forbrukere trenger ikke forholde seg til systemenes mange begrepsapparater – i stedet kan man spørre ut i fra referansemodellen • Forbrukere trenger ikke forholde seg til drøssevis av formater – i stedet ber man om data på det formatet man selv vil ha
  47. 47. 47 Oppsummering • Dette er en lang vei å gå – men hvert trinn gir stor verdi i seg selv – allerede etter trinn #1 har man oppnådd mye • Hvert trinn gir bedre grunnlag for å vurdere verdien av de neste trinnene
  48. 48. 48 "No silver bullet" • Semantisk teknologi gjør fort folk ivrige – viktig å huske at dette ikke er nok alene – det aller viktigste er å følge de rette arkitektoniske prinsippene – men semantisk teknologi understøtter dette "There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity." –Fred Brooks, 1986

×