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