Guide:
Emnekart for vanlige dødelige (del 1)
Vi har fått seniorutvikler Alexander Johannesen til å gi en innføring i temaet "emnekart". Han burde vite hva han snakker om: Han jobber for det australske nasjonalbiblioteket, der det skulle være nok informasjon som må organiseres. Les første del av de to artiklene om emnekart.
Side 1: Først og fremst
Emnekart for vanlige dødelige
Emnekart som teknologi kan være litt håpløst å få taket på med det første; her florerer det vanskelige og fremmede uttrykk, nye tankesett og dystre spådommer om vår udugelighet i datamodellering. Og det er ikke for ingenting at emnekart sprer om seg - i en verden som stadig blir mer komplisert og omfattende er det også nødvendig for våre datasystemer å holde tritt. Relasjonsdatabaser og gode gamle programmeringsteknikker er ikke lenger nok. Vi trenger nye måter å tenke på, nye metoder og nye veier å gå. Vi trenger nye måter å møte nye informasjonsbehov på. Og nettopp derfor denne artikkelen.
Mine egne første skritt i den emnebelagte verden var presset frem av profesjonell nytte-verdi-evaluering, men like fullt av egen sta og katteaktig nysgjerrighet - jeg var alltid søkende etter nye og bedre måter å løse problemer på. Som vi vet skorter det ikke på problemer som må løses, men det skorter heller ikke på mulige løsninger, både gode og udugelige. Her gjelder det bare å velge riktig løsning.
Først og fremst
Jeg skal først klargjøre noe av det vanskligste når vi snakker om informasjonsbehandlig, kunnskapsbehandling, eller kanskje kunnskapshåndtering (eller tilogmed intelligente informasjonsagenter): Terminologi og omfang.
La oss først se på omfanget av hva jeg her snakker om. Informasjonssystemer - altså datasystemer som har som modus operandi å gi deg best mulig resultat (søking, surfing, leting, gjetting, og så videre) fra gitte informasjonsmengder, finner du overalt. Fra det innerste lille intranett til det store internettet der ute og kanskje enda litt til. Det finnes dype nett (med vanskelig eller lukket tilgang) og åpne nett, applikasjoner, notiser, filer og fragmenter som alle inneholder informasjon. Det aller meste av denne informasjonen finnes i kontekst av seg selv; med andre ord, det finnes ingen eller lite annen informasjon som gir oss sterke indikasjoner på hva denne informasjonen er for noe. Hvis vi snakker om "fisk" i ett dokument, snakker vi om samme "fisk" i et annet? Det finnes millioner av informasjonsfragmenter der ute, og alt er neppe av samme kvalitet eller interessefaktor.
Trikset er, og vil alltid være, å koble denne informasjonen best mulig opp til hva brukeren (om så være en person eller et program) måtte ønske, og allerede her bør jeg nevne at mye av det vi forsøker å oppnå i disse systemene er basert på magi, speil og tankeoverføring. Hvis jeg forteller et system at jeg leter etter "Monteverdi", hvordan vet systemet at det skal ikke finne bildelfabrikanten Monteverdi , men snarere Monteverdi, barokkomponisten? Og ikke bare barokkomponisten Monteverdi, men dokumenter som sier noe vettugt - og ikke bare det at han er listet som komponist på en CD av en artist som spiller barokkslagere på trekkspill?
Hvordan skal vi få til alt dette?
Søkemotorer bruker logiske operatører for å få til en del av dette, slik som å si "finn sider med 'Monteverdi', men ikke hvis de snakker om 'biler, bil, bildeler, krom, fotasje eller testestoron' ", men hva hvis verdens viktigste Monteverdiekspert - som legger ut høyst viktige og interessante artikler - også har bildilla? Det sier seg selv av vi må jobbe litt hardere med å klemme semantiske verdier ut av informasjonen vår.
Side 2: Terminologi
Vi snakker ofte om "semantikk" i denne bransjen, men få forstår hva det ordet egentlig betyr og ikke minst hvilke konsekvenser man ville fått hvis man så gjorde. Jeg skal gi to definisjoner, og den første generelle definisjonen lyder; "velformulerte meningsfulle data", og den andre noe smalere definisjonen lyder; "velformulerte og meningsfulle data som er sann". Velformulerte data i seg selv er et komplekst emne, men husk at "meningsfulle" ofte er et personlig og individualistisk mål nært oppunder umulig og derfor kanskje en faktor som kan gjøre hele datasystemer komplett ubrukelige! Det er ikke til å stikke under en stol at dette er heite og omdiskuterte emner.

Dernest må vi snakke om ontologi, "studier i det å være, virkeligheten og dens substans." I dataverdenen bruker vi dette ordet som substitutt for "det vi snakker om" i systemene våre. I en applikasjon snakker vi kanskje om kunder, selgere, telefonnummere, kontrakter, penger og så videre; dette blir ontologien som vi snakker om, og er et uttrykk vi gjerne bruker nede i de mørkere delene av systemene våre, om de mystiske objektene som flyter omkring og tilsynelatende gjør at systemene virker. "Jeg heter Alex, og jobber ved NLA" kan sies å ha en ontologi av ordene "jeg, heter, og, jobber, ved", altså de ordene som bygger opp den semantiske verdien av de råe data "Alex, NLA."
Det neste vi må ta for oss er koblingen mellom ontologi og kunnskapsdatabase. Noen blander sammen ontologi og database til ett, mens andre har en helt klar seperasjon av de to. Her må vi bringe inn uttrykket skjema, eller det engelske "schema", som definerer en struktur og regler for hvordan dataene dine kan forklares og lagres. Et skjema kan validere at du putter en dato inn i et datofelt, og at duppedings må være i en substruktur av en ding-dong. Veldig ofte - og jeg er på nippet til å si alltid, men biter meg i det fordi det finnes ørsmå fragmenter av alternativer der ute - vil et skjema definere en binær struktur, en trestruktur. Tenk zoologi hvor alle levende vesener, store og små, blir puttet inn i kategorier der de hører hjemme, og hvor du kan lete deg opp og ned treet på leting etter andre vesener av mer eller mindre lik art.

