Fibrer

Snap = rss + interaktion

Läs Matt Webbs tankar utanför lådan om RSS-flöden i det han kallar Snap, ”syndicated next action pattern”.

RSS som vi känner det är en bärare för medieinnehåll, om det nu är blogginlägg, nyhetsartiklar, poddradioavsnitt, Flickr-foton eller något annat.

I RSS-läsaren prenumererar vi på eller syndikerar innehåll. Modellen ser ut så att vi har ett antal flöden som RSS-läsaren bevakar. När nytt innehåll upptäcks så indikeras det på något sätt så att vi kan skanna av om något nytt intresserar oss och i så fall konsumera det.

Snap är snarare en bärare av data. Och modellen omfattar även interaktion med detta data, förutom syndikering av nytt eller uppdaterat data.

Bland de möjligheter Matt ser för Snap finns en som jag särskilt tycker illustrerar det hela bra.

Tänk dig att du kunde prenumerera på ditt Facebook-flöde i din rss-läsare. Okej, det kan du, nästan. Du kan inte prenumerera på hela flödet, med alla uppdateringar från alla SuperPokes och FunWalls i ditt nätverk. Du kan bara prenumerera på flöden med kompisars statusuppdateringar samt aktivitet som är riktad till dig.

Frågan är om man verkligen skulle vilja ha hela flödet i sin rss-läsare, men låt säga att man vill det. Med Snap skulle du då kunna interagera med Facebook och de appar du får uppdateringar från. Du skulle kunna svara på en SuperPoke eller ta samma quiz som någon av dina kompisar. Direkt i din rss-läsare.

Nu var det inte Facebook som gav upphov till den här idén, utan David Allens metod ”Getting things done”.

Jag behöver inte gå in på vad ”GTD” går ut på utan det räcker att veta att ”next action” ungefär motsvarar punkter på en att göra-lista. Och det är därifrån namnet kommer, Syndicated next action pattern.

Om du föreställer dig en webbapp för att hantera att göra-listor, lägga till och bocka av punkter osv – och tänk dig att du manövrerar webbappen helt och hållet från din rss-läsare. När du lägger till en punkt på en lista dyker den upp på samma sätt som ett nytt blogginlägg dyker upp. Och när du tittar på den kan skulle du kunna ändra prioritet, schemalägga den och bocka av den.

Varför är det här intressant?

Jo, vi använder fler och fler webbappar idag. Och vi får uppdateringar från dem via mejl, sms, direktmeddelanden – och rss.

Dessa uppdateringar innehåller ofta länkar för att interagera – att svara på ett Facebook-meddelande, att lägga till någon som lagt till dig som vän osv.

Och Matt Webb visar hur rss-läsare med rätt små medel skulle kunna anpassas för den sorts interaktion som Snap skulle medge.

Kommer Snap bli verklighet? Ingen aning, men det är oavsett ett intressant tankeexperiment.

Läs också Tom Armitage, som tillsammans med Matt tagit fram ett proof of concept för Snap.

(Foto av glenneroo under Creative Commons-licens.)

Portabla sociala nätverk inte längre en geekfantasi

När det först började snackas om portabla sociala nätverk så var jag skeptisk. Av två anledningar.

1. Det är ett geekproblem. Den breda massan lider inte av social network fatigue. De går heller inte och önskar att de kunde exportera sitt data som ett XML-dokument.
2. What’s in it for them? De sociala nätverken själva, menar jag. Eller FaceBook främst, som ju är dominerande. Lock-in är ju givetvis bra för FaceBook. Varför skulle de öppna upp datat så folk (teoretiskt) kan ta sitt pick och pack och dra till en konkurrent?

Men så kom Google OpenSocial. Google kontrade alltså med öppenhet. Briljant! (Även om de kanske förhastade sig.) De pratar om öppenhet och sätter därmed fingret på att FaceBook är en sluten plattform.

