Nettstedet data.norge.no. Konkurranse med forhandling etter forskriftens del I og II. for anskaffelse av

Konkurransegrunnlag Konkurranse med forhandling etter forskriftens del I og II (Konkurransen gjennomføres i ett trinn, uten pre-kvalifisering) for anskaffelse av Nettstedet data.norge.no For levering til Fornyings-, administrasjons- og kirkedepartementet Saksnummer i DocuLive 0100109

Tilbudsfrist: 3. august 010 kl. 1:00

Innhold 1 GENERELL BESKRIVELSE 3 1.1 Oppdragsgiver 3 1. Anskaffelsens formål 3 1.3 Omfang og kontraktsverdi 3 1.4 Oppbygging av konkurransegrunnlaget 3 1.5 Kunngjøring 4 REGLER FOR KONKURRANSEN 4.1 Gjennomføring av konkurransen 4. Tilbudets utforming og levering 4.3 Innleveringsfrist 4.4 Vedståelsesfrist 4.5 Behandling av tilbud 5.6 Tilleggsopplysninger 5 3 KVALIFIKASJONSKRAV 5 3.1 Obligatoriske og ufravikelige krav 5 3. Leverandørens tekniske, faglige og økonomiske kvalifikasjoner 6 4 TILDELINGSKRITERIER 7 5 ANNEN INFORMASJON 8 6 UNDERitikk, offentlighetsloven og for statens arbeid med viderebruk av offentlige data.skrift 8 7 LEVERANDØRENS SJEKKLISTE 10 BILAG 1 HMS-EGENERKLÆRING 11 BILAG TILPASNINGSAVTALEN (SSA-T) 1 BILAG 3 KRAVSPESIFIKASJON 13 1.GENERELL BESKRIVELSE 1.Oppdragsgiver Fornyings-, administrasjons- og kirkedepartementet er ansvarlig for statens IKT-pol Oppdragsgivers kontaktperson er: Navn: Sverre Andreas Lunde-Danbolt Postadresse: Postboks 8004 Dep Besøksadresse: Akersgata 59 E-post: sld@fad.dep.no Telefon: 4 47 6 / 41 48 04 95 Eventuelle spørsmål skal rettes til kontaktpersonen pr. e-post..anskaffelsens formål Nettstedet data.norge.no skal være forvaltningens knutepunkt for alle tema knyttet til viderebruk av offentlige data. Nettstedet skal være (1) en publiseringsløsning for å vedlikeholde sider med innhold knyttet til temaet, () en blogg for

