The Muninn Project

LODLAM 2020 Review

warren — Wed, 03 Mar 2021 16:22:03 +0000

It's been a year since LODLAM 2020 took place at The Getty in LA, right before the Covid-19 pandemic hit. It seemed that my bags were barely unpacked that things went dramatically wrong as venues, institutions and cities began shutting down. Rush hour downtown Toronto was an odd spectacle of office workers awkwardly taking their computer monitors with them on commuter trains, ready for an extended period away from work. All of us ended up in one of two categories: those forcibly (and frustratingly) idled and those run ragged trying to keep the lights on. 2020 was for many a "lost year" of extremes where we did our best not to drop too many balls along the way.

A year late, here is my LODLAM 2020 recap:

Science Stories was the winner of the LODLAM challenge, featuring a biography of Grace Hopper and others. The demo website seems to be having hiccups but the challenge video is still up here. The list of entries is contained here and consisted of Biography Sampo, Center for Integrated Studies, The Israel Museum, American Art Collaborative, ExpLOD, LD4P Questioning Authority and Golden Agents.

Sessions included "Then What? User Interfaces for LOD", "LOD Education and Training", "How to get colleagues excited / Uncertainties in LOD", "Software Implementation, MetaPhacs, BIBFRAME", "Modeling Exhibitions / Machine Readable Profiles / Pragmatic Approaches", "Wikidata Best Practices", as well as a less-than-curated list of links.

The takeaway, 10 years after this unconference started, is that LODLAM is still a mixed bag: some people are at the bleeding edge while others are not quite there yet. There has been criticism that LODLAM has become more of a destination unconference rather than one where things get done. There is likely some truth to this, but formalizing the unconference further will likely pigeonhole it into a topic silo preventing a multidisciplinary approach.

Cultural Institutions Under Lockdown

A certainty is the value of properly curated and structured data. Streaming services like Amazon Prime Video are booming with the lockdowns and are taking advantage of resources such as IMDB to create very complex and effective recommendation systems. I'm highlighting Amazon Prime's Xray system in particular for its ability to repurpose metadata. Depending on the show and episode, pop-ups for additional content such as shooting locations, show trivia and supporting actor movie recommendations appear on the screen. One feature that I found especially intriguing was the use of some clever computing to link scene background music to band and title data. That alone has probably done more for smaller indie bands in the past year than anything else. Surprisingly, the technology and data to do this has been available for years.

On the museum side, it will be interesting to see what lockdown measures will have forced cultural institutions to consider. If your primary attraction can no longer be accessed, how can its data be used to support its educational mission? Putting on my military history hat for a second, I want to point out the work done by the staff of the Battleship New Jersey Museum who have been funding their museum by having their curator create video after video of inaccessible parts of the ship to keep the museum funded. It isn't linked open data, but it is a great example of simple technologies giving access to ship locations, such as the electrical trunks and shaft alley, that will never be accessible to the public for safety reasons.

Document, Document, Document!

Back to LODLAM itself: I wanted to follow up to my comments during the dork shorts (and while jogging up and down the auditorium stairs with a microphone) about documentation and communication. The primary benefit of linked open data is the ability to communicate context and knowledge that would otherwise be implicit and thus lost. However, that requires that you understand your own data and, very frankly, most people don't.

The reasons for this can be blind adherence to standards, a focus on the artifacts over the data about the artifacts and a view of data as "an IT thing" - as one participant put it: "You programmers, you're never any good at documenting things". (Maybe it's a bit much to expect them to do theirs jobs, be an expert on Sumerian art and guess correctly at what wasn't written down?) Bad communication is not only a LAM issue: computing is collectively making a experiment with "Documentation by Blog Post"1 instead of official documentation that I personally find horrifying and doomed to failure. On the Academic side, editors have been working on supporting "Data Papers" through publishers and data archiving through archiv and zenodo. These are all good ideas, but remember that if you can't understand your own data or you don't communicate its significance using LOD principles, the patrons consuming your data aren't likely to do so either.

Looking forward to 2022!

In closing, I'd like to plagiarize the advice given by Charlie Clarke to the subsequent organizing committee to SIGIR 2003 that took place during the first SARS outbreak: "Don't invent a new disease!". Fingers crossed that things will return to normal in a year. Rumours of a LODLAM 2022, possibly in Europe, are still floating around the ether...

