Author: kjetil

Enabling Diversity Through Decentralised Social Media

Awareness of the problematic aspects of social media has been brewing for a long time, but recently, it has exploded in the public debate, with the effects of “fake news” and “echo chambers”, and also on the editorial role of Facebook. The response of Facebook has not impressed commentators. To make my position clear from the start: This is a very complex problem to solve and involve social, economical and psychological problems that need to be addressed. However, I wish to make the case that the technology also matters, and an approach must necessarily begin with changing the underlying technology. In this blog post, I would like to list the primary social problems that I have personally identified. However, I’ll try to take a positive angle, this is not just about Facebook and that failings, this is what we should create for the future. Out of the social problems, the echo chamber problem is only one.

The Echo Chamber Problem

My personal history with this problem doesn’t start here, it started 20 years ago, as I took on managing the Web site of the Norwegian Skeptics Society. The subjects we were concerned with were fairly marginal, and easy to label superstition. Astrology, UFOs, etc. It soon became quite apparent that the problem wasn’t to reach out with information, the actual problem was much, much harder, it was to get that information into closed minds. Since then, this problem has grown from being a marginal problem considered only by a few, to a major social problem.

Now, some may say that the problem is not technological, and possibly that technology is indifferent to the problem, any technological platform can help get information into closed minds, and any technological platform can provide infrastructure for opposing viewpoints and enable a debate between them. I disagree, and I think recent events make that clear. Even if technology alone cannot open closed minds, there are technological choices that are critical in enabling the needed platform for an open public debate.

First, it is important to constrain the scope of the technological problem, by understanding the problems that are of different origin. The reason why fake news thrives on Facebook is complicated and this article argues it comes down to the emotions of the people in your social network. This article contains a discussion of why “popping the bubbles” is problematic. It is also important to be reminded of the effects of identity protective cognition. Facebook has themselves published research on the issue. What is interesting is that nowadays, my Facebook feed is full of anti-Facebook sentiments, but none of these articles showed up there. I had to go look for them, only after I started to share these articles in my News Feed myself, similar articles started to surface. Now, the “echo chamber” and “filter bubble” metaphors may not reflect the true nature of the problem, but Facebook arguing that they are not doing so bad is mainly due to the lack of a ambitious baseline, we don’t know yet what could be achieved if a structured, cross-disciplinary approach was made. Even if the most important effects are social and psychological, if information isn’t available it can certainly not be acted upon.

To further understand the problem, we should listen to Facebook’s Patrick Walker, who responded to the “Terror of War” photo removal with a keynote given to Norwegian editors. The keynote is well worth watching, not just because it provides insight into the core problems, but also because it provides hints to the road ahead.

Patrick Walker himself gives an excellent summary of the accusations they face:

“[…] people said that we weren’t transparent, there’s no way of knowing what our algorithms do, that publishers don’t get any warnings about changes to the news feed, that we refuse to accept that we were editors and were abdicating our responsibility to the public, that we were trying to muzzle in on the media business and eroding the fundamentals of journalism and the business models that support it. That by encouraging editors to optimize for clicks and showing people what they want to see, we were creating filter bubbles and echo chambers.”

He then goes on to forward the values of Facebook, to give people the power to share and to make the world more open and connected. I have no reason to doubt that they are actually trying to do that. In fact, they may often be succeeding. However, the Web is what to a greater extent gives people the power to share. The Web is what truly empowers people, Facebook included, Facebook is merely a thin layer on the top of the Web. The problem is that it is truly a layer. If Facebook was just yet another possible social network, with a limited scope just like Mark Zuckerberg proposed, that’d be fine:

But it isn’t, it wields much more power than that, since it has effectively put the function of a social network into its own hands and controls that. Patrick Walker then goes on to describe how difficult it is to create global community standards for Facebook, and how problematic it would be if these standards did not apply to all of Facebook. He then concludes that people are free to say whatever they want elsewhere, but not on Facebook. This part of the talk is very compelling, and calls into question the appropriateness of calls for national or EU-mandated regulations. But it also makes it clear that Facebook cannot play the role of a public debate platform, he said that pretty much himself. In the moment an opinion becomes unpleasant, and those are the opinions that need the most protection, it has no place on Facebook. He says it clearly: “Facebook is not the Internet”. It makes it clear, to solve most of the problem he mentioned we have to create that alternative to Facebook that provides the platform for an open, public debate.

It is also clear from his talk that many of the problems that Facebook faces are due to that Facebook needs a single set of rules, and while he has made a good case for that for Facebook, it doesn’t have to be that way on the Internet. In fact, the architecture of the World Wide Web is decentralised, there is no single actor, such as Facebook that should control such an important feature as a social network. Decentralising the social network will have the effect of allowing a plurality of standards. Facebook only has to solve Facebook’s problems, these problems are not universal, and that’s why I say that the underlying technology matters. A decentralised social network has a different set of problems, some are difficult, but it is my clear opinion that the hardest problems are created by Facebook, and can be solved as decentralisation enables diversity and pluralism.

The General Lack of Diversity

As Walker noted, they have been accused of attacking the ability of the press to perform quality journalism. There is some merit to the argument, even if it was easy to predict that social media would be the most important distribution channel more than 15 years ago, before the social networks grew large and strong. Now, the press has to choose between letting Facebook be the editor-in-chief and hopefully a benevolent provider of a working business model, or to maintain their autonomy, and essentially starting over and figure out how to make money in social media on their own.

The problem is not just about Facebook or the press. Recently, Elon Musk said on their carpooling efforts that it “wasn’t Tesla vs. Uber, it is the people vs. Uber”, implying that Uber is a monopoly problem waiting to happen.

The centralisation is not only a problem for opinions in the public debate and  business models, though both are important aspects. It creates difficulties for permissionless innovation, an aspect central to the Web and the reason why Facebook could succeed. It limits the research that can be done on the platform, for example, no one else could have done the article we referenced, which places the owner of the social network in an ethically problematic privileged position.

The General Lack of Universality

With diversity challenged, another key aspect of the Web is also challenged: Its universality. Not everyone has a place on Facebook. The obvious ones that are excluded are pre-teen children. Not that they seem to care. In social networks, they certainly have a place. Moreover, people with cognitive disabilities will find the environment on Facebook very hostile, where they can be fooled into helping the spread of fake news and other material, also material that Facebook legitimately may delete. To some, much damage can be done before appropriate action can be taken. Moreover, their friends are not empowered to help. That’s not what the social network should have been, what I first had in mind was to port the social cohesion of real life to the Web, but the opposite has happened. This is a great failure, but at least a problem centralised systems could solve if they wanted to.

Combating Abuse

