Auf den ersten Blick ist CycL eine frame-basierte Sprache, das heißt, Aussagen werden in der Form von Tripeln notiert, wie beispielsweise ,,Die Hauptstadt von Texas ist Austin.'' Alle Informationen über Texas werden in einer Datenstruktur gesammelt, die ,, Texas-Frame'' oder ,,Texas-Element'' genannt wird:
Texas
| capital: (Austin) | |
| residents: (Doug Guha Mary) | |
| stateOf: (UnitedStatesOfAmerica) |
Das hier dargestellte Element besitzt drei Slots, von denen jeder einen zugehörigen Wert enthält. Der Wert eines Slots eines Elements besteht immer aus einer Menge individueller Einträge. Sogar ein Slot wie ,,capital'', der eigentlich nur einen Eintrag haben sollte, besitzt eine einelementige Menge als Wert.
Jedes Element in Cycs Wissensbasis repräsentiert etwas: einen realen Gegenstand, eine Aktion, ein bestimmtes Ereignis, eine abstrakte Idee. Im folgenden wird oft eine Bezeichnung wie ,,Fred'' sowohl für die Person Fred als auch für das Cyc-Element, das Fred repräsentiert, verwendet. Im Falle der Doppeldeutigkeit wird dem Elementnamen das Symbol #% vorangestellt. Wollte man also ganz exakt sein, müßte man sagen, daß #%Texas drei Slots besitzt, wohingegen Texas keinen einzigen Slot besitzt, da es ein Bundesstaat der USA ist.
Es gibt vier grundlegende Arten von Frames: ,,Normale'' Frames, SlotUnits, SeeUnits und SlotEntryDetails.
90 Prozent aller Einträge der Wissensbasis gehören in diese Kategorie. Sie repräsentieren Konzepte und Dinge wie die Menge aller Hunde, den Vorgang des Gehens, das deutsche Wort ,,Rot'' usw.
SlotUnits sind Elemente, die Typen von Slots repräsentieren. Das Element #%residents beispielsweise ist ein Element von Cycs Wissensbasis und beschreibt diesen Slottypen. Es enthält Informationen wie ,,Nur eine geopolitische Region kann Einwohner haben; jeder dieser Einwohner muß eine Person sein; lebenslange Einwohner einer Region sind Einwohner dieser Region.''
residents
| instanceOf: (Slot) | |
| inverse: (residentOf) | |
| makesSenseFor: (GeopoliticalRegion) | |
| entryIsA: (Person) | |
| specSlots: (lifelongResidents illegalAliens registeredVoters) | |
| slotConstraints: ((coTemporal u v)) |
Der letzte Slot verdient besondere Beachtung: er besagt, daß das
Wissensbasiselement u, zu dem der Slot #%residents gehört, und der
Inhalt v
dieses Slots zur gleichen Zeit existieren müssen. Daraus kann Cyc
beispielsweise ableiten, daß Julius Cäsar kein Einwohner von New
York sein kann.
Ein SlotUnit beschreibt die Informationen, die in dem betreffenden
Slot gespeichert sind, und setzt sie in Beziehung mit dem Rest der
Wissensbasis. Dies ist ein großer Vorteil, denn man kann explizite
intensionale Definitionen von Slots
angeben (ansonsten würde die
Semantik eines Slots nur durch seinem Gebrauch, das heißt durch sein
Vorhandensein in der Wissensbasis und durch seine Erwähnung in
Regeln, definiert werden), man kann explizite Beschränkungen und
Beziehungen für den Slot angeben (zum Beispiel hat der Slot Eltern
bis zu
zwei Einträge; jedes Tier kann diesen Slot besitzen; er muß Tiere
als Einträge besitzen), und man kann explizite Beschränkungen und
Beziehungen zwischen Slots angeben (zum Beispiel sind die Großeltern
eines Elements immer die Eltern der Eltern des Elements).
Diese Elemente dienen als ,,Fußnoten'', sie liefern Informationen über einen bestimmten Slot eines bestimmten Elements. Das folgende Beispiel drückt aus, daß der residents-Slot des Texas beschreibenden Elements ungefähr zehn Millionen Einträge besitzt:
Texas
| capital: (Austin) | |
| residents: (Doug Guha Mary) |
| stateOf: (UnitedStatesOfAmerica) |
SeeUnitFor-residents
Texas
| instanceOf: (SeeUnit) | |
| modifiesUnit: (Texas) | |
| modifiesSlot: (residents) | |
| cardinality: (10000000) |
Das Karo vor dem residents-Slot von #%Texas weist darauf hin, daß dieser Slot einen SeeUnit besitzt. Da SeeUnits vollwertige Bestandteile von Cycs Wissensbasis sind, können sie auch wieder SeeUnits besitzen.
SlotEntryDetails funktionieren ähnlich wie SeeUnits, sie modifizieren
aber einen einzelnen Eintrag eines Slots eines Elements.
Sowohl SeeUnits als auch SlotEntryDetails werden benutzt, um
Beschränkungen für die Werte eines Slots,
die qualitativen und relativen Werte numerischer Slots (zum
Beispiel Höhe, Alter oder Farbe),
die Anzahl von Einträgen in den Slot oder
historische Informationen (wer diesen Eintrag zuletzt hier
gemacht hat und wann) zu beschreiben.
Zur Bezeichnung wird häufig der Slotname hinter den Elementnamen
gesetzt, durch einen
Punkt getrennt (z. B. ,,Texas.capital''). Hinter diesen
Ausdruck kann dann noch ein Eintrag des bezeichneten Slots gesetzt
werden, also z. B. ,,Texas.capital.Austin''.
Der Wert jedes Slots wird durch eine Menge gegeben. Wie bei
mathematischen Mengen darf man keine Annahmen über
eine bestimmte Reihenfolge machen, und kein Element kommt mehrfach in
der Menge
vor. Möchte man die Einträge ordnen, so muß man sie in der
gewünschten Reihenfolge in eine Liste einfügen, und diese Liste
stellt dann den einzigen Wert des betreffenden Slots dar.
CycL ändert die Reihenfolge der Bestandteile
eines bestimmten Werteintrags nicht, denn bei
einer chronologisch geordneten Liste würde ein Umordnen zwar ,,
nur'' zu einer falschen Anordnung führen, aber bei einem
Eintrag, der eine Lisp-Funktion ist, wären die Folgen fatal.
Jeder Slot jedes Elements enthält nicht nur einen Wert (genauer: einen Zeiger auf den Typ und einen Zeiger auf den Wert), sondern zusätzlich noch einige andere Felder. Diese enthalten Informationen wie:
Die meisten dieser Felder könnten sicherlich durch die Verwendung von SeeUnits eingespart werden. Doch das Untersuchen und Verschlüsseln der häufigsten dieser Informationen in solchen Zusatzfeldern machte die Verwendung von SeeUnits und SlotEntryDetails oft überflüssig; sie sind zur Zeit sehr selten in der Datenbank vertreten.