Und noch ein Fundstück: Die TIB hat ihren Terminology Service ausgebaut und in der NFDI4Culture verankert. Die Plattform dort heißt jetzt ANTELOPE und bietet einen „terminology search; entity linking“ Dienst. Mit ist nicht klargeworden, ob es wichtige Überschneidungen in Funktionalität und/oder Vokabularen mit SkoHub gibt. Soweit ich sehe, folgt die API keinem etablierten Standard (schade!), Exporte sind offenbar in JSON und CSV möglich. (Es wird wohl auch eine Präsentation auf der SWIB geben.)
Habt ihr das schon gesehen? Ist das wichtig für SkoHub?
Ich versuche die obige Frage mal in Kürze zu beantworten:
ANTELOPE ist keine Platform sondern ein Werkzeugkasten. Es geht bei antelope daher auch nicht vorrangig um die Verwaltung, erstellung und publizierung von Ontologien, wie bei SkoHub.
Stattdessen versuchen wir mit dem Service wichtige Funktionen die man bei der Arbeit im Bereich semantische Annotation benötigt an einer zentralen Stelle zur Verfügung zu stellen und die Komplexität auf ein Minimum zu begrenzen.
== Beispiel Usecases ==
Terminology Lookup:
Vor Beginn eines Projektes soll eine Ontologieauswahl erfolgen. Wir stellen hierzu Verbindungen zu verschiedenen Terminologiediensten her, in denen man dann gleichzeitig nach gewünschten Begriffen suchen kann (Lookup). Die gefundenen Entitäten werden dann in einem Klassenbaum dargestellt, so kann man z.B. schnell entscheiden ob man gerade die Entität zu „Mona Lisa das Gemälde“ oder „Mona Lisa das Musical“ angezeigt bekommt.
Entity Linking:
Im Projekt sollen Texte mit der gewählten Ontologie oder eigenen Terminologien verschlagwortet werden. Antelope stellt einfache Formulare und Api funktionen bereit um in den Texten die Wörter der Terminologie zu identifizieren. Der User kann dabei syntaktische Gleichheit der Wörter oder semantische Ähnlichkeit benutzen (Technisch realisiert durch Wordembedding modellen)
Image Recognition:
Neben der Verschlagwortung von Texten kann Antelope die Klassifikation und Verschlagwortung von Bildern unterstützen. Hierzu haben wir die Funktionen des iArt Projektes in Antelope eingebunden. Dies hilft z.B. bei einfachen Klassifizierungen von großen Bildbeständen z.B. in Allgemeine Kategorien der Bildart (z.B. Zeichnung, Ölgemälde, Druck) oder des Inhaltes (z.B. Landschaft, Porttrait, Fahrzeuge etc.). Technisch basiert das ganze auf den ClipText Modellen von OpenAI.
TextEmbedding:
Über die Api sind weitere Hilfmethoden verfügbar. So kann man z.B. per Python script die semantische Ähnlichkeit von Texten und Wörtern bewerten.
== Ausblick ==
Geplant ist eine Integration in Wikibase, so dass Daten in Wikibase mittels Antelope angereichert werden können
Es wird eine Integration in den TS4NFDI Terminologiedienst erfolgen
Die bisher vortrainierten (KI)Modelle sollen durch eigene (domänenspezifische) Modelle ersetzt werden können. Für das Training dieser Modelle wollen wir Hilfsfunktionen anbieten.
Ganz generell verstehen wir Antelope als Tool, das Daten für die Entscheidungsunterstützung generiert. Die Ergebnisse sollen also idealerweise eingebettet sein in einen Arbeitsprozess bei dem Experten die Daten kuratieren und vervollständigen. Gleichzeitig wollen wir mit dem Tool die Einstiegshürde für semantische Annotation vor allem für Anwender ohne Programmiererfahrung senken um Verfügbare Technologien schneller in die Anwendung zu bringen.
Ich hoffe die Zusammenfassung klärt die Frage zufriedenstellend. Ansonsten bitte gerne weiter Fragen
Noch hinzugefügt sei, dass alle Funktionen die man auf der Website sieht auch per API zur Verfügung stehen. man kann also sämtliche Funktionen auch in seine eigenen Forschungswerkzeuge und scripte integrieren. Die Entwicklung ist OpenSource
Erstmal herzlich willkommen im Forum, @Kolja_Bailly . Danke, dass du so schnell geantwortet hast.
Clemens NeudeckerKai Labusch (sorry) hatte bei der SWIB23 einen Vortrag gehalten mit dem Titel „Entity linking historical document OCR by combining Wikidata and Wikipedia“ (Slides, Video). Daraufhin haben wir in den Pausen und im Fediverse erste Gedankenspiele gemacht, inwiefern eine solche Funktion durch einen Reconciliation Service angeboten werden kann, anstatt etwas Neues, (noch) nicht Standardisiertes zu entwickeln. (Hier die Spec der Entity Reconciliation Service API: Reconciliation Service API)
Das Vorgehen wäre in etwa so:
Der Client erkennt Namen in dem jeweiligen Dokument.
Er sendet an einen Reconciliation Service der für die Verlinkung gewünschten Normdatenbank das Label der Entität plus den Kontext.
Der Dienst antwortet mit einer gerankten Liste gewichteter Kandidaten.
Meiner Erachtens wäre es ein großer Vorteil hier auf das existierende Protokoll zu setzen, weil es bereits viele Server- wie Client-Implementierungen gibt (die für diesen Use Case ggf. angepasst werden müssten), zum Beispiel unterstützt der TEI Publisher das Protokoll. Habt ihr so etwas für Antelope angedacht oder gar geplant?
@acka47 ich denke wir sollten uns einmal über TS4NFDI und der Reconciliation Service API unterhalten. Du bist nicht zufälligerweise diese Woche in Göttingen? Falls nein muss ich mal zeitnah nach Köln kommen. Ich sehe da ziemliche Parallelen und es macht vermutlich Sinn in dem Punkt zusammen arbeiten. @Kolja_Bailly kann gern auch dabei sein. Um die Schnittmengen zu besprechen.
Hi @baum , schön, dich hier zu sehen. Herzlich willkommen im Forum! Gerne können wir mal darüber quatschen, ggf. auch mit @fsteeg, der die Entity Reconciliation Community Group beim W3C co-moderiert. In Göttingen bin ich leider nicht. Bei Bedarf können wir uns auch online treffen. Wir haben auch vor am 27.11. im Rahmen der Online-SWIB24 eine kleine Veranstaltung im hbz zu machen (so mit 30-40 Leuten, kleinem Barcamp, gemeinsam Stream schauen und dann Kneipenbesuch, Details folgen). Vielleicht wär das ja auch ein guter Rahmen.
Das Barcamp klingt spannend. Ich hoffe die Bauarbeiten an der Bahnstrecke sind Mitte Oktober wirklich mal vorbei dann ist die Strecke Köln und Bonn ja nicht besonders weit auseinander.
Hallo, ja die reconciliation API ist ein möglicher weg das technisch zu lösen. Wir haben mit Wikibase4Research gerade eine docker pipeline entwickelt, welche die Installation von Mediawiki Umgebungen automatisiert und die auch den Reconcilaition service bei Bedarf mit deployed. Von Daher würde das also gut in unsere Toolchain passen. Hier muss aber erst noch eine detaillierte Anforderungsanalyse für die Integration erstellt werden, um die Pros und Cons informiert abwägen zu können
Standardmäßig verwenden wir das CLIPText Modell von OpenAI (https://openai.com/index/clip/) für die Zuordnung von Bildinhalten zu Vokabularen also Bildklassifikation und BildInhalts-Bestimmung. Das Entity Linking erfolgt derzeit auf dem glove-wiki-gigaword-300 Modell (GloVe: Global Vectors for Word Representation). Wir arbeiten aber daran, dass der User das Modell wählen bzw. selbst hochladen kann. Außerdem arbeiten wir an Werkzeugen um die Transparenz der Wordembedding Modelle zu erhöhen wie z.B. Visualisierung der gewählten Vokabulare aus Sicht des Modells. Falls an dem Thema interesse an Mehr Informationen besteht gerne Bescheid sagen.
