The Muninn Project - DBpedia

Retrieving Historical Photos of Film Stars using DBpedia

m4farrel — Thu, 29 Jan 2015 14:23:20 +0000

This is a follow-up to the previous blog post on retrieving historical art from the Rijksmuseum. Like historical art, film star photos inform us about politics and human culture at particular times throughout history - but there are so many film star photos that it becomes difficult to devote sufficient attention to each individual photo. We can use DBpedia to retrieve historical photos of film stars and display them in our statistically generated scenes of historical events. We'll display both film star photos and historical art that best fit the contexts of our statistically generated scenes - and use the context of the scenes that they are placed in to interpret them for their historical significance.

As an example, let’s look at film stars who were active around the time that Anne Frank was alive. We'll look at film stars who became active 1900-1945, even though Anne Frank was born in 1929. Anne Frank pasted photos of film stars on her wall who were active before she was born, such as Greta Garbo who became active in 1920. Here’s a SPARQL query to retrieve film stars who were active during that time period:

PREFIX wordnet: <http://www.w3.org/2006/03/wn/wn20/instances/>

SELECT DISTINCT ?actor ?thumb ?start {
{
    ?actor dbpprop:wordnet_type wordnet:synset-actor-noun-1 .
} UNION {
    ?actor dbpedia-owl:occupation dbpedia:Actor .
}
?actor dbpedia-owl:thumbnail ?thumb .
?actor dbpedia-owl:activeYearsStartYear ?start .
FILTER (?start > "1900-01-01"^^xsd:date)
FILTER (?start < "1945-01-01"^^xsd:date)
FILTER EXISTS {
    {
      ?film dbpedia-owl:starring ?actor .
    } UNION {
      ?film dbpprop:starring ?actor .
    }
}
}

We can execute that SPARQL query and retrieve the results by sending a GET request to DBpedia’s SPARQL endpoint:

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&for...???

Note: we’d set the query parameter to be our SPARQL query.

Here's a sample of the results that are returned after executing the SPARQL query:

actor	thumb	start
http://dbpedia.org/resource/Amparo_Rivelles	http://commons.wikimedia.org/wiki/Special:FilePath/Amparo_Rivelles.jpg?width=300	"1942+02:00"^^<http://www.w3.org/2001/XMLSchema#gYear>
http://dbpedia.org/resource/Art_Acord	http://commons.wikimedia.org/wiki/Special:FilePath/Art_Acord_Kephren_1917.jpg?width=300	"1912+02:00"^^<http://www.w3.org/2001/XMLSchema#gYear>
http://dbpedia.org/resource/Bobby_Burns	http://commons.wikimedia.org/wiki/Special:FilePath/Cuckoo_Comedies_(1919)_-_Ad_1.jpg?width=300	"1908+02:00"^^<http://www.w3.org/2001/XMLSchema#gYear>
...	...	...

There are too many results to list in the table above. So, how many film stars were active during that time period?

> (film-stars/count 1900 1945)

1633

Let’s have a look at a sample of a film star photo that we would place in our statistically generated scenes of historical events:

> (film-stars/sample 1900 1945)

There are a couple of problems with retrieving film star photos using DBpedia.

One problem is that some photos of film stars are modern, and would look out of place in our exhibits. We could check if the photos are greyscale before displaying them, but this might not always be effective. For example, this photo of Philip Ober was taken in 1950, even though we only want film stars who were active between 1900 - 1945; we wouldn't want photos that were taken after the date when a particular historical scene that we are recreating takes place. There is no property that tells us when the photo of film star was taken.

Another problem is that there isn’t information available about when some film stars were active, e.g. Sonja Henie as mentioned in this article from the Anne Frank House; this means that they are not included in the result of our SPARQL query. It might be possible to use the release dates of the films that actors/actresses starred in as a proxy for information on when they were active.

We've made a Unity3d picture frame asset that retrieves a random film star photo from DBpedia and displays it when the scene that it is placed in is played. The asset is available in this repository. Stay tuned for more on statistically generating historical scenes!

Language English

Tags:

Film Stars

DBpedia

linked open data

Unity3d

Arcadia

Clojure

Racket

Authority, Statistics and RDF

warren — Tue, 31 May 2011 23:30:00 +0000

