-<p>I dag la jeg inn en kommentar på en sak hos NRKBeta
-<a href="http://nrkbeta.no/2010/10/27/bakom-blindpassasjer-del-1/">om
-hvordan TV-serien Blindpassasjer ble laget</a> i forbindelse med at
-filmene NRK la ut ikke var tilgjengelig i et
-<a href="http://www.digistan.org/open-standard:definition">fritt og
-åpent format</a>. Dette var det jeg skrev publiserte der 07:39.</p>
-
-<p><blockquote>
-<p>"Vi fikk en kommentar rundt måten streamet innhold er beskyttet fra
-nedlasting. Mange av oss som kan mer enn gjennomsnittet om systemer
-som dette, vet at det stort sett er mulig å lure ut ting med den
-nødvendige forkunnskapen."</p>
-
-<p>Haha. Å streame innhold er det samme som å laste ned innhold, så å
-beskytte en stream mot nedlasting er ikke mulig. Å skrive noe slikt
-er å forlede leseren.</p>
-
-<p>Med den bakgrunn blir forklaringen om at noen rettighetshavere kun
-vil tillate streaming men ikke nedlasting meningsløs.</p>
-
-<p>Anbefaler forresten å lese
-<a href="http://blogs.computerworlduk.com/simon-says/2010/10/drm-is-toxic-to-culture/index.htm">http://blogs.computerworlduk.com/simon-says/2010/10/drm-is-toxic-to-culture/index.htm</a>
-om hva som ville være konsekvensen hvis digitale avspillingssperrer
-(DRM) fungerte. Det gjør de naturligvis ikke teknisk - det er jo
-derfor de må ha totalitære juridiske beskyttelsesmekanismer på plass,
-men det er skremmende hva samfunnet tillater og NRK er med på å bygge
-opp under.</p>
-</blockquote></p>
-
-<p>Ca. 20 minutter senere får jeg følgende epost fra Anders Hofseth i
-NRKBeta:</p>
-
-<p><blockquote>
-<p>From: Anders Hofseth &lt;XXX@gmail.com>
-<br>To: "pere@hungry.com" &lt;pere@hungry.com>
-<br>Cc: Eirik Solheim &lt;XXX@gmail.com>, Jon Ståle Carlsen &lt;XXX@gmail.com>, Henrik Lied &lt;XXX@gmail.com>
-<br>Subject: Re: [NRKbeta] Kommentar: "Bakom Blindpassasjer: del 1"
-<br>Date: Sat, 30 Oct 2010 07:58:44 +0200</p>
-
-<p>Hei Petter.
-<br>Det du forsøker dra igang er egentlig en interessant diskusjon,
-men om vi skal kjøre den i kommentarfeltet her, vil vi kunne bli bedt
-om å fjerne blindpassasjer fra nett- tv og det vil heller ikke bli
-særlig lett å klarere ut noe annet arkivmateriale på lang tid.</p>
-
-<p>Dette er en situasjon NRKbeta ikke ønsker, så kommentaren er
-fjernet og den delen av diskusjonen er avsluttet på nrkbeta, vi antar
-konsekvensene vi beskriver ikke er noe du ønsker heller...</p>
-
-<p>Med hilsen,
-<br>-anders</p>
-
-<p>Ring meg om noe er uklart: 95XXXXXXX</p>
-</blockquote></p>
-
-<p>Ble så fascinert over denne holdningen, at jeg forfattet og sendte
-over følgende svar. I og med at debatten er fjernet fra NRK Betas
-kommentarfelt, så velger jeg å publisere her på bloggen min i stedet.
-Har fjernet epostadresser og telefonnummer til de involverte, for å
-unngå at de tiltrekker seg uønskede direkte kontaktforsøk.</p>
-
-<p><blockquote>
-<p>From: Petter Reinholdtsen &lt;pere@hungry.com>
-<br>To: Anders Hofseth &lt;XXX@gmail.com>
-<br>Cc: Eirik Solheim &lt;XXX@gmail.com>,
-<br> Jon Ståle Carlsen &lt;XXX@gmail.com>,
-<br> Henrik Lied &lt;XXX@gmail.com>
-<br>Subject: Re: [NRKbeta] Kommentar: "Bakom Blindpassasjer: del 1"
-<br>Date: Sat, 30 Oct 2010 08:24:34 +0200</p>
-
-<p>[Anders Hofseth]
-<br>> Hei Petter.</p>
-
-<p>Hei.</p>
-
-<p>> Det du forsøker dra igang er egentlig en interessant diskusjon, men
-<br>> om vi skal kjøre den i kommentarfeltet her, vil vi kunne bli bedt om
-<br>> å fjerne blindpassasjer fra nett- tv og det vil heller ikke bli
-<br>> særlig lett å klarere ut noe annet arkivmateriale på lang tid.</p>
-
-<p>Godt å se at du er enig i at dette er en interessant diskusjon. Den
-vil nok fortsette en stund til. :)</p>
-
-<p>Må innrømme at jeg synes det er merkelig å lese at dere i NRK med
-vitende og vilje ønsker å forlede rettighetshaverne for å kunne
-fortsette å legge ut arkivmateriale.</p>
-
-<p>Kommentarer og diskusjoner i bloggene til NRK Beta påvirker jo ikke
-faktum, som er at streaming er det samme som nedlasting, og at innhold
-som er lagt ut på nett kan lagres lokalt for avspilling når en ønsker
-det.</p>
-
-<p>Det du sier er jo at klarering av arkivmateriale for publisering på
-web krever at en holder faktum skjult fra debattfeltet på NRKBeta.
-Det er ikke et argument som holder vann. :)</p>
-
-<p>> Dette er en situasjon NRKbeta ikke ønsker, så kommentaren er fjernet
-<br>> og den delen av diskusjonen er avsluttet på nrkbeta, vi antar
-<br>> konsekvensene vi beskriver ikke er noe du ønsker heller...</p>
-
-<p>Personlig ønsker jeg at NRK skal slutte å stikke hodet i sanden og
-heller være åpne på hvordan virkeligheten fungerer, samt ta opp kampen
-mot de som vil låse kulturen inne. Jeg synes det er en skam at NRK
-godtar å forlede publikum. Ville heller at NRK krever at innhold som
-skal sendes skal være uten bruksbegresninger og kan publiseres i
-formater som heller ikke har bruksbegresninger (bruksbegresningene til
-H.264 burde få varselbjellene i NRK til å ringe).</p>
-
-<p>At NRK er med på DRM-tåkeleggingen og at det kommer feilaktive
-påstander om at "streaming beskytter mot nedlasting" som bare er egnet
-til å bygge opp om en myte som er skadelig for samfunnet som helhet.</p>
-
-<p>Anbefaler &lt;URL:<a href="http://webmink.com/2010/09/03/h-264-and-foss/">http://webmink.com/2010/09/03/h-264-and-foss/</a>> og en
-titt på
-&lt;URL: <a href="http://people.skolelinux.org/pere/blog/Terms_of_use_for_video_produced_by_a_Canon_IXUS_130_digital_camera.html">http://people.skolelinux.org/pere/blog/Terms_of_use_for_video_produced_by_a_Canon_IXUS_130_digital_camera.html</a> >.
-for å se hva slags bruksbegresninger H.264 innebærer.</p>
-
-<p>Hvis dette innebærer at NRK må være åpne med at arkivmaterialet ikke
-kan brukes før rettighetshaverene også innser at de er med på å skade
-samfunnets kultur og kollektive hukommelse, så får en i hvert fall
-synliggjort konsekvensene og antagelig mer flammer på en debatt som er
-langt på overtid.</p>
-
-<p>> Ring meg om noe er uklart: XXX</p>
-
-<p>Intet uklart, men ikke imponert over måten dere håndterer debatten på.
-Hadde du i stedet kommet med et tilsvar i kommentarfeltet der en
-gjorde det klart at blindpassasjer-blogpostingen ikke var riktig sted
-for videre diskusjon hadde dere i mine øyne kommet fra det med
-ryggraden på plass.</p>
-
-<p>PS: Interessant å se at NRK-ansatte ikke bruker NRK-epostadresser.</p>
-
-<p>Som en liten avslutning, her er noen litt morsomme innslag om temaet.
-&lt;URL: <a href="http://www.archive.org/details/CopyingIsNotTheft">http://www.archive.org/details/CopyingIsNotTheft</a> > og
-&lt;URL: <a href="http://patentabsurdity.com/">http://patentabsurdity.com/</a> > hadde vært noe å kringkaste på
-NRK1. :)</p>
-
-<p>Vennlig hilsen,
-<br>--
-<br>Petter Reinholdtsen</p>
+<p>The last few days I have spent some time trying to add support for
+the <a href="http://www.open311.org/">Open311 API</a> in the
+<a href="http://www.fiksgatami.no/">Norwegian FixMyStreet service</a>.
+Earlier I believed Open311 would be a useful API to use to submit
+reports to the municipalities, but when I noticed that the
+<a href="http://fixmystreet.org.nz/">New Zealand version</a> of
+FixMyStreet had implemented Open311 on the server side, it occurred to
+me that this was a nice way to allow the public, press and
+municipalities to do data mining directly in the FixMyStreet service.
+Thus I went to work implementing the Open311 specification for
+FixMyStreet. The implementation is not yet ready, but I am starting
+to get a draft limping along. In the process, I have discovered a few
+issues with the Open311 specification.</p>
+
+<p>One obvious missing feature is the lack of natural language
+handling in the specification. The specification seem to assume all
+reports will be written in English, and do not provide a way for the
+receiving end to specify which languages are understood there. To be
+able to use the same client and submit to several Open311 receivers,
+it would be useful to know which language to use when writing reports.
+I believe the specification should be extended to allow the receivers
+of problem reports to specify which language they accept, and the
+submitter to specify which language the report is written in.
+Language of a text can also be automatically guessed using statistical
+methods, but for multi-lingual persons like myself, it is useful to
+know which language to use when writing a problem report. I suspect
+some lang=nb,nn kind of attribute would solve it.</p>
+
+<p>A key part of the Open311 API is the list of services provided,
+which is similar to the categories used by FixMyStreet. One issue I
+run into is the need to specify both name and unique identifier for
+each category. The specification do not state that the identifier
+should be numeric, but all example implementations have used numbers
+here. In FixMyStreet, there is no number associated with each
+category. As the specification do not forbid it, I will use the name
+as the unique identifier for now and see how open311 clients handle
+it.</p>
+
+<p>The report format in open311 and the report format in FixMyStreet
+differ in a key part. FixMyStreet have a title and a description,
+while Open311 only have a description and lack the title. I'm not
+quite sure how to best handle this yet. When asking for a FixMyStreet
+report in Open311 format, I just merge title an description into the
+open311 description, but this is not going to work if the open311 API
+should be used for submitting new reports to FixMyStreet.</p>
+
+<p>The search feature in Open311 is missing a way to ask for problems
+near a geographic location. I believe this is important if one is to
+use Open311 as the query language for mobile units. The specification
+should be extended to handle this, probably using some new lat=, lon=
+and range= options.</p>
+
+<p>The final challenge I see is that the FixMyStreet code handle
+several administrations in one interface, while the Open311 API seem
+to assume only one administration. For FixMyStreet, this mean a
+report can be sent to several administrations, and the categories
+available depend on the location of the problem. Not quite sure how
+to best handle this. I've noticed
+<a href="http://seeclickfix.com/open311/">SeeClickFix</a> added
+latitude and longitude options to the services request, but it do not
+solve the problem of what to return when no location is specified.
+Will have to investigate this a bit more.</p>
+
+<p>My distaste for web forums have kept me from bringing these issues
+up with the open311 developer group. I really wish they had a email
+list available via <a href="http://www.gmane.org/">Gmane</a> to use for
+discussions instead of only
+<a href="http://lists.open311.org/groups/discuss">a forum<a/>. Oh,
+well. That will probably resolve itself, one way or another. I've
+also tried visiting the IRC channel #open311 on FreeNode, but no-one
+seem to reply to my questions there. This make me wonder if I just
+fail to understand how the open311 community work. It sure do not
+work like the free software project communities I am used to.</p>