3.08.10 00.30 Konkurransegrunnlag for anskaffelse av nettstedet data.norge.no 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. Det skal ikke lagres offentlige data på selve nettstedet (ikke kartdata, eiendomsinformasjon, trafikkopplysninger, etc.), kun beskrivelser av slike datasett (metadata) og annen informasjon. For nærmere beskrivelse av leveransen se bilag 3 Kravspesifikasjon. 3.Omfang og kontraktsverdi Oppdraget er å utvikle nettstedet. Utviklingen skal skje i etapper, og flere betaversjoner skal lanseres underveis i utviklingsarbeidet. Leveransen skal derfor stykkes opp i minimum tre faser, der det skal leveres en betautgave av nettstedet på slutten av hver fase. Målsetningen er å lansere nettstedet med begrenset funksjonalitet så snart det lar seg gjøre, og bruke kommentarer og innspill fra de første brukerne av nettstedet i det videre arbeidet med å ferdigstille nettstedet. Det nøyaktige antallet utgaver/betaversjoner av nettstedet vil bli gjenstand for nærmere forhandlinger, og vil bli tilpasset ønsket progresjon i utviklingsarbeidet. Leverandør har driftsansvar for løsningen i denne utviklingsfasen. Videre drift er derimot ikke en del av denne anskaffelsen. Oppdraget har en økonomisk ramme på inntil kr 500 000,- eks. mva. 4.Oppbygging av konkurransegrunnlaget Konkurransegrunnlaget består av dette dokument med tilhørende bilag 1 (HMS-egenerklæring), bilag (SSA Tilpasningsavtalen (http://www.difi.no/emne/anskaffelser/statens-standardavtaler-ssa), og bilag 3 (Kravspesifikasjon). 5.Kunngjøring Konkurransen er kunngjort med FADs twitterkonto @fornyingsdep, i bloggen på http://data.norge.no og i DOFFINdatabasen (se http://www.doffin.no)..regler FOR KONKURRANSEN 1.Gjennomføring av konkurransen Anskaffelsen gjennomføres i henhold til lov om offentlige anskaffelser av 16. juli 1999 (LOA) og forskrift om offentlige anskaffelser (FOA) av 7. april 006 nr. 40. Del II 5-1. Kontraktstildeling vil bli foretatt etter prosedyren Konkurranse med forhandling. Alle interesserte leverandører gis adgang til å levere tilbud. Forhandlingene vil kunne bli gjennomført i flere faser for å redusere det antall tilbud det forhandles om. En første reduksjon av tilbud vil kunne skje før forhandlingene starter. Reduksjonen av antall tilbud det forhandles om skjer på bakgrunn av de fastsatte tildelingskriteriene, jfr. forskriftens 11-8(1). Bare de tilbyderne som oppfyller kvalifikasjonskravene vil få sine tilbud evaluert..tilbudets utforming og levering 1.Tilbudet skal være merket: «Anbud på utvikling av data.norge.no (DL 0100109)» 1.Dette konkurransegrunnlaget skal benyttes for å avgi tilbud/svar. Leverandørens svar skrives med blå skrift rett under det angjeldende spørsmål eller i tabeller avsatt for svar..vedlegg skal nummereres i den rekkefølge som vedlegg nevnes i konkurransegrunnlaget.

3.Tilbudet skal inneholde komplett utfylt priser/prisskjema. 4.Tilbudet skal leveres til postmottak@fad.dep.no med kopi til sld@fad.dep.no 5.Leverandørene skal også levere en utgave av tilbudet hvor det som anses å være forretningshemmeligheter er sladdet. Ved begjæring om innsyn, skal oppdragsgiver uavhengig av dette vurdere hvorvidt opplysningene er av en slik art at oppdragsgiver plikter å unnta dem fra offentlighet. 6.Underskrift Dette konkurransegrunnlaget er utformet slik at leverandøren kan fylle inn teksten direkte i konkurransegrunnlaget slik at det samlet sett fremstår som leverandørens tilbud. 3.Innleveringsfrist Innleveringsfrist er satt til 3. august kl 1.00. For sent innlevert tilbud vil bli avvist. 4.Vedståelsesfrist Leverandøren må vedstå seg sitt tilbud 10 kalenderdager regnet fra innleveringsfristen. 5.Behandling av tilbud Alle leverandører vil få tilbakemelding om hvilket tilbud som er valgt. 6.Tilleggsopplysninger Dersom leverandøren finner at konkurransegrunnlaget ikke gir tilstrekkelig veiledning, kan han skriftlig be om tilleggsopplysninger hos oppdragsgiver ved oppdragsgivers kontaktperson. Dersom det oppdages feil i konkurransegrunnlaget, bes det om at dette formidles skriftlig til oppdragsgivers kontaktperson. Skriftlig henvendelse om tilleggsopplysninger merkes: «Forespørsel om tilleggsopplysninger for anbud til data.norge.no (DL 0100109)» og sendes til oppdragsgivers kontaktperson per e-post. 3.KVALIFIKASJONSKRAV Krav til leverandøren for deltakelse i konkurransen. Informasjon til leverandør: Fra kapittel 3, 4 og 5 skal det fylles inn direkte i dette dokumentet. Samlet innfylling og vedlegg vil da utgjøre leverandørens tilbud. Husk å fylle inn med blå skrift. 1.Obligatoriske og ufravikelige krav Krav Dokumentasjonskrav Vedlegg nr: Det kreves at leverandøren har ordnede forhold mht. skatteinnbetaling og momsinnbetaling. Det kreves at leverandøren har et fungerende HMSsystem. Skatteattest (Skatteattest for skatt utstedes av kemner/kommunekasserer 1 (skjema RF-144)) som ikke er mer enn 6 måneder gammel. Merverdiavgiftsattest (Attest for betalt merverdiavgift utstedes av skattefogden (skjema RF-144)) som ikke er mer enn 6 måneder gammel. HMS -egenerklæring (Se bilag 1 til konkurransegrunnlaget) 3

.Leverandørens tekniske, faglige og økonomiske kvalifikasjoner Krav Dokumentasjonskrav Leverandørens svar Vedlegg nr: Leverandøren skal ha økonomisk kapasitet til å gjennomføre oppdraget/ kontrakten Velg en av disse to: Kredittvurdering/rating, ikke eldre enn 1 år, og som baserer seg på siste kjente regnskapstall. En rating skal være utført av offentlig godkjent kredittvurderingsinstitusjon Årsregnskap inkl. styrets årsberetning og revisorerklæring. 4 Dersom leverandøren av gyldige grunner ikke kan fremlegge den dokumentasjon oppdragsgiver har anmodet om, kan han godtgjøre sin økonomiske og finansielle stiling med ethvert annet dokument som oppdragsgiver kan akseptere. Leverandøren skal ha Beskrivelse av leverandørens 3 erfaring fra minimum 3 mest relevante oppdrag i løpet av tilsvarende oppdrag i løpet de siste 3 årene. Beskrivelsen må av de 3 siste årene. (Man inkludere angivelse av oppdragets bør utdype hva man legger i verdi, tidspunkt og mottaker (navn, "tilsvarende oppdrag".) telefon og e-post.) Referanser blir kontaktet ved behov for klargjøring av oppdragets relevans. Det er likevel slik at det er leverandørens ansvar å dokumentere relevans gjennom beskrivelsen. Leverandøren skal ha tilstrekkelig gjennomføringsevne og kapasitet. Redegjørelse for de verktøy, materiell eller teknisk utstyr som leverandøren disponerer over til gjennomføring av kontrakten/ oppdraget. Vedlegg 5, kapittel Vedlegg 4, kapittel 3 og 4 samt vedlagte CVer Det kreves et godt og velfungerende kvalitetssikrings-system for ytelsene som skal leveres. Beskrivelse av gjennomføringen (Nevn eksempler fra tidligere prosjekt) CV til nøkkelpersonene Redegjørelse vedrørende leverandørens kvalitetssikringssystem/- styringssystem eller JIRA, eget driftsmiljø, prosjektledelse. Vedlegg 5, kapittel 5. Kopi av systemsertifikat utstedt av akkrediterte sertifiseringsorganer eller tilsvarende dokumentasjon.

4.TILDELINGSKRITERIER Kriterier Vekt Dokumentasjonskrav Leverandørens svar Vedlegg nr: Samlet pris 0 % Tilbudet bør gi en oversikt 6 over prissettingen for de enkelte delelementer, samt en samlet pris for hele leveransen. Løsningsforståelse 50% Løsningsforståelse vil bli vurdert ut ifra tilbudet i sin helhet. Fordi løsningen 7 ligner mye på nettsteder satt opp i andre land (data.gov, data.gov.uk, etc.) og i andre byer (datasf.org, data.octo.dc.gov, etc.), vil det være et viktig poeng i hvilken grad løsningen gjenbruker åpen kildekode fra andre, lignende nettsteder. Leveringsdyktighet 30 % I tillegg til tilbudet i sin helhet og planlagt gjenbruk av åpen kildekode, vil leveringsdyktighet bli vurdert ut ifra leverandørens referanser. Tilbudet skal derfor inneholde kontaktpersoner hos minst tre tidligere kunder. Vedlegg 5, kapittel -6

5.ANNEN INFORMASJON Informasjon fra oppdragsgiver Svar/informasjon fra leverandøren Evt. vedlegg nr: Det forventes at leverandør drifter løsningen i utviklingsfasen og verifikasjonsfasen. Løsningen vil være. Løsningen vil bli driftet ved Bouvets eget driftssenter i Stavanger. offentlig tilgjengelig som en betatjeneste i utviklingsfasen, gjennom domenet data.norge.no. Ansvaret for dette nettstedet vil etter hvert overføres fra FAD. Vi benytter et system for utvikling- og til Direktoratet for forvaltning og IKT (Difi). FAD/Difi vil i overføring til produksjonssetting som DIFI utgangspunktet drifte denne løsningen selv. Dersom det blir har kjennskap til fra andre prosjekter. aktuelt å sette ut videre drift av løsningen vil det bli lagt opp (buildout,setuptools,distutils) til en separat anbudskonkurranse om drift av nettstedet. 6.UNDERSKRIFT Firmaopplysninger Leverandør: Adresse: Kontaktperson: Telefonnummer: Telefaks: E-postadresse: Foretaksnummer: Fyll inn..., den...... Leverandørs underskrift ved innlevering av tilbudet 7.LEVERANDØRENS SJEKKLISTE Følgende dokumenter skal leverandøren legge ved tilbudet: 1. Skatteattest (Se punkt 3.1) 1. Merverdiavgiftsattest (Se punkt 3.1) Følgende dokumenter kan oppdragsgiver be deg legge ved tilbudet:. HMS-egenerklæring (se punkt 3.1) 3. Leverandørens tekniske, faglige og økonomiske kvalifikasjoner (Se punkt 3.) 4. Kravspesifikasjoner (se punkt 4)

Leverandøren besvarer kravene til dokumentasjonen på tildelingskriterier så godt det er mulig: 5. Se oppdragsgivers liste tatt inn i punkt 5 Husk at skal vedleggene som skal med nummereres og at vedleggsnummerene tas inn i dette dokumentet. Leverandørens svar fylles inn med blå skrift.

BILAG 1 HMS-EGENERKLÆRING Egenerklæring om helse, miljø og sikkerhet (HMS) Denne bekreftelsen gjelder: Konkurransegrunnlag for anskaffelse av nettstedet data.norge.no Virksomhetens navn Adresse Postnummer Organisasjonsnr/ Fødselsnr Land* Poststed Jeg bekrefter med dette at denne virksomheten arbeider systematisk for å oppfylle kravene i helse-, miljø- og sikkerhetslovgivningen og ved det tilfredsstiller kravene i forskrift om systematisk helse-, miljø- og sikkerhetsarbeid i virksomheten (internkontrollforskriften). Jeg bekrefter at virksomheten er lovlig organisert i henhold til gjeldende skatte- og arbeidsmiljøregelverk når det gjelder ansattes faglige og sosiale rettigheter. Jeg aksepterer at oppdragsgiver etter anmodning vil bli gitt rett til å gjennomgå og verifisere virksomhetens system for ivaretakelse av helse, miljø og sikkerhet.. Dato Daglig leder Jeg bekrefter med dette at det er iverksatt systematiske tiltak for å oppfylle ovennevnte krav i helse-, miljø- og sikkerhetslovgivningen. Ingen ansatte. Dato Representant for de ansatte *For utenlandske oppdragstakere gjelder følgende: Jeg bekrefter med dette at det ved utarbeidelse av tilbudet er tatt hensyn til helse-, miljø- og sikkerhetslovgivningen som følger av forskrift om systematisk helse-, miljø- og sikkerhetsarbeid i virksomheter (internkontrollforskriften), fastsatt ved kgl. res. 6. desember 1996 i medhold av lov 17. juni 006 nr. 6 om og arbeidsmiljø, arbeidstid og stillingsvern mv. Jeg aksepterer at oppdragsgiver etter anmodning vil bli gitt rett til å gjennomgå og verifisere virksomhetens system for ivaretakelse av helse-, miljø- og sikkerhetsarbeid.

BILAG TILPASNINGSAVTALEN (SSA-T) Tilpasningsavtalen (SSA-T) finnes her: http://www.difi.no/artikkel/009/11/tilpasningsavtalen-ssa-t

BILAG 3 KRAVSPESIFIKASJON data.norge.no skal være et nettsted som informerer, promoterer og stimulerer initiativ som publiserer eller tar i bruk datasett som er gjort offentlig tilgjengelig i maskinlesbare formater. Nettsiden skal være sosialt rettet og legge til rette for at sluttbruker skal kunne bidra med informasjon og meninger relatert til emnet. Den tekniske løsning skal være modulær og åpen, på en slik måte at framtidige endringer kan skje på en smidig måte med lavest mulige kostnader. Løsningen skal i første omgang bestå av følgende moduler: Publiseringsløsning for å vedlikeholde sider med informasjon relatert til emnet Blogg for deling og diskusjon av informasjon og meninger relatert til emnet Katalog med metadata om offentlig tilgjengelige datasett Katalog med metadata om applikasjoner som utnytter offentlig tilgjengelige datasett Applikasjon for å visualisere eksempeldata fra datasett på utvalgte kjente format Tabellen under inneholder minstekrav til løsningen. Det er obligatorisk å svare på alle punktene. Indikér om kravet er oppfylt i løsningen ved å sette Ja eller Nei i tredje kolonne. Dersom svaret inneholder referanser til annen dokumentasjon så skal dette fremkomme i siste kolonne og dokumentasjonen skal leggest ved (og gjerne med kryssreferanse tilbake til kravet). Løsningens kildekode blir tilgjengeliggjort gjennom en åpen lisens som bestemmes av oppdragsgiver i etterkant av leveransen. Begreper Følgende begreper er benyttet i kravspesifikasjonen: Applikasjon: Applikasjon eller komponent som benytter ett eller flere datasett Datasett: Sett med data gjort tilgjengelig i filer eller på standardisert maskinlesbart format via ett eller flere kjente grensesnitt (API). Datasettene skal lagres hos dataeierne, ikke på data.norge.no. På data.norge.no skal det kun være metadata om datasett. Data: Innholdet i et datasett Metadata: Informasjon som beskriver datasett, grensesnitt mot datasettet, vilkår for bruk av datasettet og data i datasettet Informasjon: Innhold på nettstedet data.norge.no Innhold: Informasjon på nettstedet data.norge.no

1. Funksjonelle krav til løsning Krav nr. Beskrivelse av krav 1.1 Generelle krav 1.1.1 Løsningen skal bestå av et rammeverk som ivaretar design og navigasjon mellom de forskjellige modulene i løsningen slik at løsningen fremstår som enhetlig og sammenhengende.rammeverket skal omfatte følgende innholdskategorier: Nettstedets logo, navn, etc., som skal vises på alle sider Språkvalg Faner e.l. som hjelper brukeren å navigere mellom datakatalogen, blogg, andre dokumenter og ressurser Innlogging for brukere 1.1. Løsningen skal kunne fremstå på flere språk, med mulighet for å gjøre innhold tilgjengelig på flere språk. 1.1.3 Løsningen skal ha minst ett unikt navn, det vil si et navn som ikke er direkte knyttet til løsningen eller leverandøren av løsningen. For eksempel data.norge.no 1.1.4 Løsningen skal aktivt hjelpe brukeren til å følge referansekatalogens krav til IT-standarder der det er relevant. (http://standard.difi.no/). Et konkret eksempel på dette er at løsningen skal sørge for at dokumenter blir publisert i rett format. Stat us JA JA JA JA Leverandøren sitt svar Se løsningsforslag. Sentral funksjonalitet implementeres og omformes i CKANs rammeverk. Deliverance og WSGI syr sammen resterende frittstående moduler visuelt og navigasjonsmessig. HTML og CSS fra valgte moduler sys om til et helhetlig inntrykk på vei ut. Autentisering gjøres i WSGI mellomvare (repoze.who, en komponent i CKAN). Vi foreslår et enkelt fanebasert interaksjonsdesign inspirert av data.gov.uk. Malspråket i CKAN, genshi, støtter internasjonalisering (i18n) av ledetekster gjennom standard GNU gettext. CKAN er allerede oversatt til bokmål. Wordpress er også internasjonalisert med GNU gettext. Oversettelse av ledetekster i maler til andre språk er ikke en del av tilbudet, men gjøres gjennom standardisert programvare. Alt innhold (inklusive stilark og bilder) serveres gjennom data.norge.no eller andre ønskede domenenavn. Wordpress støtter dette.

1.1.5 Løsningen skal utformes i tråd med statens IKT- arkitekturprinsipper: http://prosjektveiviseren.no/ dokumenter/arkitekturprinsipper Tjenesteorientering: Delsystemene er tjenester som settes sammen visuelt. Dataene synkroniseres for å gjøre få inngrep i standardmodulene. REST-grensesnitt hvor eksterne kan aksessere data. Interoperabilitet: Katalogen kan lastes ned gjennom dokumentert og åpent format fra CKAN, samt bruk av RDF og Sparql. Annet innhold er tilgjengelig som HTML-nettsider. Tilgjengelighet: Løsningen vil støtte best-practives og relevante standarder for universal utforming. Sikkerhet: Ingen konfidensielle data eksponeres eller lagres. Autentisering håndteres eksplisitt. Autentisert trafikk krypteres med SSL/TSL. Åpenhet: Systemet presenteres til brukere gjennom HTML og HTTP slik det er implementert av nettlesere som benyttes av Norges befolkning. Utviklere og spesielt interesserte kan benytte RDF og Sparql til å utforske datasettet. Fleksibilitet: Bentter åpen- kildekode og fri programvare fra store, internasjonale communities (med deltakelse fra norske miljøer, inkludert Bouvet). Komponentene skreddersys i liten grad slik at oppgradering til nye versjoner ikke krever reimplentasjon. Modulene kan byttes ut. Vi benytter standardiserte formater Skalerbarhet: Oppsettet bygges rundt standard prinsipper og med komponenter som benyttes i store nettsteder. Vi planlegger i utgangspunktet å kjøre uten caching, men vil sette på en Varnish proxy hvis det viser seg å være et problem. I oppstartsfasen før drift er overlevert til DIFI vil vi i utgangspunktet kun kjøre på én virtuell tjener. Vi antar at det holder initielt. Mer maskinvare kan legges på dersom vi får ytelsesproblemer.

1.1.6 Løsningen skal tilfredsstille kravene i W3C WAI WCAG.0 AA (alle kriterier merket A og AA i standarden - http:// www.w3.org/wai/wcag0/quickref/ Overview.php). Ved leveranse skal dette dokumenteres. 1.1.7 Løsningen skal benytte RDF/Linked Open Data-attributter til å annotere innhold på nettstedet. Hovedmalene gjennomgås før leveranse og en sjekkliste leveres. Vi benytter CKANs ORDF bibliotek som igjen bygger på rdflib, en fritt tilgjengelig RDF-motor. Alle metadata om datasett i CKAN og ekstra kategoriseringer speiles i ORDF. 1.1.8 Datakatalog-delen av løsningen bør bygge på Comprehensive Knowledge Archive Network (CKAN) eller bedre. Beskriv hvordan dere ønsker å bruke CKAN. Dersom løsningen ikke bygger på CKAN, begrunn hvorfor og hva dere vil bruke istedet. 1. Administrasjon av nettstedet Linked Data eksponeres med ontosrv for visualisering. Se http:/ /ordf.org/schema/ ordf#. Løsningen vil bli levert på CKAN 1.1 eller nyere og bygges for å enklest mulig kunne følge videre utvikling av CKAN. Spesialisert funksjonalitet bygges i samme rammeverk som CKAN (pylons), men ikke som en del av CKAN. (Der hvor det er hensiktsmessig vil funksjonalitet skrives som CKAN plugins) Søkesiden utvikles i samme rammeverk (pylons) og benytter Solr som backend. Søkesiden vil, i tillegg til fritekstsøk, være et enkelt fasettert grensesnitt for å kunne filtrere på ting som geografi, avsender og gruppe.

1..1 Løsningen skal kunne håndtere et større antall brukere med ulike roller og rettigheter. Det skal registreres kontaktinformasjon relatert til hver bruker. Ingen begrensninger på antall registrerte brukere. Brukere kan opprette konto på nettstedet. Alle brukere får tillatelse til å registrere applikasjoner. Brukere fra et kontrollert sett av domener får automatisk tillatelse til å registrere datasett for institusjonen. Autentisering av eksterne brukere skjer i repoze.who WSGI mellomvare (som i CKAN). Hver enkelt komponent styrer autoriseringen selv. I Wordpress vil det kun være en liten redaksjon som oppretter og redigerer sider. Vi tilpasser ikke disse. Besøkende autentiseres i WSGI komponenten. Brukere må registere informasjon når de registrerer seg. 1.. Innholdet på nettstedet skal kunne administreres gjennom et webbasert grensesnitt kryptert med SSL. repoze.who står for autentisering for alle komponenter lenger bak som kan slå opp brukernavn i REMOTE_USER headeren. Bouvet kjøper inn et, standard, signert SSL-sertifikat for domenet data.norge.no til første lansering og installerer dette. Sertifikatet er gyldig i et (1) år. Kostnaden for å signere sertifikatet faktureres kunden. Nytt sertifikat må bestilles når DIFI overtar drift.

JA 1..3 Løsningen må legge til rette for en enkel autentisering av brukere. Det må være mulig å verifisere enkelte brukere som representanter for departement, etater og kommuner. Autentisering skjer ved kombinasjon av brukernavn (epostadresse) og passord. Innlogging og redigering skjer over kryptert oppkobling (TSL/SSL) med standard sesjonsbasert informasjonskapsel-basert innlogging. Brukere kan kun registrere datasett hvis de kommer fra et lukket sett med domener, f.eks. kommune.no, fylkeskommune.no. Vi verifiserer ved å sende en epost til adressen som inneholder en lenke de må klikke på. Konto opprettes ikke før lenken er åpnet. Passord og ekstra informasjon om brukeren kan fylles inn når lenken er valgt. Settet vedikeholdes redaksjonelt. Brukere kan få tilsendt midlertidige passord dersom de har glemt eksisterende passord. Passordene lagres ikke i databasen, kun den nødvendige hashen slik at det er sterkt redusert fare for lekkasje av passord om databasen deles. Redaksjonen får også et verktøy for å sende ut invitasjoner og samt opprette og administrere kontoer. Redaksjonen kan invitere brukere utenfor settet av godkjente domener. 1..4 Det skal være støtte for å tildele rettigheter til brukere på en enkel måte. 1..5 Alt innhold skal eies av én eller flere brukere i systemet. 1..6 Administrator skal kunne administrere alt innhold. Institusjoner er selv ansvarlig for å stenge ned brukerkonto for brukere som slutter. Autentiserte brukere vil på egen organisasjons side kunne se hvem som er registrert som representanter. Støttet allerede i hver enkelt komponent. Vi utvikler en administrasjonsside for eksterne brukerkonto. Datasettene deles mellom brukere fra samme domene. Eiere kan legge til flere eiere som har rett til å registrere nye utgivelser. Applikasjoner kan deles av eier. Administrator har adgang. Wordpress støtter ikke dette, men vi anser det som lite nødvendig i bloggkomponenten.

1..7 Løsningen skal kunne håndtere flere versjoner av metadata, der hver av versjonene korresponderer med ulike versjoner av datasettet metadataene beskriver. Det skal komme klart frem hvilke versjoner av det beskrevne datasettet som er tilgjengelige til enhver tid, og hvilke versjoner som er historiske. 1..8 Løsningen skal ha en rutine for håndtering av metadata for relaterte datasett. Det skal være mulig å se metadata for relaterte datasett i sammenheng. CKAN benytter en versjonert datamodell for datasettene. CKAN har innebygget støtte for groups og tagging. Groups er metaforen for å (manuelt) håndtere, navngi og presentere relaterte datasett. I det innleggingsskjemaet vi foreslår å lage samler vi også inn geografisk og institusjonelle kategorier. Søkesiden eksponerer ekstra kategorier som fasetter. Gjennom dette kan brukere navigerere i de ekstra kategoriene. 1..9 Løsningen skal ha en rutine for utfasing av beskrivelser av spesifikke datasett. 1..10 Løsningen skal kunne håndtere import av metadata fra andre kilder. Slik import skal kunne automatiseres. 1..11 Datakatalogen skal inneholde metadata som kreves for å kunne gjøre en tjeneste tilgjengelig, eksempelvis informasjon, relevante adresser, formater, dokumenter, standarder, lisenser og kontaktinformasjon for feilmeldinger meldt på nettstedet. Beskriv hvordan disse metadatadefinisjonene kan vedlikeholdes. Vi setter også opp en standard ORDFkomponent som henter data fra CKAN. Sparql/RDF grensesnittet kan benyttes av utviklere til å gjøre spørringer mot metadataene. Innhold kan slettes. CKAN tilbyr infrastruktor for import fra andre CKAN instanser og skript for import regneark. Ved import fra andre kilder må det først utvikles en komponent som omformer fra originalformat til CKAN-format. Tolker tjenester som en spesiell type datasett. Registreres og oppdateres som andre datasett i innleggingsskjema.

1..1 Alle innholdselement skal ha en unik permanent URI. URI-en må være lesbar ( human readable ), være hierarkisk oppbygget, og være utformet slik at man skal kunne tolke hva den representerer. Gjennom WSGI har vi full kontroll over adressestrukturen uavhengig av detaljene i underliggende komponent. De valgte komponenten har allikevel alle «pene» adresser. Beskriv hvordan disse URI-ene kan vedlikeholdes. 1..13 Det skal være mulig å navigere i metadataene på flere måter, f.eks. etter eier, forvaltningsnivå, eiers geografiske plassering, type data og lisenstype. 1..14 Det skal være mulig å gi tilbakemelding på alle datasett som er beskrevet i datakatalogen. Beskriv hvordan dette løses og administreres. Redaksjonelt vedlikehold vil ikke være nødvendig. Se avsnitt om adressestruktur i løsningsforslaget. Fasettert navigering gjennom søkegrensesnittet. Egne sider for hver enkelt institusjon, lisenstype, geografiske entiteter må utvikles separat. Vi tar høyde for at de kan utvikles senere. Vi kan støtte mange varianter av tilbakemelding men foreslår følgende: Hver datapakke får en åpen wikidiskusjonsside. Her kan alle legge inn informasjon om datasettet, dokumentasjon, utdypninger, eksempler, visualiseringer, kommentere, svare på kommentarer, fjerne kommentarer osv. (Diskusjonssiden må være tydelig fra pakkesiden.) 1..15 Det skal være mulig å følge en RSS/ Atom-feed med nyheter om hvert datasett som er beskrevet i datakatalogen. Disse nyhetene skal kunne lages direkte på nettstedet. Løsningen skal også kunne videreformidle nyheter fra dataeier. Eiere av pakken blir Støttet i CKAN 1.1 Spesialiserte feeds kan settes opp. 1..16 Alt innhold skal være synlig datert. Stort sett støttet av modulene. Vi utvider maler der det er nødvendig. 1..17 Hvert datasett som er beskrevet i datakatalogen skal presenteres med nøkkeltall relatert til visningen av datasettet. Et eksempel på nøkkeltall er antall visninger i en gitt periode. Det skal være mulig å navigere etter slike nøkkeltall. Vil teller og viser antall sidevisninger og lager en side som viser mest besøkte datasett.

1..18 Det skal være mulig å registrere informasjon om applikasjoner. Det skal være mulig å registrere metadata om applikasjonen, i tillegg til at det skal være mulig å knytte metadata om applikasjonen til metadata om de datasettene applikasjonen benytter. Bygges i CKANs infrastruktur (pylons). Om mulig benyttes CKANs egen pluginsystem. Brukere kan registrere applikasjoner og bruk av datasett. Vi lager et eget skjema som for datasett og tjenester. 1.3 Krav til nettstedet 1.3.1 Nettstedet skal ha en innbydende utforming hvor alt innhold redigeres i samme grensesnitt som visningen. 1.3. Løsningen skal ha en søkemekanisme som lar bruker søke i fritekst på alt innhold i løsningen. 1.3.3 Det skal være mulig å karakterisere noen av de beskrevne datasettene som populære eller hotte. Disse skal kunne profileres på fremsiden og/eller i sidekolonner. 1.4 Krav til bloggen 1.4.1 Det skal være mulig å importere alt innhold fra den nåværende bloggen på data.norge.no inn i den nye bloggen. 1.5 Presentasjon av datasett 1.5.1 Eier av datasett skal kunne laste opp ett eller flere eksempel på datasettet. Disse skal både kunne lastes ned og kunne visualiseres i nettleseren av besøkende. Minimum støtte er JSON og XML. 1.6 Tilgjengelighet av rådata Åpen innlegging, redaksjonen må følge med på listen og fjerne SPAM og hærverk. Bouvet lager et enkelt interaksjonsdesign med tilhørende grafisk design som dekker forespurt funksjonalitet. Vi benytter Apache Solr. Vi lager et grensesnitt for fasettert navigasjon i datasett, tjenester og applikasjoner. Innhold i Wordpress og CKAN sendes til Solr ved hver endring. Forsiden lages spesielt for data.norge.no og erstatter standard CKAN forside. Redaksjonen vil kunne beskrive hvilke felt som er prioritert. Interaksjonsdesignet styrer hvilken annen funksjonalitet som kommer på forsiden. Eksisterende blogg er i Wordpress. Vi foreslår å videreføre denne. Wordpress vil også fungere som publiseringsløsning for innhold som ikke ligger i CKAN. Vi vil vurdere om det er hensiktsmessig å benytte nettverksfunksjonaliteten i Wordpress for å isolere bloggen. Tidligere Wordpress MU. JSON/XML og andre forklaringer/ illustrasjoner kan vises på den parallelle dokumentasjonssiden. Ingen begrensninger på andre visualiseringer som kan utvikles.

1.6.1 Katalogen over offentlige datasett skal beskrives som et eget datasett i løsningen, og gjøres tilgjengelig i standardiserte, strukturerte, maskinlesbare formater. Katalogen skal som et minimum gjøres tilgjengelig på veldokumentert JSONog XML-format (Dette er det eneste datasettet som skal gjøres tilgjengelig på data.norge.no). Beskriv forslag til format og programmeringsgrensesnitt for dette datasettet. Benytter standard CKAN grensesnitt (JSON) plus RDF og et Sparqlsøkegrensesnitt. Se http:// knowledgeforge.net/ ckan/ doc/ckan/ api.html. Skisse til løsning Krav nr. Beskrivelse av krav Status Leverandøren sitt svar.1 Leverandøren må gi en skisse til løsningsforslag. Løsningsforslaget skal minst omfatte: En modell for løsningen som synliggjør hvilke funksjoner som inngår i løsningen En spesifikasjon av hvilke programvarekomponenter nettsted og database baseres på Se vedlagt løsningsbeskrivelse. Oppgi hvilke deler av løsningen som baserer seg på hyllevare, egenutviklete standardløsninger og skreddersøm, og hvilke lisenser som gjelder for hver komponent.. Dersom løsningen bygger på programvare som leverandøren ikke selv står ansvarlig for, bes det om opplysninger om forhold mellom leverandør og rettighetshaver, og om planer for videreutvikling av programvaren og løsningen. Modulene som ikke utvikles i prosjektet er utelukkende utbredt åpen-kildekode/fri programvare med brede miljøer. Vi har valgt prosjekter som ser ut til å ha momentum på egen hånd og slik sett naturlig videreutvikles. All kildekode er tilgjengelig og kan utvikles i eget tempo. Kompetanse kan hentes inn fra forskjellige leverandører. Vi har forsøkt å legge opp en systemarkitektur hvor data.norge.no ikke binder opp store investeringer i enkeltplattformer eller enkeltprodukter.