Abstrakte Wikipedia/Abstrakte Darstellung von Wikidata

Dies ist ein derzeit noch diskutierter Vorschlag für die abstrakte Darstellung natürlicher Sprache im engen Kontext von Konstruktoren und im weiteren Kontext des Projekts der Abstrakten Darstellung von Wikidata und der Generierung Natürlicher Sprache.

In diesem Vorschlag übernehmen wir als gemeinsame Grundlage den Inhalt des Artikels Architecture for a Multilingual Wikipedia von Denny Vrandečić.

Erstautor und Co-Autoren: Kutz Arrieta, Maria Keet, James Forrester, Ariel Gutman, Cory Massaro, Arthur Lorenzi.

Konstruktor-Einheit

Konstruktoren enthalten eine abstrakte Darstellung einer informationell vollständigen Prädikataussage. Normalerweise entsprechen sie einem einzelnen Renderer, dies ist jedoch keine zwingende Anforderung.

Es könnte auch Superkonstruktoren geben, die selbst Konstruktoren enthalten, z. B. entsprechend einer Gliederung eines Absatzes oder eines ganzen Artikels. Eine Verschachtelung von Konstruktoren ist grundsätzlich zulässig. Es ist auch denkbar, dass ein Konstruktor in mehr als einem Satz verbalisiert wird, um die Lesbarkeit zu verbessern (wie es auch im Beispiel im Abschnitt Gemeinsame Grundlage der Fall ist). Abhängig vom syntaktischen Kontext kann ein Konstruktor auch als Nominalsatz verbalisiert werden (z. B. "San Francisco ist die viertgrößte Stadt …", etc.) oder mehrere mögliche satzartige Realisierungen haben (z. B. gibt es im Deutschen einen Unterschied in der Struktur für eigenständige und eingebettete Sätze). All dies würde zum Zeitpunkt des Renderns passieren.

Die Anzahl der Konstruktoren wird wachsen, je mehr "Sprache" und Sprachen vertreten sind. Zukünftig könnten sie automatisch oder halbautomatisch von einem Parser generiert werden.

Wir gehen von Kompositionalität/Kombinatorialität aus. Konstruktoren werden zu größeren Einheiten zusammengefasst und unterliegen dabei formalen Änderungen einiger ihrer Elemente und Positionszuweisungen.

Konstruktor-Struktur

Als Leitprinzip gilt, dass das ursprüngliche System harmlose Fehler machen kann, um einen iterativen Korrekturprozess unter Einbeziehung der Beitragenden voranzutreiben.

Konstruktoren sollten keine syntaktischen, morphologischen, lexikalischen oder sprachspezifischen Informationen enthalten. Konstruktoren leben allerdings in einem Ökosystem mit anderen Komponenten, die sich gegenseitig beeinflussen und müssen möglicherweise entsprechend angepasst werden.

Prädikat (= Name/Typ des Konstruktors)

Dies ist der eher "verbale" Teil des Inhalts, der (in den meisten linguistischen Formalismen) oft als Verbalphrase bezeichnet wird. Dies ist der Kern der Aussage. Es wird als Aussage wiedergegeben, deren Kern ein Verb ist.

Im Kern handelt es sich um eine Beziehung (im logischen Sinne). Die spezifische Verbalisierung hängt vom Typ des Konstruktors und der spezifischen Sprache oder dem Ort ab.

In dem im Abschnitt Gemeinsame Grundlage erwähnten Beispiel ist "Ranking" das Prädikat und die tatsächliche Darstellung ist eine Instanz dieser Beziehung.

Ein Konstruktortyp, z. B. ein Ranking-Konstruktor, kann unabhängig von der einzelnen Stadt (oder Entität) existieren, sodass er für jede Stadt oder Entität verwendet werden kann, für die solche Daten verfügbar sind. [add reference to CoSMo]

Semantische Rollen & Lücken

Die Abstrakte Darstellung sendet Signale an die Renderer darüber, welche lexikalischen Entitäten (seien es benannte Entitäten, z. B. QIDs oder nicht) verbalisiert werden sollen und welche Prozesse in der syntaktischen Ebene ablaufen müssen. Diese Signale können sowohl den Lücken (Argumenten) als semantischen Rollen als auch den Prädikaten (Formalität, Sprechakte, etc.) zugeordnet werden.

Die in diesem Dokument zunächst vertretene Position besteht darin, explizit semantische Rollen (wie Agent oder Patient, obwohl die Terminologie abweichen kann) im Konstruktor zu verwenden. Diese dienen dann als Signale, die Renderer benötigen, um die geeigneten Lexeme auszuwählen und die richtige Sprachausgabe zu generieren.

In diesem Fall werden die mit jedem Prädikat verknüpften Lücken nach semantischen Rollen bezeichnet, unabhängig davon, ob sie primär oder sekundär sind.

Semantische Signale werden über die Pipeline gesendet und sollten in der Nachbearbeitung aufgelöst werden.

Es gibt mehrere semantische Frameworks / Ansätze zur semantischen Rollenkodierung, die wir hier verwenden könnten. Um nur einige zu nennen:

• Semantische Makrorollen, wie ACTOR und UNDERGOER (manchmal AGENT und PATIENT genannt). ACTOR kann mit allen Prädikaten genutzt werden, während UNDERGOER mit allen transitiven Prädikaten genutzt werden kann.
• Umfassendere Frameworks für semantische Rollen erlauben je nach Prädikat eine größere Vielseitigkeit beim Namen der Rolle. Zu solchen Rollen gehören Vorstellungen wie AGENT, PATIENT, EXPERIENCER, RECIPIENT, etc.
• Prädikatspezifische semantische Rollen, ähnlich wie Framenet. Beispielsweise definiert Framenet das Prädikat “Aufnahme” mit Rollen wie Aufnehmer, Aufnehmbar und Instrument. Beachte, dass das Prädikat “Aufnahme” verschiedenen Verben entsprechen kann (sogar in derselben Sprache), wie “essen”, “trinken”, “fressen”, etc.
• Ad-hoc-Argumente könnten für verschiedene verbale Prädikate definiert werden (möglicherweise in Zusammenhang mit bestimmten QIDs). Z. B. können wir für das Prädikat “Essen” (das mit Q213449 verknüpft werden könnte) Argumente wie Esser, Essen, Utensil definieren, je nach Bedarf für die Realisierung, etc. Dies ähnelt zwar der oben genannten Möglichkeit, ist aber ausdrücklich eher ad-hoc und versucht nicht, mehrere ähnliche Prädikate zu verallgemeinern.

Durch die Definition semantischer Rollen können wir auch zwischen oberflächlich identischen Prädikaten unterscheiden, zum Beispiel:

ORDER1

order [someone {patient} ] [to do X {object:verbal} ] [next week {time} ] [to fix Y {cause/purpose:verbal} ]

ORDER2

order [a sandwich {object} ] [in a restaurant {location/source} ] [to go {modality} ]

usw.

Grammatikalische Fälle sind die morphologische Umsetzung primärer semantischer Rollen durch Markierungen ihrer Rollen (häufig Suffixe), also ihr Rendering. Sie beziehen sich auf die syntaktischen Gegenstücke primärer semantischer Rollen. Für die korrekte Wiedergabe in natürlichen Sprachen sind diese Informationen aus folgenden Gründen erforderlich:

• In Sprachen mit einem reich markierten Fallsystem sind diese Informationen erforderlich, um die richtige Form der Lexeme auszuwählen, die die Rollen erfüllen, und manchmal auch um die geeignete Form des Verbs auszuwählen, da einige dieser Rollen möglicherweise in der Form des Verbs selbst dargestellt werden.
• In Sprachen mit einem nicht so reichen Fallsystem bestimmen diese Informationen die Position der Lücken in Aussagen und/oder werden über Präpositionalsätze wiedergegeben.

“Abhängigkeiten” oder Sekundäre Rollen

Präpositionalsätze, Adverbialsätze, Adjunkten und Postpositions-/Satzgruppen wird eine semantische Rollenfunktion zugewiesen. Diese werden je nach Sprache auf unterschiedliche Weise gerendert.

Wir unterscheiden zwischen primären und sekundären semantischen Rollen. Primäre Rollen beziehen sich direkt auf das Prädikat und sind daher Teil der Konstruktordefinition. Sekundäre Rollen könnten theoretisch zu jedem Konstruktor hinzugefügt werden.

Semantisch-Pragmatische Funktionen

Einige dieser Funktionen (z. B. Belebtheit, Menschlichkeit, Form - beispielsweise für japanische Quantoren) sollten in der lexikalischen Darstellung (d. h. lexikografische Daten von Wikidata) dargestellt werden. Diese Informationen ermöglichen es den Renderern:

• semantische Rollen den entsprechenden Lexemen zuzuordnen, die über rein syntaktische Überlegungen hinausgehen;
• die entsprechende Vereinbarung (oder Übereinstimmung) zwischen Lexemen anzuwenden.

In einer zweiten Phase des Projektes:

• Pragmatische Funktionen auf Diskursebene wie STATEMENT, WH-QUESTION, OPEN_ENDED QUESTION, etc. sollten in der Abstrakten Darstellung, im Konstruktor, enthalten sein, um die syntaktische Ebene zu signalisieren.
• Formalität und andere solche Signale sollten ebenfalls einbezogen und dem Prädikat selbst angefügt werden. Formalitätssignale sollten wahrscheinlich auch in den Vorlagen und Lexemen vorhanden sein.

Wir sollten hier auch Lücken einbeziehen, die Ausdrücke wie “wie es aussieht”, “soweit wir wissen” etc. enthalten, die Modifikatoren auf Satzebene sind und einen indirekten, aber sinnvollen Einfluss auf die Semantik der Aussage haben. Ihnen sollten Rollen zugewiesen werden.

Externe Referenz(en) des Konstruktors

Wie oben erwähnt, enthalten Konstruktoren keine sprachspezifischen Informationen wie Morphologie, Syntax, Lexikon, Inhaltsrealisierung, etc., müssen jedoch diese externen Komponenten berücksichtigen.

Inhalt

Der Inhalt verweist auf die Entitäten (QIDs oder Lexeme), auf die sich die Aussage bezieht. Der Inhalt verweist im Wesentlichen auf die Lexeme und QIDs, die die Lücken in den Aussagen füllen.

Syntaktische Ebene

Diese Ebene befasst sich mit Aspekten wie den grammatikalischen Funktionen des zu verwendenden Lexems (im Fall von Wikidata lexikalische Entitäten), der Reihenfolge, in der Komponenten/Lücken gerendert werden, und zusätzlichen Modifikationen, die diese Renderer möglicherweise vornehmen.

Diese Ebene ist kompositorisch: Sie enthält daher auch die Regeln, die erforderlich sind, um die verfügbaren Konstruktoren zu kombinieren oder nicht.

Diese Ebene enthält Signale, um die geeignete Auswahl von Lexemen gemäß morphosyntaktischen und phonotaktischen Regeln zu treffen. Sie werden von unterschiedlichen Funktionen und zu unterschiedlichen Zeiten gerendert.

Wenn die Vorlagensprache verwendet wird, stellt sie eine Verbindung zur abstrakten Darstellung und zur Kompositionssyntax her, sodass sie von der Orchestrierer-Komponente der Gesamtarchitektur von Wikifunctions verarbeitet werden kann.

Morphologische Ebene

Derzeit ist die Morphologie in Wikidata den lexikalischen Einheiten zugeordnet. Daher postulieren wir keine morphologische Ebene. Morphologische Funktionen müssen in die Darstellung der Lexeme einbezogen werden.

Lexeme sollten semantische Funktionen und alle anderen Funktionen enthalten, die die abstrakte Darstellung möglicherweise kodiert. Wir sollten keine exakte Übereinstimmung der Funktionen fordern, d. h. Funktionen überbewerten, die nicht benötigt werden. Beispielsweise können viele Nomen oder Einheiten mehrere Rollen erfüllen. Wir sollten über eine generische Funktion verfügen, die es diesen Objekten ermöglicht, Einschränkungen der Abstrakten Darstellung zu umgehen. In einigen Sprachen kann dasselbe Lexem praktisch jede Rolle erfüllen. Nehmen wir jedoch an, dass ein Lexem in der Ergativform nur die Rolle eines Agenten erfüllen kann. Wenn dieses Lexem sowohl die Merkmale Ergativ + Singular als auch Absolutiv + Plural aufweist, kann es die Rollen von Agent, Subjekt und Objekt erfüllen.

Präpositionen, Partikel und Postpositionen (und möglicherweise andere nicht-nominale Kategorien) müssen ihre Anhangseinschränkungen kodieren. Hier ist ein Beispiel:

Rolle: THEMA/ÜBER/SUBJEKT

Englisch: about {prep} (Einschränkungen: Nominalphrase / nominalisiertes Verb)

Deutsch: von {prep} (Einschränkungen: ……/ Dativ)

Baskisch: bidez {Postposition} {Instrumentalfall} (Einschränkungen: Nominalphrase / nominalisiertes Verb + Genitiv)

Wir müssen uns darauf einigen, wo und wie Regeln gespeichert werden sollen. Sie können als Funktionen oder deklarativ gespeichert werden. Der derzeitige Konsens scheint darin zu bestehen, so viel wie möglich deklarativ zu speichern.

Das Gewicht der Morphologie auf die Lexeme zu legen, ist wahrscheinlich der richtige Weg, da die abstrakte Wikipedia auf Beiträgen aus der Menge basiert, aber dies wird die Komplexität der Lexeme und möglicherweise des Orchestrierers erhöhen.

Der Aufbau einer morphologischen Ebene könnte genutzt werden, um verschiedene Formen von Lexemen zu generieren und zu übergenerieren (zur Bereinigung durch Sprecher), wenn Daten für eine Sprache eingeführt werden. Dies könnte Teil eines Werkzeugs sein, um das Hinzufügen neuer Sprachen zu erleichtern. [add link to Wikidata article-workshop]

Diskussionen

Fehlerhafte Eingaben in Konstruktoren

Wir sollten wahrscheinlich Hauptsignale von Sekundärsignalen trennen. Pluralität könnte eines der sekundären Signale sein. Wir sollten aber den semantischen Plural vom morphologischen Plural unterscheiden:

• Morphologischer Plural ist eine sprachspezifische Funktion, die in der Sprache offensichtlich ist (aufgrund der Flexion oder Übereinstimmung). Nicht alle Sprachen haben einen morphologischen Plural, weshalb wir uns dafür entscheiden könnten, diese Funktion im Konstruktor nicht zu markieren. Wenn wir aber möchten, dass Konstruktoren ausreichend abstrakt und für viele Sprachen wiederverwendbar sind, können wir uns dafür entscheiden, Pluralität in allen Fällen zu kennzeichnen und den Renderern die Entscheidung zu überlassen, was ignoriert werden soll.
• Semantischer Plural ist die Idee, dass eine Menge eine Vielzahl von Objekten enthält (z. B. könnten die Objekte mit einem Quantor wie “viele” oder “einige” verknüpft sein). Dies könnte im Konstruktor markiert werden. Ob es in einer bestimmten Sprache als Nomen im Plural, als Verbübereinstimmung im Plural oder überhaupt nicht realisiert wird, bleibt dem Renderer der jeweiligen Sprache überlassen.

Wir könnten Unterkonstruktoren haben, die sich mit Pluralität befassen. Designprobleme wie diese müssen gelöst werden.

Die Erstellung einer Reihe semantischer Rollen ist der sinnvolle Weg, jedoch sollten wir bedenken, dass Benutzer semantische Rollen möglicherweise nicht korrekt zuweisen können. Möglicherweise möchten wir abstraktere Konstruktoren erstellen, zum lexikalischen Modul gehen und die Verbprädikatstruktur überprüfen. Eine weitere Option wäre eine API und eine Dokumentation, die die Aufgabe sowie einen Überprüfungsprozess erleichtern.

Die Darstellung ist ein Wrapper und daneben gibt es eine Reihe von Einheiten und Informationen, und es ist Sache des Renderers, diese zu realisieren. Wir sollten Fälle finden, in denen wir die Informationen nicht wiederherstellen können.

Wenn der Konstruktor einem Renderer zugeordnet ist, wären die Rollen im Renderer implizit. Es wurde jedoch noch nicht entschieden, ob ein Konstruktor einem Renderer zugeordnet werden soll. In einem solchen Fall fügt der Benutzer ein Beispiel hinzu und die Rollen wären implizit im Beispiel enthalten. Es könnte jedoch riskant sein, sich auf Beispiele von Benutzern zu verlassen.

Es wird schwierig sein, eine introspektive Entscheidung zu treffen. Wir brauchen einen Mechanismus, um die Dinge, die wir nicht aufgenommen haben, wiederherzustellen: Liegt es an den Daten oder am Inhalt?

Die Gemeinschaft würde Konstruktorklassen wie bei einer Geburt erstellen. Siehe A Hierarchical Unification of LIRICS and VerbNet Semantic Roles, Abbildung 1 und A Hierarchy with, of, and for Preposition Supersenses, Abbildung 1. Es wären Rollen wie Actor erforderlich, da wir sonst die korrekte Zuordnung der Dinge in der Vorlage nicht vollständig überprüfen können.

Unterschiedliche Arten von Rollen

Verhindert irgendetwas die Koexistenz mehrerer unterschiedlicher Rollen? Wollen wir eine Situation verhindern, in der mehrere Konstruktoren für dieselbe Handlung existieren?

Beispielsweise könnte eine Darstellung für Essen im Framenet-Stil so aussehen

EAT ( role:EATER, role:THING_EATEN )

wohingegen eine Darstellung mit Makrorollen so aussehen könnte

EAT ( role:AGENT, role:OBJECT )

Dies ist wahrscheinlich eine unerwünschte Situation, aber möglicherweise unvermeidlich, wenn die Gemeinschaft beginnt, ihre eigenen Konstruktoren zu erstellen.

Man könnte leicht eine Hierarchie domänenspezifischer Rollen hinzufügen, um sie zu verwalten. Für das Beispiel: SubRole(Eater, Agent) funktioniert auch für SubRole(Predator, Agent) und so weiter. Die obligatorische Benennung durch Benutzer ist möglicherweise etwas zu viel, aber es kann nützlich sein, sie im Backend mit Werten von Framenet oder Verbnet zu füllen.

Andere Vorschläge

TBD

Beispiele

Dies sind ein paar zufällige Beispiele zum Testen dieses Vorschlags.

Beachte, dass die für diese Beispiele bereitgestellten abstrakten Darstellungen als Darstellungsvorschläge zu verstehen sind. Die Autoren dieses Dokuments haben weder über diese Darstellungen noch über den Vorschlag selbst einen Konsens erzielt. Beachte auch, dass sich diese Darstellungen nicht auf semantische Rollen beziehen, was einem der Grundprinzipien dieses Vorschlags widerspricht.

• Edith Eger ist die jüngste Tochter von Lajos und Ilona Elefánt, ungarischen Juden aus einem Gebiet, das zum Zeitpunkt ihrer Geburt in der Tschechoslowakei lag. Ihr Vater war Schneider.

Child[person=Edith Eger,father=Lajos Elefant,mother=Ilona Elefánt,rank=<last>]

->

child_renderer_en:"{Person}{Copula}the{Rank}{Lexeme(child)}of{father}and{mother}."

und z. B. ein Konstruktor auf “Typebene” wie

Child [ person = <a person>, father = <a person>, mother = <a person>, rank = <rank value> ]

damit wir Daten für alle Kinder und ihre Eltern abrufen und diese in Sätzen für jede [Kind,Vater,Mutter]-Kombination in den Daten rendern können?

Andere lose Enden, die irgendwo auf eine Liste gesetzt werden müssen, vielleicht als Teil der Beispiele, vielleicht auch nicht: Wie man den Konstruktor mit der Vorlage verknüpft, wie man sicherstellt, dass die richtigen Elemente aus dem Konstruktor mit dem richtigen Element aus der Vorlage übereinstimmen, wie beim Konstruktor für das Kind oben, wo wir z. B. folgendes haben

-> child_renderer_en_1: "{Person} {Copula} the {Rank} {Lexeme(child)} of {father} and {mother}."

oder

-> child_renderer_en_2: "{father} and {mother} had {Person} as the {Rank} {Lexeme(child)}."

aber nicht

child_renderer_en_wrong: "{father} {Copula} the {Rank} {Lexeme(child)} of {Person} and {mother}."

Jetzt in einer ersten Phase ignorieren, um darauf zu hoffen, dass dies vernünftig geschieht und es in einer zweiten Phase validiert wird? Kann/muss das in den Konstruktor oder die Vorlagensprache integriert werden? Sollte es überhaupt? Z. B. so, dass diese Person das Subjekt ist, aber das im Text realisiert wird, so dass child_renderer_en_wrong als falsch gekennzeichnet werden kann, wenn die Angabe aus UD/SUD/ähnlichem als {subj:father} verwendet wird, weil es beispielsweise subj:person im Konstruktor gibt?

-> child_renderer_en: "{Person} {Copula} the {Rank} {Lexeme(child)} of {father} and {mother}."

Ethnicity [ person = Edith Eger, ethnicities = < Jewish, Hungarian > ]

Location [ person = Edith Eger, place = Czechoslovakia, time = Birth [ person = Edith Eger ] ]

Birth [ person = Edith Eger, place = Czechoslovakia ]

Profession [ person = Lajos, profession = tailor ]

Hinweis: Das folgende Beispiel zeigt interessante linguistische Phänomene, wie ein nominalisiertes -ing (oder Gerundium), eine unpersönliche Passivkonstruktion, den Quantor beides und jede Menge Koordination.

• Gekocht wird sowohl von Menschen in ihren eigenen Wohnungen als auch von professionellen Köchen in Restaurants und anderen Gastronomiebetrieben.

Conjunct [ Cook [ chef = people, location = <home> ], Cook = [ chef = professional cook, location = restaurants ] ]

• Invasion of Privacy (Album)

Dies wäre und sollte eine QID sein. Aber wir sollten darüber nachdenken, wie andere mehr oder weniger lexikalisierte nominalisierte Strukturen dargestellt werden sollten.

Für die folgenden Beispiele wurde keine abstrakte Darstellung vorgeschlagen:

• Die Schwerkraft hat eine unendliche Reichweite, obwohl ihre Wirkung umso schwächer wird, je weiter die Objekte entfernt sind.
• Don't Starve ist ein Survival-Videospiel, das vom kanadischen Indie-Videospielentwickler Klei Entertainment entwickelt wurde.
• In der Linguistik ist eine Nominalphrase oder Nominalgruppe eine Phrase, die ein Nomen oder Pronomen als Kopf hat oder die gleiche grammatikalische Funktion wie ein Nomen erfüllt.

Das folgende Beispiel wurde im Scribunto-basierten NLG-System verwendet:

Gerenderter Text (Englisch):

Marie Curie was a Polish chemist and physicist. She was born 7 November 1867 in Warsaw and died 4 July 1934 in Passy. Marie Curie was a pioneer in the research of radioactivity. She researched radium. She was awarded the Nobel Prize in Physics in 1903, together with Pierre Curie and Henri Becquerel, for pioneering the research of radioactivity. She was awarded the Nobel Prize in Chemistry in 1911, for the discovery of polonium and radium. Marie Curie was the first woman to win the Nobel Prize.

Abstrakter Inhalt (Vorschlag):

Person { 
		person = "Q7186",
		birth = Birth {
	        	date = Date {
	            day = "7",
	            month = "11",
	            year = "1867",
	        },
	        place = "Q270",
	    },
	    death = Death {
	        date = Date {
	            day = "4",
	            month = "7",
	            year = "1934",
	        },
	        place = "Q388949",
	    },
	    origin = "Q36", -- Poland. Should be a list including France
	    occupation = List {
	    	_predicate = "List",
	    	first ="Q593644",  -- Chemist
	    	second = "Q169470", -- Physicist
	    }
	},
	Pioneer {
		person = "Q7186",
		in_what = Research { 
			research_field = "Q11448", -- Radioactivity
		},
	},
	Research {
		person = "Q7186",
		pronominalize = true, -- This should possibly done by a post-processor
		research_field = "Q1128",
	},
	AwardedPrize {
		person = "Q7186",
		pronominalize = true,
		prize = "Q38104",  -- Nobel prize in physics
		date =  Date {
	            year = "1903",
	    },
	    with = List { 
	    	first = "Q37463",
	    	second = "Q41269",
	    },
	    reason = Pioneer {
			person = "Q7186",
			in_what = Research { 
				research_field = "Q11448", -- Radioactivity
			},
		},
	},
	AwardedPrize {
		person = "Q7186",
		pronominalize = true,
		prize = "Q44585",  -- Nobel prize in physics
		date =  Date {
	            year = "1911",
	    },
	    reason = Discovery {
	    	discovery = List {
	    		first = "Q979",
	    		second = "Q1128"
	    		
	    	}
	    }
	},
	Rank {
		rank = 1,
		person = "Q7186",
		reference_group = "Q467",  -- woman
		activity = AwardedPrize {
			prize = "Q7191",  -- Nobel Prize
		}
	}