The Muninn Project - great war

Great Britain declares War on the German Empire

warren — Tue, 05 Aug 2014 01:59:05 +0000

On August 4, 1914, Great Britain declared war on the German Empire for, among a long list of complex reasons, violating Belgian Neutrality as they attempted to invade France through Belgium. While the cabinet declared war on the German empire and not the King, this was primarily a constitutional delicacy. It was really the British Empire declaring war on the German Empire and that the Dominions and the British Indian Empire would support Great Britain directly was no more surprising than Austro-Hungary supporting Germany.

This event is marked up below as it is recorded within Muninn. Nothing there should surprise you expect for the use of a Time Owl property that states that the event occurred inside the Great War and the event is not the Great War itself. Why?

<org:Event rdf:about="...Event/BritainDeclaresWar"> 
<rdf:type rdf:resource="time#Instant"/>
<foaf:name xml:lang="en">Great Britain declares War on the German Empire</foaf:name>
...
<org:hasPrincipal rdf:resource="dbpedia:British_Empire"/>
<time:inside rdf:resource="organization:EraGreatWar"/>
<time:inDateTime> 
<time:DateTimeDescription rdf:about="DateTimeDescription/BritainDeclaresWar"> 
... 
<time:year rdf:datatype="XMLSchema:gYear">1914</time:year>
<time:month rdf:datatype="XMLSchema:gMonth">08</time:month> 
<time:day rdf:datatype="XMLSchema:gDay">04</time:day>
</time:DateTimeDescription> 
</time:inDateTime> 
</org:Event>

In English speaking countries, Britain declaring war is seen as the beginning of the War. However, if you happened to be French, Belgian, German or even Archduke Franz Ferdinand, the war had already started a few weeks ago. There is a great quote in the period movie Barry Lyndon (1975):

"Barry's first taste of battle was only a skirmish against a small rearguard of Frenchmen who occupied an orchard beside a road down which, a few hours later, the English main force would wish to pass. Though this encounter is not recorded in any history books, it was memorable enough for those who took part. [and died there]"

We tend to model events from our own perspective and cultural context. Sometimes this is a appropriate and sometimes not, but in the end all events tend to be interrelated.

Language English

Tags:

events

lod

great war

My Canada does not include Newfoundland (and other provocative LOD statements)

warren — Sun, 25 May 2014 19:06:02 +0000

A given in working with historical data is that things will have changed since the data was created and this means that some interpretation is necessary to put the data in the right context. In Muninn's case the state of the world as it was in the 1910s is very different from the world of today in terms of things, places and people.

I'm picking on Newfoundland and its involvement in the Great War and as it relates to the Dominion of Canada as an example of issues that pop-up. At the time of the Great War, Canada did not include Newfoundland.

Newfoundland and it's mainland part Labrador is a former colony of the British Empire that became a Dominion in 1907. Newfoundland had decided not to join Canadian Confederation in 1869. It had limited autonomy above that of a colony, as had the Dominion of Canada. It fielded its own battalion sized regiment, the 1st Newfoundland Regiment (nicknamed The Blue Puttees), as its contribution to the Great War. By the end of the war, the Regiment would be renamed the Royal Newfoundland Regiment. The names and Linked Open Data URI's of these soldiers can be retrieved with this query.

Open Street Map uses relation 391196 (image right) for the boundaries of Newfoundland and Labrador to mark them as provincial entities. The current Linked Geo Data server isn't exporting this relation as a URL right now, but the geometry remains closely matched to the older Dominion boundaries.

The current dbpedia Dominion of Newfoundland term is an appropriate Linked Open Data URI for us to use with Muninn, though it is missing start and stop dates. There are also dbpedia terms for the Island of Newfoundland and the Labrador coast that reference the place and not the political entity itself. Geonames similarly provides terms for the Province of Newfoundland and Labrador (current province) and the Island of Newfoundland (the location) but not the Labrador coast.

Trying to defined the Dominion of Canada during the Great War is equally challenging. It would eventually become modern Canada, but only after going through several national and provincial border adjustments post-1921 and absorbing the Dominion of Newfoundland in 1947, becoming the Province of Newfoundland. To make things even more confusing, Canada became a Commonwealth realm instead of a Dominion with the Statute of Westminster in 1931, though the term Dominion of Canada remained in everyday use until late in the 1950's. Canada's constitution was repatriated in 1982 from Great Britain, but the references to Realm and Dominion still remain in some federal documents. Some border disputes still exist about Canada's geography, notably with Hans Island which is in the high arctic and is likely at the bottom of the list of things that Canada and Denmark worry about.

Getting a Linked Open Data term for the dominion is a bit difficult: the dbpedia Dominion of Canada is redirected to Canada after a small edit war about the appropriate way to represent Canadian history ended with the page getting locked. The result is a Wikipedia article organization that might look pleasant but does not work well from dbpedia's standpoint.

Open Street Map relation 1428125 currently maps out the current borders of Canada (image left), which definitely don't correspond to what it would have looked like in 1914. For its part, the FAO Political Ontology's version of Canada is marked as valid since 1985 and valid until the year 9999. We can't make use of this term as it is problematic: it entails that the entity exists outside the years range of the Great War and it is defined as an independent political entity.

This FAO term is actually an example of issues that pop-up in the shift from database schema to ontology definition. The validUntil property is defined as "the area's first year of validity... ...validSince = 1985, this indicates that the area is/was valid since 1985." instead of "the term's first year of validity". This confuses whether the property is about the entity itself or about the description of the entity. It also makes use of a 'Magic Number' instead of a machine readable term. There is no way for a machine to understand this data which can easily be understood as meaning that Canada was created in 1985 and will cease to exist in the year 9999.

Geonames lists Canada as a modern day country with a bounding box encompassing Newfoundland. Thus, if we want to refer to the Dominion of Canada in the Great War context, we will need to create our own Linked Open Data URI. Defining a geometry for both dominions is a lot of work because of the large polygons that we have to create to encompass areas who's shape we aren't completely certain about. So we postpone this work by omitting the shape information and creating an empty URI for the geometry. This does not mean that the URI is useless: we can leverage the power of the semantic web to use the existing Linked Open Data URIs to make sure our terms aren't confused with another historical period and to narrow down the range of possible locations.

Defining what something is based on what it isn't

Linked open data allows us to create things, entities or concepts without needing to be completely certain about all of the facts. In this case, we want terms defining both the political and geographical aspects of the Dominion of Canada and the Dominion of Newfoundland. This involves the political entity, their features and the geometry of the features. Given the use cases of the Muninn Project, we made the decision to merge both political entity and feature within the same URI and keep the geometry separate. Therefore, we use the Dominion term provided by the Muninn Organization ontology, the Feature term from the GeoSPARQL ontology and some glue from the neoGeo vocabulary.

Given that Geonames, Dbpedia and Linked Geo Data all model their URI and concepts using different variants of Entities, Features and Geometries, it is not necessarily easy to use them all in a way that will keep a reasoner from malfunctioning. Since they all contain some type that references Geometry, we will use their terms aggressively to compare our 'make believe' geometry against. The terms defined here are abridged to be readable, but the links will load the full RDF.

Defining Canada (which does not include Newfoundland):

<rdf:Description rdf:about="Canada">
 <rdf:type rdf:resource="Dominion"/>
 <rdf:type rdf:resource="Feature"/>
 <foaf:name>Canada</foaf:name>
 <rdfs:label xml:lang="en">Dominion of Canada</rdfs:label>
 <owl:differentFrom rdf:resource="dbpedia:Canada"/>
 <owl:differentFrom rdf:resource="geonames:Canada"/>
 <owl:differentFrom rdf:resource="fao:Canada"/>
 <geom:geometry>
  <rdf:Description rdf:about="GeometryCanada">
  <rdf:type rdf:resource="Geometry"/>
  <rdfs:label xml:lang="en">Geometry of the Dominion of Canada</rdfs:label>
  <ogc:sfDisjoint rdf:resource="GeometryNewfoundland"/>
  <ogc:sfWithin rdf:resource="geonames:NorthAmerica"/>
  <ogc:sfTouches rdf:resource="dbpedia:LabradorCoast"/>
  </rdf:Description>
 </geom:geometry>
</rdf:Description>

Thus, our Canada is not the same as the one described in the FAO, DBpedia or Geonames. Canada is a Dominion, it's geometry isn't defined but we know it is in North America, separate from the geometry of the island of Newfoundland and that it partially touches the Labrador coast. This effectively prevents anyone from confusing what we think Canada is with another political entity called 'Canada' while generally placing it in North America and enforcing the fact that the geographic does not encompass Newfoundland.

In a similar fashion, we can defined the Dominion of Newfoundland as:

<rdf:Description rdf:about="Newfoundland">
<rdf:type rdf:resource="Dominion"/>
<rdf:type rdf:resource="Feature"/>
<foaf:name>Newfoundland</foaf:name>
<rdfs:label xml:lang="en">Dominion of Newfoundland</rdfs:label>
<owl:differentFrom rdf:resource="dbpedia:Newfoundland"/>
<owl:differentFrom rdf:resource="geonames:Newfoundland"/>
<owl:sameAs rdf:resource="dbpedia:DominionOfNewfoundland"/>
<geom:geometry>
  <rdf:Description rdf:about="GeometryNewfoundland">
   <rdf:type rdf:resource="Geometry"/>
   <rdfs:label xml:lang="en">Geometry of the Dominion of Newfoundland</rdfs:label>
   <ogc:sfDisjoint rdf:resource="GeometryCanada"/>
   <ogc:sfContains rdf:resource="dbpedia:IslandNewfoundland"/>
   <ogc:sfContains rdf:resource="dbpedia:LabradorCoast"/>
   <ogc:sfContains rdf:resource="geonames:IslandNewfoundland"/>
   <ogc:sfWithin rdf:resource="geonames:NorthAmerica"/>
  </rdf:Description>
 </geom:geometry>
</rdf:Description>

Here, we are the same entity as that described in dbpedia through it is not the same as the current province, nor is it the same provincial entity described by Geonames. We still don't have a full geometry described for the dominion, but it includes the Labrador coast, the island of Newfoundland (as described by Geonames and Dbpedia) and is within North-America. Of course, it is separate from the geometry of Canada.

Linked Open Data enables you to have missing data

Our problem was that we wished to define two distinct historical entities that are the ancestors of current entities and that can be easily confused with them. Their geometry has changed over time and isn't known to a sufficient detail for us to provide a GIS polygon. Using Linked Open Data we were able to describe both historical entities while avoiding ambiguity with other terms. We were even able to define URIs for their geometry without knowing what the geometry actually was by comparing against past and modern geometries.

A fear in historical modeling is that using imprecise or unknown data will lead scholars to make erroneous decisions. Tools have had limited support for these situations in the past, but the use of Linked Open Data approaches allows us to make statements about things while allowing for some measure of managed uncertainty.

Language English

Tags:

Canada

great war

Linked Geo Data

Linked Open Data for Ultra Realistic Simulations

warren — Mon, 05 May 2014 13:36:20 +0000

One of the uncomfortable questions that is often repeated with projects generating linked open data is "So, you've created a database. Now what?". You've created the datasets, published them in linked open data and created useful API's, SPARQL endpoints and maybe even a nice html layout for the data. But how do you actually use the data and does it actually ever get used?

What we really need are smart user agents that can interpret a lot of the detail and pick out what is relevant. This has some uncomfortable connotations that we are abdicating some of our decisions to a piece of software, but to a certain extent we already do when using modern web browsers (that auto-negotiate languages) and recommendation systems when shopping online. It seems reasonable that we should extend some of the same permissions to software agents that are sifting through data. Do you really care if it makes the decision not to pick up the Esperanto language description triples on the dataset? Perhaps more importantly, as we move from data models that were first tabular, relational and then graph oriented, you have the embarrassment of choice in the data that you get and as with web search engine, a little bit of automation here won't hurt. At the core of the semantic web is the idea that the data is written for a machine that will answer a human need. And if you accept that notion, you probably don't want humans querying the data themselves or writing data so that it will be easy for humans to use but hard for a machine.

