Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Semantisk integrasjon
Ähnlich wie Semantisk integrasjon (20)
Mehr von Lars Marius Garshol
Mehr von Lars Marius Garshol (20)
Semantisk integrasjon
- 1. 1 Semantisk integrasjon og arkitektur Ut av siloene, 2010-11-17 Lars Marius Garshol
- 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 Agenda • Semantisk teknologi – rask innføring • Arkitektur – kort om utfordringer • Hva semantisk teknologi kan gi – et forslag • Oppsummering
- 4. 4 En kort innføring Semantisk teknologi
- 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 Ikke-semantiske data • Hva er dette? • Hvor mange ting er det her? • Hva er ting og hva er egenskaper?
- 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 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 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
- 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 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 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
- 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 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 "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 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?
- 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 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 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 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 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 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
- 27. 27 Egenskaper også Trinn #1 SamboerskapSamboerskap PersonPerson samboer 1 samboer 2startdato sluttdato ...
- 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Oppsummering
- 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 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 "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