Terminologie und Ontologie

(Dieser Text: Fachliche Hintergrund-Info für die Vorbereitung eines Vortrags auf der Konferenz XXXX. Ab der Konferenz dann auch die Einstiegseite für Handout, Vortrags-Folien etc.)

Ausgangspunkt: Das semiotische Dreieck

Das semiotische Dreieck kennt ja jeder:

Backlink: https://en.wikipedia.org/wiki/Triangle_of_reference

Text der Abbildung (für bessere Acessability):

  • Symbol symbolizes Thought_or_Reference

  • Thought_or_Reference refers_to Referent

  • Symbol stands_for Referent

Problem: Das semiotische Dreick gibt es in dieser Eindeutigkeit gar nicht. Hier abgebildet ist ein Dreieck aus der Theorie von Ogden and Richards: The Meaning of Meaning (1923), aber es gibt auch viele andere, ähnliche Dreiecke. Eine Gesamtschau gibt z.B. Umberto Eco:

Quelle: Eco, Umberto. Zeichen. Einführung in einen Begriff und seine Geschichte, Frankfurt a. M. 1977, S. 30. Backlinks: https://grk1876.blogspot.com/2021/02/semiotik-in-den-bildwissenschaften-ein.html | 24. Mai 2016 von semiotikundpopkulturblog | https://www.jaapvanderaa.nl/en/the-book/5-the-notion-of-concept u.V.m.

Was passiert hier? Ein einfaches Dreieck wird als intuitives Modell in unterschiedlichsten Theorien verwendet. Letztlich sagt es nicht mehr aus, als dass drei Dinge wechselseitig in Beziehung stehen. Wer das semiotische Dreieck innerhalb einer Erklärung verwendet muss auch sagen, welche Theorie er dabei verwendet. Ich kenne diese Theorien nicht im Detail, aber darüber reden will ich doch. Grob skizziert verstehe ich dieses Dreieck so:

  • “oben”: die Welt der subjektiven Gedanken und Vorstellungen eines Menschen (psychologistische Sichtweise), sichtbar werdend z.B. in mündlichen Erzählungen

  • “unten links”: Alles, was mit einem Stift auf Papier aufgeschrieben oder gezeichnet werden kann: Text, Zeichnungen und Diagramme, mathematische Formeln u.V.m.

  • 2unten rechts”: Alle Entitäten in der Welt, “real” oder gesellschaftlich konstruiert oder phantasiert: meine Brille, das Wetter in Mannheim, ein Einhorn, ein Kaufvertrag, diese Präsentation hier.

Dass dieses Verständnis unscharf ist möge uns nichts ausmachen, denn wir verwenden das semiotische Dreieck nicht als tragenden Bestandteil einer Theorie.

Aber gerade die Unschärfe des semiotischen Dreiecks erzeugt eine bestürzende Plausibilität. Es stellen sich Fragen wie:

  • Hat das semiotische Dreieck noch irgend eine Erklärungskraft für die Terminologielehre?

  • Wie verhalten sich moderne Standards wie RDF(S), das Datenmodell des (hier: Princeton-) Wordnet, die Thesaurus-Ontologie SKOS zum semiotischen Dreieck?

  • Haben die Definitionen in einer Semantic Web Ontologie irgendetwas mit dem semiotischen Dreieck zu tun?

Der vorliegende Aufsatz thematisiert vor allem die Ecken “unten links” und “unten rechts” sowie die Beziehungen dazwischen.

Die Fragestellung genauer umrissen

Terminologen unterscheiden oft lexikalische und semantische Entitäten.

Bild)

Wir betrachten einen Beispielsatz:

  • “Unsere Tanke an der Ecke hat sieben Tage in der Woche geöffnet, Tag und Nacht!”

In diesem Satz hat “Tag” offensichtlich zwei Bedeutungen:

  • {15180180} day#1: ein 24-Stunden-Zeitraum innerhalb einer Woche

  • {15190004} day#4: der helle Teil eines day#1, im Ggs. zur Nacht