Nu var det förvisso inte säkert att OpenSocial skulle innebära portabilitet för data. Vid lanseringen handlade det bara om portabilitet för applikationer. Även om du kan köra din app både på Ning och Orkut innebär det inte automatiskt att du från Ning kan kommunicera med din kompis som kör samma app på Orkut.

Men det var många som såg dataportabilitet som ett naturligt nästa steg. Och först då började jag känna att portabla sociala nätverk kanske skulle bli verklighet ändå. Eftersom Googles vapen mot FaceBooks dominans var öppenhet. Alla appar och all data överallt.

Ett av FaceBooks svar var att dess API blev tillgängligt på Bebo, ett annat socialt nätverk. Därmed skulle FaceBook-applikationer kunna köras även där, utan Googles OpenSocial (även om Bebo är med även i det initiativet).

Och det rullar på. Facebook gick för en dryg månad sedan med i DataPortability.org (samtidigt som Google). Facebook släppte häromveckan ett JavaScript-bibliotek som gör att appar nu kan bäddas in som widgets var som helst utanför Facebook. Och i fredags lanserade Google sitt Social Graph API, som även om det inte är knutet till OpenSocial kan ses som början på det förutspådda nästa steget, att göra datat mer portabelt.

Google har ändrat spelreglerna. Nu är det ett spel om öppenhet. Sannolikt får vi se mer och mer av det här slaget. Bra för alla.

(Foto av murz.)

FaceBook öppnare än jag trodde

Ok, kikade på ”OpenFaced: opening up the social graph”, en paneldiskussion som hölls under konferensen Graphing Social Patterns.

Hajade till på följande ordväxling, när Tantek Çelik frågade panelen om portabla sociala nätverk: ”But if I create a FaceBook app, I have that [social] network from the beginning, right? ... I like to ask Ted [Grubb, på Satisfaction] a question, Why did Satisfaction choose to create their own site, that obviously needs a social component there, rather than creating a FaceBook app?”

På vilket Facebooks Chamath Palihapitiya svarade, ”By the way, you can also, actually, just consume our APIs and get that information on getsatisfaction.com.”

Det var nytt för mig. Jag trodde FaceBooks terms of service sa att inget data får lämna FaceBook.

Det visade sig stämma åtminstone delvis när diskussionen fortsatte:

• Du får plocka ut information från FaceBook, men du får inte hålla på den längre än 24 timmar.
• Och du kommer inte åt folks kontaktuppgifter, så det finns inte mycket att gå på om du vill matcha ihop individer i din sociala app med individer på FaceBook, för att skapa något slags union av nätverket.

Men kanske har man nytta av Dopplr-folkets IdentityMatcher där.

Hur som helst, överlag fick jag intrycket av att FaceBook har ambitionen att bli öppnare och öppnare, men att de vill trampa försiktigt för att inte riskera användarnas integritet.

Det kommer inte vara enklare att utveckla under OpenSocial

Lyssnar på What's Next-panelen från igår där OpenSocial diskuteras.

Joakim Jardenberg säger:

Det är inte som när du på bygger någonting på Facebook att du måste lära dig FaceBook Markup Language, FaceBook Query Language och så vidare. Utan inom ramen för det här API:t så pratar man helt enkelt helt vanlig standard HTML och helt vanlig standard JavaScript. ... Tröskeln för att komma igång och skriva applikationer som fungerar under under OpenSocial är mycket, mycket lägre och har också en högre portabilitet naturligtvis.

Men OpenSocial är lika mycket ett nytt språk att lära sig. Tröskeln kommer inte vara lägre. Det är som att argumentera att FaceBook är lättare eftersom FBML är ett XML-baserat språk och FQL lånar sin syntax från SQL.

Sedan återstår det att se i vilken grad det verkligen kommer handla om att skriva en app och köra den överallt. Se bara hur du med "standard" HTML och JavaScript ändå måste testa i varje populär webbläsare.