An idea that is being worked on is the use of simulations as data visualization tools. We've explored the use of various forms of visualizations, reports and graphing tool kits but at the end of the day these are only representing a few dimensions of a data set at a time. Worse, you have to know exactly what you are looking for in order to be able to query it for the visualization tool to display it properly. Of course, this is assuming that the data is fundamentally tabular: a table, a spreadsheet, elements easily classify and summarized statistically.

Muninn has been generating some data for a time now about various aspects of the Great War, including a lot of detailed GIS geometry data derived from trench maps of the era. The trenches that snaked across Western Europe and many of the craters of explosions are still visible today in many places. To the left is an early wireframe model of the German trenches that were part of the Hindenburgh Line at 50.1633888, 3.0499266 near Moeuvres in France. With some patience and a lot of hard work on digitization techniques, an impressive collection of historical GIS features is being generated.

As the volume of data grows in both its volume and its detail, trying to find anything in the database becomes a complex querying exercise. Qualifiers, Archival Description Formats and other clever labeling techniques won't help - there is too much data and how to represent it in a way that makes sense is annoying complicated.

In a way that is similar to what the Ordnance Survey has done with their current data and minecraft, we've been exploring the use of game engines as an information retrieval engine for linked open data. The innovation is in the simulation's ability to use multiple different sources of data concurrently to deal with unknowns in the data and estimate missing data through the use of both ontology and alternative data.

There have been games that have previously used real data in their conception, but the idea of having a game dynamically load public linked open data from a database and create the terrain in an online fashion is very novel. Unity3d was used to build the visualization while fetching triples on the fly from a SPARQL servers. In the end, we created a separate server with all of the triples that could be consumed because while Unity3D provides a means of retrieving web data, it enforces a sandbox model that favors its own style of domain permission and does not support the CORS (Cross Origin Request Security) method currently favored by LOD people. (Incidentally, is your RDF data server providing CORS?)

For all of the concerns about SPARQL data throughput, the major problem so far has to do with getting the rendering engine to keep up with that data. The screen shot on the right is an early prototype that renders the trenches of Vimy Ridge in early 1914, 3 years before the Battle of Vimy Ridge. The primary focus right now is on taking advantage of the underlying ontologies that contain the geometry (we used a hybrid of Linked Geo Data, Ordered List Ontology and W3 geo:Point's) to link to both map icons and 3D assets / terrain manipulation code at the same time.

So far, the basic terrain is working and the promise is that through linked open data we can have a flexible data manipulation infrastructure that can relate a thing to various degrees of visualization or study ranging from a 2D historical map, like Open Historical Map, all the way to immersive 3D environments or 3D printed versions of the terrain.

Lastly one of the items that is being played with is renewing the idea of book stack browsing or serendipitous discovery of material and resources. The vast majority of older items in catalogs are never viewed or retrieved. There are various reasons for this, including lack of user interest, poor information retrieval mechanism and ...possibly there isn't actually anything interesting in the document. But there might be one of two documents that are extremely important in the collection that people don't know about because we have never looked at them before. Simulations and game designers have the reverse problem in that getting content for their games that looks original and isn't repetitive is time consuming. We're trying to solve two problems at once by using the content of linked open data archival libraries to provide content to the simulation. This is also an oppourtunity to ensure that the entirety of the archives get regularly looked at and ensure that valuable documents are brought to attention.

A sample implementation and a review of the advantages, pitfalls and ways of mixing visualisations and retrieval are still being determined and the topic of an upcoming publication. Stay turned for a downloadable version shortly!

Language English

Tags:

New Dictionary of Terms About the Great War

warren — Wed, 11 Sep 2013 19:38:06 +0000

A second dictionary has been added to the Muninn ontologies pages based on the Tommy's Dictionary of the Trenches by Arthur Guy Empey in the book Over The Top. It consists of about 440 different definitions relevant to the British Army experience in the trenches of the Somme during the Great War and serves as a good RDF/OWL based reference for automating disambiguation. The OWL file is here in rdf/xml with documentation on the terms here. It's also available as raw triples here.

Language English

Tags: