UNIVERSITETET I OSLO Institutt for informatikk. Evaluering av SPARQL-spørringer på en mengde enveiskilder. Masteroppgave.

Transkript

1 UNIVERSITETET I OSLO Institutt for informatikk Evaluering av SPARQL-spørringer på en mengde enveiskilder Masteroppgave Einar Myre 1. august 2011

2

3 Sammendrag De siste årene har stadig mer data blitt tilgjengeliggjort og åpnet for allmennheten. Den store mengden kan gjøre det hele mindre oversiktlig, men dataene kan kobles sammen ved hjelp av semantisk web-teknologier som RDF. Data representert som RDF kan spørres mot ved hjelp av SPARQLspørringer. Et problem kan oppstå med bestemte RDF-datakilder kalt enveiskilder. Disse datakildene gir kun deler av datasettet ved hver forespørsel, og kun der forespørselen inneholder inputverdiene datakilden krever. Problemet blir dermed om en gitt SPARQL-spørring mot en gitt mengde enveiskilder kan besvares, og i så fall, hvordan? Denne masteroppgaven forsøker å komme med en løsning på dette problemet. Vi har ikke klart å definere problemet formelt, men vi har kommet frem til en løsning som løser noen bestemte problemer vi vet vi kan svare på. Dette gjøres ved å lage en beskrivelse av hver datakilde. Ved hjelp av disse beskrivelsene kan vi samle data fra datakildene basert på dataene som allerede er samlet opp. Løsningen er implementert som en Java-applikasjon.

4

5 Forord Jeg vil gjerne takke min veileder, Martin Giese, for god hjelp og veiledning gjennom arbeidet med oppgaven. Det har vært svært interessant og lærerikt å jobbe med ham, og hans tilbakemeldinger til oppgaven har vært uvurderlige. Jeg ønsker også takke de andre deltakerne i Semicolon-prosjektet, særlig deltakerne fra Institutt for informatikk, for muligheten til å skrive min masteroppgave i forbindelse med dette prosjektet. En takk rettes til Jens Kilde Mjelva for hjelp og tilbakemeldinger. Sist, men ikke minst, ønsker jeg å takke mine foreldre for deres støtte gjennom arbeidet med oppgaven. Einar Myre

6

7 Innhold 1 Innledning 1 2 Semantisk web og åpne data Semantisk web Åpne data Grader av åpenhet Semicolon Brønnøysundregistrene RDF Oppbygning Blanke noder Datatyper og språkkoder Serialiseringer RDF/XML Turtle Jena SPARQL Typer spørringer Filtre OPTIONAL UNION Navngitte grafer Sekvensmodifikatorer ORDER Projeksjon DISTINCT REDUCED OFFSET og LIMIT Lenkede åpne data 27

8 6 Problemet 29 7 Relatert arbeid DARQ Parsing Opprettelse av spørreplan Optimalisering av spørreplan Eksekvering av spørringen Enveiskilder SemWIQ Instansbasert føderering Trippelbasert føderering Enveiskilder LOQUS Høyerenivåontologi Oversetting fra høyerenivåkonsepter til LOD-datasett Oppdeling av spørringen Eksekvering av spørringen Enveiskilder SQUIN Enveiskilder Vurdering Løsningen Datakilder Spørringsfragment Oppsamling av tripler Oppdatering av spørringsmengden Innskrenkning av datakilder Hypergraf Forward-chaining Backward-chaining Snitt Flere gjennomkjøringer Implementering Klasser Datakilder Begrensninger Begrensning av data Bruk av FILTER Hardkodede datakilder

9 11 Konklusjon og veien videre Typer datakilder Håndtering av OPTIONAL og UNION Veien videre

10

11 Figurer 3.1 En RDF-graf med tre tripler RDF-graf med folketall i Norge, uten blanke noder RDF-graf med folketall i Norge, med egne ressurser som håndterer hvert år og folketall RDF-graf med folketall i Norge, med blanke noder Kommunikasjonen mellom en klient og en tjener ved oppslag av LOD-URI Denne oppgavens beskrivelse av en datakilde består både av selve datakilden og en eventuell løsning som konverterer returverdiene til RDF. Dermed sier vi at en datakilde tar imot argumenter som er literalverdier, og returnerer informasjon som RDF Et eksempel på et spørringsfragment, hentet fra en datakilde som tar som input to sett med koordinater Informasjonsflyten i løsningen: Den innsendte spørringen blir sendt til modellen. Der blir den sammen med den oppsamlede RDF-grafen brukt som input i en datakilde, ved at den sammenlignes med datakildens spørringsfragment. Datakilden sender i retur RDF-tripler tilbake til RDF-grafen. Til slutt eksekveres spørringen mot den oppsamlede RDF-grafen Klassediagram

12

13 Tabeller 8.1 Regler for matching mellom tripler i datasett og spørringsfragment

14

15 Kapittel 1 Innledning Denne oppgaven er en del av Institutt for informatikks arbeid på Semicolonprosjektet, som er knyttet til semantisk web og åpne offentlige data. Oppgaven forsøker å komme med en løsning på et problem tilknyttet spørring over flere datakilder med bestemte karakteristikker. Dette gjelder RDFdatakilder som kun gir deler av datasettet ved hver forespørsel. Til oppgaven er det også utviklet en applikasjon som prøver å besvare SPARQL-spørringer gitt en mengde datakilder med disse karakteristikkene. Videre er oppgaven bygd opp på denne måten: Kapittel 2 Oppgaven starter med å presentere semantisk web og åpne data Kapittel 3 Så går den nærmere inn på detaljer innen semantisk web. I dette kapittelet beskrives RDF, en semantisk web-teknologi for lenking av data Kapittel 4 Deretter beskrives SPARQL, et spørrespråk for RDF Kapittel 5 Beskrivelsen av semantisk web avsluttes med en presentasjon av prinsippet om lenkede åpne data Kapittel 6 Deretter blir oppgavens problemstilling beskrevet Kapittel 7 Tidligere relatert arbeid blir presentert Kapittel 8 Dette kapittelet beskriver i detalj en mulig løsning på problemet Kapittel 9 Applikasjonen basert på løsningen blir presentert Kapittel 10 Begrensninger ved metoden blir diskutert Kapittel 11 Oppgaven konkluderes med forslag til videre forskning

16 2 KAPITTEL 1. INNLEDNING