Sökmotoroptimering affärskritiskt

Jörgen Bödmar på Scandinavian Design Online i senaste Internetworld:

Han har storsatsat på att bygga upp kompetens för sökmotoroptimering internt i företaget. Han menar att ett optimeringsföretag inte kan erbjuda motsvarande fördelar – de har oftast för lite branschkunskap [...].

– Jag har en grundläggande uppfattning om att man ska kunna de här sakerna eftersom det är en affärskritisk uppgift. Eftersom vi ser problemen, ser vi också möjligheterna. Vi kan direkt se om en produkt är dåligt optimerad och agera därefter. [...]

Portabla sociala nätverk - den semantiska webben omstöpt för den sociala?

Ett utlovat utdrag från fredagens chatt om ”portabla sociala nätverk”. Lätt redigerat och hyperlänkat här och där.

Anton J: Pownce har en bra grundidé (tror jag) men när det inte ens finns en “Invite your friends” eller en “Check if you’re friends are here too!” grej där man kan synka sin mejl/IM-client så kändes det värdelöst.. En social tjänst utan vänner är urdåligt…

Peter L: Ah! Vilket för oss till portabla sociala nätverk: http://www.brianoberkirch.com/2007/08/08/b…

Peter L: ”...simple it can be to use OpenID & microformats to 1) make your own profile portable and subscribable from any Web service and 2) make your dynamic social network(s) portable and subscrible to new services while 3) anchoring your own ID in a domain/email of your choosing and under your control.” Från ett annat inlägg, http://www.brianoberkirch.com/2007/08/02/d…

Erik S: Är tanken att man ska ha någon slags master-profil, med information om sig själv och sina kontakter? Jag ser att Oberkirch nämner Highrise som ett bra ställe för detta. Har inte fattat allt kring det portabla, även om jag bokmärkt mycket om det den senaste tiden :-)

Jonas C: Vad tycker ni om att Facebook strävar efter att bygga in användaren i sin struktur? Skall inte facebook också låta användare exportera sin information från facebook och inte bara använda andra appar som exporterar sin info in i facebook? [En parallell diskussion fördes om Facebook, men här gick de i varan lite.]

Peter L: Det är ju dit någonstans fortsättningen på det Brian Oberkirch finns. I början handlar det om att använda OpenID inte så mycket för att slippa bördan att komma ihåg lösenord eller registrera sig som för att man ska kunna välja var man känner sig hemma och sedan ha det som “roten” i sin identitet.

Typ, “Jag känner mig mest hemma på Facebook” och så anger man ens OpenID-url hos Facebook, om de nu har någon.

Och sedan, relaterat till det men med hjälp av mikroformat, synkronisera alla ens kontakter från Facebook, eller var man nu rotat sig, samt från andra tjänster man använder.

Men bortom OpenID och att synkronisera kontakter ligger ju att övrig information också skulle vara portabel. Och Brian Oberkirch verkar mena att de som inte anammar detta i framtiden kommer dö.

Men se bara på Twitter, Jaiku, Pownce, Facebook osv. Även om varje av dessa har sin särart så finns det en hel del överlapp. Och jag kanske helst uppdaterar min status och postar små blänkare till mina kompisar på Jaiku. Men andra kompisar föredrar Facebook och då skulle denna information kunna syndikeras dit.

Och det Brian Oberkirch listar är typ de mikroformat som finns idag och som skulle kunna möjliggöra detta. hReview för recensioner, t.ex. hEvent [hCalendar heter det] för evenemang/kalenderinformation. Och resten tycker han ska erbjudas via Atom/RSS och hAtom.

Erik S: Låter inte det väldigt optimistiskt, att alla skulle anamma att all information skulle bli portabel? Profil+socialt nätverk i någon slags maskinläsbar form låter dock vettigt.

Peter L: Erik: Det låter väl ungefär som den semantiska webben, men omstöpt för den sociala?

