# Allgemein 1.) Subklassierung und Freeze der bestehenden Ontologien Beim "modellieren" der Manuscriptklassen ist mir aufgefallen, dass wir wirklich tatsächlich schon sehr viel profitieren können, wenn wir eigene Klassen definieren und diese einfach subklassieren zu bereits Bestehendem. Für den Manuscript-Teil ist bereits fast alles vorhanden, das wir benötigen! :-) Das heisst, ich schlage vor, dass wir die nie-ontologien Stand jetzt einfach einmal freezen für uns und damit arbeiten, soweit möglich. Den Aufwand, alles selber zu definieren, können wir ja immer noch erbringen, falls das überhaupt notwendig/sinnvoll sein wird ... wohl eher nicht. Für den Teil der "inhaltlichen Daten"/Texte/Positionen wird es wohl noch nichts Brauchbares geben in den nie-Ontologien. Da müssen wir halt eigene, neue kreieren und erst irgendwann später mit Hans/Roberta schauen, wie/wann/ob das in generelle Ontologien umgesetzt werden wird/kann/soll. (Selbstverständlich entscheiden wir von Nietzsche selber, was für uns sinnvoll ist.) 2.) Generelle Infos zu den Ontologien a) Klassen Wenn eine neue Klasse definiert wird, ohne dass eine andere, bereits bestehende Klasse subklassiert wird, dann muss diese neue Klasse eine Subklasse von knora-base:Resource sein: nietzsche:someclass a owl:Class; rdfs:label "someclass"@en, "IrgendeineEigenständigeKlasse"@de; rdfs:comment """Any class."""@en; rdfs:subClassOf knora-base:Resource. (Wird eine bestehende Ontologie-Klasse subklassiert, dann ist unsere Klasse freilich bereits eine Subklasse davon.) b) Properties Nicht jede Property soll freilich jedem Subjekt zur Verfügung stehen und nicht jedes Objekt zu jeder Property. Welche Objekte/Subjekte eine Property binden kann, wird mit knora-base:subjectClassConstraint bzw. knora-base:subjectClassConstraint definiert. https://docs.knora.org/paradox/02-knora-ontologies/knora-base.html#constraints-on-the-types-of-property-subjects-and-objects Die Property human:hasName soll beispielsweise nur für Instanzen der Klasse human:Person zur Verfügung stehen. Also wird dies mit knora-base:subjcetClassConstraint human:Person definiert. human:hasName a owl:ObjectProperty; rdfs:label "has name"@en, "hat Name"@de; rdfs:comment """Relating a person to a name of that person."""@en; rdfs:domain human:Person; rdfs:range rdfs:Literal; rdfs:subPropertyOf text:hasName; knora-base:subjectClassConstraint human:Person; knora-base:objectClassConstraint knora-base:TextValue. c) Values Irgendwann sollen ja auch Werte importiert und nicht nur Objekte angelegt werden. Beispiel: Ein Tupel in einer Relationalen DB resultiert ja immer in ein Triple Subjekt-->Prädikat-->Objekt in RDF. Soll nun ausder Tabelle "Personen", Spalte "Name", der Value "Steinbach" in RDF dargestellt werden, so resultiert dies in eine Instanz der Klasse Human:Person, welche die Property "human:hasName" hat. Der Value "Goethe" schliesslich resultiert in eine Objekt-Instanz der Klasse knora-base:TextValue. Analog zu den erlaubten Objektklassen wird bei Values ebenfalls angegeben, dass eine Property nur eine bestimmte Art von Values binden kann: human:hasName a owl:ObjectProperty; rdfs:label "has name"@en, "hat Name"@de; rdfs:comment """Relating a person to a name of that person."""@en; rdfs:domain human:Person; rdfs:range rdfs:Literal; rdfs:subPropertyOf text:hasName; knora-base:subjectClassConstraint human:Person; knora-base:objectClassConstraint knora-base:TextValue. Weitere Value-Klassen sind beispielsweise knora-base:DateValue, oder knora-base:fFileValue. https://docs.knora.org/paradox/02-knora-ontologies/knora-base.html#values # Nachtrag 1. Redundante Definition bestehender nie-Ontologie-Klassen Wenn eine bestehende nie-Klasse oder -property passt für unsere Daten, dann habe ich diese Klasse/Property noch einmal komplett als Projekt-Klasse definiert/Projekt-Property definiert, einfach mit unserem Namespace tln ("the late Nietzsche"). Gründe: Ich will nicht etwas passendes subklassieren und den Klassenbaum künstlich vergrössern/verkomplizieren, sondern das Bestehende lieber mit unseren Klassen parallel "verbreitern". So ist alles, was wir an Klassen/Properties benötigen/verwenden, an einem Ort formalisiert und dadurch auch gleich dokumentiert. Alles, was wir für den Import verwenden, wird gleich behandelt, egal, ob von NIE-INE bereits etwas potentiell passendes modelliert wurde oder ob wir etwas komplett neues modellieren. Wo es etwas gleiches/sinnvolles gibt wird einfach auf dieses verwiesen. (s. Punkt 3) In einem weiteren Schritt können wir dann über die tatsächliche Semantik der Dinge sprechen. Das macht das Ganze klarer trennbar, schneller ersichtlich und einfacher handhabbar/änderbar, denke ich. Der Import wird auf jeden Fall einfacher! es vereinfacht Subklassierung eigener Klassen/Properties --> "2. Subklassierung ..." 2. Subklassierung, Restrictions, constraints innerhalb der eigenen Ontologie Wenn wir innerhalb von unserer Ontologie etwas subklassieren wollen/müssen, dann wird dies einfach in unserer Ontologie per Subklassierung unserer eigenen Klasse gemacht. Ich will keine Mischzustände. Jede Restriction/jeder Constraint ... wird noch einmal für unsere Klassen/Properties definiert. 3. Verweis zu äquivalenten, bereits bestehenden Klassen/Properties Damit ersichtlich ist, ob bereits eine passende Klasse existiert in den nie-Ontologien, verweise ich darauf mittels OWL Klassenaxiomen und Properties. Dasselbe mache ich mit Klassen/Properties, die womöglich gleich/ähnlich heissen, aber bei Nietzsche doch anders sind als bei der allgemeinen Definition von nie-ine: Äquivalente Klasse: owl:equivalentClass --> https://www.w3.org/TR/owl-ref/#equivalentClass-def Ungleiche Klasse: owl:disjointWith --> https://www.w3.org/TR/owl-ref/#disjointWith-def Äquivalente Property: owl:sameAs https://www.w3.org/TR/owl-ref/#sameAs-def (Wichtig: Nicht https://www.w3.org/TR/owl-ref/#equivalentProperty-def) Ungleiche Property: owl:differentFrom https://www.w3.org/TR/owl-ref/#differentFrom-def 4. Kommentare Ferner versuche ich freilich gleich zu kommentieren, welche von unseren Datenklassen/-Typen schliesslich als Instanzen einer Ontologie-Klasse resultieren sollen. Beispiel 1: infocar:Collection scheint mir geeignet für unsere Manuscript-Sammlungen. Ich verwende diese Klasse aber nicht, sondern habe eine eigene, gleiche gemacht: tln:Collection <-- eigener namespace tln # Instantiation: each in project.xml <-- 4. Kommentar, welche Daten dafür vorgesehen sind a owl:Class; rdfs:label "information carrier collection"@en, "Informationsträger-Kollektion"@de, "collection des supports d'information"@fr; rdfs:comment """Information carriers brought together, e.g. an archive."""@en; owl:equivalentClass infocar:Collection; <-- 3. Verweis zu einer äquivalenten Klasse rdfs:subClassOf human:PhysicalCreation, [ <-- Subklassierung zu anderem bleibt einfach drin a owl:Restriction; owl:onProperty tln:hasCarrierDescription; owl:minCardinality "0"^^xsd:nonNegativeInteger]. <-- Restrictions auf die eigenen properties ändern Beispiel 2: Unser tln:Nachlass passt semantisch nicht ganz in infocar:Nachlass, da infocar:Nachlass den Nachlass über den Tod eines Autors definiert. Dies ist im Fall Nietzsches nicht korrekt. Deshalb: tln:Nachlass a owl:Class; rdfs:label "nachlass"@en, "Nachlass"@de; rdfs:comment """Set of information carriers as materialized expressions of Nietsches late work as existing after Nietzsches mental health issue and unpublished by him."""@en; owl:disjointWith infocar:Nachlass; <- 3. definition, dass infocar:Nachlass keine äquivalente Klasse ist. # ATTENTION: tln:Nachlass does NOT equal infocar:Nachlass as the later is defined by the death of its creator rdfs:subClassOf infocar:Set, cidoc:E78_Collection.