Best of health from the LODLAM 2020 committee: @joanbcobb @adrianstevenson @ewg118 @muninn_project @ccthompson @marciazeng

1. I'm pretty much channeling Neil Postman here[1].

References

N. Postman, Amusing Ourselves to Death: Public Discourse in the Age of Show Business. Penguin Books, 2005, p. 208.

Language English

Francais

Vimy Ridge Day WWI Project Roundup

warren — Mon, 09 Apr 2018 18:52:38 +0000

On April 9th, 1917 the Canadian Corps attacked the German positions on Vimy Ridge. In honour of the 101st anniversary, here is a short roundup of WW1 projects and efforts that are ongoing.

Bert V. de Bruijn of wikiwar.net fame is still working on making a ridiculously detailed map of the battle of Vimy Ridge and has setup a task manager for Open Historical Map to digitize the trench maps from the McMaster Trench Map Collection.
Erik Hellstedt in Belgium is working on animating the First World War using Commonwealth War Graves Commission data.
Heather Pretty from Memorial University has been working on generating more linked open data for the Royal Newfoundland Regiment during the war, including personnel data.
Stan Hebben and Dries Chaerle at the In Flanders Fields Museum in Belgium are running a project "The Names List" to collect information about victims – both military and civilian – which died in Belgium during the course of (and due to) the First World War.
Warren Lewington has been working on artillery logistics on the Western Front (2 Minute Video here, PDF Project Description).
Bill Frost has built an awesome Trench Mapping application for tracking events on the Western front.

Aware of another project? Please reach out to @muninn_project!

Language English

Tags:

WWI

Vimy Ridge

lod

Projects

Francais

Reactivating the ADHO Linked Open Data SIG

warren — Thu, 02 Nov 2017 01:32:07 +0000

After a hiatus of some years, the ADHO Linked Open Data Special Interest Group is being reactivated under the joint leadership of trouble makers Molly Hardy and Rob Warren.

The original mission of the ADHO Linked Open Data (LOD) SIG was "to bridge between the DH community and the semantic web community of practice, encouraging and facilitating the interconnection and interoperability of open online Humanities resources, by raising awareness of new developments (both content and technology) and discussing and developing best practices".

So far the adoption of Linked Open Data (LOD) has been modest in the DH community. It still shows promise as a means of publishing and exchanging data between projects and the creation of ontologies using semantic web standards as a means of communicating complex abstractions and negotiating areas of consensus merits further study.

Some of the obstacles that are ongoing include poor user and developer-oriented tools, lack of standardization within domains of study, concerns over the applicability of discrete ontologies to complex humanities discourse and limited 'clean' data sources with which to begin publication.

This list is not exhaustive and additions are welcome.

Please join us on the LOD SIG mailing list for further discussions about moving things forward. Submissions can be made to lod@lists.digitalhumanities.org and list registration can be made at http://lists.lists.digitalhumanities.org/mailman/listinfo/lod.

Language English

Canadian Linked Data Summit: A Year After

warren — Wed, 25 Oct 2017 13:15:13 +0000

It has been a year to the day that the Canadian Linked Data Summit occurred in Montreal in 2016. The event was to push the deployment of Linked Open Data approaches in Canadian institutions who were perceived not to be as advanced as their European and American counterparts. The presentation by MJ Suhonos Linked Open Data in Canada: Behind the Curve [1] caught my eye with its candid review of the situation in Canada.

Have things changed in Canada a year later? The webpage "Linked Data Projects in Canada" compiles a listing of projects in Canada along with an evaluation grid. It shows a picture that has not improved significantly since the summit occurred. ...which itself was to be a follow up to LODLAM 2015!

Why Isn't Linked Open Data Getting Any Traction?

Given the power of Linked Open Data and the possibility of externalizing communications costs, people should be adopting this technology wholesale. So what is the holdback? Some of the issues that have been observed have been:

Selling Linked Open Data To The Wrong Audience