Disse blir ofte kalt taksonomier, og kommer nettopp fra biologien, "klassifiseringen av levende organismer." Klassifisering av ting i bestemte strukturer har vi gjort til all tid og det har stort sett gått greit, men jo mer vi vet, jo mer vi vil klassifisere, jo mere skjønner vi at ting ikke egentlig passer inn i disse forhåndsbestemte kategoriene. Plutselig finner man to veldig forskjellige ting som passer i samme kategori, eller man finner to fryktelig like ting som passer inn i to vidt forskjellige kategorier. Og da får man et problem, fordi vi i all tid har brukt strukturen i klassifikasjonsstrukturene som semantisk modell! Henger du med meg? Vi finner Homo Sapiens og Homo Erectus i samme kategori, men finner ikke Homo Sapien Sapiens i Homo Erectus selv om forskjellen er liten (og for noen ingen i det hele tatt), og datasystemer - i kraft av å være logiske kraftbeist med dårlig gangsyn - har vanskeligheter med å se sammenhengen og semantiske finurligheter slik vi gjør det. Du har kanskje hørt om "folksonomies" som i korte trekk er klassifiseringsstrukturer som brukerene av systemene lager selv, og på denne måten unngår de spesifike problemene men har til gjengjeld dårlig presisjon. For eksempel, hva med "fisk"; passer den best i "vann" eller "gjeller" kategorien? Kanskje lage ny kategori "våte dyr"? Eller må vi velge èn? Hvorfor ikke begge?
Ja, nettopp; hvorfor ikke begge? Vi må bringe fasetterte kategorier på banen. Vi kan si at "vann" og "gjeller" er fasetterte aspekter ved en gitt kategori "fisk", og det samme for "finner". Ved å finne flest mulig fasetterte kategorier for andre kategorier bygger man opp en struktur av kategorier som er fleksibel i forhold til hva du putter i dem - man er ikke bundet til en enkelt mulighet, men til flere mulige, og man kan finne snev av semantisk verdi i katalogstrukturene.
Sånn, da skal vi være på teoretisk bølgelengde, selv om vi bare har lekt litt i overflaten.
Side 3: Hvem der!?
Det neste vi må takle er identitet. En dings, et objekt, en ting, en dippedutt, en tanke, et snafs; alle ting eksisterer enten i en fysisk eller en konseptuell verden, og for at disse tingene skal kunne beskrives av datasystemer trenger vi en eller annen måte å være sikre på at vi alle snakker om den samme dingsen. I en relasjonsdatabaseverden har en rad i en database en nøkkel, et unikt felt, for dette. Det kan være et nummer eller en streng med mer eller mindre forståelige sammenhenger.
Jeg heter Alex, men det er fler enn meg som heter det. Kanskje en eller annen Alex også er gift med Julie-Anne, ja kanskje de tilogmed bor i Australia og har et par døtre, og - mot alle odds - synes at Claudio Monteverdi er verdens beste komponist noen gang! Sjansen er dog liten for at det er noen annen enn meg vi snakker om, nettopp fordi vi har bygget opp et sett med identitetsfragmenter som vi setter sammen til "å, du mener Alex." Sånn må vi gjøre med dataobjektene våre også.
Vi har gjort det i mange år allerede, og for enhver som noen gang har satt sammen et system med mer enn to databaser vet hvor viktig det er at ting er unike, at en linje i en tabell representerer en dings, og at andre linjers kolonner kan snakke om akkurat denne dingsen. Dette er datamodellering, og det første hintet til hva emnekart er for noe er at det er - ja, nettopp - en datamodell.
Datamodell
Jaha, hva er nå så spesielt med en datamodell? Det finnes jo tusenvis av dem, en for hvert enkelt lille problem i hele verden, og kanskje noen til.
Nettopp. Det finnes mange, så fryktelig mange. De som har tatt steget fra et system med to databaser til mange databaser, kanskje på kryss av domener og nettverk, vet nettopp hvor mange problemer man kan støte borti. Bare det å holde rede på unike objekter på tvers av domener og systemer er kanskje ett av de største problemene. Som gjengangere kan vi også nevne sammenkobling av data, ikke-kompatible datamodeller hvor man mister integritet i konverteringen og ikke minst mangelen på gjenbruk. Emnekart er en datamodell som faktisk løser de fleste - om ikke alle - disse problemene, og flere til.
Modellen er enkel; det finnes emner, det finnes relasjoner mellom emnene og det finnes forekomster av dem. Et emne kan være absolutt alt, fra konsepter til objekter til lukter og smaker til ... ja, hva det nå måtte være vi ønsker å modellere. Vi gir alle emner en identitet slik at vi kan snakke om dem, og så lager vi relasjoner mellom dem.
Den observante leser kan sikkert allerede nå forstå at denne datamodellen kan gjenskapes i allerede eksisterende teknologi. En SQL database kan brukes like godt som en XML eller en objekt-orientert database. Og selvsagt finnes det også emnekartdatabaser som er spesialister på alt vi her snakker om og mere til.
For mer om dette og konkrete eksempler på emnekart, les den neste delen av artikkelen om emnekart. Denne vil bli publisert her på HWB.no i nær fremtid.