Alltså, optimistiskt. (-:

Erik S: Nästan utopiskt.

Peter L: Profil+socialt nätverk finns ju idag. hEvent och hReview finns ju också, men där saknas väl lite extra metadata för att kunna avgöra vad det är för något det beskriver?

Erik S: Tänker du på typ FOAF eller nåt?

Peter L: Existerar FOAF längre? XFN fyller ju lite den funktionen och är många gånger enklare.

Erik S: Det var nog XFN jag tänkte på. FOAF är nog tynande

Lite om Amazon EC2 och S3

Jag fick en fråga om för/emot att driva sin webbapp på Amazon EC2 och S3 (Elastic Compute Cloud och Simple Storage Service).

Nu är jag ingen expert på ämnet hosting. Men jag tänkte ändå posta min redogörelse här också. Är jag helt ute och cyklar så hojta i kommentarerna.

Amazon EC2 skiljer sig från andra lösningar på det sättet att du har en eller flera ”images”, avbilder av hela filsystemet för en server. En sådan avbild kan startas upp i EC2-miljön och motsvarar då en 1,7 GHz-server med 1,75 GB minne och 160 GB disk.

Den främsta anledningen att köra sin webbapp på EC2 är just möjligheten att kunna skala upp och ned kapaciteten vid behov.

Särskilt intressant är det om man har väldigt oregelbunden trafik. Du kan dra igång extra instanser och bara köra dem i någon timme för att sedan ta ner dem igen.

Det finns andra lösningar än EC2 som ger mer men inte lika flexibel skalbarhet. T.ex. kan det vara intressant att jämföra med Media Temples Grid Server.

Har du inte behovet att snabbt kunna skala upp kapacitet kan i stället VPS (Virtual Private Server) eller shared hosting vara ett alternativ.

Både VPS och shared hosting betyder att man delar en fysisk maskin (eller flera) med andra. Det som skiljer dem är att en VPS-lösning ger prestanda motsvarande en viss fysisk maskin medan du på en shared hosting-lösning delar resurser med andra användare. Sedan uppträder en VPS-lösning som en egen fysisk server, där du är isolerad från andra kunder.

EC2 kan ändå vara ett prismässigt bra alternativ till VPS även om du inte har behov av snabb skalbarhet. Vad jag förstår står sig Amazons prissättning bra mot VPS; en instans kostar ca 70 USD i månaden.

Amazon S3 är en lagringstjänst som används ihop med EC2. Systemavbilderna lagras på S3 och när du har flera instanser kan S3 användas för gemensam lagring.

Men S3 kan också användas oberoende av EC2. Vi serverar t.ex. bilderna i Menumo från S3.

Och har du en app som inte är så processorintensiv men som serverar mycket bilder eller annan media som kräver bandbredd så kan det vara värt att överväga en vanlig shared hosting-lösning kombinerat med S3.

Vi kör även vår MP3-blogg på Amazon S3. När vi bytte från vår tidigare lagringslösning beskrev jag lite kort vad som krävdes för att gå över.

Är Freebase svaret på den semantiska webben?

Freebase beskrivs som en “öppen, gemensam databas över världens kunskap”.

Men det är inte en ny Wikipedia. Snarare är Wikipedia bara en av flera informationskällor för Freebase.

Medan Wikipedia är ett uppslagsverk för människor kan Freebase snarare beskrivas som ett uppslagsverk för datorer.

Ytterst handlar förstås även Freebase om att bättre hitta information åt människor. Och för det krävs bättre kopplingar mellan bitar av information. Att information som hör ihop kopplas samman. Och framförallt att det beskrivs på vilket sätt den hör ihop.

Den semantiska webben, med andra ord.

Klassificerad information

Tim O’Reilly ger ett utförligt exempel. Han söker på sitt företag, O’Reilly Media, och hittar en post i databasen som innehåller ett foto på företagets byggnad samt ett utdrag från Wikipedia.

Så långt är det inte så intressant. Fotot har tydligen laddats upp av någon och Freebase syndikerar överensstämmande artiklar från Wikipedia.

Mer intressant är att posten för O’Reilly Media klassificerats som “ett företag”. Jag antar att det är en användare som gjort denna klassificering.

Med typen “företag” är förknippat en uppsättning egenskaper som också kan fyllas i. Det är information såsom när företaget grundades, vilken bransch det är verksamt i, vilken årsomsättningen är osv.

Semantiska kopplingar

Varje av dessa egenskaper är “typade”, dvs. att informationen som anges inte enbart är fritext. För årsomsättning är t.ex. typen “Money value”, för bransch är den “Industry”, för antal anställda är den “Dated integer” (dvs. att det anges när i tiden siffran gällde).

Poängen med typade egenskaper är att kopplingen mellan information ska vara “semantiskt rik”. En annan egenskap för ett företag är dess nyckelpersoner. Här är typen “Employment tenure”, vilket verkar innebära att man dels pekar ut en person och dels anger befattning. Tim O’Reilly listas som företagets vd.

Om vi tänker oss att vi tittar på posten för Tim O’Reilly själv så borde man se honom klassificerad som “en person”. Man skulle också se att han är vd på företaget O’Reilly Media, eftersom han pekats ut som nyckelperson för företaget.

Vad är då poängen med det här? All denna information finns redan på Wikipedia och genom att gå dit och söka skulle man kunnat ta reda på exakt detta.

Skillnaden är att datorer inte kan gå till Wikipedia och dra dessa slutsatser. Och det är det som den semantiska webben är tänkt att råda bot på.

Ett Wikipedia för maskiner

Tanken med den semantiska webben är att gå bortom att bara presentera information så som det görs på Wikipedia idag. Och på alla andra webbplatser för den delen. Tanken är att dessutom beskriva samma information så att den kan tolkas maskinellt. “Denna webbsida handlar om företaget med namnet ‘O’Reilly Media’, vars nyckelpersoner är personen med namnet ‘Tim O’Reilly’, med befattningen ‘vd’, med flera, verksamt i branschen ‘förlagsbranschen’ osv.”

Freewebs lösning på den semantiska webben är istället att centralt samla den semantiska informationen, alltså informationen som beskriver vad det är för information och hur den hänger ihop med annan information. Och att Freewebs användare bygga upp denna information i stället för att förlita sig på att alla som publicerar information också beskriver dess semantik.

Denna lösning verkar onekligen mer realistisk. Kan du se framför dig att varje bloggare, varje kommunal webbredaktör, varje tonåring som laddar upp filmklipp på Youtube – kort sagt att alla som publicerar information på nätet skulle ta sig tid att beskriva informationen i den här utsträckningen?

Samtidigt är det ett enormt ambitiöst projekt. Men det kan fungera, givet att Wikipedia lyckats komma dit de är idag med en teknisk plattform som utesluter alla förutom de mest hängivna geeksen. Av de skärmdumpar som Tim O’Reilly postat så är det tveklöst mycket mer tillgängligt.

Konsensus eller folksonomi

Frågan är bara hur långt Wikipedia-liknelsen kan dras. Wikipedias modell bygger på konsensus, dvs. att man enas om vad som stämmer, vad som är sant. Denna modell fungerar bättre i vissa sammanhang, men när det gäller omstridda ämnen blir det svårare, som Israel-/Palestinakonflikten.

Av Tim O’Reillys text att döma så satsar Freeweb inte på konsensus. Han skriver att de istället går folksonomi-vägen, dvs. att man tillåter människor att klassificera saker på det sätt som är meningsfullt för dem. Det kommer att vara motsägelsefullt men man sätter sitt hopp till att det ska gå att avgöra vad sanningen är efter att flera har klassificerat något. Om banan är en frukt enligt 150 av 200 människor så är det en frukt och inte ett bär.

Än så länge finns inte så mycket detaljer om Freeweb. Förutom Tim O’Reillys inlägg finns en artikel i New York Times. Det har givetvis börjat snackas bland bloggar men jag har inte hittat något ännu med mer information.

Främsta anledningen till att jag är intresserad är egentligen att det är Danny Hillis som ligger bakom. Han är en av mina hjältar och inget mindre än ett geni. Min uppfattning är att hans drivkraft är att skapa saker som är av verkligt värde för människor, han är inte intresserad av att piska upp hajp.

Det ska bli mycket intressant att se hur det här utvecklar sig.

Hitta.se har ett API för sina kartor, men är det publikt?

Läste om Skypes och Aftonbladets gratis-WiFi och klickade på länken “Finn din hotspot” på deras hemsida. Denna ledde till en stor karta hos Hitta.se där alla öppna accesspunkter fanns markerade.

Det visade sig vara samma karta som man når från Hitta.se. Ingenting ovanligt i URL:en eller något.

Så jag tittade i HTML-koden på skypewifizones.se och hittade följande:

Alltså ett formulär som postas till Hitta.se, med ett XML-dokument där alla kartpunkter specificeras, ihop med vilken ikon de ska ha på kartan samt vilken HTML som ska visas i “pratbubblan” som öppnas när man pekar på varje kartpunkt.

Det är ett ganska statiskt API jämfört med t.ex. Google Maps Javascript-baserade, men man kan ju undra om det här är något som kommer bli tillgängligt för alla.

Var går rimlighetens gräns för "restful" design i Ruby on Rails?

Tanken på “restful” design gnager fortfarande. Ur Svantes och min IM-diskussion idag…

Peter: Läser lite om REST på Wikipedia

Svante: ah, hehe, jag har läst på där en gång. inför intervjuerna

Peter: Det ondaste [enligt] REST-synen är ju att hålla (mycket) state på motsatta sidan. Typ som WebObjects gör med allt session-state på servern, med backtrack-cache osv. Eller som de [vilka nu de är] som lagrar en massa state i cookies.

Men vad jag inte visste var det här att man betraktar designen utifrån “resurser” i längsta möjliga mån.

Svante: hmm, det är intressant, men svårt att vara renlärig.

Peter: Varje HTTP-request är en interaktion mot en resurs. Och där är HTTP-metoderna [de] mest basala, GET, PUT… osv. Dvs. CRUD.

Svante: jo, jag hajar, frågan är om det räcker.

Peter: Nä det gör det ju inte. Och det är det väl ingen som påstår egentligen. Men man kan ju designa utifrån resurser och operationer på dessa. Frågan är bara var rimlighetens gräns går.

Typ, är det meningsfullt att i stället för /login ha /session/new? Och /session/destroy istf /logout. [Se även Josh Sussers tankar om att införa resursen “sökning”.]

Är det inte bara analt?

Svante: Det kan ju innebära att man visar applikationen mer än man vill.

Peter: Riktigt restful skulle ju [vara att] skicka med sessions-id:t i varenda request också. /users/1?session_id=adhguq34afj

Svante: Det känns som om man låser sig tankemässigt. Men, som vanligt är jag snabb att dra slutsatser.

Peter: Scott Raymond har ett populärt inlägg om hur han refaktoriserade IconBuffet “till REST” [permalänken trasig för tillfället; sök efter “Refactoring to REST” på hans blogg]. Och han menar att han reducerade och förenklade sina controllers/actions radikalt. Han la till tre controllers och skar ned antalat actions med ett tjugotal.

Han har tre kvar som [han tycker] är “oddball”: about/home, about/license, about/privacy, about/tos och people/retrieve_password.

Det börjar klarna lite. Och om inte annat så är det intressant att tänka på sin app i termer om vilka resurser den app består av. (Persistenta eller ej; dvs. sökning kanske är en resurs, men då är den nog oftast transient).