Nettstedet data.norge.no

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: Postadresse: Sverre Andreas Lunde-Danbolt 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 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 HMS-system. Skatteattest (Skatteattest for skatt utstedes av kemner/ kommunekasserer (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 1. 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. Kredittvurdering vedlagt 4 Leverandøren skal ha erfaring fra minimum 3 tilsvarende oppdrag i løpet av de 3 siste årene. (Man bør utdype hva man legger i "tilsvarende oppdrag".) 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. Beskrivelse av leverandørens 3 mest relevante oppdrag i løpet av de siste 3 årene. Beskrivelsen må inkludere angivelse av oppdragets verdi, tidspunkt og mottaker (navn, 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. Vedlegg 5, kapittel Leverandøren skal Redegjørelse for de verktøy, Vedlegg

ha tilstrekkelig gjennomføringsevne og kapasitet. Det kreves et godt og velfungerende kvalitetssikringssystem for ytelsene som skal leveres. Konkurransegrunnlag for anskaffelse av nettstedet data.norge.no materiell eller teknisk utstyr som leverandøren disponerer over til gjennomføring av kontrakten/oppdraget. 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. 5, kapittel 3 og 4 samt vedlagte CVer 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 % Løsningsforståelse 50 % Leveringsdyktighet 30 % Tilbudet bør gi en oversikt over prissettingen for de enkelte delelementer, samt en samlet pris for hele leveransen. Løsningsforståelse vil bli vurdert ut ifra tilbudet i sin helhet. Fordi løsningen 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. I tillegg til tilbudet i sin helhet og planlagt gjenbruk av åpen kildekode, Relevant dokumentasjon: 7 Utfylt kravmatrise Vedlegg 7 - Løsningsbeskrivelse Vedlegg 5, kapittel - 6 5 6

vil leveringsdyktighet bli vurdert ut ifra leverandørens referanser. Tilbudet skal derfor inneholde kontaktpersoner hos minst tre tidligere kunder. 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 offentlig tilgjengelig som en betatjeneste i utviklingsfasen, gjennom domenet data.norge.no. Ansvaret for dette nettstedet vil etter hvert overføres fra FAD til Direktoratet for forvaltning og IKT (Difi). FAD/Difi vil i utgangspunktet drifte denne løsningen selv. Dersom det blir aktuelt å sette ut videre drift av løsningen vil det bli lagt opp til en separat anbudskonkurranse om drift av nettstedet.. Løsningen vil bli driftet ved Bouvets eget driftssenter i Stavanger.. Vi benytter et system for utviklingog overføring til produksjonssetting som Difi har kjennskap til fra andre prosjekter. (buildout,setuptools,distutils) 6. UNDERSKRIFT Firmaopplysninger Fyll inn Leverandør: Bouvet ASA Adresse: Sandakerveien4c, Boks 4430 Nydalen, 0403 Oslo Kontaktperson: Kristin Jacobsen Telefonnummer: 3 40 60 00 Telefaks: 3 40 60 01 E-postadresse: kristin.jacobsen@bouvet.no Foretaksnummer: 974 44 167 Oslo..., den...3. august 010 Se underskrift på tilbudsbrev

... 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

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 Status Leverandøren sitt svar 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 JA JA JA Se løsningsforslag. Deliverance og WSGI syr sammen frittstående moduler visuelt og navigasjonsmessig. HTML og CSS fra valgte moduler sys om til et helhetlig inntrykk på vei ut. Autentisering gjøres gjennom WSGI. 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. Er allerede oversatt til bokmål. Wordpress og Drupal er også internasjonalisert med GNU gettext. Oversetting 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. 1.1.4 Løsningen skal aktivt hjelpe brukeren til å følge referansekatalogens krav til ITstandarder 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. 1.1.5 Løsningen skal utformes i tråd med statens IKT- arkitekturprinsipper: http://prosjektveiviseren.no/dokumenter/ arkitekturprinsipper Uklart Vi vil aktivt hjelpe brukeren ved å designe innleggingsskjemaet slik at det forklarer hva som er gode datasett. Formuleringen i den andre setningen er er problematisk da data.norge.no ikke skal speile dataene, kun metadata om datasettene. Vi har heller ingen enkelt automatiserbar metode å sjekke formatet på. (MIMEtype ved HTTP GET er ofte ikke til å stole på og eksempler fra data.gov.uk og data.gov peker av og til på HTML sider med lenke videre.) Standardene fra referansekatalogen er også i stor grad for visning og dokumentutveksling. F.eks. er ikke RDF/ Linked Data eller komma-separerte verdier (CSV) en del av standarden og vi må falle tilbake på regneark-delen av ODF/OOXML. Andre utfordringer som er vanskelig å dekke er tegnsett og HTTPheadere. Vi kan peke til verktøy. 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 HTMLnettsider. 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 åpenkildekode 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. 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. 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. 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.

1. Administrasjon av nettstedet Vi vil benytte RDF eksport til å bygge navigasjonsider. 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 og Drupal 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. repoze.who står for autentisering for alle komponenter lenger bak som kan slå opp brukernavn i REMOTE_USER headeren.

1.. Innholdet på nettstedet skal kunne administreres gjennom et webbasert grensesnitt kryptert med SSL. 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. JA Bouvet kjøper inn et standard signert SSLsertifikat 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. Autentisering skjer ved kombinasjon av brukernavn (epostadresse) og passord. Innloggingen skjer over SSL/ HTTP med standard sesjonsbasert informasjonskapselbasert innlogging. Identiteten på en brukerekonto er epostadressen. 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

passordet. 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. Institusjoner er selv ansvarlig for å stenge ned brukerkonto for brukere som slutter. De kan på siden for organisasjonen se hvem som er registrert som representanter. 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. 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 blogg-komponenten.

Delvis 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. Vi benytter CKANs Versioned Domain Model. Metadataene er versjonert men ikke bundet til utgivelser slik programvarekataloger typisk er implementert. http://okfn.org/ projects/vdm/ 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. 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 NEI Delvis CKAN har innebygget støtte for groups og tagging. Groups er metaforen for å (manuelt) håndtere, navngi og presentere relaterte datasett. I tillegg vil vi tilby grensesnitt for geografisk og institusjonell kategorisering og navigasjon. Sparql/RDF grensesnittet kan benyttes av utviklere til å gjøre spørringer mot metadataene. Det samme grensesnittet vil bli brukt på spesielle navigasjonssider vi utvikler. OPSJON: Utvidelse til CKAN. 1 timer. CKAN tilbyr noe programvare, eksempler og infrastruktur. Utover dette må import utvikles i hvert enkelt tilfelle. Tolker tjeneste som en spesiell type datasett. Registreres og oppdateres som

feilmeldinger meldt på nettstedet. Beskriv hvordan disse metadatadefinisjonene kan vedlikeholdes. 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. Beskriv hvordan disse URI-ene kan vedlikeholdes. andre datasett i innleggingsskjema. Gjennom WSGI har vi full kontroll over adressestrukturen uavhengig av detaljene i underliggende komponent. De valgte komponenten har allikevel alle «pene» adresser. Redaksjonelt vedlikehold vil ikke være nødvendig. Se avsnitt om adressestruktur i løsningsforslaget. 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. Bygges over CKAN. Ekstra data samles inn i utvidet redigeringsskjema. Bygger dette på ORDF og SPARQL. Presentasjon gjennom Deliverance Vi kan støtte mange varianter av tilbakemelding men foreslår følgende: Hver datapakke får en åpen wikidiskusjonsside i Drupal. 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.) Eiere av pakken blir

varslet med epost når noe endres/legges inn. Redaksjonen får en feed hvor de kan følge med på alle endringer og funksjonalitet for tilbakerulling slik at hærverk enkelt kan rettes opp. Bruker kan fylle ut felt med kontaktinformasjon. De fleste datasett vil også være bundet til en organisasjon gjennom opplaster. Applikasjoner har kun ekstern kontaktinfo. 1..15 Det skal være mulig å følge en RSS/Atomfeed 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. DELVIS Kun feed fra hele nettstedet eller enkeltpakker er støttet i CKAN 1.1. Andre feeds må utvikles etter endringsordre. 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. 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. Delvis Vi teler og viser antall sidevisninger og lager en side som viser mest besøkte datasett. Ettersom dataene ikke speiles eller ligger på data.norge.no har vi ikke tilgang til reelle bruksdata. Bygges over CKAN. Brukere kan registrere applikasjoner og bruk av datasett. Åpen innlegging, redaksjonen må følge med på listen og fjerne

SPAM og hærverk. 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 Delvis NEI Vi finner ikke rom for utvikling av eget interaksjonsdesign og grafisk design. Vi gjenbruker grafisk profil, typografi og farger fra eksisterende data.norge.no. Interaksjonsdesignet blir rudimentært. Vi benytter forskjellige plattformer og moduler for nettsted og katalog. Redigeringsgrense snittene vil være forskjellige. Vi anser det som lite kostnadsmessig å integrere disse grensesnittene. Benytter Solr. Bygges spesielt. Redaksjonelt styrt ved å søke frem pakker. Eksisterende blogg er i Wordpress. Vi foreslår å videreføre denne slik at den eneste endringen vil være evt. oppgradering etter retningslinjene gitt fra Wordpress-utviklerne. Vi vil se på muligheten til å overføre databasen til PostgreSQL for å forenkle drift. Opplaster kan manuelt illustrere

både kunne lastes ned og kunne visualiseres i nettleseren av besøkende. Minimum støtte er JSON og XML. og dokumentere datasettene på diskusjonssiden for hvert enkelt datasett. Brukere kan også legge inn metadata som peker på visualiseringer andre steder. Ytterligere visualisering lar seg ikke realisere innenfor budsjettrammene. Funksjonalitet som automatisk opplasting av CSV til swivel.com eller inline bruk av Googles interaktive grafer må utredes som en utvidelse. 1.6 Tilgjengelighet av rådata 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 JSON- og XMLformat (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 Sparql-sø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..3 Leverandøren bes beskrive ansvarsforhold, ressurser og rutiner for utvikling, feilretting, kvalitetskontroll og support for tilbudt tredjeparts programvare. 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 arkitektur hvor data.norge.no ikke binder opp store investeringer i enkeltplattformer eller enkeltprodukter. FAD får adgang til å melde inn feil og endringsønsker i Bouvets issuetracker (Jira) for data.norge.no. Feilmeldinger fra eksterne må gå via infrastruktur FAD selv setter opp eller etterhvert via DIFIs eksisterende infrastruktur. Bouvet dokumenterer driftsmiljøet minimum slik at DIFI (eller andre) kan sette opp et produksjonsmiljø. Bouvet kan ikke ta

på utstrakt seg å feilretting i de aktuelle modulene utover at de skal levere avtalt funksjonalitet. Etter leveranse er kunden selv ansvarlig for videreutvikling og feil som følge av videre endringer. Etter ferdig leveranse forgår endringer og nye feilrettinger fortløpende til avtalt timepris. FAD/DIFI står fritt til å velge leverandører. Såfremt det lar seg gjøre vil feilrettinger i produktene, mest sannsynlig CKAN infrastrukturen som er minst moden, bli gjort tilgjengelig for de opprinnelige prosjektene. 3. Generelt Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 3.1 Dokumentasjon 3.1.1 Følgende dokumentasjon skal tilpasses oppdragsgiver og utarbeides: Brukerdokumentasjon for innholdsleverandørene Bruker/system-dokumentasjon for administrator Driftsdokumentasjon for leverandør av tjenesten Brukerveiledning for sluttbruker, tilgjengelig på nettstedet Teknisk dokumentasjon (programvare, versjoner, plattform, osv.) Vi lager egne innleggingskjema for å redusere behovet for detaljert brukerdokumentasjon. Mye dokumentasjon vil være pekere til komponentenes egen dokumentasjon. Vi dokumenterer hvordan de er satt opp

og integrert. Oppsett, drift, backup osv. Vi dokumenterer egenutviklede administrasjonsider som f.eks. brukeradministrasjon. Brukerdokumentasjon skrives av oss. Vi har satt av ett ukesverk. 3.1. Løsningen i seg selv skal være mest mulig selvforklarende, og alle moduler og funksjoner skal beskrives i dokumentasjonen. 3.1.3 Alle skjema skal følge ELMER standarden. http://standard.difi.no/ forvaltningsstandarder/anvendelsesomraade/ naeringslivskjema-paa-offentlige-nettsider http://standard.difi.no/ forvaltningsstandarder/standard/elmer/elmerv 3.1.4 All dokumentasjon som utarbeides for løsningen skal leveres i elektronisk form. 3.1.5 Driftsdokumentasjon skal være så presis og detaljert at personer som ikke har deltatt i utviklingen har mulighet til å drifte systemet. 3. Kildekode og rettigheter 3..1 Kildekoden skal leveres med historikk i form av versjonskontroll, og det skal være mulig for tredjepart å bidra med nye funksjoner til kildekoden. Oppgi hvilket Innleggingsskjema vil følge ELMERstandarden med forbehold om at det sannsynligvis bare vil være én side og at venstre kolonne vil være overflødig. Vi benytter Sphinx, en fritt tilgjengelig pakke som generer dokumentasjon til CKAN. For å spare tid vil utviklerne sette opp produksjonsmiljøet hos Bouvet. Driftsdokumentasjonen blir skrevet, og implisitt testet, når drift av systemet overføres til DIFI (eller annen leverandør). Videre vedlikehold av driftsdokumentasjon må håndteres underveis etterhvert som endringer oppstår. mercurial, men ingen sterke føringer. Et distribuert

versjonskontrollsystem dere vil levere kildekoden i. versjonskontrollsystem gjør det enklere å dele og flette inn bidrag fra tredjeparter. Samtidig bør alle endringer (patcher) vurderes sikkerhetsmessig frem til data.norge.no stoler på bidragsyteren og vil gi direkte adgang. Dersom data.norge.no forventer jevnlige bidrag til egenutviklede komponenter (ikke utenkelig) bør det estimeres med et staging-miljø når DIFI overtar drift. For å hjelpe bidragsytere bør databasene gjøres tilgjengelig. (Forutsatt at de ikke inneholder/strippes for konfidensielle data.) Produksjonssetting av endringer kan skje fortløpende gjennom pakkesystemet (buildout) så lenge databaseoppgraderinge r skriptes. Vi anser mercurial som naturlig da det er dette CKAN benytter. Generelt anbefaler vi bruk av et distribuert versjonskontrollsystem for å forenkle publikasjon og åpenkildekode garantere at alle har adgang til klientene. De vanligste åpenkildekode alternativene er: git mercurial bazaar

subversion. 3.. Spesialutviklet kildekode skal dokumenteres grundig. Det skal være mulig for andre å bruke kildekoden til å sette opp tilsvarende nettsteder. Dokumentasjonsspråket er engelsk. mercurial og bazaar er skrevet i Python, samme språk som CKAN. De har også gjort seg en del tanker rundt distribuert versjonskontroll av metadataene hvor de så på mercurial så det er derfor naturlig å foreslå mercurial. Mtp. publisering av endringer har distribuerte system infrastruktur som github, launchpad.net eller bitbucket (mercurial) til å dele sine patcher. Kode kan også publiseres direkte fra data.norge.no. Spesialutviklet kildekode vil i stor grad bli skrevet på Pythonplattformen. Python regnes for å være lettere å lese en mange andre programmeringsspråk og har funksjonalitet som «docstrings» og «modulestrings». I andre prosjekter hvor Bouvet benytter Python skriver vi delvis selvtestende dokumentasjon som i stor grad er hentet direkte fra kildekoden. Vi søker å følge samme prinsipper her. Dokumentasjonen versjonskontrolleres i samme kildekode-depot som kildekoden. Dokumentasjon skrives i formatet restructuredtext. HTML genereres med dokumentasjonsko

mponenten http:// sphinx.pocoo.org/. Produktet brukes av mange åpen-kildekode prosjekter, inklusive programmeringsspråket Python selv. Oppsettsdokumentasjon genereres legges ut på meta.data.norge.no eller lignende. 4. Test Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 4.1 Leverandøren skal lage en testplan for følgende tester: 1.funksjonstest.robusthetstest 3.integrasjonstest 4.volum-, kapasitets- og svartidstest 5.gjennomgang av all dokumentasjon 6.installasjonstest 7.test av driftsprosedyrer, herunder sikkerhetskopiering 8.nettlesertest Delvis Meget omfattende testkrav gitt budsjettrammer. Vi har satt av ett ukesverk til testing. Testene utføres systematisk av ikkeutviklere to uker før lansering av iterasjon 3. Dette gir oss én uke til feilretting. Testplan lages i iterasjon 3. Funksjonstest: Utføres på alle komponenter Robusthetstest: Utføres på registreringsskjema Integrasjonstest: Utføres ved testing av applikasjons- og ekstra metadata. Volum-, kapasitets- og

svartidstest: Utføres ikke. Gjennomgang av all dokumentasjon: Utføres. Installasjonstest: Utføres ikke før DIFI overtar drift. Test av driftsprosedyrer: Sikkerhetskopiering testes. Nettlesertest: Sjekker YAHOOs A- nettlesere for eksternt synlige sider. I interne redigeringsgrensesnitt krever vi mer oppdaterte nettlesere for å holde utviklingskostnadene nede. 4. Leverandør må ha egnede prosedyrer for endringshåndtering. Hvem og hvordan besluttes endringer? Beskriv eventuelle prosesser og prosedyrer rundt dette. Bouvet har etablerte maler og prosesser rundt endringer. Både Kunde og Leverandør kan foreslå endringsanmodninger. Disse konsekvenseutredes og estimeres så av Leverandør. Deretter har Kunde rett til å bestille endringen. Når endringen er realisert, skal den godkjennes av Kunde før saken lukkes. Hele prosessen blir dokumentert i Bouvets henvendelsessystem. 5. Fremdriftsplan Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 5.1 Leverandøren bes fremlegge en detaljert Se bilag 5, kapittel 6.

Konkurransegrunnlag for anskaffelse av nettstedet data.norge.no fremdriftsplan for utvikling, testing, installasjon, pilot og produksjonsstart.