17 Kapittel 2 Semantisk web og åpne data Semantisk web og åpne data er begreper som har blitt stadig mer aktuelle de siste årene. 2.1 Semantisk web Semantisk web[27] (eng. semantic web) består av en rekke standarder og teknologier som gjør det mulig for datamaskiner å tolke meningsinnholdet på webben.[28] Begrepet ble først lansert av Tim Berners-Lee, skaperen av World Wide Web. Sammen med James Hendler og Ora Lassila har han gitt følgende definisjon av semantisk web:[6] The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation. Blant de viktigste av disse standardene finner vi RDF, en datamodell for lenking og utveksling av data, og SPARQL, et spørrespråk til RDF. RDF blir diskutert videre i kapittel 3, og SPARQL i kapittel Åpne data Med en økende utvikling og bruk av mobilapplikasjoner, karttjenester og lignende webtjenester har det de siste årene blitt stadig viktigere med gode data. På Internett har informasjonsflyten økt kolossalt, og folk blir stadig mer vant til at informasjon skal være tilgjengelig når man har bruk for den. Samtidig finnes det i mange norske offentlige etater datasett som er betalt av skattebetalerne, men som folket ikke får tilgang til å bruke slik de ønsker.

18 4 KAPITTEL 2. SEMANTISK WEB OG ÅPNE DATA I flere land, inkludert Norge, kreves det at offentlige data skal åpnes slik at de enkelt kan brukes av andre. Åpen tilgang til gode data kan føre til økt kunnskap; for eksempel kan tidligere ukjente sammenhenger avdekkes ved at data fra flere datasett kombineres. Åpne data kan også bidra til økt verdiskapning i samfunnet i form av nyttige tjenester og produkter, og kan bidra til at demokratiet styrkes ved at myndigheter blir mer transparente. 17. november 2003 vedtok EU direktiv om gjenbruk av den offentlige sektors informasjon (direktiv 2003/98/EF)[9], kalt viderebruksdirektivet, som var ment å harmonisere regler og praksis for gjenbruk av informasjon i EU-land. Det legges særlig vekt på å legge til rette for økt gjenbruk. Til direktivet bemerkes det bl.a.: Den offentlige sektors informationer er et vigtigt kildemateriale for produkter og tjenester med digitalt indhold, og de vil få stadig større betydning som indholdsressource til de mobile indholdstjenester, der er under udvikling. En bred geografisk dækning på tværs af grænserne er også vigtig i denne forbindelse. Mere vidtgående muligheder for at videreanvende den offentlige sektors informationer bør bl.a. give de europæiske virksomheder mulighed for at udnytte disses potentiale og bidrage til økonomisk vækst og jobskabelse. [...] Mulighederne for videreanvendelse kan forbedres ved at begrænse behovet for at overføre papirdokumenter til elektronisk format eller behandle digitale filer, så de bliver kompatible. Derfor bør de offentlige myndigheder sikre, at deres dokumenter er tilgængelige i alle allerede eksisterende formater og sprogversioner og, såfremt det er muligt og hensigtsmæssigt, i elektronisk form. [...] Redskaber, der hjælper potentielle brugere med at finde dokumenter, som er tilgængelige til videreanvendelse, og betingelserne for videreanvendelse kan i høj grad gøre det lettere at anvende den offentlige sektors dokumenter på tværs af grænserne. Derfor bør medlemsstaterne påse, at der findes praktiske ordninger, som hjælper brugerne i deres søgning efter dokumenter, der er tilgængelige til videreanvendelse. Lister, der så vidt muligt bør være tilgængelige online, over de vigtigste dokumenter (dokumenter, som videreanvendes i udstrakt grad, eller som egner sig til dette formål) og webportaler, hvorfra der er adgang til decentraliserede lister over informationskilder, er eksempler på sådanne praktiske ordninger.

19 2.2. ÅPNE DATA 5 I Norge vedtok Stortinget på bakgrunn av viderebruksdirektivet LOV nr. 16: Lov om rett til innsyn i dokument i offentleg verksemd (offentleglova)[17], som trådte i kraft 1. januar I denne loven ble retten til innsyn styrket i forhold til tidligere: Formålet med lova er å leggje til rette for at offentleg verksemd er open og gjennomsiktig, for slik å styrkje informasjonsog ytringsfridommen, den demokratiske deltakinga, rettstryggleiken for den enkelte, tilliten til det offentlege og kontrollen frå ålmenta. Lova skal òg leggje til rette for vidarebruk av offentleg informasjon. Regjeringen har også vist vilje til å sørge for at offentlig informasjon åpnes opp. I stortingsmelding nr. 17 ( ) Eit informasjonssamfunn for alle [11] nevnes tiltak 6.6 om viderebruk av offentlig informasjon: Regjeringa vil føre ein heilskapleg politikk som sikrar effektiv vidarebruk av offentleg informasjon for auka verdiskaping og utvikling av nye tenester. For å leggje til rette for vidarebruk av offentlig informasjon, skal hovudregelen om at innsyn skal vere gratis oppretthaldast, og betaling skal berre takast i særlege tilhøve og då med eit kostnadsbasert prinsipp som hovudregel. I april 2010 startet Fornyingsdepartementet data.norge.no som en blogg der de kan kommunisere med folk som interesserer seg for bruk av data. Høsten samme år vedtok de en fellesføring for 2011 om at alle egnede rådata i norske offentlige etater skal tilgjengeliggjøres i maskinlesbare formater.[10] I februar 2011 la data.norge.no til en katalog over åpne datakilder Grader av åpenhet Åpne data kan klassifiseres etter grad av åpenhet. World Wide Web Consortium (W3C) lanserte i 2010 et system der data graderes med et antall stjerner fra en til fem, alt etter hvor åpne dataene er.[5] 1. En stjerne er det laveste nivået informasjon kan være tilgjengelig for at det skal kunne kalles åpent. På dette nivået må dataene være tilgjengelig for publikum, f.eks. via en webside eller et PDF-dokument. Dataene er da ikke formet på en måte som gjør det lett å viderebruke automatisk, men de må ha en åpen lisens, slik at de i det hele tatt kan viderebrukes. 2. To stjerner blir gitt til data som er oppført på tabellformat, for eksempel som regneark, eller i en annen struktur som gjør det mulig for datamaskiner å lese gjennom teksten, og slik hente ut informasjon automatisk.

20 6 KAPITTEL 2. SEMANTISK WEB OG ÅPNE DATA 3. Tre stjerner blir gitt til data som oppfyller kravene til to stjerner, men hvor dataene dessuten er strukturert på et ikke-proprietært format (f.eks. CSV i stedet for Excel-regneark). Data som er tilbudt via et API på XML-format vil som regel også ligge på dette nivået. 4. Fire stjerner blir gitt når dataene bruker åpne W3C-standarder (dvs. RDF og SPARQL) for å identifisere ressurser. 5. Fem stjerner er det høyeste nivået som er definert. Her er dataene strukturert på samme måte som med fire stjerner, men i tillegg er dataene lenket sammen med data fra andre datakilder, slik at de blir satt i en sammenheng. Det er fortsatt mulig å gjøre data enda mer åpne, selv om de allerede oppfyller kriteriene til fem stjerner. Dataene kan blant annet gjøres mer åpne ved å gjøre dem søkbare, eller ved å gjøre det mulig å spørre mot dem via et SPARQL-endepunkt. Graderingen etter stjerner dekker dermed ikke alle eksempler, men kan først og fremst ses på som gode retningslinjer. 2.3 Semicolon Semicolon er et prosjekt som prøver å bidra til åpning og utveksling av data i offentlig sektor. Prosjektet er et samarbeid mellom Institutt for informatikk ved Universitetet i Oslo og flere offentlige etater og bedrifter, som f.eks. Det Norske Veritas, Statistisk sentralbyrå, Brønnøysundregistrene og Computas 1. Prosjektets hovedmål er å:... utvikle og utprøve IKT-baserte metoder, verktøy og metrikker for hurtigere og billigere å oppnå semantisk og organisatorisk interoperabilitet innen og med offentlig sektor. 2 Semicolon har definert semantisk og organisatorisk interoperabilitet slik 3 : ˆ Semantisk interoperabilitet mellom applikasjoner betyr at de ikke bare er enige om samme format ved utveksling av data, men også at all utveksling av informasjon har basis i en felles forståelse av innhold. ˆ Organisatorisk interoperabilitet innebærer enighet om hvordan og i hvilket omfang man skal samhandle i praksis [internt og mellom ulike enheter i offentlig forvaltning.] 1 Full liste finnes på norsk.html 3 norsk.html

21 2.3. SEMICOLON Brønnøysundregistrene I en del av prosjektet der Institutt for informatikk har vært spesielt aktiv, forsøkes det å lage en tjeneste som tilbyr et grensesnitt for å kombinere data fra forskjellige datasett på en enkel måte. Blant annet har det blitt laget en tjeneste som gir data fra Brønnøysundregistrene[8]. Brønnøysundregistrene tilbyr data fra Enhetsregisteret, registeret over norske organisasjoner, via flere forskjellige webtjenester 4. Ved å oppgi organisasjonsnummeret til en gitt organisasjon kan brukere hente grunndata som f.eks. kontaktinformasjon, virksomhetstype og hvilke personer som har sentrale verv i organisasjonen. Brønnøysundregistrene krever betaling for tilgang til webtjenestene, men Semicolon-prosjektet har fått tilgang til å åpne opp deler av datasettet. Det er laget en tjeneste som kjøres på Brønnøysundregistrenes tjenere, og som gir informasjon om en gitt organisasjons adresse som RDF. Hvis vi sammenligner med W3Cs stjernemerking som beskrevet i 2.2.1, ser vi at dataene i Brønnøysundregistrenes eksisterende webtjeneste tilsvarte tre stjerner. Dataene blir tilbudt som strukturerte data i det ikke-proprietære formatet XML, som gjør det lett for datamaskiner å lese gjennom teksten og hente relevant informasjon. Denne webtjenesten er en betalingstjeneste, men dataene er også tilgjengelig gratis på Brønnøysundregistrenes nettsted. Her er de imidlertid kun tilgjengelig som en vanlig webside, og oppfyller dermed kun kravene til én stjerne fra W3C. Derimot er det først med den nye tjenesten at dataene tilbys som RDF. Det vil dermed si at Enhetsregisteret er løftet i åpenhet, fra tre (eller en) til fire stjerner. En begrensning med Brønnøysundregistrenes webtjenester er at man kun kan få informasjon om én organisasjon ved hvert kall, og kun dersom man oppgir organisasjonsnummeret til organisasjonen. Dette begrenser hvordan vi kan bruke datasettet, da vi ikke kan bruke webtjenesten til å lete etter organisasjoner som har bestemte egenskaper, eller gjøre bestemte spørringer på data på tvers av organisasjoner. Slike begrensninger er et problem vi også ser i svært mange andre datakilder, også blant dem vi ønsker å bruke i Semicolons arbeid. Det er derfor relevant for Semicolon at vi finner ut hvordan vi kan bruke data fra datakilder med lignende begrensninger som 4 En webtjeneste (eng. web service) defineres av W3C[13] som: [... ] a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

22 8 KAPITTEL 2. SEMANTISK WEB OG ÅPNE DATA Brønnøysundregistrenes webtjenester. Denne problemstillingen blir beskrevet nærmere i kapittel 6.

23 Kapittel 3 RDF Resource Description Framework (RDF) er en datamodell definert av World Wide Web Consortium (W3C) for å gjøre det mulig å lenke sammen og utveksle data over Internett. En grunnleggende beskrivelse av RDF eksisterer som et introduksjonsdokument, RDF Primer[22], som er tilgjengelig på W3Cs nettsider. Dokumentet er en del av et sett med seks dokumenter, der de andre dokumentene omhandler i mer detalj de grunnleggende RDF-konseptene (RDF Concepts and Abstract Syntax[18]), syntaksen til RDF/XML (RDF/XML Syntax Specification[1], se også kapittel 3.4.1), RDF-vokabularer (RDF Vocabulary Description Language 1.0: RDF Schema[7], se også under), semantikken til RDF og RDF Schema (RDF Semantics[15]) og tester som kan brukes til testing av RDF-verktøy (RDF Test Cases[12]). Disse seks dokumentene utgjør sammen den fullstendige spesifikasjonen til RDF. I dette kapittelet vil vi gå ut fra RDF Primer, og gi en grunnleggende beskrivelse av RDF. Med RDF kan vi uttrykke egenskaper ved alle mulige ting, konkrete så vel som abstrakte. Slike egenskaper kan også være relasjoner til andre ting. Vi kaller disse tingene ressurser, og en egenskap vil også være en ressurs. I RDF vil vi kunne identifisere en URI for alle ressurser, f.eks. kan en person identifiseres med URI-en URI-er er vilkårlige, og de trenger ikke å ha noen sammenheng med naturlig språk. Vi anser en URL som fører til et dokument på Internett til å være URIen som beskriver dokumentet. Dermed må andre typer ressurser ha URIer som ikke fører direkte til et dokument, som URN-er. Et eksempel er som ikke er URL-en til et dokument. Om man prøver å nå siden på Internett, blir man videresendt til URI-ens spesifikasjon. Grunnen til at vi bruker URI-er fremfor enkeltstående navn er å unngå

24 10 KAPITTEL 3. RDF at vi bruker samme navn til forskjellige ressurser. F.eks. kan egenskapen navn henvise til flere typer navn, som personnavn, stedsnavn eller navn på organisasjoner, eller det kan henvise til noe helt annet. På vårt eget domene kan vi selv identifisere en URI for hvilken som helst ressurs. Dermed kan vi være sikker på at vi bruker vår navn -egenskap på riktig måte. Merk likevel at det ikke finnes noen kontroll på at andre bruker den riktig. Det at hvem som helst kan opprette sine URI-er betyr i tillegg at samme ressurs kan bli tilordnet mange forskjellige URI-er. En konvensjon er at ressurser innenfor samme tema har felles URI-prefiks, og slike samlinger av ressurser kaller vi vokabularer. Flere slike vokabularer har ressurser for egenskaper som brukes ofte, og er publisert slik at alle kan bruke dem. F.eks. inneholder FOAF-vokabularet mange vanlige egenskaper for personopplysninger som navn, gruppemedlemskap og bekjentskap, mens Dublin Core-vokabularet har egenskaper for dokumentopplysninger som forfatter, tittel, dato og format. Med felles vokabularer er muligheten for misforståelser mindre, og det vil være lettere å slå sammen flere RDF-grafer. 3.1 Oppbygning All informasjon i RDF er uttrykt i tripler, setninger som består av tre deler, på denne måten: < < "Ola Nordmann" De tre delene et trippel består av er: ˆ Subjekt: Ressursen vi ønsker å uttrykke en egenskap ved ˆ Predikat: En URI som representerer egenskapen. I dette tilfellet er en URI som representerer navnet på en person. ˆ Objekt: Dette kan enten være en henvisning til en annen URI eller, som i dette tilfellet, ren tekst (en literal verdi). Tripler blir ofte vist grafisk som en rettet graf. Figur 3.1 viser tre tripler som en graf: < < "Ola Nordmann". < < < < < < Her vises triplets subjekt og objekt som noder, og predikatet som en rettet kant som går fra subjektnoden til objektnoden. Fordi alle triplene har samme subjekt, vises dette subjektet kun som én node. En vanlig konvensjon er å vise ressurser som ovale noder, og literaler som firkantede noder.

25 3.2. BLANKE NODER 11 < < < < "Ola Nordmann" < < 3.2 Blanke noder Figur 3.1: En RDF-graf med tre tripler. Noen typer informasjon er vanskeligere å uttrykke med en vanlig trippelstruktur enn andre. Hvis vi f.eks. ønsker å angi hvor mange innbyggere det var i Norge i et bestemt år, får vi et problem om vi ikke uttrykker dette på en måte som viser at innbyggertallet kun gjelder for det bestemte årstallet test:aar test:folketall test:aar geonames:norway 2010 test:folketall Figur 3.2: RDF-graf med folketall i Norge, uten blanke noder Grafen i figur 3.2 er ment å uttrykke at Norge hadde innbyggere i 2005, og innbyggere i Det gjør den ved å la geonames:norway ha en test:aar-egenskap med verdien 2005 og en test:folketall-egenskap med verdien , som er ment å uttrykke innbyggertallet i 2005, og en test:aar-egenskap med verdien 2010 og en test:folketall-egenskap med verdien for å uttrykke innbyggertallet i Men vi har ingen tilknytning mellom 2005 og eller mellom 2010 og

26 12 KAPITTEL 3. RDF utover at de i begge tilfeller er koblet til samme ressurs, geonames:norway. Det vil dermed si at koblingen mellom 2005 og i denne grafen er den samme som koblingen mellom 2005 og Derfor sier ikke grafen i seg selv noe om at et bestemt folketall kun gjelder for et bestemt årstall, og enda mindre for hvilket årstall. Derfor bør grafen omstruktureres slik at sammenhengen mellom et årstall og et folketall kan tydeliggjøres. Vi kan gjøre dette ved å la geonames:norway peke til to ressurser som hver håndterer en kombinasjon av ett folketall og ett årstall, se figur 3.3. test:aar 2005 test:folketallaar test:n1 test:folketall geonames:norway test:folketallaar test:aar 2010 test:n2 test:folketall Figur 3.3: RDF-graf med folketall i Norge, med egne ressurser som håndterer hvert år og folketall Vi bruker da ressursene test:n1 og test:n2. Dette er ressurser som kun brukes for å koble sammen andre ressurser, og det vil ikke gi mening å gi mer informasjon om disse ressursene andre steder. Derfor kan vi i stedet bruke blanke noder, noder som ikke har en URI. Blanke noder er alltid lokale innenfor ett RDF-dokument, dvs. at de ikke kan refereres til i andre dokumenter. RDF-grafen med blanke noder vises i figur 3.4. Blanke noder brukes ofte når man skal koble en ressurs til mer enn én ressurs om gangen, men de kan også brukes i andre tilfeller hvor vi ikke bryr oss om identiteten til en ressurs, men kun hvordan den henger sammen med andre ressurser. RDF har dessuten støtte for å samle flere ressurser med collections, men dette tas sjelden i bruk.

27 3.3. DATATYPER OG SPRÅKKODER 13 geonames:norway test:folketallaar test:aar test:folketall test:folketallaar test:aar 2010 test:folketall Figur 3.4: RDF-graf med folketall i Norge, med blanke noder 3.3 Datatyper og språkkoder Som nevnt i kapittel 3.1 kan noder i et RDF-dokument være enten ressurser eller literaler. Vanligvis vil en literal tolkes som en streng, men vi kan også registrere en annen datatype, representert ved en URI. Dersom vi for eksempel ønsker å registrere at en literal er en dato, kan vi skrive " "^^xsd:date Når vi har definert datatype, vil " "^^xsd:date være forskjellig fra " ". " " uten definert datatype vil også være forskjellig fra " "^^xsd:string, som eksplisitt definerer literalen som en streng. Vi kan også si at to literaler skal anses å være like. F.eks. kan man dersom man definerer en literal som et heltall med datatypen xsd:int, si at "12"^^xsd:int er lik "012"^^xsd:int. I tillegg til å definere datatype, kan vi registrere hvilket språk en streng er skrevet på, ved hjelp av en tag med språkets ISO 639-kode. Dersom vi for eksempel ønsker å uttrykke at en tekst er skrevet på engelsk, bruker vi dette språkets ISO 639-kode, en : "Norway"@en

28 14 KAPITTEL 3. RDF Merk at vi ikke kan definere datatype og språkkode samtidig. Det vil dermed si at det kun er strenger som kan ha språkkode. I eksemplene for både datatype og språk er det brukt Turtle-syntaks. Dersom en annen serialisering brukes, kan syntaksen være forskjellig fra den som er brukt her. Turtle er beskrevet nærmere i kapittel 3.4.2, inkludert årsaken til at Turtle er valgt i eksemplene. 3.4 Serialiseringer RDF er opprinnelig en datamodell, og kan eksporteres til flere forskjellige serialiseringer. I hver av disse serialiseringene blir RDF-grafene skrevet på tekstform på en standardisert måte, slik at de kan leses og bli forstått av datamaskiner. I alle serialiseringene er dataene de samme, men de blir kodet på forskjellig måte RDF/XML Den mest brukte av RDF-serialiseringene er RDF/XML[2], som er den offisielle anbefalingen fra W3C. Denne serialiseringen viser RDF som XML. XML er en allerede godt etablert standard for strukturelt oppbygde data. Derimot er RDF/XML lite lesbar for mennesker. XML er bygd opp hierarkisk, og det samme gjelder dermed også RDF/XML. Hele RDF-datasettet er pakket inn i elementet rdf:rdf. Med attributter til dette elementet kan man også deklarere forkortelser for URI-prefiks i datasettet. Det vil si at dersom flere URI-er i datasettet har samme prefiks, kan dette forkortes så vi slipper å bruke hele URI-en hver gang. Flere av de vanligste vokabularene har en fast prefiksforkortelse. F.eks. forkortes vanligvis prefikset som brukes av FOAF-vokabularet, som foaf:. Det vil dermed si at vi f.eks. kan skrive foaf:name i stedet for Innenfor rdf:rdf-elementet beskrives hver ressurs vi ønsker å si noe om, med et rdf:description-element. Dette elementet inneholder attributtet rdf:about, som forteller ressursens URI. Mens subjektet i et trippel blir beskrevet med et rdf:description-element, blir predikatet beskrevet med et underelement av subjektet, der navnet på elementet er URI-en til predikatet. Objektet blir beskrevet forskjellig avhengig av om det er en ressurs eller en literal. Dersom objektet er en literal, skrives det ganske enkelt som verdien i predikat-elementet. Men hvis objektet er en ressurs, vil predikatet inneholde attributtet rdf:resource, som refererer til objektets URI.

29 3.4. SERIALISERINGER 15 RDF-grafen i figur 3.1 vil skrives slik: <?xml version="1.0"?> <rdf:rdf xmlns:foaf=" <rdf:description rdf:about=" <foaf:name>ola Nordmann</foaf:name> <foaf:knows rdf:resource=" /> <foaf:knows rdf:resource=" /> </rdf:description> </rdf:rdf> Språk og datatyper blir begge beskrevet med XML-attributter. Språk defineres med attributtet xml:lang: <ex:landnavn xml:lang="en">norway</ex:landnavn> Datatype defineres med attributtet rdf:datatype: <dc:date rdf:datatype= " Turtle En annen mye brukt serialisering er Turtle (Terse RDF Triple Language)[3]. Den er en delmengde av formatet Notation3 (N3)[4], som ble utviklet av Tim Berners-Lee som et mer lesbart alternativ til RDF/XML. Turtle er en delmengde på den måten at det kun støtter RDF, mens N3 er utvidet til å støtte mer enn hva som er beskrevet i RDF-spesifikasjonen. Akkurat som RDF/XML, lar Turtle oss forkorte tripler ved bruk av prefiks. Dette blir deklarert helt først i filen, på ex: < Her brukes ex som forkortelse for Etter dette føres alle triplene opp, med subjekt, predikat og objekt atskilt kun med mellomrom. Hvert trippel avsluttes med et punktum. RDF-grafen i figur 3.1 kan dermed skrives på denne måten med ex: foaf: < ex:ola foaf:name "Ola Nordmann". ex:ola foaf:knows ex:kari. ex:ola foaf:knows ex:per. Vi skiller her mellom fullstendige URI-er, som skrives med <...>, og URI-er som er forkortet med et prefiks, som skrives uten. Hvis vi ikke hadde gjort

30 16 KAPITTEL 3. RDF det, kunne http i bli lest som et prefiks. Blanke noder skrives alltid uten <...>, på formen :x, der x er navnet på noden. Merk for øvrig at vi ikke trenger å definere prefiks for alle (eller for den saks skyld for noen) URI-er som brukes i dokumentet. For literaler defineres datatyper i Turtle med ^^: ex:dok1 dc:date " "^^xsd:date Literalers språk defineres ex:norge ex:landnavn "Norway"@en Turtle gjør det mulig å forenkle noen ledd. Dersom subjektet i to tripler er det samme, kan vi slå sammen to tripler med et semikolon, så vi kun trenger å skrive subjektet én gang. Hvis både subjekt og predikat er de samme i to tripler, kan vi tilsvarende slå triplene sammen med komma. RDF-grafen over kan dermed forkortes ex: foaf: < ex:ola foaf:name "Ola Nordmann" ; foaf:knows ex:kari, ex:per. I denne oppgaven vil Turtle brukes i eksemplene videre. Turtles syntaks er mye mer lettleselig enn RDF/XML, og egner seg derfor bedre til enkle eksempler. I tillegg ligger Turtle-syntaksen i bunn for syntaksen som brukes av SPARQL, som blir beskrevet i kapittel Jena Jena 1 er et RDF-rammeverk for programmeringsspråket Java. Jena tilbyr et eget API som består av metoder andre Java-programmer kan bruke for å lese og skrive data i RDF-grafer, som i Jena kalles modeller. Flere av de vanligste RDF-serialiseringer støttes, inkludert RDF/XML og Turtle. Man kan stille spørringer mot en Jena-modell ved hjelp av ARQ 2, en SPARQLimplementasjon som er en del av Jena. Det finnes også andre Java-biblioteker for RDF. For Java finnes bl.a. Sesame 3 og JRDF 4. For C finnes Redland RDF Libraries 5, som også inkluderer

31 3.5. JENA 17 bindinger som gjør det mulig å bruke Redland i Perl, PHP, Python og Ruby. Til Python finnes i tillegg RDFLib 6. For applikasjonen utviklet til denne oppgaven har vi valgt å bruke Jena. Det er dette rammeverket som er brukt i lærebøkene og undervisningen, og er derfor det vi kjenner best til. Jena inkluderer alle funksjoner vi har bruk for, og har også en fordel ved at det er dette som brukes oftest i relaterte løsninger vi har sett på. 6