The recent discussion on the LOD-LAM website have prompted me to begin writhing about some of the data available on Muninn and how it is generated. Creating a database from the contents of war archives nearly a century old presents some special challenges, some old some new. Jonathan Rochkind' flippant remark 'Sorry Linked Open Data people' was made in jest and drew a lot of responses. But it in the end you can't say that text-mining is better than linked open data anymore than apples are better than submarines as they don't perform the same function. Similarly, the problem of interpreting archival contents is central to Muninn's role as well as the question of what is an authoritative source (at least in the knowledge sense). There is no question that "applying statistical analysis text-mining ‘best guess’ type techniques, provides more relationships than dbpedia alone does".

Generating relationships is easy, since anything can be a relationship, the hard part is figuring out which class of relationship actually means something even before the accuracy of its instances are judged. Dbpedia on the other hand creates its relationships from very specific mark ups within wikipedia. Both the creation of the wikipedia rdf and the wikipedia infoboxes are human-driven and the number of classes is limited by the manpower available. There is still a possibility of errors, someone might have written in Bern as the dbpedia:capital of (dbpedia:populated_place) Germany, but there is no question this is the class that was intended to hold that information. Muninn uses linked open data to publish its processed, cleaned up, results. Behind the curtain, many domain-specific statistical and logical models (including statistical mining)look for particular patterns. However, as opposed to free-running relationship mining these are constrained to the specific linked open data tags that they actually fill. For example, Muninn automatically fills in foaf:knows tags if its calculates that two people know each other within a .95 confidence using a statistical 'best guess'. But the rel:friendOf tag require specific evidence before it is instantiated, such as a record of a communication or an entry in a diary. Most statistical data-mining algorithms won't understand the relationships between the Dominion of Canada (oddly it currently redirects to Canada instead of Canada under Imperial control) as a location and the Dominion of Newfoundland as a political entity. They will happily ignore the untidy 'Dominion', 'location' and 'political' tokens and simply file one as a owl:partOf the other since that is the strongest signal on the graph. It's a simple, easy to understand, wrong answer that causes all sorts of confusion down the line because it 'looks right' but isn't. Should we should consider wikipedia as an 'authority'? It is an outstanding resource for general background data and as a statistical resource to design things like tag clouds, auto tagging html text and creating specialized dictionaries. It does well by the law of averages since the crowd eventually fixes things. This also means that at any given time something will be broken at the page level and that is a problem for an authority. Do you really want your project to catalogue Japan as a rogue legislative element of the European Union because someone messed up a page edit last night? Or watch your reasoner spin madly because there is an edit war on whether Henry Kissinger is_a war criminal? The United States is part of the British Empire right? This is like some of the problems that Open Street Maps is having with bits of countries getting flooded after bad edits. Some data lends itself to statistical or social consensus making for a variety of reasons such as ease of observation. It's easy to fix a bad restaurant location and it only causes limited nuisances for downstream users. Fixing a bad coastline is a bit harder since few people are willing to go out with a transit to survey it. When possible, Muninn links to the appropriate dbpedia triple using rdf:seeAlso for background documents. It's not clear that it is a good idea to link Muninn triples with the dbpedia ones using owl:sameAs at this point since we don't know how authority and stability of triples works. To create a database from the documents requires some interpretation of the information beyond normal indexing or finding aids. Interpretation can range from codifying referencing standards to hard-core detective work. Right now, Muninn focuses on extracting basic facts and trying to link them across documents and entities, cleaning up ranks and names to a point where there is enough of a basic database to add more information. Eventually, there will be enough room for very high level analysis of the data and some interpretation will be done automatically. The nice thing about the Great War is the large number of forms in use, even if not all these are typed since this pre-classifies some of the information for us. Yet, there are many cases where the forms are not responsive to the users needs, so the clerk crosses out fields and replaces them by his own. It will be interesting in the long term to track when and why people do so. Text analysis is a little bit more demanding in that it gives good results when customized to the specific document or text types but that requires some hand holding and hand-coding by a human that needs to be doing too many things at once. There is an experimental text search interface that searches the human readable parts of the linked open data as well as other texts in the collection along with linguistic mood and style. The interface and presentation is still something that is being worked on and comments are welcome. A interesting occurrence is when faulty data is used within a document and is propagated within the organizations' other document, such as impossible dates of birth. The date is obviously wrong, but is still useful as a means of referencing other documents within the archive. It is impossible to trick most databases into storing this information since it fails basic consistency checks, through we are able to force rdf into supporting it through create use of mark-ups. Thus we need to be able to provide information which is clearly wrong from a temporal aspect because it is still useful for linkages purposes.

Language English

Tags:

RDF

Relationships

DBpedia