Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

  • Wenn englischsprachige Property-Namen beibehalten werden sollen, müssten in vielen Fällen präkombinierte Bezeichnungen wie female_architect verwendet werden. Dies kann die Frage nach sich ziehen, warum das männliche Pendant lediglich architect und nicht male_architect heißt (und damit einen vermeintlichen Vorrang vor der weibliche Bezeichnung genießt).
  • Bei Personen unbekannten Geschlechts kann nur eine generische Form der Bezeichnung verwendet werden. Diese würde entweder mit der männlichen Form als generisches Maskulinum zusammenfallen oder es würden drei Properties, architect, male_architect und female_architect in der Ontologie deklariert werden müssen.
  • Wird in einem Personendatensatz die Geschlechterangabe geändert (Fehlerkorrektur oder Nachtrag eines zuvor unbekannten Geschlechts), wären alle Instanzen der betreffenden Property für diese Person ebenfalls zu ändern. Anderenfalls würden sich Widersprüche zwischen der Property-Aussage Aussagen und der Geschlechtsangabe Geschlechtsangaben im betreffenden Personendatensatz Widersprüche akkumulieren.

Wenn es darum geht, an Benutzeroberflächen geschlechtsspezifische Benennung zu verwenden, sollte die in der GND bereits vorhandene Information ausreichen, um entsprechende Display-Formen zu generierengenerieren zu können. Das Prinzip lässt sich anhand dieser CONSTRUCT-Abfrage verdeutlichen, in der wir Kölner Bauwerke mit einer Angabe des Architekten bzw. der Architektin oder des Architekturbüros versehen:

Codeblock
languagesql
themeEclipse
linenumberstrue
collapsetrue
PREFIX gnd: <http://d-nb.info/gnd/>
PREFIX gndo: <http://d-nb.info/standards/elementset/gnd#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX gndgender:<http://d-nb.info/standards/vocab/gnd/gender#>
PREFIX x: <_>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

CONSTRUCT 
{  [  	x:entworfen_von ?aname ;
        x:Bauwerk ?bauwerk ;
        x:in_Rolle ?rolle
   ]
}
WHERE 
{
  ?werkId gndo:architect ?agentId ;
      # gndo:place gnd:4112721-3 ; # Berlin-Steglitz
      gndo:place gnd:4031483-2 ; # Köln
      gndo:preferredNameForTheWork|gndo:preferredNameForThePlaceOrGeographicName ?bauwerk .
  ?agentId gndo:preferredNameForThePerson|gndo:preferredNameForTheCorporateBody ?aname 
  OPTIONAL { ?agentId gndo:gender gndgender:female ; BIND("Architektin" as ?rolle) }
  OPTIONAL { ?agentId gndo:gender gndgender:male ; BIND("Architekt" as ?rolle) }
  OPTIONAL { ?agentId gndo:gender gndgender:notKnown ; BIND("Architekt" as ?rolle) }
  OPTIONAL { FILTER(NOT EXISTS {?agentId gndo:gender ?g}) . BIND("Architekten" as ?rolle) }
}
LIMIT 50 

In diesem Ansatz werten wir die neutrale Property gndo:architect aus und gewinnen eine geschlechtsspezifische Aussage mittels der Angabe im Personendatensatz. Änderungen der gndo:gender-Angabe zur Person wirken sich damit unmittelbar auf die Darstellungsform der Tätigkeit aus.

Die Unterscheidung zwischen den Benennungen erfolgt hier im Anwendungskontext. Damit bedarf es weder einer Ausweitung der Axiome in der GND-Ontologie noch einer der Wissensbasis in der GND.

Wie weit dieser Ansatz auf eine große Anzahl verschiedener Tätigkeitsbegriffe skaliert werden kann, hängt von der konkreten Implementierung ab. Da das geschlechtsspezifische Tätigkeitsvokabular in der GND bereits vorhanden ist, sollte es sich dabei vermeiden lassen, die Bezeichnungen wie in diesem Codebeispiel explizit für die Transformation anzugeben.