GND-ID als data property

[hauschke]

GND-IDs sind weit verbreitet, die Daten stehen als CC0-lizenzierter Dump zur Verfügung. Sowohl für Autoren-IDs, als auch für Schlagwörter, Organisationen oder Konferenzen. Daher ein Vorschlag:

:gndID label: GND-ID property group: identity domain: Hier müssten wir überlegen, ob wir unterschiedliche für Personen etc. anlegen. Aber eigentlich könnte man das generisch halten und darauf verzichten? Andere Option: foaf:agent.

[tawahle]

Ich schlage vor als Domain die Klasse foaf:Agent festzulegen und weitere Klassen wie z.B. event:Event oder auch bibo:Document usw. über owl:Restriction hinzuzufügen.

[tawahle]

Wenn man die neue Property über einen File implementiert, kann man verschiedene Klassen als Domain über owl:unionOf zusammenfassen, aber das funktioniert in VIVO leider nicht immer. Ich hatte das für VIVO-KDSF gemacht, und es hat erst funktioniert, dann aber irgendwie nicht mehr und ich weiß nicht, warum ... Für einige Properties, die in VIVO per Default vorhanden sind, sind solche "generische" Domains definiert. In dem Fall sieht man in dem Property Control Panel beim Domain gar nichts ... Und über die Oberfläche geht es am besten mit owl:Restriction, owl:allValuesFrom / owl:someValuesFrom usw.

[annakasprzik]

Das hieße also, die Property :gndID mit einer domain zu versehen, die über eine Restriction definiert ist, und zwar als Union von foaf:Agent, event: Event, bibo:Document, und weiteren. Alternativ, ginge das auch über eure Faux Properties (also eine Art operator overload)?

[tawahle]

Ja, das ginge auch über Faux Properties... Dann müsste man für jede weitere benötigte Klasse eine Faux Property erstellen.

[tawahle]

Alternativ könnte man als Domain einfach obo:Continuant die obo:IndependentContinuant und obo:GenericallyDependentContinuant als Unterklassen hat, die widerum einerseits foaf:Agent und andererseits bibo:Document umfassen. Aber in dem Fall hätten auch ganz andere Dinge die GND-ID, und das müsste vielleicht nicht sein.

[Stefan-Wolff]

In der VIVO-Instanz des Arthistoricums haben wir neben anderen IDs auch die GND-Nummer ergänzt. In diesem Fall haben wir sie wie folgt abgebildet:

Data Property (string) Label (de): GND-Identifikator Label (en): GND identifier Property Group: identity Local name: GND-Identifier Domain: -

[tawahle]

Und Domain?

[tawahle]

Ah, als none specified?

[Stefan-Wolff]

Genau, die Domain hatten wir nicht eingeschränkt.

[Stefan-Wolff]

Verwendung findet sie in diesem Fall für Personen, Werke und Sachgruppen.

[tawahle]

Dann taucht die Property aber nicht bei den benötigten Klassen auf... Was aber auch nicht stört, wenn man die Daten nicht über die Oberfläche eingibt.

[Stefan-Wolff]

Das ist richtig - Ich habe noch mal nachgeschaut: Als "GND-Identifier" haben wir sie tatsächlich auch nur für Personen importiert. Bei den anderen beiden Entitäten ist sie lediglich in der URI enthalten. Für diesen Fall würde die Einschränkung auf foaf:agent also keine Probleme machen.

Ich würde mich freuen, wenn wir dazu einen Konsens erzielen würden. Dann könnte ich diese Property aus der lokalen Ontologie-Erweiterung streichen und dafür die VIVO-DE-Ontologie nutzen.

[tawahle]

Genau das ist auch unser Ziel! :-)

[tawahle]

Wir würden das gerne beim nächsten VIVO-DE-Ontology-Call diskutieren und gemeinsame Lösung erarbeiten, die in die VIVO-DE-Ontology einfließen soll.

[Stefan-Wolff]

Das können wir gern machen. Eine Frage möchte ich noch einwerfen, die wir uns damals auch gestellt hatten: Ist die GND-ID tatsächlich ein Attribut des Datensatzes oder redet man an dieser Stelle nicht eher von einer URI? Müsste man also einen Datensatz mit der GND-URI erstellen und diesen per sameAs verknüpfen? Unsere Ergänzung in der lokalen Ontologie war ein pragmatischer Ansatz, um die ID eindeutig als diese auszuzeichnen und mit wenig Aufwand anzuzeigen.

[tawahle]

Wir benutzen GND-ID auch als globale URIs für Personen, Events, Publikationen und Organisationen. Daher würde es auf den ersten Blick zumindest für uns wenig Sinn ergeben, Datensätze mit den lokalen VIVO-URIs zu erstellen und diese mittels owl:sameAs mit den Datensätzen mit den GND-ID als URIs zu verknüpfen. GND-ID als Attribut würde den Aussenstehenden, die den URI nicht sofort sehen, als Hinweis auf die entsprechende GND-Entität dienen. So sehe ich das. Aber das können wir gerne diskutieren.

[Stefan-Wolff]

Zur Frage der sameAs-Verknüpfung: Die GND-ID lässt sich nur dann als URI für die eigenen Datensätze verwenden, wenn die GND die einzige Datenquelle darstellt. Wenn es weitere Quellen gibt (z.B. manuelle Eingaben), die die GND-ID nicht enthalten, sie später durch Datenanreicherung aber ergänzt werden soll, stellt sich doch die Frage, ob ggf. die GND-ID als Attribut nachgetragen oder der Datensatz mittels sameAs verknüpft werden sollte. Zur Frage "GND-ID als zus. Attribut": Natürlich ist es günstig, die GND-ID als Angabe zum Datensatz anzuzeigen. Dazu ist es aber nicht notwendig, sie redundant zur URI auch als Attribut zu speichern. Dies ließe sich auch über das Template steuern.. .

[tawahle]

Ja, das stimmt beides! Wie gesagt, wie können das gerne besprechen und eine gemeinsame Lösung erarbeiten.

[hauschke]

Es werden zur Zeit verschiedene Identifier zur VIVO-Ontologie hinzugefügt. Ich halte es nicht für sinnvoll, für die GND einen Sonderweg zu gehen. Ich werde die GND als einen von verschiedenen neuen IDs vorschlagen, damit eine einheitliche Behandlung aller IDs in VIVO gegeben ist. Ticket: https://jira.duraspace.org/browse/VIVO-1663