Im diesem Beispiel ist “Tag” eine lekikalische Entität, und die technisch anmutende Zeichenketten day#1 und {15180180} sind semantische Entitäten. (Tatsächlich meine ich, dass {15180180} sogar als eine pragmatische Entität verstanden werden sollte, s.u.)

Schlägt man im (leider nur auf EN verfügbaren Princeton-) WordNet das Wort day nach, erhält man diese Auskunft:

Quelle (und live): https://wordnet.princeton.edu/ > Use Wordnet Online > “day”

Problem: Lexikalische und semantische Entitäten werden je nach wissenschaftlicher Herkunft und zugrundegelegter Bedeutungstheorie auf verschiedenste Weise beschrieben (benannt, bezeichnet, denotiert, konzeptualisiert, …) und in Beziehung gesetzt. Übliche Wörter (Begriffe, Benennungen, …) lauten je nach Kontext z.B. Wort, Begriff, Term, Bezeichnung, Benennung, Konzept, Definition, Sinn, Bedeutung, Referent, Designat, Extension, Intension u.s.w.

Sowohl (oft eher aus der Übersetzungswissenschaft stammende) Terminologen wie auch (oft aus Mathematik, Philosophoe oder Informatik stammende) Ontologen haben viele einzelne Modelle zur Verfügung, die mit der Unten-link-untern-rechts-Beziehung” zu tun haben, und die teilweise dasselbe in unterschiedlichen Worten und teilweise in gleichen Worten sehr Verschiedenes beschreiben. Dieser Aufsatz beschäftigt sich damit, den Kern einiger wichtiger Modelle zu benennen, und einige wenige dieser z.Z. auch technisch bedingten Modelle zu einem Gesamtbild zusammenzusetzen.

Wir machen das “analytisch”: In der Tradition der analytischen Philosophie (wie etwas von von John L. Austin TBD: zitiere Austin “Ein Plädoyer für Entschuldungen” (“a plea for excuses”)) untersuchen wir die Verwendung von Wörtern in der normalen Sprache. Und wir sezieren die Bedeutung von Wörtern der normalen Sprache, indem wir nach Unterschieden, Gemeinsamkeiten, Abgrenzungen suchen, und diese Unterscheidungen systematisieren.

Konkret thematisieren wir die folgenden Modelle, von denen jedes einzelne einen Teil zur Terminologiearbeit beiträgt:

  • “das” semiotische Dreieck, das es so eindeutig gar nicht gibt

  • das RDF Datenmodell

  • Functional Requirements for Bibliographic Records (FBFR)

  • das HTTPRange-14 Problem: SlashURI vs. HashURI

  • WordNet

  • SKOS

  • OntoLex

  • Ontologie

Wir gehen hier erste Schritte auf einem Weg, an dessen Ende eine Ontologie von Terminologiebegriffen stehen könnte.

“unten rechts” (1): SlashURI vs. HashURI (HTTPRange-14)

Quelle: https://ldapwiki.com/wiki/URL

Welche Aussage ist korrekt?

Die URL https://de.wikipedia.org/wiki/Faust._Eine_Trag%C3%B6die wird offensichtlich in zweierlei Weise verwendet:

  • Identifiziert sie das literarische Werk Faust I?

  • Oder identifiziert sie das Wikipedia-Dokument, das den Faust I beschreibt, und das im Jahr 2021 33 mal editiert wurde?

Wir wechseln das Beispiel, um mit Standard-Dokumenten kompatibel zu sein: Wir gehen auf einen Wetterbericht über. Also:

  • Identifiziert ein IRI wie z.B. https://www.windfinder.com/forecast/st_leon_lake eine Entität in der Welt, wie z.B. das Wetter am St. Leoner See, oder

  • identifiziert der IRI ein Dokument (oder eine Datei oder eine bestimmte Kopie einer Datei), das über dieses Wetter Auskunft gibt?

Was durch eine URL bezeichnet wird, wurde im historischen Grundlagen-Dokument Architecture of the World Wide Web, Volume One https://www.w3.org/TR/webarch/ definiert. ABER diese Abbildung aus dem Dokument https://www.w3.org/TR/webarch/ enthält ein Problem, und entspricht nicht mehr den heutigen Empfehlungen:

Quelle: https://www.w3.org/TR/webarch/#intro

In dieser historischen Abbildung aus dem Jahr 2004 identifiziert ein IRI wie http://weather.example.com/oaxaca (resp. im obigen Beispiel https://www.windfinder.com/forecast/st_leon_lake)

  • offensichtlich nicht das Dokument, welches über das Wetter in Oaxaca Auskunft gibt,

  • sondern das Wetter in St. Leon selbst.

Das Problem ist bestens bekannt unter HTTPRange-14-Problem. Lösung:

  • Ein SlashURI (also ohne “#” Hash-Zeichen) bezeichnet das Dokument (oder genauer: die Informations-Resource), die man auf eine http-Anfrage bekommt.

  • Ein HashURI (also mit “#” Hash-Zeichen) bezeichnet eine beliebige Entität in der Welt, die nicht unbedingt durch eine eigene SlashURI repräsentiert sein muss.

Heute würden wir diese Abbildung anders gestalten: Im Unterschied zu obiger Abbildung aus 2004 bezeichnet ein SlashURI heute eigentlich direkt http-adressierbares Dokument; ein HashURI kann beliebiges bezeichnen.

Diese Konvention wird auch empfohlen in: Empfehlung für die RDF-Repräsentation bibliografischer Daten (Textressourcen). Erstellt von Kett-Hauser, Julia, zuletzt geändert von Rühle, Stefanie am 2019-10-08. (Bei dieser Webseite handelt es sich um eine inhaltsgleiche Webversion zur PDF-Publikation “Empfehlungen zur RDF-Repräsentation bibliografischer Daten / DINI-AG KIM Gruppe Titeldaten. (DINI-Schriften - 14) Version 2.0. November 2018.”, urn:nbn:de:kobv:11-110-18452/2153.3-7) https://wiki.dnb.de/pages/viewpage.action?pageId=68060017

Obige Abbildung zum Wetter in Oaxaca würde man heute eigentlich so nicht mehr interpretieren. Um das Oaxaca-Wetter zu identifizieren, würde man heute eine eher eine HashURI verwenden, z.B. http://weather.example.com/forecast#oaxaca. Der Webserver würde dann wissen, dass er eine eine Datei zurückliefern muss, die einen Wetterbericht enthält, und erwartungsgemäß das Wetter in Oaxaca beschreiben.

Vorausschau: Gemäß dieser Konvention sollten Terminologen Terme als Hash-URI notieren. Dann kann der vor dem Hash- (“#”) Zeichen stehende SlashURI ein Dokument denotieren, in dem wir Informationen über unseren Term erwarten dürfen. Im Idealfall liefert uns bei einer http-Anfrage die Content Negotiation eine Datei vom Typ RDF (z.B. in Formaten wie JSON, RDF/XML oder Turtle) zurück, in der wir mindestens ein RDF-Tripel erwarten dürfen, bei dem dem die Hash URI in Subjekt-Position steht. (Wenn wir Pech haben, liefert uns die Content Negotiation ein html-Dokument zurück; dann dürfen wir immerhin erwarten, dass es zu dem Fragment Identifier ein @id-Attribut gibt, der ein Textfragment identifiziert: Auch die Pragmatik von HashURIs ist in der Praxis vielfältig.)

RDF uses IRIs, which may include fragment identifiers, as resource identifiers. The semantics of fragment identifiers is defined in RFC 3986 [RFC3986]: They identify a secondary resource that is usually a part of, view of, defined in, or described in the primary resource, and the precise semantics depend on the set of representations that might result from a retrieval action on the primary resource. https://www.w3.org/TR/rdf11-concepts/#section-fragID

Vertiefung:

“unten rechts” (2): FRBR

  • FBFR: Functional Requirements for Bibliographic Records

Die Lösung zum HTTPRange-14 Problem unterscheidet addressierbare Dinge (aka Informationsressourcen, SlashURIs) und nicht adressierbare Dinge (HashURIs).

Bezüglich der Resourcen, die ein URI identifizieren kann, gibt es weitere Unterscheidungen. Eine schöne Darstellung gibt z.B. https://www.librarianshipstudies.com/2017/09/functional-requirements-for-bibliographic-records-frbr.html, oder auf DE: Bibliographische Entitäten, Merkmale und Beziehungen der Gruppe 1.

Historischer Ausgangspunkt: Im Bibliothekswesen aus der Vorinternet-Zeitalter werden u.A. vier Dinge unterschieden:

  • Werk

  • Expression

  • Manifestation

  • Item

Group 1 entities are the foundation of the FRBR model:

Work is a “distinct intellectual or artistic creation.” For example, Beethoven’s Ninth Symphony apart from all ways of expressing it is a work. When we say, “Beethoven’s Ninth is magnificent!” we generally are referring to the work.

Expression is “the specific intellectual or artistic form that a work takes each time it is ‘realized.’” An expression of Beethoven’s Ninth might be each draft of the musical score he writes down (not the paper itself, but the music thereby expressed).

Manifestation is “the physical embodiment of an expression of a work. As an entity, manifestation represents all the physical objects that bear the same characteristics, in respect to both intellectual content and physical form.” The performance the London Philharmonic made of the Ninth in 1996 is a manifestation. It was a physical embodiment even if not recorded, though of course manifestations are most frequently of interest when they are expressed in a persistent form such as a recording or printing. When we say, “The recording of the London Philharmonic’s 1996 performance captured the essence of the Ninth,” we are generally referring to a manifestation.

Item is “a single exemplar of a manifestation. The entity defined as item is a concrete entity.” Each copy of the 1996 pressings of that 1996 recording is an item. When we say, “Both copies of the London Philharmonic’s 1996 performance of the Ninth are checked out of my local library,” we are generally referring to items.

FRAGE: Wie sieht das in der elektronischen Welt aus, in der wir Dokumente, Dateien, Datensätze, Formate etc. haben?

Wir bleiben beim Beispiel https://www.windfinder.com/forecast/st_leon_lake:

  • Werk: eine komplexe Sammlung von Informationen

    • z.B. eine spezifisch auf die Bedürfnisse von Wassersportlern zugeschnittene Wettervorhersage, hier z.B. für den See bei St. Leon-Rot

    • Web Document

  • Expression: eine sprachlich-typografische Darstellungen eines Werks, z.B. eine Wettervorhersage als Dashboard in DE oder EN

    • Übersetzungen in DE und EN, Angaben in Knoten oder km/h erzeugen verschiedene Expressionen desselben Werks.

  • Manifestation: eine Datei, die man als Ergebnis einer http Content Negotion als Message Payload erhält.

    • Verschiedene Formate (pdf, html, Markdown, csv, xls etc.) erzeugen unterschiedliche Manifestationen derselben Expression.

    • File?

  • Item

    • eine Datei, die ein Webserver für mich gebaut, auf seiner Festplatte zwischengespeichert und mir dann zugeschickt hat, sowie die Datei, die ich dann erhalten und in meinem Literaturverwaltungsprogramm abgelegt habe, sind zwei unterschiedliche Items derselben Manifestation.

    • File?

FBFR unterscheidet also vier unterschiedliche Tpen von Entities, die mit einem IRI identifiziert werden können.

FRIR

Wir bringen die ersten drei Puzzlestücke zusammen: semiotisches Dreieck + FBFR + HTTPRange-14-Lösung = FRIR

https://www.researchgate.net/profile/Timothy-Lebo/publication/262369023/figure/fig3/AS:296904282918941@1447798905910/Relating-URIs-Resources-and-Representations-using-FRIR-FRBR-and-the-semiotic.png

Quelle: James P. McCusker, Timothy Lebo, Alvaro Graves, Dominic Difranzo, Paulo Pinheiro, and Deborah L. McGuinness: Functional Requirements for Information Resource Provenance on the Web. https://www.researchgate.net/publication/262369023_Functional_Requirements_for_Information_Resource_Provenance_on_the_Web June 2012, DOI:10.1007/978-3-642-34222-6_5, Conference: Proceedings of the 4th international conference on Provenance and Annotation of Data and Processes

Wordnet

The core concept in WordNet is the synset. A synset groups words [JB: UNGENAU! exakter wäre “senses”, notfalls auch “word meanings”, “lemma_name”, “wordsense ID”] with a synonymous meaning, such as {car, auto, automobile, machine, motorcar}. Another sense of the word “car” is recorded in the synset {car, railcar, railway car, railroad car}. Although both synsets contain the word “car”, they are different entities in WordNet because they have a different meaning. https://www.w3.org/TR/wordnet-rdf/#wnmetamodel

Bildung von Wortfeldern und Begriffsfeldern, indem man Synonyme zu einem Feld, einem „Konzept“[1] (im Sinne einer Begrifflichkeit) zusammenfasst. https://de.wikipedia.org/wiki/Synset

According to WordNet, a synset or synonym set is defined as a set of one or more synonyms that are interchangeable in some context without changing the truth value of the proposition in which they are embedded. https://en.wikipedia.org/wiki/Synonym_ring

Quelle / dieses Beispiel live: WordNet > Search > “car”

Text:

  • {02961779} S: (n) car#1, auto#1, automobile#1, machine#6, motorcar#1 (a motor vehicle with four wheels; usually propelled by an internal combustion engine) “he needs a car to get to work”

  • {02963378} S: (n) car#2, railcar#1, railway car#1, railroad car#1 (a wheeled vehicle adapted to the rails of railroad) “three cars had jumped the rails”

  • {02963937} S: (n) car#3, gondola#3 (the compartment that is suspended from an airship and that carries personnel and the cargo and the power plant)

  • {02963788} S: (n) car#4, elevator car#1 (where passengers ride up and down) “the car was on the top floor”

import nltk
from nltk.corpus import wordnet as wn
print(wn.synsets('motorcar'))
# Ausgabe: [Synset('car.n.01')]
print(wn.synset('car.n.01').lemma_names())
# Ausgabe: ['car', 'auto', 'automobile', 'machine', 'motorcar']

Für unsere Argumentation lässt sich die Idee von WordNet auf eine Tabelle reduzieren.

Datenmodell: Im Kern eine Tabelle, mit

  • Spalten: WordSense-ID

    • menschenlesbar: car#1, car#2

  • Zeilen: Synset-ID

    • {15180180}

ABBILDUNG? Oder einfacher ein Dict von Listen, dann ein Pandas Dataframe … programmatisch erzeugen mit NLTK und car

Tatsächlich ist es natürlich komplexer. Für Interesserte:

BEGINN ZITAT der Quelle https://github.com/wordnet/wordnet/blob/master/README.md:

  • Lexeme - unit of lexical meaning that exists regardless of the number of inflectional endings it may have or the number of words it may contain (e.g. run, ran, runs)

  • Lemma - particular form of a lexeme that is chosen by convention to represent a canonical form of a lexeme (e.g. run)

  • Sense - a Lexeme associated with particular meaning. Each Lexeme can have multiple Senses. In Wordnet each Sense is associated with number to easily distinguish (e.g. I can write run 4 meaning an unbroken series of events, or run 5 meaning the act of running)

  • Synset - a set of Senses (not Lexemes) with similar meaning, i.e. synonyms (e.g. run 2 forms Synset with following Senses: bunk 3, escape 6, turn tail 1).

  • Sense Relation - a relationship between two Senses, i.e. relationship between two particular meanings of words (e.g. big 1 is antonym of little 1)

  • Synset Relation - a relationship between two Synsets, i.e. relationship between two groups of Senses (e.g. Synset { act 10, play 25 } is hyponym of Synset { overact 1, overplay 1 }).

  • Relation Type - each SenseRelation and SynsetRelation has its type, it can be among others: antonym, hyponym, hyperonym, meronym, …

In summary: Each Lexeme is represented by Lemma. Each Lexeme has multiple Senses. Each Sense forms Synset with other Senses. Each Sense can be in SenseRelation to other Senses. Each Synset can be in SynsetRelation to other Synsets.

Above concepts of Wordnet are modelled in application in following way:

(Bild: https://raw.githubusercontent.com/wordnet/wordnet/master/doc/class_diagram.png)

ENDE ZITAT der Quelle

WordNet hat also ein sehr differenziertes Datenmodell. Die für unsere Argumentation ausreichende maximale Vereinfachung ist die: Wir haben technisch gesehen zwei Tabellen, nämlich

  • Wort (repräsentiert durch Lemma) vs. WordSense

  • WordSense vs. Synset

MAximal vereinfachend lassen sich diese zwei Tabellen zu einer einzigen Wort vs. Synset-Tabelle fusionieren:

  • Das gleiche Wort (lexikalische Kategorie, repräsentiert durch sein Lemma) taucht je nach Bedeutung in verschiedenen Synsets (semantische Kategorie) auf

  • Ein Synset repräsentiert abstrakt die Bedeutung meist mehrerer Wörter

Etwas differenzierter bilden beide Tabellen zusammen einen dreidimensionalen Raum:

  • Dimension 1, x-Achse: Wort

    • Vertreter: Rechtschreib-Duden Band 1: Lemmata plus grammatikalische Informationen wie Genus, Pluralformen, Deklination / Konjugation etc.

    • Wort

    • lemon:lexical_entry

  • Dimension 2, y-Achse: EN:Sense, DE:Bedeutung, Term

    • Gottlieb Frege verwendet um 1890 “Sinn” und “Bedeutung” gerade umgekehrt, der heutige Sprachgebrauch in DE ist anders; Wordnet verwendet “sense” * Vertreter: große, dicke Wörterbücher wie z.B. “Wahrig”: Es werden verschiedene Bedeutungen unterschieden

    • lemon:lexical_sense

    • skos: concept (?)

    • Tag(1): 24h; Tag(2): heller Teil eines Tag(1); Tag(3): Gedenk~, Geburts~ etc.

  • Dimension 3, z-Achse: Synset

    • Menge von Senses, die in einem bestimmten Verwendungszusammenhang eine ähnliche Bedeutung (sense) haben.

    • Vertreter: Wordnet

    • skos: concept (?)

    • Wichtig: im Princeton Wordnet besteht ein Synset aus Entitäten der y-Achse, also Senses, und nicht Lemmata aus der x-Achse

Interpretation JB:

  • Wortfeld Dimension 1 betrifft Syntax: Wort, Lexem, Syntax, Wortformen

  • Wortfeld Dimension 2 betrifft Semantik: Term

  • Wortfeld Dimension 3 betrifft zusätzlich auch Pragmatik: Synset

Zum Weiterlesen:

SKOS

Die SKOS-Dokumentation visualisiert den Unterschied von URI und Literal so:

Quelle: https://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/

Die wesentlichen Aspekte von SKOS sind in dieser Abbildung zusammengefasst:

Quelle: https://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102/#secintro

SKOS in seiner Grundform ist vergleichsweise einfach aufgebaut: Resources vom Typ skos:concept (bei kleinen und mittleren Vokabularen typischerweise HashURIs) …

  • zeigen über labelling properties wie skos:prefLabel oder skos:altLabel auf Literale, die wir typischerweise als Lemmata oder Nounphrases wiedererkennen;

  • zeigen über documentation properties wie skos:definition auf die Definition eines Begriffs (die als Literal, als HashURI oder als ein Web Dokument angegeben sein kann, siehe SKOS Core Guide > Documentation Properties);

  • zeigen über semantic relationships wie skos:broader, skos:narrower und skos:related auf andere Resources vom Typ skos:concept https://www.w3.org/TR/swbp-skos-core-guide/#secrel

Quelle: SemAuth1, ca 2011, http://www.jbusse.de/semauth/smmm2013_%20anwendung_schema-visualisierung.html

Bemerkungen:

  • SKOS verwendet die übliche, aber in RDF nicht normierte Unterscheidung: relationship als Relation zwischen zwei Resources, sowie property als Relation zwischen Resource und Literal. In OWL entspricht dies der Unterscheidung zwischen object properties (owl:ObjectProperty) und data properties (owl:DatatypeProperty) https://www.w3.org/TR/owl-ref/#Property

  • Unterscheidung zwischen URI und Literal … erinnert an an die untere Kante

Offene Frage:

  • Die Zuordnung zwischen SKOS und WordNet ist unklar: Entspricht ein skos:concept in WordNet einem Sense oder einem Synset?

https://www.w3.org/TR/skos-reference/skos-xl.html

OntoLex-Lemon

Ontolex-lemon ist eine Ontologie, um lexikalische Daten in RDF zu publizieren.

Wir verwenden hier die Konzepte aus OntoLex, um den in der Terminologie gut bekannten Unterschied zwischen Benennung und Term genauer zu konzeptualisieren.

Quellen:

Backlink: https://www.w3.org/2016/05/ontolex/#core

Klassen:

Lexical Entry: A lexical entry represents a unit of analysis of the lexicon that consists of a set of forms that are grammatically related and a set of base meanings that are associated with all of these forms. Thus, a lexical entry is a word, multiword expression or affix with a single part-of-speech, morphological pattern, etymology and set of senses. […] Lexical entries are further specialized into words, affixes (e.g., suffix, prefix, infix or circumfix) and multiword expressions. https://www.w3.org/2016/05/ontolex/#lexical-entries

Lexical Sense: A lexical sense represents the lexical meaning of a lexical entry when interpreted as referring to the corresponding ontology element. A lexical sense thus represents a reification of a pair of a uniquely determined lexical entry and a uniquely determined ontology entity it refers to. A link between a lexical entry and an ontology entity via a Lexical Sense object implies that the lexical entry can be used to refer to the ontology entity in question. https://www.w3.org/2016/05/ontolex/#lexical-sense-reference

Lexical Concept: sometimes we would like to express the fact that a certain lexical entry evokes a certain mental concept rather than that it refers to a class with a formal interpretation in some model. Thus, in lemon we introduce the class Lexical Concept that represents a mental abstraction, concept or unit of thought that can be lexicalized by a given collection of senses. A lexical concept is thus a subclass of skos:Concept. https://www.w3.org/2016/05/ontolex/#lexical-concept

ACHTUNG: Die Beispiele in OntoLex werden nicht mit HashURIs, sondern mit SlashURIS angegeben:

:lex_cat a ontolex:LexicalEntry;
   ontolex:canonicalForm :form_cat;
   ontolex:denotes <http://dbpedia.org/resource/Cat>.

Quelle: https://www.w3.org/2016/05/ontolex/#semantics.

https://lemon-model.net/lemon-cookbook.pdf

Preferred Reference of prefLabel Alternative Reference of altLabel Hidden Reference of hiddenLabel

lemon also allows for SKOS’s semantic properties broader, narrower and related to be mapped in a one-to-one manner to lemon’s broader, narrower and senseRelation.