Impressions from the LODLAM 2017 Un-Conference

Shlomo Sanders, CTO, Ex Libris

Before I begin, permit me to explain a few things. LODLAM stands for Linked Open Data Libraries, Archives and Museums. Officially it is not a conference but a summit. In the first summit in 2011 there were 100 participants from 17 countries and 85 organizations. This year’s 2017 summit was in Venice at the end of June and had a similar number of participants, countries and organizations. Very impressive. (More information about LODLAM can be found here.)

Next, it is important to note that the summit this year was organized as an “un-conference.” This means that were no presentations or even any predefined agenda. The entire agenda was created during the first hour by attendees suggesting topics and then an informal count of how many people were interested in each topic. For a long-time conference goer this was very strange for me, but it certainly did seem to work. My personal feeling is that for some of the topics a mix might be appropriate: some short practice presentations just to make sure that everyone is using the same terminology, and the rest of the sessions remaining open discussion.

There was one notable exception to the above format, which was the LODLAM Challenge. To quote the LODLAM web site, “The 2017 LODLAM Challenge highlights data visualisations, tools, mashups, meshups, and all types of use cases for Linked Open Data in libraries, archives, and museums. Entries for the Challenge will be demonstrable use cases that leverage Linked Open Data in libraries, archives and museums, and include digital humanities projects.” Each project that got to the finish line presented their project at the summit. The attendees voted and decided the winner. Let me just say that all entries that were presented were very impressive. You can see the winner here.

Now down to some of the topics. I will be remarking on only a small subset of topics discussed during the conference.

  1. Interlinking – A simple or should I say basic subject for linked data, right? Wrong. This topic drew the largest number of sub-topics and attendees. The more popular sub-topics, just to name a few, were multiple vocabularies, equivalent classes, sub-classing, using “same as,” reasoners, and templating. From a vendor’s perspective, working with many customers, we have seen that some of the above directions have historically been very useful (e.g. templating) and others have caused challenges, especially in the area of interoperability. For example, multiple vocabularies are challenging to interoperability . Time will tell if equivalent classes coupled with mature reasoners will be able to alleviate the challenges posed to others having to work with foreign vocabularies.

  3. SPARQL – This is a topic of keen interest to me as a vendor, since we always prefer to support industry standards when our solutions need to interact with external services. It seems like a “no-brainer” that a generic interface meant to perform a linked data lookup for an “authority” at some external source should use SPARQL. The surprise is that the production SPARQL service is almost non-existent. I came to the conference hoping that someone would tell me that I am wrong. Instead all sadly agreed with me.

  5. Reconciliation – In the linked data universe this is the equivalent of identifying that two URIs are actually one and the same thing. For example, the Getty location URIs, Geonames, and Wikidata location entries are essentially three different URIs for the same locations. This is not a new issue. Reconciliation is not a new issue. Any library system must match incoming bibliographic descriptions with existing descriptions. One example is VIAF, which has done an admirable job of cross-referencing name authority information from a multitude of national libraries.LODLAM is not the only group active in this area. As we speak, the LD4x project has spun off a dedicated group to linked data reconciliation. From the perspective of a vendor that will soon have over one thousand live customers in Alma, this is a very important issue. For example, should Alma have a universal (at least in the universe of Alma institutions) URI or should each institution have a specific URI for their Work record with Same As to the corresponding Library of Congress or OCLC Work records? Both are plausible and each has its fans, and more time is needed to decide which is the more viable alternative.

I think it is safe to say that many of the issues continuing to challenge the linked data community have been around for a long time. It will be interesting to see if the linked data community will develop better and simpler solutions to these issues. Time will tell.

Spread the word. Share this post!


  1. Reply

    Regarding your second point, on the use of SPARQL for authority lookup, there are good reasons why a public SPARQL interface is not the best option. SPARQL is too powerful for the job; it’s very easy to write a SPARQL query that consumes enormous resources of CPU and memory. The administrators of a SPARQL service must be careful to regulate SPARQL queries with timeouts, by requiring authorisation, etc. That’s not to say that a data provider shouldn’t use SPARQL internally; just that it is problematic to offer it publicly.

  2. Vladimir Alexiev


    Speaking as a vendor who powers the Getty LOD, we have both.
    Business entities (eg concepts) are served through semantic resolution of URIs (with content negotiation) and serve a business-meaningful amount of info (not just direct statements).
    But we also have SPARQL querying so you can answer a variety of questions or do a variety of analyses (100 sample queries are included). It has limits on query execution time and number of results, so you shouldn’t use it to try and download say 100k Painters.
    The uptime of that endpoint is such that many systems use it online (mostly for auto-completion of eg AAT terms), without having to keep the data locally.
    I was at LODLAM, so Shlomo, maybe you talked to the wrong people 🙂

Leave Comment

Your email address will not be published. Required fields are marked *