Categories
Events Linked (Open) Data

HackaLOD 2019

Op 29 en 30 november 2019 deed ik mee aan de HackaLOD 2019, een hackathon met als doel iets te doen met Linked Open Data uit de erfgoedsector. Het was mijn derde keer en hoewel sommige dingen hetzelfde waren als vorige keren, ging ik er met een heel ander gevoel heen en was de ervaring nog beter dan in de gevangenis en in de kerk. Dit is geen precies verslag van de HackaLOD — vier maanden na dato zou ik daar een beetje laat mee zijn — maar een persoonlijke reflectie.

Zonder team

Het was me niet gelukt om collega’s van de UBL mee te krijgen, dus anders dan in 2016 en 2018 was er geen Team UB Leiden. Je moet het ook maar willen en kunnen regelen met partner en eventueel kinderen, want na ruim anderhalf etmaal met weinig tot geen slaap ben je op zaterdagmiddag/-avond waarschijnlijk niet meer zo gezellig.

Voorafgaand was er mailcontact tussen teams en team-zoekenden en ik dacht een team te hebben gevonden in Team SOLID, maar toen het idee dat ze voor ogen hadden onhaalbaar bleek, trok het team zich terug. Jammer, want ik had graag iets gedaan met SOLID.

Inmiddels had ik een flinke lijst met ideeën die ik niet met collega’s hoefde af te stemmen (ook al zijn ideeën van collega’s soms ook goed voor de Publieksprijs) en was ik erg benieuwd naar ideeën van anderen, dus ik was niet bang om geen team te kunnen vinden.

Hetzelfde, maar dan anders

De organisatie van de HackaLOD bestond uit vertrouwde gezichten, hoewel enkele mensen vorige keer nog deelnemer waren. Zoals altijd was het eten en drinken goed verzorgd — dat is de voornaamste ‘tegenprestatie’ die deelnemers naast respect voor hun ideeën mogen verwachten in elke hackathon — de HackaLOD is absoluut geen bier-en-pizzahackathon.

Wat altijd anders is, is de locatie. Het doel is een ietwat alternatieve locatie om zonder veel afleiding van buiten te kunnen werken aan nieuwe ideeën en oplossingen. Mijn eerste keer was in een voormalige gevangenis in Utrecht, vorige keer in een voormalige kerk in Amsterdam (waar het slapen in de kelder door de kou nog minder comfortabel was dan het door de veldbedden al is). Deze keer was de locatie ver buiten de stad, in Radio Kootwijk! Hoewel telefoon- en internetbandbreedte hier minder groot zijn, biedt deze plek spectaculaire afleiding: de Kathedraal. ‘s Nachts moesten we binnen blijven omdat het gebied een stiltegebied is, maar ook om 21u is het pikdonker en kun je nachtfotografie oefenen.

Foto van de Kathedraal (het Zendgebouw) van Radio Kootwijk gemaakt met lange sluitertijd
Het Zendgebouw bij nacht

Buiten een rondje lopen in de kou (voor 23u of na 6u) was één manier om je af te leiden; binnen was er ook entertainment in de vorm van muziek-op-verzoek. Ooit was dat een mondharp in het kerkzaaltje van de gevangenis, nu waren het twee muzikanten met een hoop elektronica die om een uur of vier nog live wat techno voor mij geïmproviseerd, als muzikale boost. Heerlijk.

Wat langzaam verandert bij elke HackaLOD zijn de teams: niet alleen bij de organisatie zie je bekende gezichten, maar de samenstelling van mensen en kennis in teams verschuift. Natuurlijk zie je dat ook in wat er gepresenteerd wordt. In Utrecht was er nog een eenpersoons team met nauwelijks ervaring met Linked Data; de winnaar had een chatbot gemaakt. Nu merkte je dat het kennisniveau tussen teams minder verschilde en ook hoger lag. Ik vermoed dat het helpt dat eigenlijk alle data via betere (commerciële) platforms beschikbaar was, waarop je makkelijker kunt bouwen.

Dat er datasets zijn om mee te werken is logisch: het doel is om iets te doen met meerdere datasets. Terugkijkend is het wel gek om te constateren dat bijna alle datasets speciaal voor de HackaLOD leken te zijn verzameld. Natuurlijk is Wikidata een optie om te gebruiken en mag je zelf op zoek naar data, maar de datasets in ons project werden door Netwerk Digitaal Erfgoed gehost — niet door de eigenaars. Er zijn data, die data zijn open en er zijn links in de data. En toch zijn Linked Data nog geen standaard, zelfs niet in de erfgoedsector waarin ik mede door de beloften van Linked Data in terecht ben gekomen.

Ik kom nog terug op die observatie. Ik denk dat de GLAM-wereld terecht nog heel erg bezig is met het implementeren van Linked Open Data, maar ook dat de killer apps van Linked (Open) Data waarschijnlijk intern geen RDF-technieken gebruiken zoals SPARQL en het volgen van willekeurige links om meer data te vinden. Linked Data als platform voor data-uitwisseling is een prima doelstelling.

Niet te vergeten

Zonder team om direct mee van start te gaan moest ik wel gaan kennismaken met de verschillende teams en hun plannen horen. Dat had ik vorige keren ook moeten doen… Niemand doet mee om in het grootste geheim 20 uur aan iets te werken; men wil graag van elkaar leren of ten minste inspiratie opdoen. De grootste inspiratie komt daarbij uit de verhalen die deelnemers proberen te vertellen, niet uit de combinaties van datasets die willen gaan gebruiken.

Vorig jaar won ik met Saskia en Lucas in Team UB Leiden de publieksprijs voor het idee van een app Prentenmapper met een werkend prototype. Dat was niet de belangrijkste reden dat ik tijdens het avondeten op de vrijdagavond bij Team ExpLOD werd gevraagd, denk ik; waarschijnlijker was dat ik praktische kennis van Linked Data had. Ik heb dit vermoeden niet gecontroleerd en het maakt me ook niet uit — veel belangrijker is dat we een leuk team vormden. Met het team hebben we gebrainstormd en gadgets besproken, ethiek in collectievorming verkend en zijn we naar buiten gegaan, waardoor ik me niet bezwaard voelde om wat foto’s te maken.

In team ExpLOD 🤯 zaten meer mensen die elkaar niet van tevoren hadden gezien. Philo, Matus, Jorim, Edward en ik hadden samen gelukkig genoeg verbeelding en kennis om een installatie te verzinnen, te maken en te presenteren die niet alleen voldeed aan de eis om twee LOD-datasets te verbinden (een formaliteit, hoewel niet triviaal), maar ook het publiek het meest gunstig stemde.
Weer een publieksprijs, voor Unforgettable/Niet te vergeten!

Het was niet gemakkelijk geweest om zoiets in een korte tijd in elkaar te zetten. Ik ben nog steeds onder de indruk van de interface en de demo die net goed genoeg werkte (met meerdere laptops als infrastructuur) om het verhaal te vertellen dat zijn vorm had gekregen tussen het avondeten en het moment dat de jury ons als laatste team kwam kijken.

De zon komt langs de bomen door de ramen in de Theaterloods naar binnen
Zonneschijn na een nacht zonder slaap, terwijl we de laatste hand leggen aan Niet te Vergeten

Ik heb (te) lang zitten stoeien met mijn belangrijkste taak, het verbinden van de data van het Rijksmuseum en die van de Nederlandse Musea van Wereldculturen (NMVW). Slaapgebrek en tijdsdruk helpen mij nooit bij het snel tot oplossingen komen. Het volkomen onterechte gevoel dat ik zelf een slimme oplossing moet verzinnen, terwijl er veel meer mensen met (veel) meer LOD-ervaring waren dan ik, hielp ook niet.
Als je dan ontdekt dat het Rijksmuseum en NMVW vergelijkbare aspecten in collectiebeschrijvingen (wanneer is iets gemaakt? waar komt het vandaan? waar is het van gemaakt?) op heel verschillende manieren in RDF aanbieden, lijkt het ideaal van Linked Open Data heel ver weg.

Op dat moment had ik moeten beseffen dat data wrangling een wezenlijk onderdeel is van de HackaLOD. Net als vorige keer, toen Saskia uren bezig is geweest met het normaliseren van namen van kerken die in verschillende spellingen in bijschriften van topografische prenten stonden.
Na afloop heb ik zitten spelen met LinkedPipes ETL om een verrijkte dataset te maken van ‘onze’ twee datasets. Als ik nou wat meer ervaring met dit soort ETL-tools voor Linked Data had gehad…
Gelukkig had ik genoeg ervaring met mijn eigen servertje, om Docker, Traefik, GitHub en Let’s Encrypt te gebruiken om iteratief te werken aan de backend API (en Nextcloud om wat data te delen).

En dan verder

Ik kijk dus terug op een succesvolle HackaLOD met een ander gevoel over wat je tijdens een hackathon allemaal kunt doen naast programmeren, modellen maken en hacken. Als het kan, doe ik volgende keer weer mee, hoewel ik dan van tevoren onderzoek of we datasets moeten opschonen. Het zou mooi zijn als het verbinden van datasets echt meer formaliteit dan uitdaging is.

We hebben in januari/februari nog meegedaan aan de LODLAM Challenge, maar terecht ging die prijs naar een van de andere inzendingen. Het was misschien een beetje grootheidswaanzin om met het resultaat van een dag hacken mee te doen tussen de resultaten van maanden werk.

En natuurlijk doe je niet mee voor de prijzen, hoewel het wel leuke bedragen zijn om bijvoorbeeld meer gadgets van te kopen. Wie weet lukt het de volgende keer om de juryprijs te bemachtigen…

Categories
Meta

Bende is WebSub-enabled

I created my own hub with Superfeedr and added it to the blog settings, so you should now be able to subscribe to this blog via WebSub.

Categories
General

(A) Todoist milestone

I’m about to complete my 10000th task in Todoist, yet I’m still over 8000 points of karma away from the Enlightened state…

Categories
Uncategorized

Clivia in volle bloei

Kleurrijke bloemen van de cliviaplant
De clivia van oom Peter toont voor het eerst zijn bloemen
Categories
Academia Technology

Short review of “Spamming in Scholarly Publishing: A Case Study”

Interesting: a researcher, Marcin Kozak, gets a lot of unsollicited email (spam) trying to convince him to publish in a journal or with a publisher and decides to check out these journals and publishers.

Kozak, M., Iefremova, O. and Hartley, J. (2015), Spamming in scholarly publishing: A case study. Journal of the Association for Information Science and Technology. doi: 10.1002/asi.23521

The abstract covers it well:

Spam has become an issue of concern in almost all areas where the Internet is involved, and many people today have become victims of spam from publishers and individual journals. We studied this phenomenon in the field of scholarly publishing from the perspective of a single author. We examined 1,024 such spam e-mails received by Marcin Kozak from publishers and journals over a period of 391 days, asking him to submit an article to their journal. We collected the following information: where the request came from; publishing model applied; fees charged; inclusion or not in the Directory of Open Access Journals (DOAJ); and presence or not in Beall’s (2014) listing of dubious journals. Our research showed that most of the publishers that sent e-mails inviting manuscripts were (i) using the open access model, (ii) using article-processing charges to fund their journal’s operations; (iii) offering very short peer-review times, (iv) on Beall’s list, and (v) misrepresenting the location of their headquarters. Some years ago, a letter of invitation to submit an article to a particular journal was considered a kind of distinction. Today, e-mails inviting submissions are generally spam, something that misleads young researchers and irritates experienced ones.

Some details were missing, however. I think good methodologies for assessing a publisher’s or journal’s trustworthiness are necessary, so it would be great if people researching these methodologies get the details correct.

The location of the headquarters was determined via various means, one of these being a lookup of the domain name holder’s (or registrant’s) country in a WHOIS system. The authors conclude this is not a reliable method, but do not explain why. A few sentences before they do suggest that the registrant’s country is the country the publisher/journal is based in, or that WHOIS shows the location of the server. Exactly what information was used from WHOIS is not described.

Another way of determining the headquarters’ location was to look up the information on the website. How to determine that information is found or missing is not mentioned.

One of the conclusions is that “the average time claimed for peer review was 4 weeks or less.” I don’t see how this follows from the summary table of claimed time for peer review, because it contains N/A values, and nearly all claimed times are 4 weeks or less. The form of the statement is wrong.

Finally, I would have liked to see a reason for not including the dataset. I can only guess why the authors deliberately did not provide the names of journals and publishers.

I think the conclusions hold (except for the one mentioned above), and that work should be performed to improve the methodology for judging journal quality. Eventually, the work would be automated and be easily replicated over time. Results from such automated checks could be added to the DOAJ.

Categories
General Linked (Open) Data Technology

Terms of Semantics

From the “just throwing it out there” dept. in cooperation with the “I’m too lazy to do some research into existing efforts” dept.

It is generally known that people rarely read all terms of use and privacy statements of all involved parties providing a service. South Park used that knowledge as a storyline in The Human Cent-iPad.

One of the reasons for ignoring the Terms of Use (ToU) is their excessive length and use of legalese. They contain too much incomprehensible language. You need a lawyer to fully understand the rights and obligations that come with the service.

But many services share many characteristics, like the definition of a jurisdiction whose laws guide the service conditions, the definition of a service provider and consumer, definitions of content, ownership and other rights to the content.

Isn’t it possible to encode the characteristics of definitions in a standardised sets of terms?

If various (similar) services provide the definitions of their services in standardised terms, they could more easily be understood and compared. It would help non-human agents to select the best services for themselves and their human controllers.

More thought is needed.

Categories
General Ideas for things Technology

Email wish list

Things I might find interesting in an email client or environment. Raw thoughts.

  • fast search
  • search inside encrypted emails
  • get related and linked stuff easily at any time during reading
  • easily organise windows and content, e.g.
    • when you select to reply to an email, put the draft next to the original so that you don’t need to switch windows
    • use a consistent style when commenting inline
  • easily create tasks and notes from parts of emails
  • organise / order following user’s workflow
    • by people, topic, tone of content, project, task, event
    • integrate with business process(es)
  • suggest while typing
    • spelling and grammar
    • references to other emails / notes / events / conversations
    • people to include as recipient
    • named entities
    • expansions of abbreviations
    • different tone of text by using templates
    • replacement text
  • find and use embedded machine-actionable information
  • explain what the client did to your experience
    • log observations and following actions by the mail user agent
    • show the reasons for suggesting stuff
Categories
General Technology

New hobby: “You’re vulnerable as in CVE-2009-3555”

I started a new hobby: pointing out vulnerabilities for a particular man-in-the-middle attack. It is described in CVE-2009-3555:

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a “plaintext injection” attack, aka the “Project Mogul” issue.

I bet I am not the only one practioning this activity, because the vulnerability was described in 2009. And the fix for this vulnerability has been around for quite some years too. After the releases of the various fixes for this vulnerability the quest for KAMITMA (Knights Against Man-In-The-Middle Attacks) began. It is easy to become a KAMITMA in the context of CVE-2009-3555. You just need to point out this vulnerability to the owner of TLS/SSL protected websites that are vulnerable, politely asking that they update their software. You might mention that this is an old vulnerability (2009 is like a century in computer development).

I started this hobby because I found my own website (and ownCloud and email) is vulnerable. I asked my hosting provider and they responded by offering moving to a ‘new’ hosting environment. New is not the newest version of Apache httpd, but I am planning to move to this new hosting environment soon. If that doesn’t fix this vulnerability, I’ll have to move and suggest others to do so too because it’d show my hosting provider doesn’t care about security.

The easiest way of spotting this vulnerability is to use Firefox and make it block connections that are made using the old vulnerable protocol. Open a tab in Firefox, enter about:config and press enter. Search for security.ssl.require_safe_negotiation and double-click the row to set it to true. The next time you try to visit a vulnerable website you’ll see this:

bitly-fail

When you see this, it’s hobby time: send a message to the owner of the website asking to get updated and more secure.

I found these websites and try to keep this list updated when I find something changes:

