Podes prosjektblogg

Tradisjonell v.s. semantisk mashup

Postet den 7. January 2011 | Skrevet av Magnus | 1 kommentar

Jeg har i løpet av de siste par årene hatt gleden av å bidra på 4 ulike mashups for Pode, to basert på tradisjonelle APIer og to helt eller delvis basert på SPARQL endpoints. Denne bloggposten prøver å si noe om fordeler og ulemper med disse to typene av datakilder.

Kort fortalt tror jeg tradisjonelle APIer er lettere å forholde seg til enn et SPARQL endpoint når man skal lage sin første mashup. Stort sett handler det da om å finne ut hvilke parametere en tjeneste kan ta i mot, og hvilke verdier de kan ha. Med REST-fulle tjenester er det så enkelt som å konstruere en URL med de ønskede parameterne.

Ulempene med tradisjonelle APIer oppdager man etter hvert som man tar i bruk flere: alle har sine egne parametere med egne tillatte verdier, og man må finne ut av alt sammen fra bunnen av igjen for hvert nye API man prøver seg på. Dette i motsetning til SPARQL endpoints som alle sammen tilbyr den samme “mekanismen” for å hente ut data. SPARQL har en brattere læringskurve enn de fleste APIer, men når man først har lært seg det kan man overføre lærdommen fra en datakilde til en annen.

Når det er sagt er det et par potensielt problematiske sider ved SPARQL også: Det ene er at måten dataene er beskrevet på kan variere fra endpoint til endpoint, dvs hvilke ontologier som er brukt, og kanskje også hvordan de er brukt. Man har strengt tatt ingen garantier for at de om står bak har en felles forståelse av hvordan en ontologi skal brukes. (Vi får imidlertid håpe at det her vil foregå prosesser som gjør at man beveger seg mot økende grad av konsensus, ikke mot økende kaos…) Foreløpig virker det også noe tungvint å orientere seg i en et ukjent endpoint, for å danne seg et bilde av hvilke data som finnes der og hvordan de er beskrevet (med mindre det finnes dokumentasjon som gir gode svar på dette). Dette kan skyldes undertegnedes korte erfaring med SPARQL og det kan også vise seg at dette blir avhjulpet etter hvert av verktøy som kan gjøre det lettere å få oversikten over hva som er i en triplestore og hvordan det er beskrevet.

Et annet potensielt problem med SPARQL vil oppstå dersom vi etter hvert får

  • mange ulike versjoner av SPARQL – i dag har vi versjon 1.0 og 1.1 er på vei, men hvem vet hvor langt vi har kommet om 10 år?
  • ulike og mangelfulle implementasjoner av SPARQL, slik at man blir sittende og lure på hvilke operasjoner et endpoint støtter, omtrent slik man jakter på parametere for tradisjonelle APIer.
  • tjenester som ikke oppdateres etter hvert som det kommer nye versjoner av SPARQL og/eller triplestore-programvare.

Vi kan i og for seg se tendensene til disse problemene med den triplestoren Pode har benyttet (ARC), som støtter SPARQL og noe de omtaler som SPARQL+, som later til å være en forsmak på funksjonalitet som er planlagt i SPARQL 1.1. Forhåpentligvis vil de færreste prosjekter velge å selv implementere sin egen SPARQL-funksjonalitet når de skal gjøre data tilgjengelig, men heller gjenbruke eksisterende systemer, slik at antallet ulike implementasjoner blir så lavt som mulig. Tilstedeværelsen av gode triplestores/endpoints som er tilgjengelige som fri programvare vil forhåpentligvis bidra til dette.

En annen stor fordel med SPARQL som semantisk datakilde er at det innebærer et helt spørrespråk (query language), i motsetning til en liste med parametere i tradisjonelle APIer. Hvis man tenker seg parameterne i et tradisjonelt API som forhåndsdefinerte spørsmål det er mulig å stille til en tjeneste, så åpner SPARQL opp for en mye større fleksibilitet, i og med at det blir mulig for utviklere å stille en tjeneste “spørsmål” som de som står bak tjenesten aldri ville tenkt på å gjøre det mulig å stille gjennom et tradisjonelt API.

Konklusjon? Semantiske datakilder innebærer større muligheter for gjøre interessante ting med data enn det man får gjennom tradisjonelle APIer, men de innebærer også en brattere læringskurve. Alle som er involvert i utviklingen av semantiske datakilder bør jobbe bevisst for å unngå fragmentering av de semantiske datakildene, og bidra til en enhetlig utvikling gjennom åpne standarder, konsensusløsninger og fri programvare.

Vi lever i spennende tider!

Kommentarer

Et svar på “Tradisjonell v.s. semantisk mashup”

  1. Tweets that mention Tradisjonell v.s. semantisk mashup : Podes prosjektblogg -- Topsy.com
    January 8th, 2011 @ 00:01

    [...] This post was mentioned on Twitter by Jonas Svartberg and keithalexander, Podeprosjektet. Podeprosjektet said: Tradisjonell vs semantisk mashup. Erfaringer og tanker etter 2 år med utvikling av 4 mashuper i Podeprosjektet; http://bit.ly/gSgIGn [...]

Legg igjen en kommentar





  • RSS Linked data

  • RSS Semantic web

  • RSS FRBR

  • RSS Eksempler på mashups

  • RSS Tilgjengelig innhold

  • RSS Eksempler på katalogsøk (både trad og sosiale SOPAC

  • RSS Eksempler på systemer/produkter i bruk

  • RSS Fakta om/dokumentasjon av systemer/produkter

  • RSS Eksempler på biblioteksider