Linked Open Data is primarily about engaging with people through their software and as such they have no basis for wanting [Linked] Open Data; they deal with the end application. An anecdotal example of this audience mismatch can be found in the comments on the Soldiers of the First World War dataset located on the Open Government Portal: "The average computer user could not possibly find anything in this totally useless data base. Please restore the original search base which was user friendly"₁. The actual application that the end users want is located here (and to the portal's credit, it is clearly listed at the top of the page) but the overloaded vernacular use of the "data-" words does not let end users make a distinction: "this section should be regarding the 'dataset' for the Soldiers of the First World War. For comments about the 'database' ... Yeah right, everyone understands that for sure. I think the same folks designed this as designed the Phoenix software"₂.

The tension between easy-to-use applications and sophisticated datasources can similarly be seen at the ODI which has been pushing Comma Seperated Values (CSV) as a file format for data exchange for the past few years. This has been well received because anyone can consume it using excel, make a bar chart and demonstrate a simple to understand (and probably wrong₃) answer. Anyone who has had to create a detailed analysis across more than one data set realizes how quickly CSVs become unmanageable, especially when trying to repeat the analysis or establish the data methodology. To this end the ODI has also been promoting the use of json schemas to document csv headings which strikes one as having all of the problems of, and none of the benefits of, the semantic web stack.

Both situations point out that data consumers are self-interested and have different levels of sophistication. Linked [Open] Data is a tremendously powerful tool for managing and exchanging of data. However it requires a high level of sophistication for its consumption, it is not an end-user facing technology and the problems that it solves have traditionally been hidden from the consumers both by the lack of available data and the application design. Examples:

In a pen-and-paper world, a long hand reference from the Canadian Price Index as reported in 326-0021 or 326-0020 would have a narrative attached identifying which subfield was used. In a data table without a data dictionary, which of the different CPI's is being reported under the CPI table column and what will the application tell the end user about it?

We deploy content stores with 10's of thousands of digital assets on the web searchable by keywords because that is easy for the end user to understand and use. We also expect that the user will search that particular content store because it holds the collection that they are interested in. What happens when there are 10's of thousands of content stores to choose from? 100's of thousands? Our ability to generate content is overwhelming our ability to search it and soon the shortcuts that users 'understand' will cease to be effective.

We are dangerously close to a second digital dark age where access will become impossible because we won't be able to find anything. The data mob will take us to the guillotine when told to eat semantic cake!

I do believe that Linked Open Data is our best solution yet, but we have to focus on end-user applications that solve their problem with our tools and that means eating our own semantic dog food. I go back to my previous blog post about cool tools and the deafening sound of crickets on applications, perhaps "cool tools" was the wrong title. We need to start using Linked Open Data ourselves, eat our own semantic dog food and push the technology to end users via applications that solve basic but useful problems. Developers similarly need superior tools that match those we have constructed for the previous generations of structured data.

Mismatch With Organizational Structure And Culture

Most organizations work on a model where software applications are acquired, installed and maintained by an IT department that responds to business unit needs. Linked Open Data sits uncomfortably between web-publishing and databases; it is not a ready-made shrink-wrap application and its publication functions are close enough to the web to trigger a "just use the web site we have" response. Same issue with the "SPARQL server" that needs to be firewalled from the public because the IT security policy says that databases need to be.

The same thing occurs with the marketing department which now see a new channel to the customer but devoid of the properties that they expect: branding, user experience, human interaction, look and feel. Comical conversations have ensued in the past where a business analyst deemed an API unprofitable since no ads conversion occurred or when demands made that the company logo be shown on every API call.

A move to Linked Open Data requires a period of adjustment to align the different operating procedures and policies to new technology. It can be a hard time and/or a funny one; we forget there was a time where people used to print their own email to read it! Even Amazon, the 800-pound gorilla of the SOA world, famously required a direct company-wide order from the CEO to start using APIs internally within Amazon.

Finally, there is a deeply rooted belief that more value can always be created by selling closed data sets than simply opening up the data. A recent example is the removal from the public domain of Saskatchewan's Land Dominion Survey shape files in favour of a commercial product now being sold by Information Services Corporations. There is a trust issue in linking and using someone else's data in that the data must be available in the long term for people to be willing to invest the time required. This isn't to say that there isn't room for Linked Data as well as Linked Open Data, many commercial services should be built around the technology, but consistency is a large part of creating a knowledge graph.

Why Don't We Just Put It in Wikidata (WDWJPIIW)?

When faced with limited resources, creating entries into Wikipedia / Dbpedia / Wikidata becomes attractive: we create the data but someone else gets to do all of the heavy lifting. These are ideal services especially for one-off pieces of information which when all added together make for large and diverse knowledge bases. The issues that do pop-up are of agency, mission and authority. The wiki's function in what may be best described as a chaotic democracy: reversion, corrections, deletion all occur on an ongoing basis through a process of community curation. That system is not perfect and at times mistakes, vandalism and unreasonable behaviours do occurs. One tongue-in-cheek dbpedia entry for the fictitious Official Timocracy of Sapinetia even managed to get itself inserted in a now-deprecated version of the Muninn Military ontology.

Wikipedia processes are not necessarily aligned with your own, through there is a lot of goodwill to be hand. If your own systems depend on that goodwill to function on Monday morning at 3am, your mileage may vary. As with all other crowdsourced environment, you must accept that people with much less knowledge of your area will feel free to edit your carefully curated triples, sometimes inappropriately. If you are in a situation where you can tolerate this and keep watch over your triples, then perhaps these services may be a good home for your data.

The remaining issue is one of mission and authority. When people retrieve data from any of the crowd sourced sites, they have an understanding that the data may not be authoritative. The triples are likely to be valid, but you are getting a data set that may have been edited inappropriately. At times, the truth from the proverbial horses' mouth is needed with an authoritative answer from the competent institution. If this is you, then perhaps you want to serve your own data in house since in this case the primary value of the data is it's authenticity and the fact that you are delivering it preserves the chain of trust.

Conclusion

The gains of Linked Open Data in Canada have been meagre in the past year. There have been a number of issues holding adoption back, none of which are insurmountable or inherently show-stoppers. The Linked Data Projects in Canada webpage will be updated on an ongoing basis, please feel free to email me about updates or, better yet!, new Linked Open Data sets in Canada.

(With thanks to Joel Cummings for his comments)

1. Arnold Fee, 2017-2-24

2. Tim Jaques, 2017-3-30

3. With apologies to Henry Louis Mencken.

References

M. J. Suhonos, “Linked Data in Canada: Behind the Curve”, in Canadian Linked Data Summit, Montreal, Canada, 2016.

Language English

CanLink: Linked Open Theses

warren — Fri, 29 Sep 2017 15:59:17 +0000

CanaLien : un projet de données liées pour les thèses Canadiennes - CanLink : a linked data project for Canadian theses is now online!

CanLink is a collection of thesis data from collaborating institutions part of the Canadian Linked Data Initiative. It features over 5,000 theses from participating Canadian universities[1] on a broad range of topics, from "post-humans" to "mechano-electric feedback" with new theses being added on an ongoing basis. The project is an initiative of the Digital Projects committee of the Canadian Linked Data Initiative with the development work done by Sharon Farnel, Rob Warren and Maharsh Patel[2].

The data set is described in void / dcat format and is also registered in the Data Hub. The virtual machine is provided by West Grid and the domain name is provided by the University of Alberta.

Getting the data

The data is made available through a Linked Open Data interface and a website permits the simple querying of the data. A download page is available for bulk retrieval of the raw data itself, as well as the full Canadian Subject Headings dataset as re-hosted by canlink. The retrieval of individual records can be done through URL identifiers. Let's look at the thesis titled "Isolation and identification of the flavouring principle in maple syrup" (in 1925!) by Robinson. The thesis record itself can be retrieved in multiple different formats including rdf/xml, turtle, json-ld, ntriples, bibtex and ris by simply adding the extension to the URL or going through HTTP content negotiation.

¹. University of British Columbia, University of Alberta, Library and Archives Canada/Bibliothèque et Archives Canada, Queens University, University of Toronto, McGill University, Université de Montréal and Memorial University of Newfoundland.

². Maharsh was supported by Young Canada Works and the University of Alberta Library.

Language English

Tags:

Linked Open Data: We Need Cool Tools

warren — Tue, 05 Sep 2017 13:30:00 +0000

A disturbing trend emerged during both LODLAM 2017 in Venice, Italy and Digital Humanities 2017 in Montreal, Canada concerning Linked Open Data and the semantic web in general. Both conferences were chalk-full of projects that were either creating data or thinking of publishing their data as Linked Open Data, but very few projects dealt with the consumption of the data. When the topic of consuming LOD is discussed, it is in the context of faceted search or schema.org style discovery. This is problematic because we are not leveraging the linkages of the data and the work done within the project ontologies. And... who really wants to look at triples? The Linked Open Data tools available so far (Pelagios Commons, Trench Map Converter) tend to be highly integrated with the data of the organization that created it, if we are to move on with this technology we need tools that apply to multiple datasets.

The LODLAM 2017 session Cool tools was well attended by over 30 people crowding around the tables in the Salone Degli Arazzi about cool tools to consume LOD. Oddly, most of the tools discussed were still of the backend or engineering variety. With production getting so much attention, the lack of thought about consumption is concerning: What do we expect end-users and scholars to do with this data? When asked what tools they would like to see, the session members still talked about workflow toolchains and backend facing processes. This isn't unexpected as LAM practitioners worry about their day to day responsibilities first and foremost. Enrichment and creating linkages were similarly popular topics as people wanted to cross-link their datasets on a larger scale than is possible with manual methods. For all of the work entailed, it is all primarily a straight-forward engineering problem.

If we expect end-users to make use of the data, then tools must be available for them to do so.

A similar event occurred in the 1A Workshop "From Production to Consumption (Tools)" at DH2017 late this summer. The discussions about the entire process revolved primarily about production and distribution tools instead of consumption. The question was asked repeatedly about what the specific research problem was that the participant were trying to solve when using linked open data. Few answers from the workshop were forthcoming. The notion of dataset exploration from an ontological / vocabulary perspective was discussed, but this is really a backend view of the problem that a data "wrangling" specialist would worry about.

Worrisome was the enthusiasm for training scholars in the creation of SPARQL queries to access data. It initially appears to be a reasonable thing to do: there is value in being able to write ad-hoc queries about the number of Oscar winning female actors born in 1965 or the proportion of university educated parliamentarians. In the end, it may be a frustrating and wasting effort, not because scholars aren't capable but because they should not have to. Few forensic accountants write their own SQL statements on their own accounting systems. Why should we expect scholars to do the same using a complex graph query language that was primarily meant for machine-machine data interchange?

The topic of a natural language interface for building SPARQL queries was similarly touched on. Historically, these tools have not done very well. An early (earliest?) example was Hermes in 1998[1] for SQL databases and most recently Siris and Alexa. These tools are backed by huge amounts of development time dedicated to handling exceptions, every day user requests and embedding the odd Monty Python joke. Your mileage solving research problems with these tools may vary and the underlying reason is the same that occurs with any other layer of abstraction: it's hard to keep out of expert user's way while simultaneously helping novice users get started. Add to this the complexity of selecting "correct" answers to non-trivial questions "Why did the Roman empire fall?" and the tool breeds distrust from a domain-specialist community that is unaware of its inner workings. Paradoxically, the communities that do understand how these tools work find them cumbersome because they don't need the mediation in the first place!

John Simpson brought forward the notion that a Linked Open Data tool should be a car with a steering wheel; whether it be a family car, the farm tractor or heavy quarry truck, the interface remains the same. The analogy is nice, materializing it into an actionable design strategy isn't strait forward. We are now approaching a period where reviewing (or close reading) the raw data is no longer possible for a human being; software agents are needed as data mediators. It is unclear how this will develop in the end, but web browsers are the primitive materialization of the these tools. ...where does the steering wheel go? The only way to find out is to experiment.

The question that needs to be asked is:

If you had all of the data you needed as LOD, what is the research question that you would want to answer?

So far, there is an uncomfortable silence after this question. To move forward we need applications that are generic enough to be applied across multiple datasets and that can leverage the richness of the underlying data. These will be the LOD Killer Apps.

References

C. Benjamin Rivera and Cercone, N., “Hermes: Natural Language Access to a Medical Database”, Department of Computer Science, University of Regina, Regina, 1998.

Language English

Tags:

The Geometries of Vimy Ridge, 100 years ago

warren — Fri, 07 Apr 2017 14:51:00 +0000

The Battle of Vimy Ridge began 100 years ago on April 9th through 12th, 1917. It holds importance in the Canadian consciousness in that this was the first time that the Canadian Corps fought as a single unit on the Western Front with the 1st, 2nd, 3rd and 4th Division deployed side-by-side¹. With a lot of patient geo-referencing work and a joint efforts between Muninn, the Canadian Expeditionary Force Study Group and Wikiwar, a number of the units locations, place names and trenches have been extracted. The simplest way at the moment to visualize the locations is through the Open Historical Map which is an OSM-like website that records historical mapping data and can export the raw geometries for further use.

At the time of the Battle of Vimy Ridge, the Headquarters of the Canadian Corps were located near Camblain-l'Abbé (Painted by David B. Milne in 1917). The 1st Canadian Division Headquarters was located in Écoivres near the banks of the La Scarpe river. It's troops were the southernmost deployed with the 17th Corps at their right and the 2nd Canadian Division at their left. The 2nd Canadian Division Headquarters was in a farmer's field near route D58 (There is a google street view pictures of the houses and farms at that current location). The 3rd Canadian Division was next to the left and the 3rd Canadian Division Headquarters was located in Villers-au-Bois. The 4th Division was the northernmost with its flank against the 1st Corps and the 4th Division Headquarters located in a farmer's field near route D65.

How accurate is this information?

A survey section during the war would be expected to triangulate a feature within 20 yards while out in the field. In actuality areas of high activity were well surveyed and the accuracy of a trench map is often within 5 yards for important features. Since we used hand tracing to extract the trenches some inaccuracy is to be expected. One can do much better by creating a line finding algorithm that traces the trench based on colour separation and that will be the topic of future work. The figure to the right is an overlay of the German trenches extracted from a trench map over the Open Street Map's rendering of the current preserve trenches at the Vimy Ridge Memorial. The alignment is not perfect, but sufficient for way-finding purposes.

The location of the Headquarters and the area of operations of the different Divisions, Brigades and Battalions are derived from an aggregate map that was reprojected based on landmarks contained within the current landscape and those within other georeferenced trench maps of the period. The original map was not to scale and large (a 100 meters of so) errors in location can be expected. Of course, features such as a Battalion's area of operations are very large and even a Brigade headquarters involves multiple tents and/or buildings. The map locations on the original source map were simple icons which created their own spatial inaccuracies and one should expect large errors in the actual location. Whenever possible, you should use these features as general areas and not consider their centroid as the ground truth.

This represents the best information currently available and the geometries will improve over time as more information is unearthed. All of these geometries are available from the Open Historical Map's export function which works with all of the tools that were designed for the Open Street Map.

Where did you get this information?

The trenches and trench name information were extracted from maps M_81_000287 and M_89_000382 in the Imperial War Museum's archive. The parameters for the reprojection are described in [1], [2] and this ontology document. Tracing was done manually and exported to both shape files and RDF before being imported to the Open Historical Map.

The location of the headquarters and units during the onset of the battle are derived from the aggregate "map 7" from the Official History of the Canadian Army in the First World War: Canadian Expeditionary Force, 1914-1919 ([3]). The original book was scrubbed for image quality and reprocessed by the good folks at the Canadian Expeditionary Force Study Group before its map was reprojected and bounding areas created before being exported to the Open Historical map.

1. The 5th Canadian Division was not fully formed at the time and it's units were absorbed by the other Divisions.

References

R. Warren and Evans, D., “Translating Maps and Coordinates from the Great War”, in Proceedings of the Terra Cognita Workshop at ISWC 2014, Riva Del Garda, IT, 2014.
R. H. Warren and Evans, D., “From the Trenches - {API} Issues in Linked Geo Data”, in Linking Geospatial Data Workshop, London, UK, 2014.
G. W. L. Nicholson, Official History of the Canadian Army in the First World War: Canadian Expeditionary Force, 1914-1919. Ottawa: Queen's Printer and Controller of Stationery, 1964.

Language English

Tags:

Time to say goodbye to an old friend

warren — Fri, 01 Jul 2016 00:24:17 +0000

When the Muninn Project started several years ago, it was a wild idea that started at the paper napkin stage and that slowly evolved into one of the more complex projects in the Linked Data Cloud today. Along the way, Muninn's mascot Le Corbeau was chosen, as designed by "Steve" on a free CC clipart site which has since disappeared along with any lineage and provenance data. While at the time that decision seemed sound, it isn't great not knowing the status of an abandoned clip art and to this end, we ended up asking a designer to create a version of the Corbeau specially for Muninn. The designer is Erin Windrim from Toronto who also released her work under the Creative Common license. She's currently working on the next batch of stickers that you you'll be able to get at a future conference!

Language English

Tags:

corbeau

muninn

CC0

LOD at #dh2015, #lodlam and #ww1hack in Sydney, Australia

warren — Tue, 11 Aug 2015 02:41:34 +0000

It was a busy July in Sydney Australia for everyone with the LODLAM Summit, Digital Humanities Conferences and World War One hack day back to back! This blog post is a short synopsis of the events that occurred over was an stimulating and interesting week.

The State Library of New South Wales hosted the 2015 Linked Open Data Summit. In typical un-conference style, a number of birds of a session occurred including one on the First World War (sessions notes here and here) that resulted in the creation of a generic Linked Open Data subject heading for the war that has already been written about here.

The LOD challenge at LODLAM had three entries related to the war with Agate World War I by Clare Job, Rebecca Daly, Susan Jones, and Noel Broadhead all from the University of Wollongong, Core Contextual Reader by Thea Lindquist (University of Colorado Boulder) and Eetu Mäkelä (Aalto University) and by Muninn’s entry by Rob Warren (Muninn Project) and Mark Farrell (University of Waterloo).

The University of Western Sydney was the site of the Digital Humanities Conference 2015 where a number of presentations related to the Great War and Linked Open Data occurred. A panel "Linked Open Data and the First World War" kicked things off with presentations by Kathryn Rose (Memorial University, Dominion of Newfoundland), Mia Ridge (Trinity College, Dublin), Rob Warren (Big Data Institute, Dominion of Canada), and Valentine Charles (Europeana Foundation, The Netherlands). A full blog post is being written up on the Europeana blog. Other presentations about similar approaches included "Beyond the Library Walls: The National Library of Wales Research Programme in Digital Collections" by Rhian James and Paul McCann (National Library of Wales, UK) and "Language, Cultural Influences and Intelligence in Historical Gazetteers of the Great War" by Rob Warren (Muninn Project).

A related presentation about Linked Open Data included "Sounding It Out: The Mariposa Folk Festival and a Linked Open Data Digital Library Prototype" by Stacy Allison-Cassin et al., "An Entity based Approach to Interoperability in the Canadian Writing Research Collaboratory" by Susan Brown at al., "Accidental Discovery, Intentional Inquiry: Leveraging Linked Data to Uncover the Women of Jazz" by Cristina Pattuelli et al. and "From the Holocaust: Victims’ Names to the Description of the Persecution of the European Jews in Nazi Years: The Linked Data Approach and a New Domain Ontology. The Italian Pilot Project" by Mazzini and Brazzo who also won the LODLAM Challenge.

Finally, the State Library of New South Wales hosted a hackday on the First World War as part of the greater GovHack competition happening throughout Australia. Some serious hacking happened including the beginnings of a Linked Open Data name authority file for every ANZAC soldier of the war. Other projects included the tracking of Indian soldier and there is noise about further Gallipoli GIS resources for World War One research.

Finally, the wizards over at the Auckland War Memorial Museum ended the week with a bang by announcing that it was taking its collections data online along with its online Cenotaph into an integrated online API! which should open the doors for interesting collaborations and linking opportunities!

Language English

Tags:

One URI for the Great War

warren — Wed, 01 Jul 2015 05:52:58 +0000

The Great War occurred again during a session at the #lodlam Summit in Sydney that was held in the Mitchell Library and hosted by the State Library of New South Wales.

One of our conversation turned on the use of a global subject identifier for the Great War since most systems still represent it as a series of strings: "The Great War, Great War (1914-1918), World War One, WW1, etc... Furthermore, different nations entered the conflict at different times (The United States entered the war in 1917) which implies that the event is seen as matching or not different views of the event, e.g.: Great War (1914-1918) versus Great War (1917-1918).

To get around this we created a global URI for any and all aspects of the Great War:

http://rdf.muninn-project.org/ww1/2b460

The term contains labels in several languages that we will keep adding on to and the human-readable term definition is "Any data related to the Great War" which should be wide enough for all usage. You don't need to agree with this definition: through the use of OWL, OWL2 and SKOS vocabularies you can further refine your own collection subject heading by linking to the above URL. The linking aspect is what will enable more people to find you collection and its holdings.

So, if you have a collection or items that are about anything related to the Great War, do:

Use the term directly as a subject heading, OR:
owl:sameAs's to it with your own subject heading, OR:
owl:differentFrom to it if you disagree with how we are going about this, OR:
skos:exactMatch to it if you live in the SKOS world and agree with the term, OR:
skos:closeMatch to it if you live in the SKOS world and the term is close to what you think the Great War should be, OR:
skos:broadMatch to it if you live in the SKOS world and the term is too broad for your needs, OR:
rdf:subClass to it if you live in the OWL/RDF world and the term is too broad for your needs, BUT:

Do link to the term if you are working on the Great War. Linking is the only way we are going to get Linked Open Data working for everybody.

Language English

Tags: