The Muninn Project - lod

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

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:

The Business Value of Linked Open Data

warren — Fri, 24 Apr 2015 13:55:56 +0000

Note: The following is a synopsis of comments I made to the Publishing and Managing Linked Open Data in Cultural Heritage Institutions session at Museums on the Web 2015. I'm posting them after a follow up conversation with Cristina Pattuelli of the Linked Jazz Project.

What is the business value of Linked Open Data? What is the business case that drives you to support / invest / develop into yet-another-platform and what will it do for your business/library/museum/archive/store-front? Anecdotal, academic and one-off examples aside, why should you care?

A quick answer to these questions In three parts: because a) it promotes and facilitates citation (eg: Marketing), b) creates cost externalization opportunities (eg: Get other people to do your work) and c) it leverages the idiosyncrasies of your business (eg: Your unique selling proposition).

a) Citations (It's a popularity contest)

Linked Open Data gives others an automated means to cite your data. At first that does sound like something that an academic would say, but it also means that Linked Open Data gives you a means to market your data.

Linked Open Data publishes machine readable data with long term URLs for everything your customers care about. This gives them a reference to point to that can use to tell you what they like, what they want and what they don’t want. Linked Open Data is the primary building block of a sophisticated sales and marketing analysis system.

It’s less trouble to point to something than to copy it: if you copy it, you have to store it and manage it. Why do you think that so many pinning/referencing applications exist? Linked Open Data also makes that data wrangling a little easier and lowers everyone's costs.

b) Externalizing Costs (Let people work to get what they want)

Costs are a major concern for everyone: needs are infinite, resources are limited. Your website (content management system) is something that takes up a lot of resources, why should you spend on yet another communication mechanism?

One of the reason that you spent resources on the website is that creating a solution that can handle everyone’s wants and needs is hard and we all aim for the 80% solution. That leaves the remaining 20% out of luck and resorting to underhanded means like crawling your website, likely to answer a reasonable question that you didn’t think about in the first place.

Linked Open Data lets you publish content without the layout and graphical design costs that go into a web site. It also lets you make your content available without having everyone fighting for that coveted front page on the web site. LOD lets other people build applications to answers questions that you haven’t thought about yet. Case in point: schema.org has been working to standardized vocabulary for boring, but useful, questions like when is your building open to visitors.

Your website has a salad-bar of icons and links to social media tools, bookmarks and shared content. You bore the cost of finding out about those applications and integrating them with your website. Of course, the popularity of these shift over time, older ones disappear and new ones are created. Why not push that work back on the social tools developers by letting them make a search / discovery interface?

Linked Open Data gives other people the opportunity to do work that will be of benefit to you without requiring you to bare the costs of doing so. Your current web analytics will work at whatever granularity of content that you publish and who knows, maybe that poorly accessioned print will be a masterpiece that was thought lost. Or maybe that bag of obsolete bearings hidden deep in your inventory system is desperately needed by someone else around the world.

c) Data idiosyncrasies (Your business data is a blizzard of beautiful snowflakes)

Parts of your business are unique, others aren't. There are hundreds of thousands of museums / widgets shops / locations world wide just like you and yet you have something that makes people want to come to see you because you have what they want. Maybe it's a Rembrandt (which one?), a replacement servo motor with the right mounting holes for your 3D printer or decent coffee in an otherwise bleak place. Who knows.

When it comes to software, the common wisdom has been to standardize on commercially available packages unless you really need to roll your own. For many years experts would recommend that you should change the way you do business to the way the software package worked since this was cheaper. Linked Open Data allows you to do both through ontologies that support common standards while using your own definitions. And even if the standards you want to use are incompatible, you can still work with them.

Human beings are self-interested and both suppliers and customers will always insist that you use the appropriate data standard: theirs. The ability to translate across different viewpoints, and in many cases the ability to agree-to-disagree, is a business advantage even before you retain the ability to model your business in the way that it actually happens.

Common LOD Objections

I'd like to address some objections raised during a few talks at the conference, I regret that this is from memory as I neglected to write down the names of the people that brought these issues up.

1. We've been talking about this for 10 years and it still hasn't happened.

I'd rather say that we have been talking about this for about 50 years now.

Many people have tried, the Xanadu project is one of the better known projects, but it has taken this long to get the underlying nuts and bolts working. That includes the Internet, the World Wide Web, XML, basic schema's for Gregorian dates, hypertext, web ontology languages, machine readable time zones, reasoners marginally better integrated than Prolog, and enough raw data to label everything in natural languages. Linked Open Data is built on all of this.

It's been a hell of a trip if you were working on technology in the past 50 years and it's happening now.

2. People can find all of this out on my website, why don't they look there?

We have the hubris to think that people care about us when they really only care about our product. Sometimes, the product actually is the website, but not always. To recap an earlier example, if someone cares about Rembrandt they will want to know what works of Rembrandt you have on display, where the works are and when they can see them. The fact that it happens to be the prestigious Janvrin Island Museum of Fine Art is a nice-to-have. Does it matter if they find out through the website, someone's lovingly curated list of Rembrandt works, or a flyer by the tourism office?

There are a lot of websites out there. In a world where information relevance is key, every little bit that clearly explains the "unique selling proposition" is an edge.

3. We can't give away the intellectual property that is in our data.

Information has value in a context; it seems counter-productive to hide the fact that your business has things that someone might want. Linked Open Data also implies Linked Data - perhaps you don't want to publicly release all of the information within your databases. Perhaps some of it was acquired by subscription to another catalog. If you are unable to publicly release the basic holdings / catalog of your offering (Name, ID Number, Image), you might have a larger problem to worry about than Linked Open Data. Keep in mind Section a) above, the network effects alone increase the value of your own data. The simple act of publishing a URL and a machine readable label goes a long way in making your value obvious to the rest of the market.

4. There are errors in our data

Yes. There are errors in everyone's data. As the amount of data that you own grows, so does the statistical probability that something will go wrong and that's before a human being is involved in the process. You organization will likely never have the resources needed to check up on the quality of your entire dataset. As embarrassing as it may be, releasing some of your data in the open will likely result in them pointing out the mistakes in your data without them being asked to do so (See b). Their motivation will range from altruism to being vile, either way you will get the benefits of having the errors located.

5. People will steal my data

Yes. People will steal your data. They will crawl your web site. They will use your images as their desktop wall paper. They will cut and paste your website text into their own blog and claim it as their own. They will print your images on posters and sell them on the street corner. Linked Open Data carries the same risks of data theft as having a website but creates new opportunities for revenue, I'd say that's a win.

Language English

Tags:

Reusing LOD Vocabularies: It's not all it's cracked up to be.

warren — Tue, 24 Mar 2015 16:14:29 +0000

"Re-use data, re-use vocabularies", this has been the battle cry for Linked Open Data and Semantic Web enthusiasts since day one. Formally, the W3C Government Linked Data Working Group has published a Working Group Note on the matter where they state that "Standardized vocabularies should be reused as much as possible to facilitate inclusion and expansion of the Web of data". What seems to be a reasonable point of vue has been pushed a little bit too strongly of late. Bibframe, an effort by the Library of Congress to push beyond MARC, has met a significant amount of criticism for not reusing existing vocabularies instead of rolling its own vocabulary. The BBC also decided to create its own vocabularies that bare a uncanny resemblance to other well known vocabularies instead of building on known ontologies. So what should you do? Is using pre-existing vocabularies really a best practice?

"Which vocabulary to use" triggers arguments that border on the religious, yet few people really understand what the vocabulary implies about the data. For example, the choice between using a geo:Point's and a asWKT("POINT (x y)") ¹ entails uncertainties about location and data consistency.

The Linked Open Vocabularies (LOV) website lists over 475 vocabularies while the prefix.cc database lists over 1,508 vocabularies available for re-use. But by Linked Open Data Vocabularies, people mean one of three things:

Schemas such as the XML Schema define data-types (xsd:int and xsd:dateTime.) and basic structures (like XML). The formal definition is needed but besides serving as a bootstrap for format parsers, the document is mostly useful to lock in a range for a term.
Vocabularies such as Dublin Core elements, which have neither ranges or domains and are deprecated by Dublin Core Terms, provide an identifier through a url for a piece of information.
Ontologies, such as Bibo, have a structured, declared format for the data and how it is going to relate to other pieces of data out there. OWL provides a mechanism to import other ontologies into your own for data publications and this is reviewed by some as a means of extending a new vocabulary for a new dataset.

A really nice piece written in 2012 by Phil Archer talks about the completeness of vocabularies, their purposes and tradeoffs about the coverage. I would argue that the 80% use case for a number of properties is to have something to put up on the screen for the user to see. This is one of the reasons that void recommends the use of generic Dublin Core elements within dataset descriptions but provide their own custom property void:inDataset for linking datasets and nodes to their dataset description.

Suggested good practice for the re-use of a vocabulary:

The vocabulary must be dereferencable, that is available through an http request that matches it's base, in a format that is machine readable. It's better if it is available in multiple linked open data formats (rdf/xml, n3, ttl, etc..). If machines can't read the vocabulary definition, they they can't read your data either.
The vocabulary has to fit the needs of the data in modeling not only in marking up its contents, but in recording implicit, unwritten assumptions: if your data is about is about facts at a specific point in time, then you should have some way of recording it.
The vocabulary must have an expectation of being available for as long as the dataset will be made available. In some cases this may mean that you want to re-host the vocabulary on your own server through some creative uses of OWL: if the vocabulary definition goes away, so does people's ability to interpret your data.
The vocabulary must be relatively stable. If the semantics of the term definition changes, then the meaning of your own data changes also. Picking vocabularies that have machine readable versioning and deprecation tags is a sign that the vocabulary authors care about how their actions affect downstream users.
The vocabulary has to provide a level of specificity that is appropriate to your dataset. A typical example would be the under-specification of Dublin core: A recording of a song might have the triple <foaf:Document> <dc:subject> "French Song"@en, causing some confusion to a human being, let alone to a machine, as to whether the song is culturally French or interpreted in French.

Consumers of Linked Open Data requires a grounding - Somewhere.

At the end of the day, someone will write a piece of software that will either present the contents of the Linked Open Data to the user on the screen or plug its value into some other piece of code. That requires the programmer writing the software to understand what specific term he is looking for and when/where to look for it. At the very top-level, finding a class or property that might have what you are looking for isn't all that hard: the vocabularies provide <rdfs:comment>, <skos:definition>, <rdfs:label>, etc.. to identify to a human-being what is in the term and that provides you the information you need to create a query to retrieve that information.

The problem that occurs next is a bit of a paradox: You can re-use existing vocabularies but documenting the relationships between those vocabularies is going to require some machine readable OWL/RDF glue which necessitates changing the value of the tag / uri. This should not be a problem since this is all machine readable, yet the great majority of people do not consume Linked Open Data with a reasoner.

Part of the notions about publishing data using existing standards in Linked Open Data is a holdover from the days of XML where the tags had an individual definition through a schema but were not taxonomically or ontologically linked. That means that programmers working a dataset would lookup the namespace / term of a tag to identify its contents (eg: <dc:title> contains the title string of the works) without the expectation that it would be contained by say a <foaf:Document> - XML tags mean nothing besides pointing to human-readable definitions.

A real world example is the Bibo ontology .n3 definition: the <dcterms:title> terms is copied over from the Dublin Core definition. It may occur (or not) at any time as a property of a node but has no declared relationship to anything. However, the <bibo:shortTitle> term assigns a short title to a <bibo:Document> and won't appear anywhere else. "Dumb" parsers will handle both <bibo:shortTitle> and <dcterms:title> being placed pretty much anywhere while an OWL enabled system will throw an exception if the data is violating the ontological definition.<bibo:shortTitle>. Similarly, a dumb parser would overlook <bibo:annotates> as being a sub-property of <dcterms:relation> and even through it would have a use for the relation: the code does not know what to do with <bibo:annotates>.

Note: To explicitly let a programmer know what to expect, some vocabulary / ontology authors will insist on re-declaring all relevant terms from other vocabularies with <owl:sameAs> statements. An irony is that while not re-using vocabularies in the classical sense, this method explicitly documents all terms in both machine-readable, human-readable and dumb-software-readable formats. This alternative re-use methodology is not based on popularity either (See Schaible et al.[1]) although good documentation and vocabulary popularity helps as "it increases the probability that data can be consumed by applications".

There are a few obstacles to vocabulary re-use:

The domain and ranges of vocabularies and ontologies don't always work well together.

Finding an instance of that term in the appropriate context in the data is a bit more complicated. In the commonly held view, terms appear serendipitously in the (syntactically correct) arrangement that made sense to the data set publisher. So you might get:

<foaf:Person rdf:about="Wilhelm II, German Emperor">

<foaf:name>Wilhelm II, German Emperor</foaf:name>

<foaf:interest>

<rdf:Description rdf:about="dbpedia:hunting">

<rdfs:label>Hunting</rdfs:label>

</rdf:Description>

</foaf:interest>

</foaf:Person>

Which basically means that Kaiser Wilhelm is (was) interested in hunting. This will work with RDF software, but not in an OWL-aware stack that will complain that the range of <foaf:interest> is <foaf:Document>. We can fix that by additionally <rdf:type>'ing the dbpedia url for hunting as a <foaf:Document> and go with the presumption that the term is about hunting and not the act of hunting.

<rdf:Description rdf:about="dbpedia:hunting">

<rdf:type rdf:resource="foaf:Document"/>

<rdfs:label>Hunting</rdfs:label>

</rdf:Description>

Not a big deal in this case, but if the statement had been that he has been <foaf:interest>'ed in dbpedia:German_Empire, it would have made a non-sensical statement that he was interested in a German Empire that was both a foaf:Document and a Place at the same time...

The cost of parsing data increases with the number of vocabularies used.

Not everyone is using Linked Open Data with a Linked Open Data stack. Sometimes, people just grep the data they need from a flat file or xpath their way through an XML dump because that is the fastest way to get the data that they want. For every new name space and/or term set in use within the document, some more exception coding needs to be done. Worse, you need to know what tags to expect somewhere way down into the file because as opposed to SPARQL or other query language you have to know what you are looking for in order to get it.

As an example, we document that Kaiser Wilhelm II knew Edward VII. Neither liked the other very much, but we use "knows" to keep their complicated personal relationship simple. Normally, we'd record that through the built-in Foaf properties but we could have also used the relationship vocabulary to document the web of relationships that link the two.

<foaf:Person rdf:about="Wilhelm II, German Emperor">

<foaf:name>Wilhelm II, German Emperor</foaf:name>

<rel:knowsOf>

<rdf:Description rdf:about="dbpedia:Edward VII">

<rdfs:label>Edward VII</rdfs:label>

</rdf:Description>

</rel:knowsOf>

<foaf:knows>

<rdf:Description rdf:about="dbpedia:Edward VII">

<rdfs:label>Edward VII</rdfs:label>

</rdf:Description>

</foaf:knows>

</foaf:Person>

<rdf:Description rdf:about="foaf:knows">

<owl:sameAs rdf:resource="rel:knowsOf"/>

</rdf:Description>

The terms <rel:knowsOf>in the relationship vocabulary and <foaf:knows> in the foaf vocabulary are equivalent, but you have to parse both cases for the same condition if your stack isn't owl enabled and does not understand the <owl:sameAs> triple. Furthermore, if you stated that both were related through an <rel:acquaintanceOf> tag, you will still be in a mess since <rel:acquaintanceOf> implies <foaf:knows> but you need to know about the tag before you parse for it.

Sometimes good practice works against you.

Ontology design rules are there to permit the creation of a consistent systems of logical facts. People approach ontology design in different ways through a sets of design patterns that attempt to avoid inconsistencies, redundancies and ambiguities [2]. Like Third Normal Form (3NF) in classical relational databases, a lot of thought went into these rules but they come at a cost that you may not be willing to bear.

Some of the ontology design patterns include:

No leaf concepts: Terms that are not exactly matched to the purposes of the ontology, either as sub-classes or super-classes, are discarded from the ontology.

Typical examples of this are Seco and the ARC Marine Ontology:

In the Seco world, organizations are military in nature, which is to be expected since it concerns itself with the First World War like Muninn does. However, in line with ontology design guidelines Seco's Military Organizations do not descend from generic Organizations which also means that non-military organizations (like a civil government) aren't supported within this world. You can work around this by adding your own OWL statements that subclass the W3 Organization ontology, but you are then patching the original ontology.

Similarly, if you are trying to record maritime data and you settle on using the Arc Marine Ontology, it is a well engineered ontology to record cruise data. However, you inherit all of their design decisions including the "best practices" ones that may not match your data. All events within ARC are MarineEvent's with no sub-classing of a general event class. That's good practice according to their original requirements but that might not match your data behavior. As an example, if you are recording ship movements, then how do you record non-maritime events that are ancillary to shipping movements like the issuing of manifests or generic weather events? An extra hiccup is that ARC sees a ship as a property to add a string to the cruise. If you happen to record detailed ship-specific properties like tonnage or call-sign, you have to modify the ontology itself so that the domain of the ShipName property does not clash with your data.

No extraneous concepts: Ontology terms that are not expressed within the data-set, such as a marine population report that has no observation of a type of whale, should be dropped.

The underlying thinking is not to add complexity to an already complex system by only handling the bare essentials or fulfilling the requirement exactly but no further. This can leads to an over-fitting of the ontology to the data-set that it was meant to represent while making it useless for everyone else. This specific best practice is explicitly ignored by some ontology designers in order to make their vocabulary useful to non-OWL enabled systems.

No redundant concepts: Ontology terms that have the same meaning should be merged. On occasion, this rule is misinterpreted by some designers who fail to differentiate between the thing being modeled and the name of the thing. The result is an ontology that is consistent from a logical perspective but incoherent from a nomenclature perspective. Since reasoners only worry about the logical errors within an ontology, the automated tools will never catch errors that make the vocabulary useless for other users.

An classical example of this is with DBpedia:

<rdf:Description rdf:about="dbpedia:Boiler">

<rdf:label lang="en">Boiler</rdf:label>

<rdf:label lang="fr">Chaudière</rdf:label>

<owl:sameAs rdf:resource="http://fr.dbpedia.org/resource/Chaudière" />

</rdf:Description>

The French word for a boiler is chaudière, which unfortunately also means "a bucket". DBpedia takes a straightforward view of labels in that they aren't disambiguated or annotated per languages as you would using skos-xl. In 90% of cases this isn't a problem since the context of the application handles disambiguation implicitly. However, your own application might have different requirements.

Not everyone see the world the same way.

Persons should be an object that Linked Open Data has figured out by now, but has not. Foaf is likely the most mature ontology used to represent people and pretty much covers most of what you'd want when talking about a person, but it won't handle name changes, multiple names or royal styles. Similar claims are made by CRM-CIDOC's crm:E21.Person, dbpedia.org Person, FRBR Person, BibFrame Person, schema.org Person and I am likely missing a few (See Brown and Simpson [3]). People are pretty much the single most important thing in modeling and yet we have a long list of definitions and re-definitions of classes for defining a person. And don't get me started about handling fictitious people.

The other tradeoff in that people tend to optimize their work for their problems: Foaf was meant to support people in an internet context when it was written, this is obvious in its support for online accounts, projects worked on and tipjars. schema.org is meant to streamline the process that tells search engines what your webpage is about. It does a pretty good job for day-to-day use, such as recording the location of a curry place you like. But it won't record its last address before it moved or the name of its previous owner. Similarly, Muninn worries about the First World War and the ontologies tend to be highly tuned to the problems of that era.

