Post on 15-Jan-2015
description
1
Semantisk integrasjon og arkitektur
Ut av siloene, 2010-11-17Lars Marius Garshol
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
Agenda
• Semantisk teknologi– rask innføring
• Arkitektur– kort om utfordringer
• Hva semantisk teknologi kan gi– et forslag
• Oppsummering
4
En kort innføring
Semantisk teknologi
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
Ikke-semantiske data
• Hva er dette?• Hvor mange ting er det
her?• Hva er ting og hva er
egenskaper?
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
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
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:BusDriverowl:intersectionOf owl:restriction
ex:Bus
owl:on
ex:drives
owl:someValuesFrom
ex:Person
ex:Driverowl:intersectionOf owl:restriction
owl:someValuesFrom
ex:Vehicle
owl:on
owl:subClassOf
http://owl.man.ac.uk/2003/why/latest/
owl:subClassOf
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
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
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
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
Arkitekturutfordringer
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
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
"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
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
Nye arkitekturmuligheter
Semantisk integrasjon
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
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
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
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
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
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
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
Egenskaper også Trinn #1
SamboerskapSamboerskap PersonPerson
samboer 1
samboer 2startdatosluttdato...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Semantiske formater (2)
• Semantiske formater støtter fletting– data om samme entitet fra ulike kilder kan
flettes sammen– flettingen er usynlig for mottaker
Sak #1Sak #1
Sak #1Sak #1
Egenskap 1
Egenskap 2
Egenskap 3
Egenskap 4
Egenskap 5
Egenskap 4
Egenskap 5
Trinn #7
44
Scenario
App #1App #1Trenger alle X som fylleret visst kriterium, i formatY.
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
Oppsummering
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
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
"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