It gets even harder once we get to the problems surrounding revenge porn and “grooming”. I want to make clear that Facebook is not the target for this criticism, I’m talking more generally here. The problem is severe, but a problem that has just a few victims, and I believe that it cannot be solved if one is thinking only in terms of commercially viable systems. The technical contributions towards solving this problem is something I think needs to be government funded. Decentralisation is not necessarily helpful technologically, but standards and adoption of once approach could make a large impact. I think it is critical to addressing this problem that we enable trust models to work on the Web and that people are enabled to look out for each other.

Respect for the Individual

Finally, and this is a key problem for the future as well as the present, is the respect for the rights of individual citizens. We are moving towards an Internet of Things, where all kinds of sensors will provide lots of data, often connected to persons, and mining them can yield information that each citizen would certainly consider highly sensitive. I believe we cannot simply go on, neither in research nor in business technology, and pretend these problems are not significant, or that they are simply Somebody Else’s Problem. I reject the notion that the majority doesn’t care, they care, but they are left powerless to remedy the problem.  I hold it as a moral imperative to empower people, and we, as technologists have to tackle this problem.

I fear that we may have an anti-vax or anti-GMO type backlash if we do not commit to a privacy-aware infrastructure, so even if the moral imperative isn’t accepted, one should take this possibility seriously.

A Different World is Possible

I have already pointed out that decentralisation is an important technological enabler for a different world, and stated that this new infrastructure must be privacy aware. Obviously, neither the motivation nor the solution of a decentralised social network is new, it has been tried for a long time. So, how can we possibly succeed now? I think several things have changed: Most importantly, it is now understood that this is a problem that have large effects for entire societies. Secondly, we have standards, and we have learned much from the past, both in terms of technological mistakes and from research.

Now is time for action. We need a broad understanding of the problems, but we also need to start with the fundamental technological infrastructure that we need to provide to the world, and try out several possible approaches, approaches that can further the understanding of the cross-disciplinary solutions. I hope to be able to contribute in this space.

Mer om å erstatte Facebook

Jeg har nettopp fått inn en kronikk i Dagbladet om å skape et åpent, desentralisert alternativ til Facebook og andre sosiale medier. Min oppfattning er at dette må til for å blant annet løse problemet med “kommersiell sensur”, slik Facebook sin sletting av bildet Tom Egeland la ut og senere sensurerte hans kritikk er et eksempel på. Dette ble naturlig nok tatt ille opp her i landet, og godt er det, men spørsmålene som følger av episoden er større enn de som har blitt besvart ved at Facebook tok til vettet. Om ikke kronikken min var lang nok for deg, så følger jeg opp med flere meninger rundt temaet.

Jeg mener det er to svært sentrale problemstillinger, og en hel haug med underproblemer under disse.

Den ene problemstillingen handler om Facebook (og andre) faktisk har et ansvar for å publisere bildet på sin plattform. Dette er ikke noe enkelt spørsmål, for selv om jeg stiller meg bak mesteparten av landet og statsministeren i presset mot Facebook til å publisere bildet, så gjør jeg det mest fordi Facebook har mye makt. For mye makt, og denne makten må balanseres. Jeg hadde heller sett en annen løsning. Jeg ønsker meg en dypere debatt om man faktisk bør ha en plikt til å publisere andres materiale, ikke bare sett i lyset av dagens publikasjonskanaler og teknologi,  men også sett i lyset av teknologiske muligheter.

Jeg prøvde egentlig å begynne å snakke om dette for ca. 20 år siden. Hvis jeg husker riktig, var det Europarådet som begynte å snakke om å innføre en tilsvarsrett i digitale medier, etter modell av trykte medier. En tilsvarsrett er at man kan få publisert et svar på et angrep på en, mao.  innholder begrepet forenklet sagt at man må publisere andres materiale. Det er definitivt en god ting for en offentlig debatt, man har behov for å kunne forsvare seg, oppklare misforståelser osv. Likevel var jeg skeptisk, av en kortsiktig grunn og en langsiktig: Den kortsiktige var at kommentarsystemene var dårlig utbygd i veldig mange av de små organisasjonene som drev webben framover, og det trenges en betydelig innsats for å få det. En plikt til å publisere tilsvar var en mulighet til å overbelaste publikasjonsprosessen for små organisasjoner. Det problemet har vi ikke lenger. Den andre grunnen var at i praksis er tilsvarsretten selvsagt sterkt begrenset, det er redaktøren som må ta en vanskelig avgjørelse. Selv om jeg strevde med kommentarsystemene mine der og da, var det ikke vanskelig å se en vei framover, vi trengte bare litt tid til å skape det som trengtes. Derfor, mente jeg og mener fortsatt, at vi kunne erstatte en svært begrenset tilsvarsrett med en nær absolutt tilsvarsmulighet. Vi kunne altså skape, ved hjelp av teknologien, noe som var mye bedre. Og at det er kanskje bedre å sette av noen midler til å skape enn å skrive betenkninger i det vide og det brede…

Problemet med Facebook som overredaktør, som har store følger for både ytringsfriheten og for media sin mulighet til å følge opp sitt samfunnsmandat, både med hensyn til hva de kan få distribuert og de økonomiske rammene, oppstår fordi Facebook har fått en svært sentral rolle. Det var ingen overraskelse at det skulle bli slik, vi så allerede for 20 år siden at sosiale medier ville bli en viktig distribusjonskanal, sannsynligvis den viktigste. Problemet var at alle ville sentralisere de sosiale nettverkene og alle prøvde å bli Facebook. Facebook vant og derfor er vi nå i den situasjonen at store deler av distribusjonen skal igjennom ett selskap som skal ha en standard for hva som kan publiseres. Hadde de sosiale nettverkene vært desentralisert, slik at det ikke var en aktør, men mange aktører med forskjellige standarder, hadde ikke dette problemet oppstått. Kanskje det er mulig å sentralisere de sosiale nettverkene uten å få disse problemene vi nå ser, men jeg vet ikke hvordan det kan gjøres i praksis.

Mitt åpenbare forslag er å desentralisere de sosiale nettverkene, slik at mange aktører er involvert. Webben er slik at hvem som helst kan koble en datamaskin til Internett og publisere, bare begrenset av den lokale nett-tilbyderen sine regler og lovene på stedet, og i Norge reflekterer de vår forståelse av ytringsfrihet. Webben kan utvides til å takle sosiale nettverkene helt fint. En liten, men viktig bit av det som skal til ble lagt ut i år 2000: FOAF, eller Friend of a Friend. Senere fikk vi flere muligheter til å representere sosiale data i Semantically Interlinked Online Communities (SIOC). Nå fikk vi aldri løftet dette opp fra nerdenivå, kjøret mot sentraliserte sosiale nettverk var så sterkt at det ble vanskelig for en liten gruppe nerder å gjøre det. Vi trenger et bredere samfunnsengasjement for å gjøre det. Jeg håper at den siste tidens debatt har gitt oss dette samfunnsengasjementet.

Vi nerder har nemlig hatt dette problemet opp lenge. Wikipedia har en lang liste av forsøk. Vi har dessverre ikke fått løftet det opp til å synes som et samfunnsproblemet, selv om det helt åpenbart er et samfunnsproblem. Media har etter min mening et stort ansvar fordi de er en del av problemet, ved å søke å holde kontrollen over distribusjonen istedetfor å sørge for at man kan bære en pengestrøm over desentraliserte nettverk. Man burde innsett for lenge siden at de sosiale nettverkene skulle bli så kraftige at det ikke nyttet.

Samtidig sitter media på nøkkelen til å løse problemet, de må bli med å utvikle desentraliserte sosiale nettverk.

Mens jeg er ganske overbevist om at desentraliserte sosiale nettverk er meget viktig, kanskje nødvendig, for å løse mange av samfunnsproblemene som oppstår med f.eks. Facebook, er jeg mer i tvil om andre aspekter ved å løse problemene. Som nevnt i Dagblad-kronikken har Facebook vunnet fordi det er nyttig og å forsøke å lage noe basert kun på idealer som ikke klarer å konkurrere på nytte er en håpløs tilnærming. Et alternativ må være like nyttig, sett fra brukernes perspektiv, og må også gi noe mer.  Det er altså ikke bare-bare å kaste penger etter et alternativ, og dermed tro at folk skal ta ibruk systemet, selv om det synes bedre sett fra noens idealer av verden.

Jeg er generelt skeptisk til at det offentlige skal komme inn og skape et idealistisk system, noe som jeg innrømmer er et paradoks utifra det jeg tidligere har skrevet. Jeg har ingen enkel oppskrift. Når det gjelder forskning mener jeg det er ganske klart at man bør ha sterk, offentlig finansiering, og det finnes forskningsproblemstillinger knyttet til problemene vi diskuterer her som bør undersøkes og som har en del relevant litteratur bak seg. Likevel synes det meg ganske snodig at man roper på flere regler og faktisk legger ganske store ressurser i å skrive disse reglene, selv om reglene ofte er særdeles sneversynte, som tilsvarsretten over. Da synes det meg mer fornuftig å bruke midlene til å forsøke å skape en bredere teknologisk løsning på teknologiske problemer, gjerne i samspill med bedre regler når de teknologiske mulighetene er bedre forstått av flere aktører i samfunnet.

Spesielt gjelder dette der det er en uklar forretningsmodell for tjenester som er viktig for samfunnet, eller der forretningsmodellen er veletablert men til ugunst for befolkningen. Vi ser en “pay-by-privacy”-modell som har blitt svært utbredt, Facebook er et godt eksempel på dette. Dette er et tilfelle hvor jeg mener det vil være riktig å tenke på å finansiere et felles gode med fellesskapets midler.

Store, overordnede utviklingsprosjekter kan også ha stor suksess med offentlig finansiering, der det største eksempelet er Apollo-programmet som satte mennesket på månen. Videre er norsk elbil-politikk en suksess, delvis fordi man ikke fra politisk hold kom med for sterke føringer, man satte f.eks. ikke et tak på pris og dermed har man bidratt til en solid teknologidemonstrator i form av Tesla-bilene. Dette er to svært forskjellige eksempler: I Apollo-programmet trengte man ikke å lykkes i et marked, det er ikke noe stort marked for månelandinger. I tilfelle elbil er det derimot et svært vanskelig marked å komme inn i, og man må fra politisk hold være tilbakeholden med føringer, slik at produsenter som sitter tettes på markedet har muligheten til å forstå og tilpasse seg markedet.

I tilfellet sosiale medier/sosiale nettverk har vi også en situasjon der markedet er svært vanskelig å komme inn i, illustrert av de mange prosjektene som ikke har tatt av. Hvordan det offentlige bør investere i teknologiske løsninger for å løse samfunnsproblemene er ikke veldig klart for meg, men jeg håper man vil prøve å gjøre det. I tillegg ønsker jeg å utfordre mediene, ettersom de har så mye å vinne på å gjøre det og så mye å tape på å ikke gjøre det, samt at de faktisk fortsatt sitter i en posisjon der de kan hjelpe.

Hvis man skal se hvordan det offentlige bør hjelpe, kan man eventuelt ta utgangspunkt i spørsmålet om “hva bør befolkningen ha universell tilgang til?” Kanskje de bør ha en identitet? Hva med en mulighet til å publisere kommentarer, bare begrenset av norsk lov? Datadeling med formål å dele data med myndighetene (f.eks. selvangivelse)? Datadeling med formål å dele data med private aktører (f.eks. strøm og vannmålerdata)?

Som en mulig løsning har jeg valgt meg Crosscloud-prosjektet. Det er flere grunner til det: Det bygger tett på det eneste globale informasjonssystem som har fungert, nemlig Webben, det ledes av han som oppfant denne, Tim Berners-Lee. Det er også viktig å innse at Webben i seg selv dyttet overende store markedsaktører da den kom og at dette skjedde med små midler. Det fantes på den tiden en haug med lukkede nett folk ringte opp til med modemene sine. Med Webben tok Internett over for alle disse i løpet av et par år.  Det er lurt å låne øret til en som har gjort slikt en gang før. Crosscloud er også nettopp et slikt åpent desentralisert nettverk som vil løse mange av problemene vi har diskutert, og det har allerede en rekke forskere og utviklere i lønnet arbeid, selv om de jobber med andre problemstillinger enn media. Jeg kjenner også teknologien godt, og noe av min forskning er direkte relevant.

Jeg mener at det må være et langsiktig økonomisk potensiale bak en teknologi hvis den skal stå seg over lengre tid, og jeg er sikker på at Crosscloud-plattformen har potensiale for å bli en stor kommersiell suksess, men at profitten vil bli distribuert over et mye større antall aktører. Det vil ikke være en stor aktør som Facebook, men det kommersielle potensialet er totalt minst like stort.

Det man har nytte av som bruker av Facebook er ikke særlig store greiene å lage. Facebook strever med enorme problemer delvis fordi de er så sentralisert, men de fleste av disse problemene er ikke av særlig interesse for brukerne, de handler om hvordan Facebook tjener penger: Å selge informasjon om oss. Et brukerorientert desentralisert system vil ikke nødvendigvis være så komplisert å lage. Vi har noen samfunnsproblemer å løse, og jeg er ikke den beste til å tenke forretninger, så jeg tenker først og fremst at det offentlige bør tenke hardt på hvilke deler av økosystemet som bør sees på som en rettighet, og så bør private kunne bygge opp rundt det for å tilby tjenester. Dessuten tror jeg plattformen trenger et enkelt men standardisert betalingssystem. Et sentralisert system kontrollert av en aktør, som f.eks. Vipps, vil etterhvert treffe på samme typen problemer, foruten at jeg mener man må tenke globalt fra dag 1. For å være nyttig må plattformen behandle innhold fra alle mulige aktører. Nasjonale løsninger er ikke interessant. Slik kan man begynne å bygge betydelig økonomisk aktivitet rundt det.

Til slutt vil jeg bemerke hvordan jeg så for meg sosiale medier for 20 år siden. Eller forresten, først må jeg peke på hvordan Douglas Adams oppsummerte det:

One of the most important things you learn from the internet is that there is no ‘them’ out there. It’s just an awful lot of ‘us’.

Sosiale nettverk skulle først og fremst handle om å overføre det som på engelsk kalles “social cohesion” (jeg vet egentlig ikke helt hva vi vil si på norsk) til nettet. Det som får folk til å returnere en mistet lommebok til sin eier selv om de vel kunne ha kommet unna med pengene, eller ta stor risiko for å redde en fremmed. Mulig det er naivt, men jeg mener det fortsatt er verdt å prøve.

Et desentralisert sosialt nettverk skaper en del utfordringer, det blir utvilsomt vanskeligere å få ting slettet slik Facebook kan med et tastetrykk. Likevel, ta eksempelet med hevnporno, som gjerne forekommer i nære relasjoner, altså kan det også være overlapp mellom de sosiale nettverkene til overgriper og offer, noe som igjen betyr at hvis venner av offeret gjenkjenner offeret kan man flagge at videre distribusjon ikke bør forekomme. Man kan også tenke seg algoritmer som sjekker om det finnes gjenkjennelige personer i filmer eller bilder og få de store distributørene til å bruke dette. Dermed kan man prøve å sørge for at videre distribusjon ikke skjer før alle gjenkjennelige personer er identifisert og gitt eksplisitt samtykke. Her har også reglene en viktig rolle å spille. Tilnærmingen er ikke vanntett og heller ikke autoritær, men den kan godt fungere bedre enn det vi har i dag.

Mitt store prosjekt om Semantisk Web

Mitt Ph.d.-prosjekt nærmer seg slutten, og jeg tenkte det var på tide å skrive litt om det. Dette er en populærvitenskapelig framstilling av prosjektet:

Jeg startet med en dyp fascinasjon for ideen om Semantic Web, og mye praktisk erfaring. Som forsker er det kanskje ikke det beste utgangspunktet, siden det kan kan være en utfordring for objektiviteten forskeren bør ha. Men akkurat det viste seg å være mitt minste vitenskapsfilosofiske problem, vitenskapsfilosofiske grublerier skulle bli langt mer framtredende en jeg hadde forestilt meg på forhånd.

Semantic Web er ideen om at man skal kunne bygge ut dagens World Wide Web med data som skal i større og mindre grad analyseres av datamaskiner. Egentlig var det ideen helt fra starten: Hvis en webside har en tabell, og en av kolonnene har overskriften “Pris” kan man gjette seg til at i cellene står prisene for produktene som angis på radene. Innen 1997 begynte det å bli ganske klart at websider ble i praksis kodet på en slik måte at dette var noe man ikke ville klare i praksis og dermed startet man arbeidet med en datamodell kalt “Resource Description Framework” (RDF).

Året etter startet jeg på mitt hovedfag i astrofysikk, men i bakhodet hadde jeg en problemstilling som jeg hadde opplevd da jeg på frivillig basis startet skepsis.no: Problemet med å opplyse de overtroiske var ikke snakk om å nå ut med informasjon, det er banalt enkelt. Det vanskelige var å nå inn i lukkede sinn, trenge inn i ekkokamre, få noen interessert i det de aller minst vil høre. Naturligvis er de tekniske løsningene bare en liten del av bildet, men det begynte å tegne seg et bilde av noen teknologiske muligheter i mitt hode. Jeg skrev noen ideer og sendte dem litt rundt på nett, og en av dem som plukket dem opp og fortalte at de tenkte i samme retning var han som uka etter skulle bli leder og redaktør for standardiseringsarbeidet av RDF. Han overbeviste meg raskt om at mine tekniske ideer var realistiske innenfor rammeverket av Semantic Web. Skjønt, selv om jeg fikk sjansen til å jobbe med det, var det for mye for en mann å løse med svært umoden teknologi. Kommentarfeltenes tragiske endelikt skylder jeg fortsatt på at ingen gjorde den jobben, demokratiet kunne ha vunnet så mye.

Anvendelsene av Semantic Web-teknologi er brede, så brede at det bør kunne gjennomsyre samfunnet i langt større grad en dagens Web. Rørleggeren som skal levere tilbud burde bruke det, skal man ut på reise bare vet hva man vil oppleve og ikke helt hvor man skal, bør man bruke det, i medisin og i industri. Kort sagt over alt der noe som er offentlig tilgjengelig skal integreres med noe som er privat, for å hjelpe noen med å ta en avgjørelse.

Dataintegrasjon er stikkordet. I dag er situasjonen at hvis man skal integrere flere datakilder trenger man gjerne en programmerer til å gjøre jobben. Jo flere datakilder som skal integreres, jo mer arbeid, og sannsynligvis er det ikke bare dobbelt så mye arbeid for dobbelt så mange datakilder, det er enda verre! Samtidig går antallet som er interessert i akkurat den kombinasjonen ned. At kostnaden går opp etterhvert som færre kan betale for jobben gjør at man ikke ser så veldig store integrasjonsprosjekter til daglig, de er for dyre.

På Semantic Web skal hver enkelt gjøre en litt større innsats for å gjøre sine egne data lettere å integrere, men belønningen er at datamaskinene skal gjøre resten av jobben. Det bør legge teknologien i hendene til folk flest.

Og det er nettopp det som er idealet bak mitt prosjekt. Industrien har tatt teknologien i bruk, og Semantic Web ble brukt da IBM brukte sin Watson til å sette menneskeheten i forlegenhet da den vant Jeopardy over de mestvinnende menneskene i øvelsen. Mektig imponerende, helt klart, men teknologi for de få i overskuelig framtid.

Prosjektet skulle først og fremst være praktisk. Måten man lager applikasjoner på må endres, fra systemer der utviklere må ha eksplisitt informasjon til systemer som drives av dataene de får fra nettet. Dette er essensen i hypermedia. Når jeg sier hypermedia, tenker de fleste på en film med tekst rundt, men det er bare det enkleste tilfellet. I det tilfellet vet applikasjonen at når den har siden, og finner en film, så kan den filmen spilles av. Men hypermedia handler egentlig om at det er en dialog der brukerens system resonnerer seg fram til hva den skal gjøre. En applikasjon skal ikke trenge å være kodet for å bestille pizza, den blir fortalt hvordan den skal gå fram av restaurantens websider.

Likevel er det utenfor hypermedia-området jeg har jobbet mest, med et spørrespråk ved navn SPARQL. Enkle spørrespråk har nok de fleste sett: På Google kan man skrive + foran et ord hvis man vil at det skal være med, eller gåseøyne rundt en frase hvis ordene skal stå akkurat slik. Med et ordentlig spørrespråk kan man f.eks. si at “gi meg alle steder der det er meldt over 25 grader, i nærheten av en UNESCO world heritage site, men også badestrand, minst 4 stjernes hotell, hvor det er mindre enn 6 timer å fly fra min nærmeste flyplass med ledig plass neste uke, og min nåværende posisjon er…”, pluss at man kan ordne, begrense antall resultater, osv., osv.

Dataene kan være under forskjellige aktørers kontroll, i forskjellige databaser med forskjellig struktur. Det Semantic Web gir oss er en måte å koble dem sammen hvis man enes om et navn for hver ting og felles navn for egenskapene, og et språk til å bygge broer der man ikke enes. Navnene som brukes på Semantic Web er velkjent fra Weben. Navnet på denne artikkelen er dens adresse, og den kalles en URL: http://kjetil.kjernsmo.net/2016/04/phd-semweb-no/ . Semantic Web generaliserer dette til noe vi kaller URI, som kan brukes for ting som ikke er på nett, som en person, eller abstrakte ting, som en værtype. Men, siden dette er Web-teknologi, så begynner gjerne også disse navnene med ‘http’ slik at man kan få data om tingen bare ved å laste ned navnet. Data som brukes på denne måten kalles “Linked Data”.

Med SPARQL kan man stille spørsmål og få svar på svært innviklede spørsmål, og etter ganske kort tid spratt det opp flere hundre databaser åpent på nett der enhver som kunne språket eller hadde et verktøy som kunne hjelpe med å lage spørringene, noe som også finnes flere av, kunne gjøre det.

Det som dermed ble en interessant forskningsproblemstilling var å bruke språket ikke bare på en database, men på kryss av mange, alt etter hvilke data som finnes hvor. Dette ble mitt tema i likhet med mange andre grupper.

Problemet var den nagende mistanken om at infrastrukturen ikke klarer trafikken, noe som ble bekreftet av et studie av flere hundre slike databaser. De var svært ustabile og svært få var stabile nok til praktisk bruk.

Et nytt felt, som Semantic Web, kan beskyldes for å glemme gammel lærdom, og snart kom kritikken fra database-miljøet: Selvfølgelig kan man ikke la tilfeldige brukere stille tilfeldige spørringer med et så kraftig spørrespråk som SPARQL, det er ikke vanskelig å lage en spørring som vil ta årevis å svare på. Det kan skje enten fordi man ikke forstår hva man gjør, eller som et angrep. Man ser da heller ikke vanlige databaser på nett, det er alltid et forenklet grensesnitt man får som tilfeldig bruker. Nei, sa de, sentralisering av databaser til datavarehus og strenge begrensninger på hvilke spørsmål man kan stille er løsningen.

Rent teknisk kan det være korrekt, men det er ikke bare tekniske forhold som kan motivere forskningspørsmål. Sentralisering kan føre meg seg at enkeltaktører blir for mektige, og at hvis du ikke er innenfor en større kundegruppe blir dine problemer kommersielt uinteressante. Det er nettopp kommersielt uinteressante problemer vi skulle løse, fordi virkelige mennesker trenger en løsning også der det ikke finnes en klar forretningsmodell.

Så dermed må vi utnytte fordelen med å være et nytt felt til å utfordre gamle selvfølgeligheter, ved å formulere nye problemstillinger. Det er to retninger min forskning har gått i:

For det første: Hvorfor har vi ikke gjort de store framskrittene mot stabile løsninger? Spørsmålet plaget meg så mye at jeg tok en lang tur bort fra det praktiske og over til det vitenskapsfilosofiske og den statistiske litteraturen.

Mye av forskningen foregår med formelle metoder, som står støtt på sine formelle bevis. Problemet er når veldig mange formelle resultater legges sammen til et ferdig utviklet databasesystem har systemet blitt så komplekst at evalueringen av helheten må skje med empiriske metoder. De er lite utviklet i litteraturen. Hypotesetester finnes nesten ikke, man setter opp systemet man har utviklet, sender noen spørringer til det og måler hvor lang tid det tok før man fikk svar. “Benchmarking” kaller man det. Det er ingen samlende statistikk rundt de forskjellige testspørringene, ingen strukturert måte å finne ut om evalueringen i seg selv gir meningsfylte resultater. Man forsøker å møte problemet med at man i prinsippet kan velge spørringer utifra hvilken konklusjon man ønsker ved å standardisere spørringene, men dermed gjør man det umulig å teste utsagn som ligger utenfor standarden.

Mitt forslag var derfor å introdusere metode fra statistikken kjent som “Design of Experiments”. Med et eksperiment som kjørte i flere dager viste vi hvordan man kan generere testspørringer, gjøre hypotesetester, finne de viktigste problemene og lage en strukturert måte å vise om selve eksperimentet har viktige feil.

Likevel fortsatte flere vitenskapsteoretiske problemstillinger å plage meg. Når man står på Semantic Web-konferanser, som forøvrig kjennetegnes av svært godt sosialt og inkluderende miljø, så påstår så godt som alle at deres løsning fremmer visjonen om Semantic Web. Men hvordan underbygger man en slik påstand, all den tid Semantic Web ikke eksisterer ennå i den formen som visjonen forutsetter? Kan den trege utviklingen tilskrives at vi rett og slett ikke driver vitenskap, og i så fall, hva er vitenskap? Klare, popperske kriterier viser raskt sine problematiske sider, ettersom man innenfor dagens evalueringsmetodikk ikke har rimelig grad av sikkerhet på om det er studiets resultat som falsifiseres eller bare evalueringsmetodikken som er for dårlig. Vi har ingen formulert teori der hypotesene finner sin kontekst, slik min hovedfagsoppgave i sin tid fant sin kontekst i generell relativitetsteori og kvasarteori.

De gamle vitenskapsfilosofer gir en god ide om hva som kan gå galt hvis man ikke holder tunga rett i munnen, men jeg finner lite rettledning i de konkrete problemene jeg står oppi, og spørsmålet om sviktende metode er en av årsakene til treg framdrift har blitt stående.

Et annet svar til databasemiljøet er at “vi har nå et fungerende, globalt informasjonsystem som dere ikke hadde da dere prøvde å legge databaser åpent for mange år siden”. Dette informasjonsystemet, Webben, har visse egenskaper i infrastrukturen som muligens kan utnyttes. Et av dem er mellomlagring. I nettet finnes det maskiner som mellomlagrer data fra forskjellige kilder for å hjelpe til med å ta last fra publiseringssystemet, og for å sørge for at brukeren får bedre opplevd hastighet.

Det første spørsmålet var om Web-standardene for mellomlagre er i tilstrekkelig utbredt bruk av eksisterende datakilder på Semantic Web, noe som allerede innebærer ganske mye data. Jeg gjorde et omfattende søk over alle data jeg fant, og konkluderte med at situasjonen må forbedres mye, men at for enkelte deler kan man dra nytte av denne infrastrukturen.

For mitt siste arbeid gikk jeg tilbake til det praktiske, nemlig å lage et system som utnytter mellomlagringen i nettet, prøver å gjette hvilke data som kan være nyttige for brukernes framtidige spørringer og integrerer hypermedia i tillegg til databasene. Dette skal bli et modulært og ganske komplett system jeg publiserer som fri programvare. Flere av modulene har allerede blitt tatt opp av Debian-prosjektet, som danner grunnlaget for de mest utbredte Linux-baserte operativsystemene.

Dette arbeidet vil også ha en Design of Experiments-basert evaluering. Uansett hva den sier, vil de store spørsmålene bli stående ubesvart, jeg kan fortsatt ikke si om mitt arbeid er et verdifullt bidrag på veien mot Semantic Web.

BYOD+FYOR: Semantic Hypermedia in Sports tracking in bandwidth constrained environments

Abstract

We propose a project to enable mobile units users to follow a video stream of their choosing. The video sources are distributed along a sports course by event organizers at certain positions, and the positions are available in hypermedia resources. We propose a system to allow configuration of which video streams are transmitted based on event organizer’s input as well as users with mobile units.

Introduction and Background

Motivation from orienteering

The sport of orienteering is mostly practices as running in forests with a detailed map, where the competitors visit a number of control points in a pre-specified order, but they are free to pursue any route between the control points. Although it is sizable in terms of participation in the Nordic countries (where the largest events exceed 20000 participants), it has not until recently seen much media attention.

Orienteers have themselves put considerable effort into producing attractive media content for broadcast, an effort that has seen some success. In addition to video content, the presumed best athletes are given a tracking device consisting of a GPS and a GPRS modem. This will transmit their position to an Internet server, where a Java or JavaScript client can be download so that their position is displayed on the competition map. In addition, it has become possible to display these productions on big screens on the largest competition venues. The economic benefits from increased exposure has yet to materialize, however, and so it has become harder to justify the costs of the big screens for the vast majority of events.

It is in this context that we propose a different direction: Instead of a big screen, we would like to encourage interested spectators (out of which other orienteers tend to be the largest group), to bring their own devices (thus BYOD, an common acronym for Bring Your Own Device).

Moreover, we are of the impression that most spectators have a personal relationship, as family, friends or club mates, or close competitors, of the athletes themselves, and so, it is not only the leader that is interesting, but the athlete that they know personally. This is a radical departure from the contemporary narrative of sports broadcasts, where the fight for the lead and eventual victory is the main and often sole focus. We call this approach Follow Your Own Runner, or FYOR.

Finally, we note that the video production may, and has in the past, compromised the athletic quality of the competition. This should be avoided as much as possible.

Technical challenges

Both the BYOD and the FYOR aspects bring considerable practical challenges. There are two ways of providing bandwidth to mobile units, Wifi or mobile networks. While mobile networks are nearly ubiquitous, the latest generation, LTE is not very widespread as of this writing, and even if it were, a large number of devices within a small area is likely to saturate the bandwidth quickly.

Wifi, or rather the 802.11 series of IEEE standards can be deployed on an ad hoc basis in competition venues to provide sufficient bandwidth to an audience of a few hundred, a limit that is sufficient for most orienteering events. There are many practical problems to be addressed, but for the scope of this paper, we only note that although Wifi broadcasts are possible in a lab environment with known devices, it is unlikely to work for this practical purpose. This leaves us with the unicast option, but this is needed to support the FYOR aspect, so it is hardly a concern.

The FYOR aspect also brings technical challenges in a bandwidth constrained environment. A single standard definition video stream requires around 2 Mbit/s bandwidth. Often, orienteering competition venues are in relatively remote locations, and so, the available bandwidth into the venue may not exceed 10 Mbit/s, or even less. In the forest, one may use cameras connected to LTE modems to stream to the Internet, making sure to place them where the LTE signal is strong. Even though a handful of cameras can be operated this way, it is in the above case not possible to stream more than 4-5 video streams into the venue through the link. If LTE is also used into the venue, it is also likely to consume much of the available bandwidth.

Recently, it has also become possible to buy relatively inexpensive radio link equipment to stream video point to point in the 5.8 GHz band. Nevertheless, this places further constraints on the placement of cameras, as well as regulatory constraints, and even though it is an option, in many cases, using the LTE infrastructure makes it possible to set up cameras on an ad hoc basis.

This motivates the constraint that cameras should not transmit unless the streams are known to be watched. Moreover, the total number of streams that can be transmitted must be configurable by the organizer’s operator, so that the most important traffic is allowed to be transmitted.

Scenario

The above background and constraints prompts a more detailed scenario development, first we start by identifying different persona involved:

Persona

Athlete Person participating in the present competition. May be interesting for others to follow. The athlete must be prevented from watching the cast before their own start as they are not allowed to acquire knowledge about the course the will run in the event. Spectator Person attending the event without participating in the sport. Doesn’t have any deep understanding of the intricacies of orienteering technique. May or may not have any relationship with any of the athletes. Participant Person attending the event who has good knowledge about orienteering as a sport, having participated in it themselves, but is not participating in the present competition. Is likely to have a personal relationship with one or more athletes. Operator Person designated by the organizer to perform administrative tasks on the system. Producer Person designated by the organizer to produce a broadcast based on available video streams. Course-setter Person appointed to set the courses, i.e. determine where the control points will be, to make the competition fair and interesting. Their primary concern is the quality for the athletes, but they may have to compromise for the video production. Commentator Person designated by the organizer or the media to provide commentary on the athlete’s performance. Will be well versed in the sport. TV watcher A spectator or participant watching the production without being present at the venue. Audience The participants, spectators, and producer (the latter acting on behalf of the commentator and the TV Watchers) collectively.

