Name Data Sources for Semantic Enrichment

We can access the info about Cranach in various ways:

• Per-entity web page: http://www.wikidata.org/entity/Q191748

• Per-entity semantic format. We can request the entity with content negotiation (Accept header), or with the corresponding file extension. Turtle is the easiest to read (the names use real Unicode chars), NTriples may be easier to compare (it's line-oriented), JSONLD may be easiest to process in applications.

  curl -L -Haccept:application/rdf+xml http://www.wikidata.org/entity/Q191748 > cranach-wikidata.rdf
  curl -L -Haccept:text/turtle         http://www.wikidata.org/entity/Q191748 > cranach-wikidata.ttl
  curl -L -Haccept:text/plain          http://www.wikidata.org/entity/Q191748 > cranach-wikidata.nt
  curl -L -Happlication/ld+json        http://www.wikidata.org/entity/Q191748 > cranach-wikidata.jsonld
  

  • This includes only labels and Wikipedia (inter-language) links. Other statements are not yet available by Wikidata entity access

  • To get the best of both worlds (line-oriented and real Unicode chars), reprocess the Turtle with Jena rdfcat. (Note: rdfcat does not produce proper Unicode from the NTriples file):

    rdfcat -out ntriple cranach-wikidata.ttl | sort > cranach-wikidata1.nt
    

• Reasonator application, which collates a lot of useful info in a pretty way: http://tools.wmflabs.org/reasonator/?&q=191748
• Wikidata API (Reasonator is built using it)
• DBpedia SPARQL endpoint: http://dbpedia.org/sparql.
  • In DBpedia the entity URL is rewritten to http://wikidata.dbpedia.org/resource/Q191748

  • You can get the info with a query like this, since the rewritten URL does not resolve

    describe <http://wikidata.dbpedia.org/resource/Q191748>
    
    

  • Compared to Wikidata there may be some more info (especially for less popular items), but it's less precise/accurate
  • It's not clear where this data came from, or how often it is updated

Wikidata also provides a number of powerful tools that are described next

• Wikidata Statistics shows the number of items (Content pages) and editorial statistics
• Stats tables and charts shows the growth since Feb 2013
• Year in Review shows a breakdown of items per number of labels and number of statements comparing Jan 2014 and Jan 2015
• Live stats provides up to date information on Wikidata size, number and percentage of statements of different kinds, and the WDQ clause used to access this kind of data element

Comparing the Live numbers to the triples in the next section:

• Labels=63M would leave 81.7M to descriptions & aliases, but in our opinion these are fewer than the labels
• Sitelinks=42M is only 30% of the number reported above? We don't have the correct count, since WDQ doesn't return accurate results for empty link[] or nolink[] clauses. 4.4M items have link to enwiki or dewiki, and 8.7M don't have such links: we can estimate that 6M items have any wikilink, and the other 7M don't
• Total number of statements (54M) doesn't even reach the number of "simple statements"
• The percentage breakdown of statements gives us a useful overview of the kind of data in Wikidata at present

Wikidata provides comprehensive RDF data dumps: http://tools.wmflabs.org/wikidata-exports/rdf/exports/

• There is some discussion of implementing Incremental dumps (similar to http://live.dbpedia.org), but such are not yet available
• The full dumps are made quite often (monthly or bimonthly)
• Note: the interactive query tools described above work with a delay of 5-15 minutes compared to the live data

(1) And items used as target of "subclass of" or "instance of" -> owl:Class

Wikidata statements (claims) may carry complex associated information in qualifiers, such as dates of applicability, source references, scope ("of"), etc. Such claims are exported to RDF in a complex way using reification: see [5] fig.3 and sec.3.2.

• The last file "statements" in the tabe above uses this complex modeling and is quite hard to work with.
• The files marked "+" are derived from "statements". They are quite simpler to work with, and also smaller.

Ontotext has taken a recent count of all direct type ("instance of") RDF statements as of Dec 2014. The count files are on Gist

• There are 12331093 "instance of" statements. Wikidata has 13M items, so about 93% of all items have types (if we assume that only a small percent of the items have multiple types)
• There are 17875 classes with at least one instance, of which 6510 classes (36%) with at least 5 instances. The rest (64%) are a very long tail of items that are inappropriately used as classes, e.g. Indian Rhinoceros, Trumbull's Declaration of Independence, stud, meatloaf…

Specific classes that are useful for Person/Organisation Recognition:

• There are 2.7M (2662626) humans (matches the number reported by WDQ 2.1.1.1). This is fairly well focused, in that it collects a large proportion of all humans. There are a few exceptions, e.g. "minister", "table tennis player", "chess composer": these should be used as "occupation" while "instance of" should be "human".
• There are 5k families: 4569 noble family, 635 family, 465 Dutch noble family, 95 Belgian noble family, 35 clan
• There are some 22k literary characters: 11993 fictional character, 6963 fictional human, 2589 mythical character, 357 group of fictional characters, 159 fictional organization
• There are at some 215k organisations (not counting governments, city councils, etc). These are spread across a wide list of classes, so the totals below are not comprehensive and represent the possible minimum:
  • 55k businesses: 47149 company, 2653 business, 2321 transport company, 885 public company, 718 corporation, 152 motorcycle manufacturer, 95 joint-stock company, 80 holding company
  • 66k creative organizations 42179 band, 17904 radio station, 6187 newspaper, 1540 film production company, 843 theatre company, 22 theatre troupe
  • 31k sports clubs: 26200 association football club, 5376 sports club, 184 American football club, 169 golf club, 154 country club
  • 30k educational institutions: 16611 high school, 6396 school, 6321 university, 1062 Engineering College, 771 college, 301 research institute
  • 20k non-profit organisations: 8929 organization, 7026 political party, 2853 association, 1052 nonprofit organization, 307 international organization, 246 charitable organization, 226 Esperanto organization, 144 political organization, 73 non-governmental organization
  • 13k GLAM orgs: 438 art gallery, 83 art gallery; 882 library, 199 national library, 114 public library, 60 library, 28 Carnegie library, 27 academic library, 16 municipal library; 108 archive, 26 cantonal archives, 24 municipal archive; 6516 museum, 2176 art museum, 873 military museum, 569 museum ship, 513 historic house museum, 181 maritime museum, 151 musée de France, 119 aviation museum, 80 natural history museum, 68 science museum, 57 open-air museum, 48 railway museum, 37 local museum, 37 children's museum

In addition, the following types may be interesting:

• There are 40k+20k names: 40038 family name, 10320 given name, 5569 male given name, 4828 female given name.
  • Due to the good efforts of the WikiProject "Wikidata names", these items provide valuable information on names themselves, e.g. variations, male/female correspondences, etc.
  • This can probably be used for disambiguation or for generating language-specific name variants, but we have not investigated this topic
• Some 500k Creative Works: 154125 album, 140820 film, 59242 single, 51765 book, 31623 painting, 23055 scientific journal, 20032 song, 26789 video game, 18338 television program, 14838 short film, 13461 television series, 13098 silent film, 11876 periodical literature, 11297 episode, 6739 literary work, 6627 television season, 3488 sculpture, 2374 manuscript
• Some 110k heritage sites and monuments: 64806 Rijksmonument, 21076 Iranian National Heritage, 19696 scheduled monument, 1370 natural monument, 1150 World Heritage Site. This is expected to grow sharply for other countries as well.

The link given above also reports various defective classes.

Now we turn to checking what person names (labels) are provided in Wikidata.

• Preferred names are repeated as rdfs:label, skos:prefLabel, schema:name
• Alternate names are in skos:altLabel

Some of the original strings differed only by punctuation, eg

• Lucas Cranach "el Vell" vs Lucas Cranach el Vell vs Lucas Cranach, "el Vell"
• Lucas Cranach o Velho vs Lucas Cranach, o Velho
• Кранах Лукас Старший vs Кранах, Лукас Старший

The comma is often used to indicate last, first name inversion (a variant used "for indexing"). But we cannot rely on it:

• "Lucas Cranach, o Velho" shows the comma is sometimes used for other purposes
• "Кранах Лукас Старший" shows the comma is not consistently applied to name inversion

So we removed the punctuation chars ,." and ended up with 70 Wikidata name forms for Cranach: ./cranach-wikidata.txt. Examine the file to get a feel for the names.

Wikidata includes names in a variety of languages.

• Lang tags are included for all languages, which is valuable

There are 57 unique lang tags, representing 44 languages and 13 language variants (e.g. de=German vs de-ch=Swiss German):

• af arz az be be-tarask bg br ca cs da de de-ch el en en-ca en-gb eo es eu fa fi fr ga hu hy it ja ka ko la lt lv mk nb nl nn pl pt pt-br ro ru sh sr sr-ec sr-el stq sv sw th uk zh zh-cn zh-hans zh-hant zh-hk zh-sg zh-tw

Only 3 of the language variants are truly distinct:

• zh-hans (Chinese Han Simplified) vs zh-hant (Chinese Han Traditional); be (Belorussian) vs be-tarask (Belorussian Taraskevica); sr=sr-ec (Serbian Cyrillic) vs sr-el (Serbian Latin)

The other language variants carry the same name string, e.g.:

• en, en-ca, en-gb; de, de-ch; pt, pt-br; zh, zh-cn, zh-sg

Observations on prefLabel and altLabel:

• There is a single prefLabel per language, following SKOS recommendations
• If the lang tag is taken into account, prefLabels and altLabels are disjoint
• But if you discount the lang tag, many of the altLabels are redundant. e.g. the German prefLabel "Lucas Cranach der Ältere"@de is repeated as altLabel for languages: lt lv nl pt stq sv.
• If you discount the lang tag, some of the prefLabels are also redundant

Ontotext started using Wikidata in commercial applications since mid-Dec 2014, so we have a good feel about the quality of different data elements:

• Labels (names) are almost universally good
• Descriptions are sensible, though short, not authoritative, and often missing. Descriptions can be used only to disambiguate two items with the same name, but not to provide info about the item
• Linkage to different Wikipedias, Wikimedia Commons and other Wikimedia sites is always good
• Direct types ("instance of") are accurate for most of the entities in 2.1.4
• The set of properties is good. There are established property proposal editorial practices, based on a detailed proposal template followed by discussion and "voting". e.g. see properties for Authority Control). If after some time there are some supporters, but no or very few opponents, the property is created only by a property creator or an administrator. All discussion, decisions and their rationale are preserved. Defined property metadata is collected, including guidelines for use (e.g. on what items it should be applied), to which register or authority file it corresponds (if any), examples, format validation, uniqueness constraints, lists of known exceptions, etc. e.g. see GND identifier.

• These constraints are used to discover violations, which can drive coreferencing and merging/splitting investigations. e.g. see violations for GND identifier.
• Nevertheless, the overall property design is still in flux. e.g. there is a current proposal to eliminate a number of properties such as place/date of birth/death/burial and replace them with a generic "significant event" where details are provided with qualifiers.
• The class hierarchy is not good at all. The reason is that there is no editorial control over "instance of" and "subclass", so anyone can "make" a class. 63% of all classes have fewer than 5 instances. Play with the Wikidata Generic Tree 2.1.1.3 to see some very idiosyncratic classes, and a messed up hierarchy. Just a couple of examples:

  location> geographic location> facility> laboratory> lab-on-a-chip

  But "lab-on-a-chip" is a "device that integrates one or several laboratory functions on a single chip of only millimeters to a few square centimeters in size", hardly a "geographic location"

  location> storage> data storage device> audio storage device> album

  Any NER implementor will balk at "albums are locations". The everyday understanding of "location" as "place" is implemented as the subclass "geographic location". But nevertheless, an "album" is a creative work, and as such is a conceptual object that persists even after all its copies are destroyed. It's definitely not a "storage device"

Here we summarize some important points about the future data freshness of Wikidata

• Most Wikidata data (labels and links) was originally extracted from Wikipedia
• Wikipedia inter-language links are maintained in Wikidata, and are therefore authoritative in Wikidata
• The idea is that all Wikipedias will gradually transition to using data from Wikidata. However, this is still long coming
• Articles are added to Wikipedia all the time and names are added/edited, and similarly items are added and labels are edited in Wikidata. This can lead to desynchronization between the two
• There are bots that can transfer Articles and names from Wikipedia to Wikidata, but we have not investigated whether that happens regularly, especially for minor-language editions
• In the converse direction, we are not yet aware of tools to create a Wikipedia article stub from Wikidata

• The Freebase URL for Cranach is http://www.freebase.com/m/0kqp0.
• An "almost Turtle" file is available at http://rdf.freebase.com/m/0kqp0, but some fixes are needed:
  • Replace hex escape sequences \x in literals with unicode escape sequences \u00
  • Replace dollar escapes in URLs with proper URL escaping
  • Replace the quotes surrounding literals ("…") with triple quotes """…""" since some literals include quotes
• Freebase provides 32 names for Cranach (./cranach-freebase.txt), all with language tags

[1] presents very comprehensive statistics (p.12 table 2). The most recent version of these statistics is online. EN DBpedia being the first and largest language editions is taken as Canonicalized Data ("CD") (namespace http://dbpedia.org/resource; there is no namespace http://en.dbpedia.org/resource). Other editions are called Localized Data ("LD"). EN DBpedia provides the following number of entities:

• 1,445k persons
• 735k places
• 241k organizations
• 411k creative works: 123k music albums, 87k films, 19k video games…
• 252k species; etc
• 4,584k total

The total number across editions is harder to calculate since it depends on the degree of cross-language overlap popular entities appear in many editions, while purely "local heroes" may appear in a single edition. The numbers grow to:

• 1,471k persons
• 818k places
• 266k organizations
• 462k creative works
• 279k species; etc

Please compare to Wikidata Counts 2.1.4. We estimate that national editions add 15% more entities and perhaps 50% more labels (names)

To understand the dynamics of DBpedia, one should understand raw properties vs mapped properties and classes, which is described really well in [1]. In brief, the process is as follows:

• Extracts all properties from all significant templates applied to the article. These properties are different for every language edition and are spelt in the national language, so they are called raw. Various heuristics are applied to recognize dates, numbers, links. No type information is applied here, which leads to some problems, e.g.:
  • The name of the asteroid 1111 Reinmuthia is extracted as dbpprop:name 1111 (xsd:integer) because of a heuristic "if the field starts with an integer, assume it's an integer"

  • A template field like

    firstAscent = [[John Smith]], [[England|English]] expedition [[1 May]] [[1941]
    firstAscent = in [[Prehistory]]
    
    

    will extract resources of variegated types: person, country, notable month-day, notable year, and historic period.

• Extracts a number of other characteristics, e.g. all used templates and categories, links, redirects, abstract (text before the first heading), geographic coordinates, etc
• Reads crowd-sourced class and property definitions and mappings from http://mapping.dbpedia.org
• Computes mapped properties from the raw properties and mappings. There is no editorial process in the mapping wiki, so there are significant defects, especially for languages other than English. This involves:
  • Classes, e.g. non-sensical class like VicePresident
  • Properties, e.g. DBpedia has no less than 86 "name" properties of which about half should be eliminated
  • Mappings. The problems here are most extensive and vary from non-standard properties (e.g. sex="a" on bg.dbpedia to indicate Female) to mixing the predecessors/successors of a public official across several terms (pl.dbpedia)

Because domains & ranges are not used when extracting raw properties nor checked when mapping, this leads to data problems. e.g. the firstAscent template property (see above) is mapped to two:

• firstAscentYear a owl:DatatypeProperty; rdfs:range xsd:gYear
  • Will get value 0001 since that's the first number that appears (instead of 1941)
• firstAscentPerson a owl:ObjectProperty; rdfs:range Person
  • Will get values dbr:John_Smith, dbr:England, dbr:1_May, dbr:1941, dbr:Prehistory, of which only 1 is a Person!

Mapping problems also lead to class errors. For example:

• dbr:United_Nations has type dbo:Country instead of dbo:Organisation
  • On enwiki United_Nations uses Infobox_Geopolitical_organization
  • The mapping Infobox_Geopolitical_organization has mapToClass = Organisation
  • however the template Infobox_Geopolitical_organization on enwiki is redirected to Infobox_Country.
  • So the mapping Infobox_Geopolitical_organization is disused, but the mapping wiki does not warn about it
  • We need to merge the mapping Infobox_Geopolitical_organization into the mapping Infobox_Country, discriminating on some field (e.g. org_type) whether to emit class Organisatin, GeopoliticalOrganization or Country. See more details in discussion
• bgdbr:Лили_Иванова, the icon of Bulgarian pop music with 53 years on stage and still going, until recently was mapped to Band (and thus Organisation) instead of MusicalArtist (and thus Person). The reason is that the mapping Музикален_изпълнител (Musical Artist) mapped all cases to Band. Now we distinguish between several cases (translated here from BG to EN for easier understanding):
  • if "members", "former members", or "established" is set -> Band
  • if "background" is "quartet", "ensemble", "choir" -> Band
  • if "background" is "composer" -> MusicComposer
  • if "background" is "director" -> MusicDirector
  • if "background" is "she-singer" -> MusicalArtist & gender = Female
  • if "background" is "he-singer" -> MusicalArtist & gender = Male
  • if "suffix" is "a" -> MusicalArtist & gender = Female
  • else -> MusicalArtist & gender = Male

There are very many cases like this that need to be investigated and resolved.

Discrepancies in type, gender, agenthood have serious negative impact on Enrichment.

These problems have seen a lot of attention lately, see forum and tracker

• The formation of a DBpedia Ontology Committee is foreseen
• This will be one of the important points for the upcoming DBpedia meeting 9th February 2015, Dublin, Ireland; with topics like:
  • Break Out Session 3 The new DBpedia Ontology
  • DBpedia Ontology and Extractor Problems
  • DBpedia in Web Protege, by Alexandru Todor
  • Discussion on the new ontology editing workflow and future directions of the DBpedia ontology

The latest download was extracted in Aug/Sep 2014. This includes directories for 124 language editions:

• af als am an ar arz ast az ba bat_smg be be_x_old bg bn bpy br bs bug ca ce ceb ckb cs cv cy da de el en eo es et eu fa fi fr fy ga gd gl gu he hi hr ht hu hy ia id io is it ja jv ka kk kn ko ku ky la lb lmo lt lv map_bms mg mk ml mn mr ms my mzn nap nds ne new nl nn no oc pa pl pms pnb pt qu ro ru sa sah scn sco sh si simple sk sl sq sr su sv sw ta te tg th tl tr tt uk ur uz vec vi vo wa war yi yo zh zh_min_nan zh_yue

Notes:

• "simple" is a kind of English, used in the Simple English Wikipedia, where articles are written with a repertoire of a couple thousand words only
• "commons" is an extract from Wikimedia Commons, which includes metadata for 15M freely reusable images, diagrams and multimedia
• "links" provides cross-references to various other datasets

If you look at one of the editions e.g. EN, you'll see a daunting picture: 162 files of size 37.6Gb zipped. But they come in quadruples, eg

If your triplestore can handle Unicode IRIs and you don't care about this fine-grained provenance, use the last one (ttl) only.

An excellent description of the downloads is available, although a few of the files are not listed there.

• It presents the files in a logical sequence and has some description
• There is a preview of each file: the first 100 lines, anchored at "?".
• It shows at a glance which files are not available for download for a particular language, eg

For example, images (links from DBpedia resources to Commons images) were missing fo BG. But they are important for bg.dbpedia, we took care to generate them.

A rather unique feature of DBpedia is DBpedia Live. It can provide RDF updates tracking the minutely edits on Wikipedia, Wikipedia infoboxes, and the Mapping wiki too. A stream of changes is generated and a Synchronization Tool is provided, which makes it easier to deploy a continuously updating RDF server.

The datasets loaded on dbpedia.org include:

• 27 en files: article_categories category_labels disambiguations external_links freebase_links geo_coordinates geonames_links_en homepages images infobox_properties infobox_property_definitions instance_types instance_types_heuristic interlanguage_links_chapters iri_same_as_uri labels long_abstracts mappingbased_properties_cleaned page_ids persondata redirects_transitive revision_ids revision_uris short_abstracts skos_categories specific_mappingbased_properties wikipedia_links
• labels, short and long abstracts in the following additional 11 languages:
  • ar, de, es, fr, it, ja, nl, pl, pt, ru, zh
• 37 linkset files to external datasets, including opencyc, umbel, yago

Names found in a language edition are not necessarily limited to that language.

Unfortunately DBpedia lang tags on fields other than rdfs:label are sometimes missing or unreliable. The reason is that some national mappings don't specify a language tag adequately.

Just like Wikipedia, DBpedia has different language editions. The inter-language links generate owl:sameAs statements across the editions. Let's try this query on http://dbpedia.org/sparql:

select * {dbpedia:Lucas_Cranach_the_Elder owl:sameAs ?x}

Note: although sameAs is supposed to be symmetric (actually an equivalence), this returns more results than the following query:

select * {?x owl:sameAs dbpedia:Lucas_Cranach_the_Elder}

This returns results like

http://rdf.freebase.com/ns/m.0kqp0
http://wikidata.org/entity/Q191748
http://wikidata.dbpedia.org/resource/Q191748
http://yago-knowledge.org/resource/Lucas_Cranach_the_Elder
http://sw.cyc.com/concept/Mx4rvXh1w5wpEbGdrcN5Y29ycA

http://af.dbpedia.org/resource/Lucas_Cranach_die_Ouere
http://arz.dbpedia.org/resource/لوكاس_كراناك_الاكبر
http://az.dbpedia.org/resource/Lukas_Kranax_(böyük)
http://be.dbpedia.org/resource/Лукас_Кранах_Старэйшы
http://be_x_old.dbpedia.org/resource/Люкас_Кранах_Старэйшы
http://bg.dbpedia.org/resource/Лукас_Кранах_Стари

See ./dbpedia-sameas.txt for the full set of owl:sameAs for Cranach.

• The first few are links to Freebase, Wikidata (one correct URL and another "bastardized" by DBpedia), Yago Knowledge 2.7 and Open Cyc
• The rest are the interlanguage links.

The sameAs do not return extra data on http://dbpedia.org, e.g.:

select * {<http://de.dbpedia.org/resource/Lucas_Cranach_der_Ältere> ?p ?o}
select * {<http://bg.dbpedia.org/resource/Лукас_Кранах_Стари> ?p ?o}

The labels and abstracts in the 11 additional languages are attached to the en URLs.

Wikipedia redirect page goes to the target of the redirect. e.g. http://en.wikipedia.org/wiki/Cranach,_Lucas_the_Elder goes to the page about Cranach. A redirect may point to another redirect, but the DBpedia extractor chases all redirects to their ultimate target.

• DBpedia implements a similar redirect: http://dbpedia.org/resource/Cranach,_Lucas_the_Elder goes to the DBpedia resource/page about Cranach

However, DBpedia also includes statements that we can use:

select * {?x dbpedia-owl:wikiPageRedirects+ dbpedia:Lucas_Cranach_the_Elder}

returns all EN redirects for Cranach, which are:

http://dbpedia.org/resource/Cranach,_Lucas_the_Elder
http://dbpedia.org/resource/Cranach_the_Elder
http://dbpedia.org/resource/Lucas,_the_Elder_Cranach
http://dbpedia.org/resource/Lucas_Cranach,_Sr.
http://dbpedia.org/resource/Lucas_Cranach_der_%C3%84ltere
http://dbpedia.org/resource/Lucas_Cranach_der_Aeltere
http://dbpedia.org/resource/Lucas_Cranach_der_Altere
http://dbpedia.org/resource/Lucas_Cranach_the_elder
http://dbpedia.org/resource/Lucas_Muller
http://dbpedia.org/resource/Lucas_the_Elder_Cranach
http://dbpedia.org/resource/Lucius_Cranach_the_Elder
http://dbpedia.org/resource/Lucius_Cranach_the_elder

Let's check the first one:

describe <http://dbpedia.org/resource/Cranach,_Lucas_the_Elder>

It returns a number of statements, of which the most important are:

<http://dbpedia.org/resource/Cranach,_Lucas_the_Elder> rdfs:label       "Cranach, Lucas the Elder"@en .
<http://dbpedia.org/resource/Cranach,_Lucas_the_Elder> dbpedia-owl:wikiPageRedirects dbpedia:Lucas_Cranach_the_Elder ;

Not all redirects provide alternative names for an entity (e.g. https://en.wikipedia.org/wiki/God_does_not_play_dice goes to the page Albert_Einstein, although this is something he said, not an alternative name for him). But most provide alternative names, so we can use them:

select ?x {[] dbpedia-owl:wikiPageRedirects <http://dbpedia.org/resource/Lucas_Cranach_the_Elder>;
  rdfs:label ?x}

Because redirects are resolved to the ultimate target, we don't need to use a property path "+" (Kleene closure)

Different editions use different raw properties for names. A lot of them but not all are mapped to standard properties, because name properties are not always used consistently across DBpedia mappings. We explored the different name properties on en, fr, de DBpedia and came up with a query like this:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
prefix dbo: <http://dbpedia.org/ontology/>
prefix prop: <http://dbpedia.org/property/>
prefix prop-de: <http://de.dbpedia.org/property/>
prefix prop-fr: <http://fr.dbpedia.org/property/>

select ?x ?p ?n {
  {?x dbo:wikiPageRedirects <http://dbpedia.org/resource/Lucas_Cranach_the_Elder>; rdfs:label ?n} union
  {<http://dbpedia.org/resource/Lucas_Cranach_the_Elder> ?p ?n.
    filter (?p in (
    foaf:name, foaf:givenName, foaf:surname, foaf:familyName, rdfs:label, skos:prefLabel, skos:altLabel, dbo:birthName,
    prop:birthName, prop:name, prop:title,
    prop-de:name, prop-de:alternativnamen,
    prop-fr:nom, prop-fr:commonsTitre, prop-fr:nomDeNaissance,
))}} order by ?x ?p ?n

Note: unfortunately some DBpedia endpoints (e.g. Italy) don't support SPARQL 1.1.

Using this query across several national DBpedias (or a variant with sameAs on the LOD Cache 2.9), we collected 43 names for Cranach: ./cranach-dbpedia.txt

Mapped name properties include:

foaf:name, foaf:givenName, foaf:surname, foaf:familyName, rdfs:label, skos:prefLabel, skos:altLabel, dbo:birthName

You may wonder why do we need "raw" properties like these:

prop:birthName, prop:name, prop:title,
prop-de:name, prop-de:alternativnamen,
prop-fr:nom, prop-fr:commonsTitre, prop-fr:nomDeNaissance

The answer is that some templates take care to map all name properties, but others don't. Here we find people with the raw property prop:birthName that don't have the mapped property dbo:birthName

prefix dbo: <http://dbpedia.org/ontology/>
prefix prop: <http://dbpedia.org/property/>
select * {
  ?x prop:birthName ?n
  filter (lang(?n)="en" &&
    !(str(?n) in ("?", "???", "Unknown", "unknown")) &&
    not exists {?x dbo:birthName ?n})}

• The raw property grabs anything it finds in the template field. If you remove the condition lang(?n) you'll see all kinds of junk, from dates to families.
• language tags are fixed to en (by default), so are not reliable. e.g. "Никола́й Ива́нович Буха́рин"@en is in Russian not English

VIAF uses sophisticated matching and clustering algorithms [3] to match named entities across name authorities. These include people, organizations, conferences, places, works, expressions (e.g. a certain edition or translation of a work), subject headings, etc. VIAF is somewhat conservative in not making possible matches that are not warranted by sufficient information.

VIAF cluster IDs are relatively stable, but when monthly updates are received from the contributing institutions, it is possible that an authority record is reassigned to another VIAF cluster, or two VIAF clusters are merged, or a VIAF ID is abandoned. Nevertheless VIAF makes everything possible to preserve IDs:

• when a new cluster is formed, it first seeks to reuse an abandoned ID that was previously used for some of the records in the cluster
• when an ID is abandoned, leaves a redirect to the surviving cluster that holds most records from the abandoned cluster

Recent VIAF counts are provided in the 2014 Annual Report. The number of VIAF clusters is as follows (also see 4 for breakdown per VIAF member):

• Personal: 35,163,929
• Corporate/conferences: 5,425,304
• Geographic: 416,316
• Work: 1,685,745
• Expression: 287,211

Also interesting are the numbers on p6, in particular:

• Wikipedia/Wikidata: 1,135,025 Person records imported, of which 37% are matched

To appreciate the size, we reproduce an image from [6] that compares VIAF with Wikidata (thus indirectly DBpedia):

Please compare to 2.1.4, which counts "human" items in Wikidata as 2.7M.

• This is lower than on the graphic, but higher than the number on p6 (how were these 1.1M records selected?)

VIAF has a basic search at http://viaf.org/, and an advanced (SRU-based) search at http://viaf.org/viaf/search/.

If you search for "Personal name: Lucas Cranach" you may find:

• (top) a main cluster http://viaf.org/viaf/49268177 that carries a lot of info and is the result of matching many source records (including from DNB)
• (middle) 31 persons who are either related to Cranach (e.g. Maximilian I Holy Roman Emperor, painted by Cranach in 1509), or share a name
• (bottom) two stand-alone (singleton) clusters (coming from DNB):
  • http://viaf.org/viaf/308208350 from DBN: "Cranach, Lucas d. Ä. oder d. J." (The Elder or The Younger), to be used for works with unclear attribution to the father or the son
  • http://viaf.org/viaf/238031633 from DNB: "Cranach, Lucas"‏ marked (undifferentiated) (sparse), for which there is too little info to warrant a match.
  • http://viaf.org/viaf/96020412 from ULAN: which has this note: "Given that the name is rather common, it is uncertain whether or not this artist is identifiable as one of the two famous artists named "Lucas Cranach."

VIAF is conservative in matching: even though the names of these clusters match, there are no years, so VIAF does not cluster them.

The main Cranach cluster has 44 Works, several download formats in Record Views, and 71 names: ./cranach-VIAF.txt.

The RDF is at http://viaf.org/viaf/49268177/rdf.xml and is available here in Turtle for easier understanding: ./cranach-viaf.ttl. It follows a dual approach as explained in [7] sec 3.3. An abbreviated version follows:

<http://viaf.org/viaf/49268177/> a foaf:Document ;
  void:inDataset     <http://viaf.org/viaf/data> ;
  foaf:primaryTopic  <http://viaf.org/viaf/49268177> .

<http://viaf.org/viaf/49268177> a schema:Person ;
  schema:alternateName   "Sunder-Maler, Lucas" , "Müller, Lukas" ...;
  schema:birthDate       "1472-10-04" ;
  schema:deathDate       "1553-10-16" ;
  schema:description     "German painter, draftsman, and printmaker, 1472-1553" ;
  schema:familyName      "קראנאך" , "Cranach" , "Кранах" ;
  schema:givenName       "Лукас" , "Lucas" , "לוקאס האב" , "Lucas the Elder (studio of)" ...;
  schema:name            "Кранах, Лукас" , "קראנאך, לוקאס, האב (סדנת)" , "Cranach, Lucas, the Elder" ...;
  schema:sameAs          <http://data.bnf.fr/ark:/12148/cb12176451h#foaf:Person> ,
                         <http://dbpedia.org/resource/Lucas_Cranach_the_Elder> , <http://d-nb.info/gnd/118522582> ,
                         <http://www.idref.fr/028710010/id> , <http://libris.kb.se/resource/auth/182422> ;
  foaf:isPrimaryTopicOf  <http://en.wikipedia.org/wiki/Lucas_Cranach_the_Elder> .

<http://viaf.org/viaf/sourceID/BNF%7C12176451#skos:Concept> a skos:Concept ;
  rdfs:seeAlso     <http://catalogue.bnf.fr/ark:/12148/cb12176451h> ;
  skos:altLabel    "Cranach der Ältere Lucas 1472-1553" , "Cranach Lukas 1472-1553" , "Cranach l'ancien Lucas 1472-1553"...;
  skos:exactMatch  <http://data.bnf.fr/ark:/12148/cb12176451h> ;
  skos:inScheme    <http://viaf.org/authorityScheme/BNF> ;
  skos:prefLabel   "Cranach, Lucas, 1472-1553." ;
  foaf:focus       <http://viaf.org/viaf/49268177> .

• The central node is a schema:Person, having birth/death dates, names, anternate names, even given/family names (though "studio of" is hardly a given name)
• The Person is declared owl:sameAs all coresponding nodes in contributing organizations that have an appropriate type (e.g. foaf:Person for BNF, dbo:Person for DBPedia)
• There are two documents (the VIAF page and Wikipedia page) that point to the Person using foaf:primaryTopic.
• There is a skos:Concept for each of the contributor nodes (members of the cluster) that points to the Person using foaf:focus
• These Concepts hold the prefLabel and altLabels as determined by the contributing institution
• VIAF doesn't have language tags, which is an omission

Overall, this structure is perfectly correct and provides both a lot of names, and also a lot of links

VIAF provides monthly dumps at http://viaf.org/viaf/data/ (this file is RDFa, i.e. both human and machine readable description). The following files are of interest to us, of which we analyze the first and load the second to a repository:

The average compression is 4.8x. The files are pretty large, but manageable (unzipped: links.txt 2Gb, clusters-rdf.nt 40G)