Data.norge.no. 13. september Revidert Løsningsbeskrivelse. Tilbud : anbud på utvikling av data.norge.no (DL ) Innholdsfortegnelse

Transkript

1 Data.norge.no Saksnr: 2010/01092 Vårref: CXT september 2010 Revidert Løsningsbeskrivelse Tilbud : anbud på utvikling av data.norge.no (DL ) Innholdsfortegnelse 1 Om revidert løsningsbeskrivelse Denne beskrivelsen utdyper, men erstatter ikke, beskrivelsen gitt av svarene til kravspesifikasjonen og løsningsbeskrivelseskapittelet gitt i tilbudets vedlegg. Bakgrunnen er FADs ønske om noe mer begrunnelse for komponentvalgene, mer detaljer i løsningsbeskrivelsen og detaljering av noen av svarene. Når det i teksten refereres til de individuelle kravene i kravspesifikasjonen er dette markert med kursiv. Kapittel 2 beskriver arkitektur og komponentene i detalj, kapittel 3 beskriver konkrete valg i forhold til FADs krav. Kapittel 4 beskriver vurderinger og konklusjoner med hensyn til begrunnelse for komponentvalg. Kapittel 5 beskriver oppdatert prisnedbrytning.

2 2 Teknisk løsning og arkitektur Basert på FADs utlysning vil følgende funksjonalitet dekkes av løsningen: (1) en publiseringsløsning for å vedlikeholde sider med innhold knyttet til temaet, (2) en blogg for deling av informasjon og offentlig debatt om temaet, (3) en katalog med metadata om tilgjengelige, offentlige datasett, (4) en katalog med metadata om applikasjoner som utnytter offentlige datasett, og (5) en applikasjon for visualisering av eksempeldata. Punkt 1, 2, 4 og 5 vil i hovedsak dekkes av CMS-systemet Drupal, mens 3 hovedsak vil dekkes av katalogsystemet CKAN. Figuren under illustrerer systemets komponenter. Dette er en detaljering av figuren levert med det opprinnelige tilbudet. Figure 1 - detaljering av systemskisse I det følgende to del kapittel går vi i dybden på Drupal og CKAN. 2.1 Drupal CMS Om Drupal Drupal er valgt som det grunnleggende CMS (Content Management System) i løsningen. Det er flere grunner til dette, men hovedsakelig er dette valgt fordi vi ønsker å benytte oss av mest mulig åpen teknologi for publisering, blogging og generell administrasjon av nettestedet. Drupal er en fritt tilgjengelig web publiseringsløsning basert på åpen kildekode. Produktet er utviklet med PHP og benyttes av et stort antall nettsteder over hele verden. Drupal er meget modulbasert og har et godt rammeverk for å utvide løsningen med nye moduler og funksjoner. Avhengig av valgt malverk er løsningen godt tilrettelagt for å tilfredsstille de WAI/WCAG krav som beskrevet i kravspesifikasjonen fra kunden. En av de store fordelene med å benytte seg av Drupal er det store engasjementet som har eksistert over lengre tid innen det å støtte semantiske teknologier og moduler. Det finnes flere moduler som kan benyttes hurtig og enkelt for å kunne tilpasses kundens behov. Drupal benyttes i dag av flere løsninger innen open-data, blant annet data.gov.uk. Data.gov.uk er et prosjekt nært opp til hva Kunden etterspør. For å gjøre det videre arbeid så hurtig og kostnadseffektivt som mulig er det ønskelig å benytte så mye som

3 arbeid så hurtig og kostnadseffektivt som mulig er det ønskelig å benytte så mye som mulig av eksisterende løsninger og programvare. Leverandøren har gode relasjoner med miljøet rundt data.gov.uk og ønsker å benytte seg av disse under prosjektgjennomføringen. Både for å kunne nyttiggjøre seg av nyutvikling der, men også for å kunne føre opparbeidet kompetanse og utviklet kode tilbake til fellesskapet Standardinstallasjonen I den tilbudte løsningen er flere moduler tenkt benyttet, det er dog ikke besluttet en endelig liste over moduler. Det endelige valget vil bli foretatt i løsningsbeskrivelsesfasen og under gjennomføringen av prosjektet (se fremdriftsplan). Men med utgangspunkt i hva som er kjent i dag tror vi at vi vil trenge minimum disse modulene: Drupal Core o Publisering, blogg, forum, administrasjon Administration Menu Pathauto o Modul som bygger opp brukervennlige linker til sider basert på regler Views o Modul som gjør at man kan lage egne visninger av innhold Content Construction Kit (CCK) o Modul som benyttes av andre moduler FileField o Modul for å laste opp og vise filer på nettstedet, trenger CCK ImageField o Modul for enkelt å kunne laste opp bilder på nettstedet, trenger CCK GoogleAnalytics o For å kunne tilby analyse av trafikk og innhold på sidene. WebForm o Skjemabygger for å kunne tilby kontakt-skjema m.m. Wysiwyg o En forbedret redigeringsfunksjon for å redigere blogger, forum-poster m.m. o Finnes flere alternative løsninger for dette, kan endres avh. av behov. Nodewords o Metadata på sider Link o Gode lenker til eksterne kilder Panels o For å bygge en side der innhold grupperes som ønsket på siden. Internationalization o Modul for å forenkle støtte av flerspråklighet i løsningen Menu Breadcrumb Taxonomy Manager I tillegg til disse modulene vil det kanskje være nødvendig med noen moduler for å støtte samhandlingsgrupper i løsningen. Det vil si grupper som administrerer seg selv og som får egne gruppe-sider Publiseringsfunksjonalitet (CMS) Drupal tilbyr et relativt enkelt og brukervennlig grensesnitt for publisering på ett nettsted. Det er mulig å legge opp til en løsning der flere brukere har forskjellige rettigheter. Ved å benytte seg av moduler som er enkle og hurtige å implementere kan man tilby funksjonalitet skreddersydd for de fleste brukerbehov. Når man er pålogget kan man enkelt publisere flere typer innhold. Under kan man se et eksempel på en drupal-installasjon som er satt opp til å støtte blog, forum og et enkelt utvalg av andre innholdstyper.

4 Figur 1: Drupal som CMS Tilgangen til de forskjellige innholdstypene kan variere basert på brukerrettigheter, blant annet ved å installere moduler for å konfigurere tilganger til dette Bloggfunksjonalitet Bloggmulighetene i Drupal er veldig gode. Det er også mulig å legge til støtte for å benytte seg av Windows Live Writer eller andre blogg-redigeringsverktøy som kan publisere blogg-innlegg via API er Med å inkludere flerspråklig-støtte kan man enkelt også synliggjøre blogg-innlegg og andre innholdselementer kun for de språk hver enkelt bruker til enhver tid benytter. Det vil si at et blogg-innlegg på bokmål kun er tilgjengelig for de som sier at de vil lese sidene på bokmål. Det er støtte for kategorier, tagging og rss-lister for å tilgjengeliggjøre blogg-innlegg på en hver ønskelig måte. Det er også mulighet for lesere og medforfattere å kommentere på blogg-innlegg. Ved å sette riktige rettigheter kan man enkelt lage en godkjenningsprosedyre som sikrer at kun godkjente kommentarer blir synlige på nettstedet.

5 Figur 2: Eksempel på blogg-post Diskusjonsforum Den sterkeste funksjonaliteten til Drupal er den innebygde forum-støtten. De fleste andre PHP-baserte CMS-verktøy krever egen Forum-modul for å tilby slik støtte, men dette er innebygget i Drupal og gjør at integrasjonen med andre informasjonselementer fungerer på en utmerket måte. Ved å bygge opp forum-hierarkiet på en gjennomtenkt måte kan man enkelt strukturere forum og innlegg for å tilby forskjellige forum til forskjellige brukergrupper og delegere moderering av innlegg og kommentarer til de forskjellige administratorene Administrativ funksjonalitet Drupal har et meget kraftig administrasjonsgrensesnitt som enkelt kan utvides med mer funksjonalitet og flere moduler. Det planlegges å gjøre dette enda enklere og lettere tilgjengelig i neste versjon av Drupal (versjon 7.0) som er ventet å komme om ikke lenge.

6 lenge. Figur 3: Enkelte administrasjonsfunksjoner CKAN integrasjon CKAN er nylig blitt tilgjengeliggjort som en drupal-modul av data.gov.uk. ( ) og gjør det mulig å publisere CKAN-katalogen på en søkbar og navigerbar måte. Selve implementasjonen gjøres ved at man importerer metadata fra CKAN og lager noder (innlegg) i Drupal som inneholder de nødvendige metadata for å kunne nyttiggjøre seg slike datakilder. I den tilgjengelige koden fra data.gov.uk som leverandøren har tenkt å ta utgangspunkt i er det satt opp ferdige kommandoer som henter ned alle nye og endrede metadata fra CKAN til de tilsvarende informasjonselementer i Drupal. Dette gjør at vedlikeholdsarbeidet på tvers av CKAN og Drupal blir enklest mulig og at dobbeltredigering av data blir holdt på et minimum. Ved å vedlikeholde data i CKAN vil også all informasjon i Drupal bli oppdatert når man kjører oppdateringsscriptet Visualiserings-funksjonalitet Til dette benyttes Google Chart Tools. Google Chart Tools er en pakke med visualiseringsverktøy som er fritt tilgjengelig fra Google. Man kan enten lage diagrammer som bilder eller interaktive diagrammer basert på JavaScript.

7 Figur 4: Eksempel på diagrammer Figuren over viser grovt forskjellen på et bilde og et interaktiv diagram, men det dynamiske aspektet kan naturligvis ikke dokumenteres. Det nederste diagrammet tilbyr brukerne å trykke på kake-diagrammet for å få mer informasjon, eller holde musen over de forskjellige kart-områdene for å få opp detaljer om dette landet. Siden dette, etter ønske fra Kunden, vil være begrenset bruk i denne første releasen, forutsettes det at eksempel-dataene legges ut som JSON og følger Google Chart Tools JSON skjema. Basert på dette vil vi redusere vårt estimat fra 70 timer til 20 timer for Google Chart Tools integrasjon. De resterende 50 timene blir flyttet til å forbedre språkstøtten i CKAN Apps-katalogen Applikasjonskatalogen er langt mer begrenset enn datakatalogen, og det velges å implementere denne som en egen innholdstype i Drupal. Feltene som skal beskrive en app er i utgangspunktet identifikator URL Tags/emner Screenshots Dette er også løsningen som er valgt i data.gov.uk. 1. OKN opplyser at det i EUprosjektet LOD2.eu 2, som de er deltakere i også arbeides med å inkorporere denne type bruksinformasjon i CKAN. Når dette er blitt en del av CKAN implementasjonen kan man enkelt lage konverteringsscript som overfører de data som har blitt redigert i Drupal over til CKAN og deretter la dette gå som en del av den vanlige CKAN-importen som er beskrevet tidligere. Denne konverteringen er ikke en del av tilbudt løsning RDFa-støtte RDFa 3 er en W3C-standard på hvordan man kan kombinere strukturerte data med mennesketolkbar HTML. Dedikerte browsere og crawlere kan dermed tolke denne informasjonen som om det var en database. I Drupal7 benyttes RDFa for metadata om en artikkel, blogpost m.m. I hovedsak dreier dette seg om metadatafelter som forfatter, overskrift osv. tilsvarende RSS/ATOM felter. Datakatalogen som RDFa Kravspesifikasjonen spesifiserer RDFa kun for informasjon, ikke katalog-data. I det følgende illusteres likevel hvordan data.gov.uk og data.australia.gov.au har også publisert katalogen som RDFa i en HTML side. Dette illustreres kun som en mulighet for 1) ønske om å benytte katalogen som en datakilde (krav Katalogen over offentlige datasett [..] skal gjøres tilgjengelig i standardiserte, strukturerte, maskinlesbare formater), og 2) ønsket om å vise et datasett på annen portal (ref under). Løsningen illustrerer en tilnærming for å oppfylle dette kravet. Det er imidlertid som også svart i kravspesifikasjonen en dump av hele katalogen i format (RSS, RDF og JSON) som er inkludert i tilbudet). Eventuell annen løsing for oppfyllelse av dette kravet kan vurderes i en løsningsbeskrivelsesfase. I data.gov.uk har man benyttet RDFa ut over hva Drupal gir ut av boksen. Man har lagt til rette for å eksponere datasettene som RDFa i HTML 4, f.eks. < dct:coverage "Great Britain (England, Scotland, Wales)"@en ; dct:created " "@en ; dct:creator "Department for Environment, Food and Rural Affairs"@en ;

8 dct:isreferencedby < ; dct:license "Crown Copyright"@en ; dct:source < < ; dct:subject < < < < < < Dette muliggjør at man enkelt kan bygge interessante klienter utenfor data.gov.uk som benytter katalogen som et datasett. Man kan f.eks. lage enkle script som leter gjennom alle dct:source og ser om de faktisk er gyldige/dvs datasettet selv er tilgjengelig 5. Et liknende eksempel er om etat ønsker å kan trekke ut de datasett publisert av en selv, og i tillegg til å presentere dem på data.norge.no, vis og visualisere dem på egne sider. (REF KRAV: 1.6.1) python rdfa.py 6 som returnerer eksempelet over. 2.2 CKAN - Datakatalogen CKAN er et katalogsystem for å beskrive kunnskapsressurser. Primært er dette beskrivelse av datasett som selv refereres til med en URL. I løsningen fungerer CKAN som en back-end til Drupal, samt en infrastruktur for synkronisering med andre register, i tillegg til administrativ tilgang til datasettbeskrivelsene. Det er ulike løsninger når det gjelder redigering av datakatalogen. I data.gov.uk er CKAN brukt av etatene direkte for å legge inn og redigere data sett beskrivelser. CKAN opplyser imidlertid at de også har andre som benytter facading, slik at f.eks. Drupal benyttes på toppen av administrasjonsgrensesnittet. Det ble i kontraktsforhandlingsmøtet spurt hvorvidt vi ønsket at etatene skal gå via CKAN eller Drupal for å registrere nye datasett. Det er å foretrekke at dette gjøres via CKAN, da det allerede finnes import-funksjonalitet som importerer nye og endrede data fra CKAN inn til Drupal automatisk. Dette gjør at de som skal publisere slikt innhold ikke trenger å registrere informasjon 2 steder. CKAN har et web grensesnitt som håndterer mye du trenger i av katalogfunksjoner. De forteller det er lett å utvide dette web-grensesnittet om ønskelig. Vi vil uansett tilby administrasjonsfunksjonaliteten som ønskes, og vil ønske å vurdere disse valgene opp mot hverandre i en løsningsbeskrivelsesfase sammen med kunden. I standardinstallasjonen av CKAN er et datasett er beskrevet med minimum (mapping til Dublin Core i parentes) identifikator (dct:identifier) tittel (dct:title) URL (dct:source) forfatter (dct:creator) forfatters e-post (dct:agent/foaf:mbox) versjon (dct:version) notat (dct:description) lisens (dct:license) tags

9 Skjemaet kan utvides på med nye felter gjennom migrering 7 eller utvides med mange metadatafelter (kalt tags ).. Computas vil her anbefale bruk av Dublin Core Terms (DC Terms) så langt det lar seg gjøre, og utvide disse metadatafeltene etter behov. Et av DC termene er dct:subject som normalt peker på en liste av tematiske emner. Disse vil bli representert i thesauri-form med SKOS vokabularet. Det anbefales å bygge opp en taksonomi tilsvarende som er gjort ved data.gov.uk 8 ikke å forveksles med CKAN tags/metadatafelter. CKAN API 9 kan benyttes til å lese og manipulere katalogen utenfra. APIet er RESTful, dvs. det benytter standard Web-tekniske protokoller (HTTP GET, PUT, POST og DELETE) til å lese, søke, legge til og slette elementer i katalogen. Det er dette grensesnittet som benyttes av Drupal-CKAN modulen som nevnt tidligere. Som eksempel på CKAN APIet kan man taste følgende i browseren Dette gir tilbake en JSON serialisering av et datasett direkte fra katalogen Applikasjonskatalogen Data.uk.gov benytter Drupal direkte for applikasjonskatalogen. Siden applikasjoner så langt er begrenset, og ikke gjenomgår like sterke versjoneringsbehov, er dette en design som har blitt valgt her. OKFN forteller at dette også kan gjøres i CKAN med utvidelser her, eller med plugin støtten som finnes i CKAN. Leverandøren tilbyr altså applikasjonskatalogen som en del av Drupal Versjonering CKAN versjonerer automatisk alle endringer til metadata. Se for eksempel COINS data 10. Denne viser historikken av editeringer til en konkret data pakke på CKAN. Grunnet underliggende versjonerte datamodell, kan CKAN opptre som en wiki for datasett, der alle kan legge til materiale understøttet av versjonskontroll. Visning av bestemte versjoner må forøvrig understøttes av front-end CMS, Drupal (se forøvrig avsnitt under) Flerspråklighet Utgangspunktet her er ikke flerspråkligheten til web løsningens (internasjonalisering), men hvorvidt det i CKAN finnes støtte for flere språk for hvert attributt (f.eks. tittel). Dette vil for Norge f.eks. være aktuelt for å kunne beskrive et datasett på bokmål, nynorsk, samisk og engelsk tilsvarende dct:title "Antall skipsanløp fordelt på ulike typer skip"@no dct:title "Number of ship entries grouped by type of ship"@en I dagens CKAN løsning løses dette ved å lage flere pakker og relatere dem. OKFN har imidlertid forsikret oss om at vi er en av flere som har ønske om en slik funksjonalitet, og vurderer å starte utvikling i denne retning. Computas vil, på vegne av data.norge.no, bidra til å adressere dette, og bidra til en slik forbedring av CKAN. Dersom det er ønskelig fra Kunden vil Leverandøren gjennom data.norge.no leie inn en CKAN utvikler som underleverandør for å bidra til at denne funksjonaliteten blir utviklet. Leverandøren er allerede i kontakt med OKFN representanter med tanke på dette Oppsett og vedlikehold Installasjon av CKAN i seg selv er rimelig rett fram og tar godt under én dag. Tilpassninger i felter o.l. vil kreve databaseoppdateringer, det foreligger detaljerte beskrivelser på hvordan dette gjøres Beskrivelse av Katalogen

10 Som en forlengelse av i dette dokumentet illustreres her hvordan beskrivelse av datakatalogen som det eneste datasettet i løsningen kan bygges opp på en standardisert måte. Det understrekes at dette er illustrativt. Leverandøren tilbyr en nedlasting av hele datasettet i hertil egnede formater som nevnt i avsnitt DERI 11, det største forskningssenteret for semantisk web og linked open data i Europa, har utviklet DCAT vokabularet 12. Dette vokabularet beskriver utveksling av databeskrivelser mellom data kataloger. Meningen er å benytte dette til å utveksle katalogdata mellom f.eks. data.gov og data.gov.uk. Vokabularet utvikles i W3C regi. Figure 2 - Beskrivelsen av et datasett og dets katalog Dette svarer forøvrig bra til kravet om at katalogen skal være tilgjenglig som datasett. Data.gov.uk benytter altså dublin Core og DKAT beskrivelser av alle datasett når de eksponeres som data (RDFa) (ref krav 1.6.1) CKAN og geodata CKAN støtter lagring av datasett med geografiske beskrivelser. Det er imidlertid viktig å skille mellom Geografiske Informasjonssystemer (GIS) og geodata. Register/repositories som lagrer GIS data har normalt en bounding box beskrivelse for hvert data sett. Det å legge til en bounding box forutsetter beskrivelser ut over hva som er normalt utenfor GIS verden. Liknende funksjonalitet oppnås normalt med gazzateer eller stedsnavn og lokasjonspunkter. F.eks. vil pakker merkes med dct:subject Oslo, og dermed kunne hentes basert på å browse emnet Oslo. Med beskrivelse av Oslo som del av Østlandet vil også Oslo kunne inkluderes i treff som gjelder Østlandet. Disse hierarkiske beskrivelsene gjøres normalt med standarden SKOS 13. I eksempelet vårt illustreres dette som < a skos:concept ; skos:broader < Denne muligheten benyttes i dag ikke av data.gov.uk, men CKAN har mulighet for å lage hierarkiske emnelister, som så kan eksponeres som RDFa. Det understrekes at løsningen som tilbys vil datasett beskrivelsene ha lokasjonsinformasjon som en metadata-attributt, ikke som en GIS bounding box. Krav refererer til relaterte datasett og navigering i metadata. Kategorisering kan benyttes til å bygge opp geografiske relasjoner. Dette vil detaljeres i en løsningsbeskrivelsesfase Status CKAN, pågående videreutvikling og videre planer Interessen for CKAN har dramatisk økt etter at CKAN ble tatt i bruk av data.gov.uk. I dag finnes CKAN for flere enn 10 installasjoner bl.a.

11 dag finnes CKAN for flere enn 10 installasjoner bl.a og Like mange er på trappene. Av pågående utvikling er det spesielt fokus på relasjoner mellom pakker (depends-on, derived-from), og detaljert statistikk. Blant temaer som kommer opp i forbindelse med videre planer er å vurdere en RDF backend til CKAN 14. Det finnes allerede en implementasjon av dette 15 som også har et SPARQL endpoint. En slik migrering kan forventes over tid, og vil gi bedre muligheter for skalerbarhet med tanke på beskrivelser (felter), content negotiation, spørringer, sammenstilling av datasett m.m. Leverandøren vil sørge for god kontakt med CKAN-miljøet nøye gjennom et eventuelt prosjekt, og sørge for at ønsker fra Kunden blir hørt. 3 Svar til FAD I det følgende utdypes konkrete spørsmål som dukket opp i forhandlingsmøtet 6/ Språkstøtte Drupal har god støtte for flerspråklige nettsteder og ved å benytte seg av riktige moduler er det mulig å ha innhold som filtreres avhengig av hvilket språk brukeren har valgt når man besøker nettstedet (GUI-språk). Dette betyr at innhold som er produsert i Drupal (blogg, forum, o.l.) kan separeres avhengig valgte språk. Når det gjelder språkstøtte for metadataene (beskrivelsene av datasettene) er det litt mer komplisert. Dagens CKAN løsning baserer seg på kun et felt per attributt. Det betyr at f.eks. tittel (dct:title) vil vise det samme for enhver endring i GUI-språk. Computas har vært i dialog med CKAN knyttet til å innføre språkavhengige attributter. I praksis vil det bety at tekst-felter (dct:title, dct:description osv.) vil kunne ha flere varianter avhengig av språk. Det betyr forøvrig at også innleggingen i hovedsak bør inneholde å legge inn tekst-felter på flere språk. Computas setter av 50 timer til å gjøre dette gjennom et samarbeid med CKAN Versjonering Drupal har god støtte for versjonering av Drupal-innhold. Versjonering av CKAN innhold gjøres, så langt vi har klart å faststlå, ved at to forskjellige versjoner av ett element får to forskjellige informasjonsobjekter i Drupal. Dermed vil versjonering av datakilder fungere relativt uproblematisk fra Drupal sin side. Det er ikke inkludert å lage egen versjoneringsløsning i Drupal utover det som finnes i CKAN-modulen for Drupal Om integrasjonsstøtten CKAN Drupal Ved å benytte seg av de ferdig utviklede integrasjonsmuligheter som finnes i Drupal modulen utviklet for data.gov.uk vil man kunne sette opp automatisk integrasjon mellom CKAN og Drupal. Leverandøren vil da for eksempel kunne sette opp en automatisk oppdatering av Drupal innhold hver natt, eller hver time. Se også kapittel i dette dokumentet CMS er det noen grunn til å bruke noe annet Det er flere gode CMS-verktøy basert på åpen kildekode. Noen av de største er Drupal, Joomla og EZPublish. Joomla har noe enklere administrasjonsgrensesnitt, men her kommer Drupal med vesentlige forbedringer i neste versjon (versjon 7). Drupal har vesentlig bedre utvikler-støtte og virker å være enklere å utvide med moduler og annen funksjonalitet. Den største fordelen med Drupal er den gode støtten de har fått for åpne-data implementasjoner og semantisk web standarder.

12 Når det gjelder utbredelse så har Drupal bevist at de kan implementeres i store løsninger og med for et stort antall samtidige brukere Design: 60 timer Det er tenkt at man skal ta utgangspunkt i samme mal som benyttes av data.gov.uk og tilpasse denne til designmalen til FAD og data.norge.no Det er ikke tenkt å benytte seg av en designer for å lage en fullt tilpasset mal fra bunnen av for denne løsningen da dette vil ta mer enn 60 timer. Ved å basere seg på såkalt beste praksis vil vi kunne lage en brukervennlig og spennende løsning for data.norge.no basert på den funksjonalitet og de malverk som finnes som en del av Drupal Ideal kildekode (HTML) I alle webløsninger er det utfordringer med å tilby brukerne å publisere informasjon. En webredaktør kan ødelegge en side ved å legge inn dårlig formatert html uten at utviklere kan hindre dette. Kvalitet på kildekode er dermed avhengig av flere elementer. Det legges opp til å benytte seg av malverk og konfigurasjon som i størst mulig grad tilfredsstiller de WAI/WCAG krav kunde har spesifisert i kravspesifikasjonen. Det vil også bli kjørt validering av HTML-kode for å sikre at den genererte koden tilfredsstiller de krav som finnes til god HTML-kode. For å validere den informasjon som vil bli tilgjengeliggjort gjennom løsningen anbefaler leverandøren at man jevnlig kjører validering av sider på nettstedet for å sikre at det som publiseres av innhold også tilfredsstiller de samme krav til kvalitet. Leverandøren kan bidra med å sette opp noen automatiserte tester Dublin Core ønsker vi å bruke det? Dublin Core, eller mer spesifikt, Dublin Core Term Set er et sett av egenskaper som benyttes for å beskrive et informasjonselement. Dette kan være artikler, blogposter, forum eller datasett. Leverandøren vil benytte Dublin Core som det grunnleggende settet av egenskaper (eksponert gjennom RDFa) Blog funksjonalitet Se kapittel Krav : Hvordan håndtere 601 virksomhetsrepresententer? På dette punktet er det avsatt noe tid til en initiell enkel sjekk basert på følgende scenario (scenarioet kan detaljeres noe under løsningsbeskrivelsesfasen). Brukere som ønsker å legge inn informasjon må komme fra et offentlig domene. Representantene må med andre ord ha en e-post adresse med domene fra en liste som foreligger i løsningen. Når en bruker registrerer seg blir det gjort en sjekk mot denne listen. Deretter går det ut en e-post til brukerens adresse. Når denne bekreftes (med en link i e-posten) vil brukeren kunne legge inn datasett for dette domenet Relatert til krav spurte Kunden om eventuell gjenbruk av løsning fra geonorge.no. Geonorge er Norge Digitalt sitt nasjonale nettsted for geografisk stedfestet informasjon i Norge. Geonorge er primært en karttjeneste som er tilgjengelig for partene i Norge Digitalt. Geonorge har en ticket tjeneste, BAAT 16, som gjør at autentiserte brukere skal kunne laste ned digitalt innhold. Det sikrer både en tilgangskontroll og statistikk på bruk. Leverandøren ble forespurt om hvorvidt tjenester herfra kan gjenbrukes av data.norge.no. I data.norge.no er det ikke lagt opp til et registeringsbehov for å hente data, primært fordi det faktisk ikke er data tilstede i løsningen, men også fordi hovedformålet er å gjøre det enkelt å bruke data (så enkelt at man ikke bør behøve å registrere seg).

13 Når det gjelder innlegging av pakker (datasett beskrivelser) vil det derimot være behov for registering. Imidlertid anses en ticket-løsning for lite relevant ettersom det kun er behov for autentisering mot domene. BAAT serveren gir deg først og fremst en ticket som er ment for å overvåke hvem som gjør nedlasting, mens det i data.norge.no er det hvem som gjør opplasting. Registering bør være tilstrekkelig i en slik løsning. Slik BAAT-løsningen fremkommer på websidene oppfattes også som en tjeneste som krever en manuell behandling av forespørselsene gjennom portalen. Dette oppfattes som uheldig. Leverandøren mener derfor at løsningen er mer komplisert enn ønskelig, og lite egnet for data.norge.no. En autentisert kobling mellom domene og e-postadresse som beskrevet i anses som en bedre løsning Autoimport av beskrivelser Det er svært aktuelt å autoimportere beskrivelser av datasett. I tillegg til å kunne lage enkle rutiner basert på REST-APIet til CKAN, finnes det allerede import rutiner her. CKAN-løsningen har import rutiner for import 17 som rangerer fra Excel til CSV import. Avhengig av hvorvidt Kunden ønsker å endre default oppbygging av katalogen, må også disse importskriptene modifiseres. Katalogens oppbygning, f.eks. hvilke felter som ønskes benyttet - se forøvrig kapittel 2.2 og ev. beskrankingskrav, vil detaljeres sammen med Kunden i en løsningsbeskrivelsesfase. Leverandøren ønsker å tilby i alle fall én enkel importrutine for autoimport Vise kataloginformasjon på andre portaler Kunden ønsker å kunne vise kataloginformasjon på andre nettsteder og spurte spesifikt om for eksempel å benytte iframes for dette. Dette er mulig, men av flere årsaker vil ikke Leverandøren anbefale dette. I stedet vil vi anbefale å lage en liten html/javascript snutt som kan enkelt kopieres inn på en side og som igjen vil hente innhold fra data.norge.no. Et eksempel på slik kode finnes på YouTube eller Flickr for å inkludere video/bilde på et eksternt nettsted. Alternativt kan kataloginformasjonen vises som RDFa (se kapittel ), og kunden benytte en RDFa parser til å igjen fremstille katalogdata på sin site. Det å lage en slik automatisk generert HTML-kode snutt som eksterne brukere kan kopiere inn i sine løsninger er ikke en del av tilbudt løsning Krav Datasett statistikk Kunden vil gjerne ha tilgang til statistikk for å kunne se mest leste informasjon om katalog m.m. Erfaringsmessig er det en del utfordringer med dette. Det er mulig å lage slik funksjonalitet og det er også til en viss grad støttet ved å implementere Google Analytics støtte. Men for å sikre en mer rettferdig visning av kvalitet og interesse tror Leverandøren heller at man bør benytte seg for en eller annen form av rating eller like funksjonalitet. En endelig løsning for dette kan avklares under løsningsbeskrivelsesfasen og/eller eventuelle kontraktsforhandlinger Krav Søk I datasettet Leverandøren anbefaler å skille søk i katalogen og publiseringsløsningen. Katalogløsingen vil basere seg på indeks i CKAN, mens Drupal vil håndtere fritekstsøk. Som alternativ kan det sees på om nodene som kreeres av CKAN-Drupal modul integrer søkeresultater fra katalog og blog, diskusjoner, publiseringer, men Leverandøren tror likevel at katalog-søk bør separeres.

14 Krav Google Chart Tools Leverandøren hadde opprinnelig satt av 70 timer til å lage en generisk løsning for visualisering av datasett. Ettersom signalene fra FAD om at kun to datasett skal visualiserings fokuseres det heller på at disse eksempel datasettene legges ut som statiske JSON filer, med tilhørende Google Chart Tools uten fancy visualisering. Dette vil frigjøre ca 50 timer til andre oppgaver. Leverandøren har derfor valgt å redusere dette punktet til 20 timer og legge 50 timer til språkstøtte Krav Katalogen som datasett Dette punktet har vært berørt gjentatte ganger i det overstående. Leverandøren ser for seg en løsning der datasettet (les katalogen) er nedlastbart i sin helhet i form av JSON. Hvert enkelt datasett beskrivelse vil i tillegg være nedlastbart i form av RSS og JSON som REST-baserte oppslag på identifikatorene. Leverandøren tilbyr ikke et spørrespråk i denne omgangen ettersom det menes at det rette løsningen er på et senere tidspunkt å benytte SPARQL Scenario for bruk Kunden ønsket å få beskrevet et scenario for bruk av data fra katalogen (igjen datasettet, ref. Krav 1.6.1) i en eventuell klient (Dette punktet relaterer seg også til svaret og over) I det følgende illustreres et enkelt scenario med dette formålet: 1. En kommune har lagt inn to datasett som er tilgjengeliggjort i sin kommune. Datasettene er byggesaker og el-bil parkeringer. Kommunen ønsker å illustrere på egen web-side hvor populære disse datasettene anses av de som slår opp i data.norge.no for å finne gjenbrukbare datasett 2. Kommunen velger taggen xxx-kommune og finner RSS feeds for de to datasettene. Kommunens IT-ansvarlig lager et enkelt script som parser denne feeden og legger ut relevant informasjon som antall likes osv. i sin HTML side, sammen med linken til der rå-datasettet kan lastes ned. I Løsningsbeskrivelsesfasen ønsker Leverandøren å benytte interaksjonsdesignere for å bygge opp flere slike scenarier. 4 Vurdering og begrunnelse for valgte komponenter Dette kapittelet gir noen stikkord som begrunnelse for de valgte komponentene. Det er på ingen måte en komplett analyse, og ser bort fra hensyn som at Kunden i utlysningen har gitt føringer på valg av komponenter. Disse siste aspektene har selvsagt også spilt en rolle når Leverandøren har gjort sine valg. 4.1 Frontend CMS-funksjonalitet I det foregående har vi beskrevet løsningsforslaget basert på Drupal som CMS med tilhørende moduler. Vi gjør her en enkel vurdering av andre alternativer Alternativ 1: Drupal Se kapittel 2 for mer detaljer om Drupal. Leverandøren har vurdert Drupal positivt for formålet bl.a. basert på følgende - åpen kildekode (+) - stor utvikler-masse (+) - egnet til å utvide med moduler med ny funksjonalitet (+) - et stort antall moduler (-) - god støtte for semantisk web standarder (+)

15 - god støtte og bruk i åpne data (+) - bevist at de kan implementeres i store løsninger og med for et stort antall samtidige brukere. (+) - CKAN modul finnes allerede (+) Alternativ 2: Annen CMS Det er flere gode CMS-verktøy basert på åpen kildekode. Noen av de største er Drupal, Joomla og EZPublish. Vi har her fokusert på sammenlikningen med Joomla. - Joomla har noe enklere administrasjonsgrensesnitt enn Drupal, men her kommer Drupal med vesentlige forbedringer i neste versjon (versjon 7) (+) - Joomla har begrenset funksjonalitet for roller og rettigheter (-) - Moduler i Joomla kan være beheftet med kostnader og andre lisenser (-) - URLer i Joomla er ikke friendly. Dette anses som svært uheldig både i forhold til søkemotorer og lenker generelt. (-) - Joomla anses for å ha dårligere blogfunksjonalitet enn Drupal (-) Altrnativ 3: CKAN som CMS CKAN har selv mye funksjonalitet for katalogfunksjonalitet, tilgangskontroll, diskusjoner med mer. CKAN benyttes også av en rekke sites som eneste front-end til åpne data kataloger. Dersom det er lite ekstra-funksjonalitet påkrevet (f.eks. blog, publisering, visualisering) kan en ren CKAN-katalog med web frontend vurderes. - open source (+) - p.t. finnes kun datasett som kunnskapselement, men dette vil utvides i fremtidige releaser - blogfunksjonalitet og generell publiseringsfunksjonalitet mangler, dette vil måtte lages custom kode for/plug-in moduler (-) - Utvidelser av CKAN bør fokusere på CKANs katalogfunksjonalitet, andre elementer vil vi ikke kunne forvente vesentlig støtte fra andre CKAN brukere. (-) Konklusjon Basert på det overstående, og generelle vurderinger gjort bl.a. av data.gov.uk, har vi konkludert på bruk av Drupal som frontend CMS. 4.2 Backend katalogfunksjonalitet CKAN er valgt som katalog-komponent. I det følgende er det gjort noen vurderinger rundt alternative løsninger Alternativ 1: CKAN - I utstrakt bruk, blant annet av data.gov.uk (+) - Aktiv viderutvikling, tjener på at flere miljøer videreutvikler denne (+) - Versjonshåndtering (+) - Klare ideer og eksperimenter i retning av trippelstore backend (alternativ 3) (+) - Rask å sette opp (+) - Utvidelsesmulighetene noe begrenset av relasjonsdatabasearkitektur, tagger løser på dette, men medfører igjen tunge spørringer, dvs. potensiell ytelsesdegradering og behov for caching (-) - Miljøet er aktiv mht utvidelser for bl.a. språkstøtte (+) Alternativ 2: relasjonsdatabase med Drupal,. mysql - rask å sette opp (+) - kjent teknologi (+) - vil ende opp med vårt eget skjema, som medfører dårlig interoperabilitet med andre kataloger (-) - må settes opp fra bunn av, alle tjenester (synkronisering, versjonering) må skreddersys (-) - liten eller ingen gjenbrukseffekt (-) Alternativ 3: Fordeler med en separate triplestore - en riktig løsning basert på linked open data (+)

16 - noe komplisert å sette opp (-) - må bygge opp skjema, her kalt vokabularer. Kan benytte de samme som CKAN (dublin core, dcat). (+) - Mangler funksjonalitet for tjenester som synkronisering og versjonering, må skreddersys (-) - Lettere å håndtere utvidelser av felter (+) - Lettere å håndtere språkutvidelser (+) - få tilstrekkelig modne open source stores, men i sterk forbedring (-) Konklusjon Vi mener det er riktig å satse på CKAN ettersom at løsningen gir det vi trenger på kort sikt, er i utstrakt bruk og vi kan tjene på at mange bidrar til videreutvikling. Det kan også forventes at denne beveger seg i en retning på lenger sikt, noe som vil øker fleksibiliteten til beskrivelsene samtidig som det beholder kjernefunksjonalitet rundt synkronisering og versjonering. 5 Prisnedbrytning Denne prisnedbrytningen er oppdatert i forhold til opprinnelig tilbud. Timepris fra opprinnelig tilbud er gjeldende. Oppgave Estimat (timer) Løsningsbeskrivelse og sprintplanlegging 100 Initiell løsningsbeskrivelsesfase 20 Sprintplanlegging og demo (3 personer, ½ dag, 3 ganger) 40 Referansegruppemøter (3 personer, ½ dag, 3 ganger) 40 Design og interaksjonsdesign 60 Design av utseede (grafisk design) 20 Informasjonsstruktur (interaksjonsdesign) 40 Utvikling 240 Oppsett av miljø (maskinvare og programvare) - Ubuntu Linux,, CKAN, Apache, MySQL, Drupal, CKAN. 20 Konfigurasjon og tilpassning av Drupal, tilpassninger av maler 70 Integrasjon med katalog (inkluderer språkstøtteutvikling) 120 Integrasjon med chart verktøy 20 Konvertering av gammelt innhold fra Wordpress (forutsetter ingen datavask) 10 Prosjekt og testledelse 100 Testledelse og testing 40 Prosjektledelse 40 Feilretting i forbindelse med testing 20 TOTALT 500

17 1 E.g. 2 Lod2.eu Dette scriptet tilfeldigvis skrevet i Python (rdfa.py), er en enkel RDFa parser som tar en side og returnerer RDFa, se