32 18 KAPITTEL 3. RDF

33 Kapittel 4 SPARQL SPARQL er et spørrespråk for RDF, også definert av World Wide Web Consortium. Deler av syntaksen kan minne om SQL, men er tilpasset slik at man skal kunne spørre mot et sett med RDF-tripler. SPARQL er spesifisert i dokumentet SPARQL Query Language for RDF[25], som definerer språkets syntaks og semantikk. Vi formulerer spørringer i form av RDF-tripler der vi erstatter de ønskede ressursene med variabler. Variabler er skrevet på formen?x, der x er navnet på variabelen. En mengde med RDF-tripler kaller vi Basic Graph Pattern. En spørring kan bestå av flere Basic Graph Patterns, gruppert med { og }. Her er et eksempel på en SPARQL-spørring som returnerer navn og alder på alle personer vi har informasjon om: PREFIX foaf: < SELECT?navn?alder WHERE {?x foaf:name?navn.?x foaf:age?alder. } Resultatet av evalueringen er en mengde variabeltilordninger. En variabeltilordning er en mengde par (x, v) fra variabel til verdier. Variablene er ikke påkrevd å ha en tilordnet verdi, og variabeltilordningene kan være tomme ved bruk av UNION eller OPTIONAL (se under). Spørringen ovenfor vil kunne få et resultat som vi kan skrive ut som en tabell. Vi kan se for oss at vi har følgende tripler: _:a foaf:name "Ola Nordmann" ; foaf:age "30". _:b foaf:name "Kari Nordmann" ; foaf:age "25". _:c foaf:name "Per Nordmann".

34 20 KAPITTEL 4. SPARQL _:d foaf:name "Lise Nordmann" ; test:aar "1980". På grunnlag av dette kan vi få resultatet som vises i tabellen under. Her viser øverste rad variablene vi ønsket, og hver av de neste radene er en variabeltilordning, med variabel og tilhørende verdier i samme kolonne navn alder =========================== "Ola Nordmann" "30" "Kari Nordmann" "25" Vi kan bruke blanke noder i spørringer, på samme måte som i RDF-tripler. Blanke noder skrives på formen :x, der x er navnet på noden. Hvis en blank node bare nevnes én gang kan vi også skrive dem som []. Vi kan dessuten forkorte spørringen ved å omkranse predikat og objekt med [ ] for å vise at subjektet er en blank node. Videre kan vi forkorte spørringen enda mer: dersom subjektet i to tripler er det samme, kan vi slå sammen to tripler med et semikolon, så vi kun trenger å skrive subjektet én gang. Hvis både subjekt og predikat er de samme i to tripler, kan vi tilsvarende slå triplene sammen med komma. Dette følger forkortingsreglene i Turtle, som beskrevet i Eksemplet ovenfor vil dermed kunne forkortes slik: PREFIX foaf: < SELECT?navn?alder WHERE { [ foaf:name?navn ; foaf:age?alder ] } 4.1 Typer spørringer SPARQL har fire typer spørringer: ˆ SELECT: Returnerer en tabell med verdier for de ønskede variablene. ˆ CONSTRUCT: Lager en ny RDF-graf fra verdier for de ønskede variablene. ˆ ASK: Svarer ja eller nei på om spørringen får treff. ˆ DESCRIBE: Gir et utvalg av informasjon om ressurser. For denne oppgaven er det først og fremst SELECT-spørringer som er relevante.

35 4.2. FILTRE Filtre Vi kan inkludere noen begrensninger vha. filtre. Med filtrene kontrollerer vi om de tilordnede variablene i et resultat følger bestemte regler definert i spørringen. På denne måten skrenker vi inn antallet resultater ved kun å returnere de som oppfyller filtrene. Hvert filter kan bestå av flere filteruttrykk, der hvert uttrykk blir vurdert som sant eller usant for hvert resultat. Under ett må hele filteret vurderes som sant for at resultatet skal returneres. Flere filteruttrykk kan kombineres med &&, som betyr at begge uttrykk må være oppfylt (logisk konjunksjon), eller, som betyr at minst ett av uttrykkene må være oppfylt (disjunksjon). Dessuten kan vi bruke! som logisk negasjon, dvs. at uttrykket skal ikke oppfylles. Blant de forskjellige typer filteruttrykk har vi: ˆ Numeriske filtre, som gjør begrensninger i tallverdier: For eksempel kan vi begrense forrige spørring til personer som er eldre enn 25 år: PREFIX foaf: < SELECT?navn?alder WHERE { [ foaf:name?navn ; foaf:age?alder ] FILTER (?alder > 25) } navn alder ========================== "Ola Nordmann" "30" Merk at vi også har en Lise Nordmann, som har test:aar "1980", i datasettet. Det er naturlig å tenke seg at dette betyr at også hun er eldre enn 25 år. Men vi søker bare etter personer som har foaf:age, og det er på verdien tilknyttet dette predikatet vi bruker filteret på. Derfor vil ikke Lise Nordmann være med i resultatet. ˆ Filtre på verdier som er strenger eller URI-er. Vi kan si at en variabel må tilordnes til en bestemt streng, f.eks.... [ foaf:name?navn ] FILTER (?navn = "Ola Nordmann") men det vil i slike tilfeller være mer naturlig å bestemme dette direkte i trippelen, dvs.:

36 22 KAPITTEL 4. SPARQL... [ foaf:name "Ola Nordmann" ] Mer interessant er det å gjøre videre begrensninger i strenger ved hjelp av regulære uttrykk. Vi kan for eksempel spørre etter navnet på personer i datasettet, begrenset til personer med en L i navnet: PREFIX foaf: < SELECT?navn WHERE { [ foaf:name?navn ] FILTER regex(?navn, "L", "i") } i er en valgfri parameter som gjør at vi ikke skiller mellom store og små bokstaver navn =================== "Ola Nordmann" "Lise Nordmann" Dersom vi ønsker å bruke dette filteret mot strengverdien av en URI, kan man bruke str(?uri). ˆ Filter for at variabler er bundet til en verdi. Vi kan for eksempel spørre etter alle personer som ikke har en verdi for foaf:age?alder: PREFIX foaf: < SELECT?navn WHERE { _:x foaf:name?navn. OPTIONAL { _:x foaf:age?alder. } FILTER (!bound(?alder)) } OPTIONAL beskrives i navn =================== "Per Nordmann" "Lise Nordmann"

37 4.3. OPTIONAL 23 ˆ Det finnes flere andre lignende funksjoner som kan brukes på variablene: isiri(?a), isblank(?a), og isliteral(?a) sjekker om?a er henholdsvis en URI, en blank node eller en literal. Vi kan bruke lang(?a) for å finne språkkoden til en literal eller datatype(?a) for å finne literalens datatype. Dessuten kan man lage sine egne funksjoner som kan fungere som filtre. FILTER kan brukes hvor som helst innenfor gruppen av tripler (med unntak av innenfor et annet trippel). Det vil si at både... WHERE { [ foaf:name?navn ; foaf:age?alder ] FILTER (?alder > 25) } og... WHERE { FILTER (?alder > 25) [ foaf:name?navn ; foaf:age?alder ] } vil gi samme resultat. 4.3 OPTIONAL Vi kan også velge om variablene må være med eller ikke, med nøkkelordet OPTIONAL. For eksempel kan vi spørre etter alle personer som er oppgitt med navn i vårt datasett. Dersom personen også har oppgitt alder, vil dette også returneres: PREFIX foaf: < SELECT?navn?alder WHERE { _:x foaf:name?navn. OPTIONAL { _:x foaf:age?alder. } }

38 24 KAPITTEL 4. SPARQL navn alder =========================== "Ola Nordmann" "30" "Kari Nordmann" "25" "Per Nordmann" "Lise Nordmann" UNION Som i SQL har vi nøkkelordet UNION som gir oss unionen av treff i delspørringer. PREFIX foaf: < SELECT?navn?alder?fodselsar WHERE { { [ foaf:name?navn ; foaf:age?alder ] } UNION { [ foaf:name?navn ; test:aar?fodselsar ] } } navn alder fodselsar ======================================= "Ola Nordmann" "30" "Kari Nordmann" "25" "Lise Nordmann" "1980" Navngitte grafer Datasettet SPARQL kjøres mot, kan bestå av én eller flere RDF-grafer, dvs. separate mengder av tripler. En av disse er ikke navngitt, og kalles

39 4.6. SEKVENSMODIFIKATORER 25 standardgrafen, men datasettet kan også bestå av flere navngitte grafer. SELECT?x FROM < WHERE {... } SELECT * FROM < FROM NAMED < WHERE { GRAPH < {... } } Her kjøres spørringene mot RDF-grafene angitt ved grafenes URI-er. 4.6 Sekvensmodifikatorer Resultatet vi får fra spørringen er en usortert samling med variabeltilordninger. Variabeltilordningene vil så settes i en tilfeldig sekvens. Vi kan lage en ny løsningssekvens ved hjelp av sekvensmodifikatorer. I denne nye løsningssekvensen kan vi ordne og redusere antallet variabeltilordninger. Sekvensmodifikatorene blir anvendt i en bestemt rekkefølge: ORDER ORDER sorterer treffene etter ønsket variabel. PREFIX foaf: < SELECT?navn?alder WHERE { [ foaf:name?navn ; foaf:age?alder ] } ORDER BY?alder Projeksjon Vi kan velge ut kun de variablene vi ønsker. Dette er variablene vi velger i SELECT?navn?alder. Projeksjon anvendes etter ORDER, slik at man kan sortere på variabler som ikke vises.

40 26 KAPITTEL 4. SPARQL DISTINCT DISTINCT fjerner doble treff, dvs. alle løsninger der samlingen av de utvalgte variablene er lik en annen løsning. DISTINCT anvendes etter projeksjon; ellers ville vi beholdt doble treff der de utvalgte variablene er like, mens ikke alle de andre variablene er det. PREFIX foaf: < SELECT DISTINCT?navn?alder WHERE { [ foaf:name?navn ; foaf:age?alder ] } REDUCED REDUCED kan, som DISTINCT, fjerne doble treff, men fungerer forskjellig i forskjellige implementeringer. I motsetning til DISTINCT er det ikke sikkert at den fjerner alle (eller i det hele tatt noen) doble treff. Til gjengjeld kan REDUCED være mer kostnadseffektiv enn DISTINCT. PREFIX foaf: < SELECT REDUCED?navn?alder WHERE { [ foaf:name?navn ; foaf:age?alder ] } OFFSET og LIMIT OFFSET fjerner treff før ønsket radnummer, mens LIMIT kun velger et bestemt antall treff. Disse anvendes til slutt, da de brukes for å vise et utsnitt av en ellers ferdig løsningssekvens. PREFIX foaf: < SELECT?navn?alder WHERE { [ foaf:name?navn ; foaf:age?alder ] } ORDER BY?alder LIMIT 10 OFFSET 20

41 Kapittel 5 Lenkede åpne data Med lenkede åpne data (LOD) er målet å lenke sammen data fra forskjellige datakilder[5]. Dette gjøres ved at vi bruker prinsippet fra RDF om at alle ressurser skal ha en URI. I tillegg skal man kunne slå opp denne URI-en og få informasjon om ressursen. Der det er informasjon som peker til andre ressurser skal disse vises som referanser som kan følges så man kan få informasjon om de andre ressursene, og all informasjon er knyttet sammen. Konvensjonene i RDF sier at en URI som fører til et eksisterende dokument automatisk vil være URI-en som beskriver dokumentet. Dermed kan URI-er til andre ressurser nødvendigvis ikke føre til eksisterende dokumenter. Det kan virke som LODs prinsipp om at man skal kunne slå opp alle URI-er strider imot dette prinsippet, men med LOD benytter man seg av HTTPs redirect-funksjon. Det vil dermed si at når man prøver å slå opp en URI om en ressurs som ikke beskriver et dokument, vil man bli videresendt til et annet dokument som gir informasjon om ressursen. Klient GET <URI> Accept: application/rdf+xml Tjener 303 See other Location: <URL> GET <URL> Accept: application/rdf+xml 200 OK Figur 5.1: Kommunikasjonen mellom en klient og en tjener ved oppslag av LOD-URI

42 28 KAPITTEL 5. LENKEDE ÅPNE DATA Det at informasjonen er distribuert, er den viktigste fordelen LOD har over SPARQL. Med SPARQL må man ha alle data på ett sted, mens med LOD kan man koble sammen data fra flere forskjellige kilder. Det vil også si at man slipper å holde alle data oppdatert; man kan nøye seg med å vedlikeholde sin del av dataene, mens andre sørger for at resten av dataene er oppdatert. Et problem med distribuert informasjon er at informasjon om en ressurs kan være fordelt over mange forskjellige steder. Man kan dermed måtte gjøre oppslag mange forskjellige steder for å finne den informasjonen man ønsker, og man vet ikke alltid hvor den riktige informasjonen ligger. Dette betyr også at man aldri kan si at man har all tilgjengelig informasjon om en ressurs, fordi man ikke kan vite om det finnes en datakilde man ikke kjenner til, som har mer informasjon om ressursen. LOD har dessuten sine begrensninger sammenlignet med SPARQL med tanke på at man ikke kan spørre videre enn det som allerede er lagt ut. Med SPARQL-endepunkter kan man spørre på nye måter, og returnere større mengder informasjon ut fra bestemte utvalg og aggregeringer. Som en kontrast kan man med LOD kun hente ut den informasjon som eieren av LODendepunktet har valgt å knytte mot den spesifikke URI-en man slår opp. Ofte er dette kun informasjon som er direkte, eller i noen tilfeller indirekte via blanke noder, knyttet til ressursen man slår opp. Man må på denne måten på forhånd vite hvilken ressurs man ønsker informasjon om, men ikke engang da kan vi være sikker på at vi får informasjonen vi ønsker. I tillegg kan man ofte ikke gå motsatt vei fra en bestemt informasjonsbit til mer generell informasjon om ressursen. For eksempel kan man slå opp en ressurs som beskriver en person, og se at personen heter Ola Nordmann, men i motsetning til med SPARQL har man ingen måte å finne ressursen til en person ved navn Ola Nordmann.

43 Kapittel 6 Problemet Vår problemstilling er knyttet til spørring av en bestemt type RDF-datakilder. Dette er datakilder som bare returnerer en del av datasettet, og bare dersom man oppgir bestemte inputverdier. Fordi vi må oppgi noen bestemte data for å få tak i andre bestemte data, men ikke kan gå andre veien, har vi kalt dette enveiskilder. Et eksempel på hva som kan være en enveiskilde, er en god, gammeldags telefonkatalog. I trykte telefonkataloger er personer oppført alfabetisk etter navn, og man kan relativt enkelt finne telefonnummeret til en person, så lenge man vet navnet på personen. I de fleste kataloger vil det derimot ikke være aktuelt å prøve å finne personen som eier et gitt telefonnummer. Et digitalt eksempel på enveiskilder er webtjenestene som gir data fra Brønnøysundregistrene. Både fra Semicolons tjeneste nevnt i kapittel og fra Brønnøysundregistrenes andre webtjenester må man oppgi et organisasjonsnummer for å kunne motta andre data, og man kan ikke gå andre veien. Merk for øvrig at selv om de fleste av Brønnøysundregistrenes webtjenester tar organisasjonsnummer som input, har de også en webtjeneste som tar som input en tekststreng, og returnerer informasjon om organisasjoner som har et navn som matcher tekststrengen. Det vil dermed si at vi kan bruke en webtjeneste som går fra organisasjonsnummer til organisasjonsnavn, og en annen webtjeneste som går fra organisasjonsnavn til organisasjonsnummer. Men isolert sett kan man bare gå den ene veien innenfor hver av webtjenestene. Vi kan tenke oss enda flere eksempler, f.eks. en tenkt datakilde som tar som input koordinatene til to punkter, og returnerer avstanden mellom punktene. Her vil det også være umulig å gå andre veien, dvs. gi avstand som input, fordi det vil finnes uendelig med mulige løsninger. I det hele tatt er det mange forskjellige typer datakilder som er aktuelle i problemstillingen.

44 30 KAPITTEL 6. PROBLEMET De leverer forskjellige typer data på forskjellige måter, og med forskjellige typer teknologier. Men felles for datakildene er at de kun returnerer deler av datasettet ved hver forespørsel. Vi snakker ikke om enveiskilder når vi snakker om datasett hvor vi har alle tripler tilgjengelig hele tiden. Problemet vårt blir da: Gitt en spørring, kan vi besvare spørringen med en gitt mengde enveiskilder? Og hvis ja, hvordan? For å ta noen eksempler, gitt webtjenesten til Brønnøysundregistrene: Kan vi finne daglig leder for organisasjonen med et gitt organisasjonsnummer? Svaret blir ja; vi kan slå opp organisasjonsnummeret i webtjenesten som heter hentroller, og vi vil dermed få riktig svar tilbake. Men: Kan vi få en liste over alle bedrifter i en gitt kommune? Her blir svaret nei, fordi vi ikke har noe sted å bruke kommune (kommunenummer) som inputverdi, og som returnerer en mengde organisasjoner. I teorien kan vi tenke oss at vi kan slå opp hvert eneste tenkelig organisasjonsnummer i webtjenesten, få tilbake data om hvilken kommune organisasjonen ligger i, og samle opp alle bedrifter med riktig kommune til vi til slutt har alle bedrifter i kommunen. Problemet med dette er at det vil være altfor ressurskrevende, og det er derfor en måte vi ikke ønsker å gjøre ting på. Men selv om vi ikke kan svare på en gitt spørring ved hjelp av en bestemt datakilde, kan det likevel hende at vi kan bruke en annen datakilde. Hvis vi har flere datakilder betyr det at det er mer sannsynlig at vi klarer å svare på spørringen, fordi det er nok for oss at én av dem kan besvare spørringen. Flere datakilder vil likevel komplisere problemet. En datakilde kan f.eks. delvis besvare en spørring, mens en annen kan besvare resten. Eventuelt kan en datakilde ut fra inputverdiene gi et helt annet svar enn det vi var på jakt etter, mens en annen datakilde kan bruke dette svaret til å finne det riktige svaret på spørringen. La oss for eksempel tenke oss at vi ønsker å finne ut hvor langt det er mellom to kommuner i Norge. Vi har to kommunenumre som vi kan bruke som input, og vi ønsker avstanden mellom kommunene i retur. Men vi har ingen datakilder som har nøyaktig dette som input og output. Derimot kan vi tenke oss at vi har en datakilde som tar et kommunenummer som input og returnerer koordinatene til kommunen, og en annen datakilde som tar to koordinater og returnerer avstanden mellom dem. Dermed vil vi kunne bruke den første datakilden til å hente data som vi ikke direkte spør etter, men som vi kan mate inn i en datakilde som gir oss det vi ønsker. På grunn av slike eksempler må vi kunne koble sammen flere datakilder. Men hvordan kan vi vite hvilke datakilder som skal kobles sammen, og hvilke datasett som skal hentes fra datakildene? Vi har prøvd å formulere problemet matematisk, men vi har ikke klart å få et presist begrep om avgrensning. Problemet så vi tidligere med spørsmålet om alle bedrifter i en gitt kommune. Vi mener at det ikke er hensiktsmessig å slå opp alle organisasjonsnumre som finnes, selv om det i prinsippet er mulig.