Description of the race

To understand what could be interesting to watch, it is important to understand the progress of the race. The race may start in a mass start, where all athletes start simultaneously, a chase start, where they start based on a prologue (in both case, the first to finish wins), or an interval start.

At the start, the athletes is handed the map with the course at the moment of start. They generally start reading and running simultaneously. At some point, their route choices will diverge. Some route choices are significantly faster than others, but this is not known to the athletes or anyone else. Commentators and participants are likely to speculate based on their expert opinion, and much of the interest is generated by finding out if they are right. Moreover, it may be that different strengths of different athletes result in that there isn’t a single best choice.

At some point during the course, athletes may “miss”. A miss occurs when the athlete looses time relative to route choice the athlete has made. A miss may occur en route but commonly occur near the control points. Misses at the level of the best orienteers usually occur because of cognitive overload due to fatigue, excessive speed (the athletes usually run at a pace very close to the maximum ability of a very well trained endurance athlete), very complex patterns in the terrain, etc. However, it is not necessarily clear when the athlete is making the mistake. Spectators cannot be expected to understand in many cases, while participants and commentators may speculate that a mistake has happened as the athlete is following a parallel track to what they intended. However, since a parallel track may be indistinguishable from a route choice, it can take several minutes from the actual mistake was made to the point where it results in a clear miss.

In general, time can be lost by not running fast enough, bad route choices, and misses. Hesitation and spending excessive time on the control points may also be factors.

In some events, the athletes will pass through the venue area, to be readily visible to everyone present.

After visiting all control points in the specified order, the athletes will return to the finish line. From the last control point to the finish line, it is usually just a few hundred meters. Crossing the finish line is a culmination of the race drama in the sense that the winner is determined there, however, there are parts of the race that are more interesting for the overall narrative.

Typically, moments where route choices are made, or misses are made are decisive for the outcome of the race, and so, it is very interesting to have cameras where these moments are likely to happen in space. To determine where these are requires extensive collaboration between the producers and the course-setters.

Camera selection

Let us assume that cameras have been placed along the course in interesting spots. They will start streaming video if something interesting happens, the meaning of interesting will be clear later. As noted previously, they cannot all stream all the time, and so our first concern is the overall system health, i.e. the organizers must ensure that the system performs so that a production of at least one video stream for participants and spectators can be made by the producer and streamed to their devices.

Overall system health

Assuming there’s a larger number of cameras than can be supported by the available bandwidth (which is likely to be the case), an operator must be tasked with limiting the number of cameras streaming at any given time to avoid saturating the data transfer link(s).

Despite of FYOR, the first priority must be to be able to produce one video stream that is interesting to most participants and spectators. This is likely to be a broadcast type production with a classical narrative. The producer is the person tasked with determining what will be interesting to the audience. The commentator is tasked with providing commentary on this production.

We envision a voting system, where the producer as well as the spectators and participants who have a device, will have votes, but the producer will be assigned more votes than the rest of the audience. The software system will then open the stream from the highest voted cameras that are ready to stream. The cameras can be designed to themselves find out if they are ready to stream by using e.g. motion detection. The producer may also have the option to turn a certain camera on and override the motion detection and the voting system.

If the number of cameras with votes exceed the safe system limit, and a camera that has more votes than a currently streaming camera becomes ready, the complexity rises because the system must decide if it should shut down an already streaming camera. As motion detection comes with some uncertainty, it makes sense to raise the confidence limit to let it stream, and also introduce a delay, in case the event on the new camera is short-lived.

Assignment of votes

The audience may assign votes manually by interacting with a map that shows the course as well as the positions of the cameras. We envision a GUI where the producer or operator can set a camera in an on, off, or auto state. In the on position, the camera will stream, irrespective of votes or motion detection. In the off position, it will likewise not stream (this may be an situation where the operator may need to interfere for the overall system health). If a camera is in an auto position, any member of the audience may assign votes by selecting the camera in the UI. The producer will have a high number of votes, while participants and spectators will assign their votes inversely proportional to the number of cameras they select.

This creates an opportunity for computer assisted assignment of votes. Typically, the GUI will let the audience select the runners they are interested in, and so assignment may happen based on how sure the system is that an interesting athletes is nearing that camera. For the producer, interesting athletes are those fighting for the lead, or for athletes gaining on the lead. For participants, it may be club mates or close competitors. If the athlete is tracked by GPS, the GPS position could be used, and if not, the likely arrival time can be extrapolated based on past performance.

Protocols

Details of the video streaming protocol will have to be worked out later, what is important to note is that the most common protocol for this purpose, the Real Time Streaming Protocol (RTSP) requires a client to initiate streaming. It therefore makes sense that the camera just reports if it is ready to play and if something interesting may be recorded, it is up to the viewers to decide whether to actually stream if they are authorized. The streaming itself is likely to happen through a proxy in the LAN.

This problem appears to lend itself very well to RESTful protocols. The term RESTful is frequently abused to mean any HTTP-based protocol where a resource has a URI, that is only a small part of the point of REST. Critical to REST is that the messages contains everything needed to drive the interaction. Thus, a detailed description is superfluous, indeed, a detailed description is a sign that REST constraints are not understood, as it then relies on external documentation rather than messages are needed. Suffice to say that we rely on hypermedia RDF.

Camera interaction

For the camera control protocol, each camera acts as a client in a client-server architecture and submits some RDF to a central server controlled by an operator on the venue, where the subject URI tells the central server where to find the video stream if it needs it; if it is authorized to start playing, pausing, etc.; some information about the readiness to stream, containing information from the motion detector, etc.

Based on this information, the server may then decide to instruct the camera to start streaming. When responding to the RDF submission, the response may not contain any content, but it should indicate to camera how often it should send its updates. If the camera has very few votes, the server could instruct the camera to send updates infrequently, e.g. every 10 seconds, whereas if a camera has many votes and the server is just awaiting motion detection in the field of view, it should update more frequently, possibly as fast as possible.

HTTP Example

An HTTP implementation of the above is possible, the below is a simple example, disregarding complexities that may arise from the fact that each event possibly should carry an explicit timestamp also identified by a URI.

PUT /cam HTTP/1.1
Host: venue.orienteering.org
Content-Type: text/turtle
Date: Fri, 24 Jan 2014 23:13:03 +0100

@prefix hm: <http://example.org/hypermedia#> .
@prefix disco: <http://rdf-vocabulary.ddialliance.org/discovery#> .
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix dcmit: <http://purl.org/dc/dcmitype/> .

<rtsp://camhost1.orienteering.org/stream> a dcmit:MovingImage ;
  geo:lat 59.97061 ;
  geo:long 10.64216 ;
  hm:can hm:play, hm:pause, hm:stop ;
  disco:standardDeviation 124.12 ;
  disco:mean 1050.21 .


204 No Content
Date: Fri, 24 Jan 2014 23:13:04 +0100
Expires: Fri, 24 Jan 2014 23:13:06 +0100

The above examples tells the server the camera’s position, that it may start and stop (defining the semantics of the operations in the object such that they can be acted upon is a topic for further research) the remote video stream (being authorized in a preceding request), and it assumes a simple motion detection algorithm where the average is seen to change beyond what is expected from the standard deviation. Then, the response tells the client that it may/should update the server with new information after two seconds.

User interaction

The audience and the operators need to interact with a system to set priorities for cameras and to watch video streams. For this, the user agents need to know the position of the cameras, the status, i.e. whether it is set to on or off by an operator or producer, or auto, where the audience may vote. It should also have the total number of votes for a certain camera, so that the audience may see if their votes may be better used elsewhere. Finally, hypermedia triples should be added for logged-in users, to tell the client how to cast votes. This can be done like in the following example:

HTTP Example

GET /cams/ HTTP/1.1
Host: venue.orienteering.org

200 OK
Date: Fri, 24 Jan 2014 23:16:13 +0100
Content-Type: text/turtle

@prefix rev: <http://purl.org/stuff/rev#> .
@prefix hm: <http://example.org/hypermedia#> .
@prefix hma: <http://voting.orienteering.org/hypermedia-application-specific#> .
@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix dcmit: <http://purl.org/dc/dcmitype/> .

<rtsp://camhost1.orienteering.org/stream> a dcmit:MovingImage ;
  geo:lat 59.97061 ;
  geo:long 10.64216 ;
  ex:status ex:on .

<rtsp://camhost2.orienteering.org/stream> a dcmit:MovingImage ;
  geo:lat 59.9503 ;
  geo:long 10.7214 ;
  ex:status ex:auto ;
  hm:canBe hma:votedFor ;
  rev:hasReview </user/foo/vote/1>, </user/bar/vote/56> .

</user/foo/vote/1> rev:rating 1.2 ; 
                   rev:rewiever </user/foo> ;
		   hm:canBe hm:deleted, hm:replaced .

</user/bar/vote/56> rev:rating 5.4 ; 
                    rev:rewiever </user/bar> .

In the above example, it is assumed that </user/foo> is authenticated and authorized to edit their votes as well as to cast votes for a certain camera.

To vote, the client would first dereference hma:votedFor to obtain something like (omitting the HTTP dialog and prefixes for brevity):

hma:votedFor rdfs:comment "To vote for a resource, add review to the
                           camera with rating."@en ;
	      hm:httpMethod "PUT" ;
	      hm:collection </user/foo/vote/> ;
	      rdfs:seeAlso [ 
	        rdfs:label "Review ontology" ;
	        rdfs:isDefinedBy <http://purl.org/stuff/rev#> . 
              ] .

Then, it should follow the directions to add their votes, e.g. with HTTP:

HTTP Example

PUT /user/foo/vote/2 HTTP/1.1
Host: venue.orienteering.org

@prefix rev: <http://purl.org/stuff/rev#> .

<rtsp://camhost1.orienteering.org/stream> 
  rev:hasReview <> .

<> rev:rating 4 ; 
      rev:reviewer </user/foo> ;

204 No Content

The relative URI <> will resolve to the Request-URI, i.e. http://venue.orienteering.org/user/foo/vote/2. Thus, this will add another vote to the first camera. For the user experience, the user agent should check that the user does not exceed its allowed number of votes, and incorporate that in the user interface. If malicious users are feared, it should also be verified on the server side. The total number of votes per user can be part of the user profile, not shown here.

Implementation

With the protocol established for communications, it is time to examine some details in the implementation on the server and in the clients.

Server

To find which cameras will be streamed, the server will run two SPARQL queries against its own database:

SELECT ?camera WHERE {
  ?camera ex:status ex:on .
} LIMIT $MAXCAMS

where $MAXCAMS is not part of the SPARQL language but a configuration parameter set by an operator to the maximum number of cameras that can be streamed simultaneously.

When this query has returned and the number of solutions (hereafter denoted $OPCAMS) is smaller than $MAXCAMS, the following query will be executed:

 
PREFIX rev: <http://purl.org/stuff/rev#> .
SELECT ?camera WHERE {
  ?camera ex:status ex:auto ;
          disco:standardDeviation ?stddev ;
          disco:mean ?avg ;
          rev:hasReview ?vote .
	  FILTER ( ?avg > $RUNNINGAVG + $THRESHOLD * ?stddev)
  ?vote rev:rating ?rating .
} 
GROUP BY ?camera
ORDER BY sum(?rating)
HAVING(sum(?rating) > 0)
LIMIT $MAXCAMS - $OPCAMS

where $RUNNINGAVG is a variable kept by the application that is the running average of observations that happen when a camera is not filming, and $THRESHOLD is a configuration variable to set the sensitivity of the camera. (Queries have not as of yet been tested)

These queries will yield a list of cameras that at any given time shall stream. The application will hold a list of playing cameras so that cameras that are added to the list will receive a play request and cameras that fall out of the list will cause a stop request to be sent. Some extra work must be done to ensure that cameras are not switching too fast to changing circumstances. A proxy will be set up so that the clients that are held by the audience can access the streams.

User Agents

The User Agents will run the gpsseuranta.net light client, which provides the map for the event and the GPS tracks. Onto this map, the cameras will be projected. This application also provides a list of GPS-equipped runners, with the possibility to select interesting runners. If this data is accessible to the camera layer of the system, this could be used to distribute votes automatically.

We also noted above that athletes without a GPS may also be interesting, and the implementation may also need to take this into account.

Open problems

The current application is intended for rapid deployment, and so, cannot rely on open research problems to be solved. Nevertheless, it does point out some open problems.

Reasoning on actions

It would be interesting if applications could be driven around a small number of standardized primitives, e.g. CRUD-operations, and reasoning could be applied to find out what a certain high-level instruction, e.g. “vote” means. In the above example, it is sufficient in-band information for a programmer to implement the voting system (of course, in a real implementation, the inline documentation should be more verbose), but it is insufficient information for a machine to itself create in required functionality. Reasoning and bounded homomorphisms is worth looking into for this purpose.

Cascading updates

As can be seen in the above example, deleting all triples with the subject </user/foo/vote/1> will not delete the cameras linking to it. This is not a problem for the application in this scenario, since it counts the votes, but it is a possible problem in other application scenarios and there should be a general solution, possibly cascading updates through the graph.