Addition, 2014-08-28: Tweakers.net, a news website and price comparison website for electronics, hosts its images on a different domain (tweakimg.net and subdomain ic.tweakimg.net). Apparently, these are vulnerable because all color and layout is lost when I look at the Pricewatch. The browser console shows what is going on:

tweakers-fail

Categories
General

Canoe campsite view

Panorama view from a campsite in Sweden

I won’t forget this view soon, as part of a fantastic week of canoeing and surviving in Sweden between Gustavsfors and Bengtsfors.

Categories
General

Can you really refine DC elements in HTML as explained in the Metadata MOOC?

I originally posted this as a question in the Coursera MOOC on Metadata’s discussion forums on 2014-07-30. So far I have received no written responses at all, but I did get 5 points (upvotes) for posting. I hope someone outside the MOOC may be able to answer and please correct me if I’m wrong. If my concerns are justified, perhaps this may trigger a bit of a change in the course materials — I’m wary that in the coming video lecture series on Linked Data dr. Pomerantz will still confuse subject and object, but I’ll wait to see if anything has changed since last year’s session.

I’m having trouble understanding why using DC.date.modified as name in a <meta> element is the correct way of refining the date element in HTML, for two reasons:

  1. I cannot find anything explaining it in the current specifications
  2. I use elements in someone else’s namespace that have not been defined in that namespace (or anywhere else), don’t I?

Longer version:

It appears that the document Element Refinement in Dublin Core Metadata (linked next to the 2-7 lecture about Qualified Dublin Core) only describes element refinement using the RDF model. I know the semantics of rdfs:subPropertyOf and it makes sense to me to express refinements this way.

For learning to express Dublin Core elements in HTML, the document refers to the obsolete http://dublincore.org/documents/dcq-html/, which has one reference to refining DC elements by appending . + the refinement, namely in the section that describes how the spec is (in)compatible with previous and other versions.

Note that previous versions of this document (and other DCMI HTML-encoding documents) made some different recommendations to those found in this document, as follows:
(…)
Previous recommendations specified prefixing element refinements by the element being refined, for example ‘DC.Date.modified’ rather than ‘DCTERMS.modified’.
(…)
These forms of encoding are acceptable but are no longer considered the preferred form.

The document that replaces it, Expressing Dublin Core metadata using HTML/XHTML meta and link elements, has no references or examples of refined elements at all. It does make clear how to interpret the properties as URIs:

In a DC-HTML Prefixed Name, the prefix is the part of the name preceding the first period character; the remainder of the string following the period is treated as the "local name" and appended to the "namespace URI". If a DC-HTML Prefixed Name contains more than one period character, the prefix is the part preceding the first period, and the local name is the remainder of the name following the first period, and any subsequent period characters simply form part of the local name.

In the following example the DC-HTML Prefixed Name "XX.date.removed" corresponds to the URI http://example.org/terms/date.removed

<link rel="schema.XX" href="http://example.org/terms/" >
<meta name="XX.date.removed" content="2007-05-05" >

If I were to apply this to a property whose namespace is the DC Elements Set namespace, I’d get a URI that is in the DC namespace, but that is not defined in that namespace.

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" >
<meta name="DC.title.serial" content="Services to Government" >

I say that the value of the property http://purl.org/dc/elements/1.1/title.serial of a described resource is "Services to Government". This property is not defined. The same goes for the examples in the lectures and homework: by just appending some string that may or may not make sense to other humans, you can’t really expect to refine the property, can you?

So I’m puzzled. What document(s) explain this way of refining (well-)defined elements?

After continuing my search: Is it RFC 2731 from 1999 by Kunze, Encoding Dublin Core Metadata in HTML? Section 6 indeed explains the use of

<meta name    = "PREFIX.ELEMENT_NAME.SUBELEMENT_NAME" ... >

for "qualifying" elements, but a few lines below, it says:

Note that the qualifier syntax and label suffixes (which follow an element name and a period) used in examples in this document merely reflect current trends in the HTML encoding of qualifiers. Use of this syntax and these suffixes is neither a standard nor a recommendation.