Another example of differing views on the world is the differing ways in which Seco, DBpedia and Muninn see Corps organizations in an army. An army corps can either be a formation of troops that is part of an army or a unit with a specialized purpose. Because DBpedia is derived from the Wikipedia that explains both concepts, the dbpedia Corps term is not disambiguated and hence matched Muninn's Corps disambiguation term. Seco's term for a Corps is under-specified and used when the name of the unit has 'Corps' listed in it.

Hence if your dataset would be about the Royal Pioneer Corps or the Machine Gun Corps, using either Seco or DBPedia's terms would not be outright wrong, but it would be under specified. You likely would want to use Muninn's CorpsUnit term to specify the unique mission assigned to Pioneer troops.

Different applications need different levels of complexity

Where did Nelson pass away?

We know that Admiral Nelson was shot by a marksman at the Battle of Trafalgar. He was brought below deck of his flagship HMS Victory. Dramatically different approaches to recording this events is possible that are completely incompatible with each other while being completely reasonable on an individual basis. A very simple approach to modeling this event using DBpedia's placeOfDeath property.

<DBpeda:Horatio Nelson> <dbpedia-owl:deathPlace> <DBpedia.org:HMS Victory> .

Take for example Nelson's death at Trafalgar. Very complex modeling can be done with some ontologies like CRM-CIDOC [4] which require large amounts of triples and a very deep understanding of the ontology. If that level of detail isn't right for you, another solution might be to build a location piecemeal:

Nelson actually died of his wounds in the cockpit of the orlop deck of the HMS Victory. We don't have the full trajectory or position of the ship at the time, but its not necessary. All we really need is to define the place and to link it to the ship.

<foaf:Person rdf:about="">

<foaf:name>Horatio Nelson, 1st Viscount Nelson</foaf:name>

<dbpedia-owl:deathPlace>

<rdf:Description rdf:about="NelsonDeathLocation">

<rdfs:label>Cockpit, Orlop Deck, HMS Victory</rdfs:label>

<rdf:type rdf:resource="Orlop Deck"/>

<rdf:type rdf:resource="Cockpit"/>

<rdf:type rdf:resource="Feature"/>

<dc:partOf rdf:resource="HMS Victory"/>

<ogc:sfWithin rdf:resource="Cape Trafalgar"/>

</rdf:Description>

</dbpedia-owl:deathPlace>

</foaf:Person>

Depending on the complexity of the data and the application that is being worked on, different vocabulary choices will be made.

Conclusion

Vocabulary re-use isn't the silver bullet that it is sometimes advertised for the simple reason that unless the vocabulary is a perfect match to the type of data you are publishing it is likely missing something that you need. There is a lot of great engineering done in vocabularies and the right mix of re-use, addition, modification and roll-your-own will help you create a great data-set.

1. geo:Point' is meant to handle a single point in WGS84 (GPS) projection while the GeoSPARQL asWKT( is a container for GML strings that can define projections different from WGS84. Most implementation of GeoSPARQL I've seen so far assume a default of WGS84 for a GML snippet like POINT (x y), but that is not set in stone and someone might get very bizarre results depending on the engine they are using.

2. rel:knows_Of was changed from a subproperty of foaf:knows to work around the reciprocity problem. Relationship accepts that a person might know about someone without the reverse being true. Foaf does not.

References

J. Schaible, Gottron, T., and Scherp, A., “Survey on common strategies of vocabulary reuse in linked open data modeling”, in The Semantic Web: Trends and Challenges, Springer, 2014, pp. 457–472.
T. Gherasim, Berio, G., Harzallah, M., and Kuntz, P., “Problems impacting the quality of automatically built ontologies”, Proceedings of Knowledge Engineering and Software Engineering, vol. 949, 2012.
S. Brown and Simpson, J., “The curious identity of Michael Field and its implications for humanities research with the semantic web”, in Big Data, 2013 IEEE International Conference on, 2013.
M. Doerr and Hiebel, G., “CRMgeo: Linking the CIDOC CRM to GeoSPARQL through a Spatiotemporal Refinement”, 2013.

Language English

Tags:

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

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: