Uitgevers van closed-accesstijdschriften moeten niet zeuren

Uitgevers die bang zijn voor een lagere Impact Factor moeten hand in eigen boezem steken. Zeker uitgevers van wetenschappelijke tijdschriften die niet Open Access zijn, want zij helpen de afhankelijkheid van Thomson Reuters en de Journal Citation Reports® in de hand.

Thomson Reuters legt op hun website uit hoe de simpele formule achter de IF in elkaar steekt. Als je de getallen hebt, is het berekenen van de IF een invuloefening. Met de hedendaagse computerkracht is het mogelijk om op elk moment de scores van alle tijdschriften in seconden uit te rekenen. Dus is het eigenlijk onzin dat we met zijn allen zitten te wachten op De Lijst die in juni uitkomt. Maar het zijn die noodzakelijke getallen die niet zo makkelijk te verkrijgen zijn en uitgevers hebben daar zelf invloed op.

Voor citatiecijfers heb je betrouwbare referentielijsten van alle artikelen in alle tijdschriften nodig. Dat gaat al niet makkelijk; het is niet alsof je op de website van elke uitgever zomaar een lijst vindt die steeds actueel blijft. Misschien wordt de referentielijst gezien als deel van het (overgenomen) intellectueel eigendom en is men bang voor waardevermindering als de lijst openbaar is. Misschien is er geen betrouwbare lijst, omdat deze wordt gebaseerd op patroonherkenning in de tekst en redacties of uitgevers(!) juist díe citatiestijl (uit duizenden) voorschrijven die niet goed wordt herkend door de software. En dan ben je nog afhankelijk van de auteurs die de referentielijst aanleveren in het manuscript – hopelijk gebruiken de auteurs hiervoor tenminste literatuurbeheersoftware om de kans op spel- en typefouten te verkleinen.

Iedereen zou van een tijdschrift met open referentielijsten snel kunnen inzien hoevaak artikelen in het tijdschrift zelf-citaties krijgen (en dat met andere tijdschriften vergelijken, of tussen auteurs vergelijken). Ook wordt een eventuele niche snel duidelijk: de tijdschriften in een niche zullen relatief vaak naar elkaar verwijzen. Voor lezers en schrijvers ontstaat zo ook een snel overzicht van de markt in het onderwerp.

Thomson Reuters doet nog wel enige kwaliteitscontrole van een tijdschrift voordat in de lijst wordt opgenomen. Daarom kan het gebeuren dat een tijdschrift dat jaren in de JCR voorkwam opeens is verdwenen. Thomson Reuters heeft de data om die beslissing te ondersteunen, maar geeft geen antwoord op vragen over die beslissing. En dat is misschien nog wel het gekste van de hele discussie rond de Impact Factor. De wetenschap drijft op onderzoek dat repliceerbaar moet zijn, ondersteunende onderzoeksdata wordt daarom steeds vaker gedeeld en we weten dat de IF niet zaligmakend is. Maar toch vertrouwen we graag op zo’n lastig te controleren getal.

UT-evenementen mét tijdzone :)

Nadat ik erachter was gekomen dat mijn problemen met de evenementenkalender van de Universiteit Twente, die ik via Google Calendar op mijn Androidtelefoon wilde hebben, niet werden veroorzaakt door de software van de UT, maar door Google Calendar, heb ik eerst gehoopt dat Google voor een oplossing zou zorgen. Maar dat is niet waarschijnlijk; het probleem bestaat al jaren. Met een hack lijkt het nu wel gelukt. Continue reading “UT-evenementen mét tijdzone :)”

Google Calendar #fail

In de post Evenementenkalender UT gedebugd heb ik weliswaar serieuze fouten ontdekt in de iCalendarfeed van de evenementenkalender van de Universiteit Twente, maar het probleem met tijdzones ligt niet per se aan de iCalendar. Google houdt zich niet helemaal aan de standaard voor iCalendar.

Zoals ik had geschreven, bevat de evenementenkalender van de Universiteit Twente (UT) geen informatie over tijdzones. Uit het bestand blijkt dus niet op welke tijdzone de tijden van evenementen slaan. Maar dat is geen probleem volgens de specificatie van het iCalendarformaat.

Tijden van evementen kunnen volgens de paragraaf Date-Time verschillende vormen aannemen. De UT doet het op manier 1: met ‘drijvende’ tijden die geen tijdzone gebruiken of aan UTC refereren. Waar ook ter wereld zouden deze tijden op hetzelfde moment van de dag in de agenda moeten verschijnen (160000 is vier uur ‘s middags, in Japan, of Nederland, of de VS). Maar Google doet iets anders: Google interpreteert deze tijden als Greenwich Mean Time, de Britse wintertijd. Daardoor begint een evenement dat op 21 oktober 2011 om 17:00 uur lokale tijd in de iCalendar staat in mijn agenda om 19:00 uur (Europese zomertijd). Als bij ons de wintertijd ingaat op 30 oktober zit er nog maar één uur verschil in, maar dat maakt het natuurlijk niet minder lastig.

Ik ben niet de eerste die hier last van heeft. Google zegt er niks over in zijn eigen ondersteuning, maar gebruikers klagen er wel over op het forum:

Een workaround wordt wel geopperd door andere gebruikers (het gebruiken van een script om de UT-feed in te lezen en hem van tijdzone-informatie te voorzien), maar dat heb ik nog niet geprobeerd. Het valt me vooral tegen van Google dat ze zich op dit punt niet aan de (open) standaard houden.

Nu maar hopen dat Google nog eens de klachten leest en oplost.

Evenementenkalender UT gedebugd

De Universiteit Twente biedt een iCalendar-bestand aan met de evenementen uit de evenementenkalender. Dat is handig voor mensen die niet verschillende websites willen afstruinen op zoek naar iets om hun tijd aan te besteden, of hun afspraken willen afstemmen op UT-evenementen. Maar ondanks beloftes om mijn klachten over de kalender door te spelen aan de leverancier, lijkt er weinig te zijn veranderd.

Mijn eerste klacht ging over de rare tijden van evenementen. Sommige evenementen duurden niet langer dan een flits (opening van het academisch jaar van het ITC liep van 14:33 tot 14:33, bijvoorbeeld), andere evenementen die als dagevenementen waren ingepland liepen van 2 uur ‘s nachts tot 2 uur ‘s nachts de dag erop.

Maar is Google Calendar om nog onbekende reden gestopt met het importeren van evenementen uit het iCalendar-bestand. Herhaaldelijk unsubscriben en subscriben werkt niet, maar misschien ligt het niet aan Google.

Kijkend naar de inhoud van het iCalendar-bestand, valt het volgende op:

  • het bevat geen tijdzone-informatie voor de gehele kalender
  • evenementen zijn aangegeven in de lokale tijd (start- en eindtijd bevatten geen indicatie van tijdzone)
  • verschillende evenementen duren ook echt niet: een voorstelling van Andermans Veren Live! op 28 september duurt van 000000 tot 000000 (lees: 28-9-2011 0:00 tot 28-9-2011 0:00)

Deze iCalendar Validator geeft in al eerste instantie aan dat er iets serieus mis is: in één van de evenementbeschrijvingen zitten regelovergangen zonder spatie of tab aan het begin van de nieuwe regel (dit wordt aangemerkt als serieuze fout, die slechts door zeer weinig applicaties wordt genegeerd) en lege regels worden misschien niet door alle applicaties ondersteund (dit is slechts een waarschuwing; binnen evenementen ziet het er wel wat gek uit, maar het zal door veel applicaties wel geaccepteerd worden).

Als ik het bestand handmatig heb aangepast en upload voor controle, springen er andere errors en een nieuwe waarschuwing naar voren. De waarschuwing is voor de regel die aangeeft welke iCalendar-versie het bestand gebruikt die niet de tweede regel van het bestand is. De errors zijn voor het niet-escapen van komma’s en puntkomma’s in de evenementbeschrijvingen, al vermoed ik dat Google daar geen moeite mee heeft.

Nadat ik alle fouten uit het bestand heb gehaald, geeft de Validator “100 out of 100”, dus Google Calendar zou het nu toch moeten kunnen snappen. Importeren dus!

In een nieuwe agenda worden inderdaad vrijwel probeemloos de evenementen geladen – 1 van de 55 wordt genegeerd, misschien omdat het al voorbij was, misschien met een andere (mij onbekende) reden.

Alles wat er nu nog vreemd uitziet, komt mijns inziens voort uit problemen met invoer aan de kant van de redactie of met interpretatie (ofwel door het CMS, ofwel door Google Calendar), namelijk:

  • evenementen zonder tijdsduur duren standaard een uur (Google)
  • evenementen zonder tijd beginnen om twaalf uur ‘s nachts (gebrekkige invoer: een High Tech High Tea of P-uitreiking hebben zeker wel een bekende start- en eindtijd, maar die is ook op de website niet aangegeven)
  • meerdaagse dagevenementen worden niet aangegeven met datumwaarden (een datum, zonder tijdaanduiding zoals 20110928), maar met datum-tijdwaarden (combinatie van datum en tijd, zoals 20110928T000000). Daardoor komen meerdaagse evenementen altijd een dag te kort, zoals bijvoorbeeld het Techniek-meidenkamp dat volgens de website tot en met 30 september duurt, maar volgens ‘mijn’ nieuwe agenda tot 30 september (klokslag middernacht) duurt.
  • geen enkel evenement heeft informatie over de locatie ervan.

Het is dus te makkelijk om klachten alleen door te geven aan de leverancier, want de softwareleverancier zit waarschijnlijk niet evenementen in te tikken.

Via Twitter heb ik de webredactie al eens gewezen op een mooi voorbeeld van een iCalendar: die van de Vrijhof. De Validator geeft dat bestand een score van 48 van de 100 punten, want komma’s en puntkomma’s zijn niet voorafgegaan door een backslash, de versieregel staat niet op regel 2 en de regeleindes zijn niet in Windowsformaat gecodeerd. Maar er zit wel volledige tijdzone-informatie in, tijden kloppen, locaties kloppen en de beschrijving van het evenement is geen slappe samenvatting, maar het hele verhaal – al hoeft dat van mij weer niet zó uitgebreid.

Kortom: dit ligt niet alleen bij de leverancier van het CMS, maar ook bij de redactie die informatie preciezer moet invoeren en als het even kan ook meer informatie invoert. Ik kijk alvast in mijn agenda.

Update 28-9 16:11u De webredactie en de leverancier zitten niet stil, laten ze via Twitter weten: https://twitter.com/#!/UTwente/status/119047175052341249 De e-mail bevestigt dat ook, dus dat komt wel goed.