Inferencing

Inferencing#

REDAKTION

Inferencing vs. Reasoning: mechanisches Ableiten, Ausmaterialisieren vs. menschliche Logik

In diesem Skript nur RDFS und OWL: Open World Assumption (OWA); keine Unique Name Assumption (UNA) … Das geht mit OWL und RDFS in der Theorie; Negation ist komplex und teuer; Wunsch nach Monotonie; Vorsicht vor RDF full; RDFS ist langweilig; praxistaugliche OWL2-Profile; … alternative wäre F-Logik: Kiefner 1995, Angele und Angele 2016 (?)

Zunehmend komplexere Aufgaben: Entailment = Ableitung von Beziehungen; Integrität = Identifikation von problematischen Exemplaren; Skolemisierung: Erzeugung neuer Knoten

Zustand des Textes: nur skizzenhaft, cursorisch. Verweis bzgl. Inferencing auf dedizierte andere Publikationen.

Entailment#

REDAKTION

Entailment: Ableitung, explizit machen von implizit bereits enthaltenem Wissen … keine Skolemisierung, keine neue Knoten, sondern “nur” neue Relationen – aber auch das ist schon viel … Beispiele zeigen mit Code: “im Prinzip” hier, ausführbar dann extern: vor allem auch hier Links nach draußen anlegen

ZWAR:

This specification introduces an RDF vocabulary for describing the meaningful use of properties and classes in RDF data. For example, an RDF vocabulary might describe limitations on the types of values that are appropriate for some property, or on the classes to which it makes sense to ascribe such properties. (https://www.w3.org/TR/rdf-schema/#ch_domainrange, auch https://www.w3.org/TR/rdf12-schema/#ch_domainrange)

ABER auch:

The basic facilities provided by rdfs:domain and rdfs:range do not provide any direct way to indicate property restrictions that are local to a class.(https://www.w3.org/TR/rdf12-schema/#ch_properties)

Entailment-regeln in der RDFS-Spezifikation: rdfs:domain und rdfs:range als Entailment-Regel … Beispiel …

unintuitive Nebenfolgen

Diskussion: Semantische Netzwerke und REL-Semantik e_rel-semantik

ggf. nur online:

  • Fehl-Konzeptionen mit domain und range ..

  • auch als Beispiel OpenWEMI? besser nur Online

RDFS entailment#

Anknüpfen an RDF (Inhalte siehe lesson-rdf12-im-detail) … dann das “S” erklären in RDFS

RDF Schema 1.1, W3C Recommendation 25 February 2014, https://www.w3.org/TR/rdf11-schema/

Entailment, logische Ableitung, ausmaterialisieren, implizites Wissen explizit machen:

RDF 1.1 Semantics, W3C Recommendation 25 February 2014, https://www.w3.org/TR/rdf11-mt/

RDF 1.1 Turtle, Terse RDF Triple Language. W3C Recommendation 25 February 2014 https://www.w3.org/TR/turtle/

BEISPIEL ONLINE

RDFS plus

Grundlagen:

OWL Entailment#

REDAKTION

Nur die Basis (aber immerhin): Restrictions … sind keine Restriktionen, kein Integritätscheck, sondern Entailment-Regeln … OWL1 vs. OWL2; OWL DL, OWL lite, OWL2 RL … Python Inferencing Engine: owlrl

BEISPIELE ONLINE

Integrität#

REDAKTION

Integritäts-Checks: Das, was man eigentlich will … eigentlich SHACL und ShEx, aber das geht über unsere Einführung hinaus … hier ein ergänzender Ansatz: Integrität durch Entailment und Klassifikation von Exemplaren als “problematisch” … dadurch erhalten wir eine mit RDFS und OWL kompatible formale Semantik für UML-Diagramme in Specs wie insbesondere DCAT

Unser Kontext ist govdata.de, ein Verzeichnis offenener Matadaten. Die Datensätze in govdata müssen einem Schema gehorchen, nämlich DCAT-AP (im Folgenden kurz für https://www.dcat-ap.de/def/dcatde/2.0/spec/, einer Spezialisierung von DCAT2, dem Vorgänger von aktuell https://www.w3.org/TR/vocab-dcat-3/).

Wie viele andere Recommendations auch verwendet DCAT-AP Begriffe aus https://www.rfc-editor.org/rfc/rfc2119.txt, insbesondere DE-Äquivalente von MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, siehe https://www.dcat-ap.de/def/dcatde/2.0/spec/#terminologie-und-definitionen:

Die Begriffe MUSS, SOLL und KANN werden in diesem Dokument entsprechend ihren in RFC2119 definierten Bedeutungen verwendet, wenn sie wie hier gezeigt durchgehend groß geschrieben wurden.

  • Verpflichtende Klasse: Sender MÜSSEN Informationen über Instanzen dieser Klasse zur Verfügung stellen. Empfänger MÜSSEN Informationen über Instanzen dieser Klasse verarbeiten können.

  • Empfohlene Klasse: Sender SOLLEN Informationen über Instanzen dieser Klasse zur Verfügung stellen. Sender MÜSSEN Informationen über Instanzen dieser Klasse zur Verfügung stellen, falls solche Informationen verfügbar sind. Empfänger MÜSSEN Informationen über Instanzen dieser Klasse verarbeiten können.

Nun ist DCAT-AP in Form eines RDF(S) Vokabular definiert. Bekanntermaßen kann man in RDF(S) keine Integrity Constraints abbilden. Diese Lücke füllt u.A. die normalsprachliche Beschreibung. Beispiel 4.3 Klasse: Datensatz:

Wir stellen fest:

  • “Pflicht” wird mit einer Kardinalität [1..*] gleichgesetzt

  • “Empfohlen” (lauf rfc2119 synonym mit “Optional”) wird mit einer Kardinalität [*] gleichgesetzt

In OWL lässt sich die Kardinalität abbilden, aber das Kardinalität-Inferencing ist kompliziert und teuer. Auch spielt meines Wissens nach OWL für DCAT-AP keine Rolle.

Für DCAT-AP liegt ein Validator vor, siehe z.B. https://www.itb.ec.europa.eu/shacl/dcat-ap/upload. Der Validator überprüft die Norm-Konformität eines RDF-Datensatzes mit Hilfe der Shapes Constraint Language (SHACL). Persönlicher Kontakt mit den Maintainern von govdata.de zeigt, dass die SHACL-Regeln teils automatisch, teil händisch erzeugt und fortgeschrieben werden. Letztlich definiert ein solcher Validator die “Semantik” der rfc2119-Begriffe prozedural durch eine Referenz-Implementierung.

Fragen:

  • Welche weiteren Möglichkeiten gibt es, die RFC2119-Begriffe zu interpretieren?

  • Lässt sich sogar eine Abbildung auf eine Modallogik denken?

  • Welche Modallogik: epistemisch? deontisch?

  • Wie lassen sich solche modalen Interpretationen von RFC2119-Begriffen wieder in einer Ontologie abbilden?

  • Wo können wir die Fähigkeiten von OWL- oder anderen Reasonern nutzen; wo wollen wir mit SPARQL arbeiten; wo mit SHACL?

  • Wie passt das alles zusammen?

RFC 2119#

rfc2119>

https://www.rfc-editor.org/rfc/rfc2119

  1. MUST This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.

  2. MUST NOT This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.

  3. SHOULD This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

  4. SHOULD NOT This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

  5. MAY This word, or the adjective “OPTIONAL”, mean that an item is truly optional. […]

Modallogik#

Umgangssprache … verboten - erlaubt - geboten … intuitiv könnte man drei “Modi” in einer Reihe anordnen: verboten - erlaubt - geboten. … Jeder dieser 3 Modi kann man syntaktisch mit einer Negation versehen werden: nicht {geboten|erlaubt|verboten}; und auch jeweils die Handlung. Damit sind Sätze möglich wie:

  • g(h): Es ist geboten zu helfen

  • ¬g(h): Es ist nicht geboten zu helfen

  • g(¬h): Es ist geboten nicht zu helfen

  • ¬g(¬h): Es ist nicht geboten nicht zu helfen

Schöne fachliche Einführung für Menschen mit formalwissenschaftichem Hintergrund: [Gar14] https://plato.stanford.edu/archives/win2014/entries/logic-modal/ … auch [Joe10] (S.210), leicht modifiziert in https://scilogs.spektrum.de/die-natur-der-naturwissenschaft/erweiterungen-der-aussagenlogik/ …

Ergebnis: (a) in der Welt von sollen, werden, wissen haben wir die Wahl zwischen verschiedenen Glasperlenspielen; (b) fast überall verbergen sich unintuitive Stolperfallen; (c) für unsere Zwecke zu komplex!

In addition to the TDS, it was traditionally assumed that the following, call it “The Traditional Threefold Classification (TTC)” holds: […] three boxes containg respectively the words Obligatory, Optional, and Impermissible. Obligatory and Optional are braced as Permissible; Obligatory and Impermissible are braced as Non-Optional, and Optional and Impermissilbe are braced as Omissible. (<TDS aus https://plato.stanford.edu/entries/logic-deontic/)

ABBILDUNG

Ergebnis: (a) in der Welt von sollen, werden, wissen haben wir die Wahl zwischen verschiedenen Glasperlenspielen; (b) fast überall verbergen sich unintuitive Stolperfallen; (c) für unsere Zwecke zu komplex!

rfc2119 in GenDifS#

Interpretation von rfc2119 zur Implementierung von Integritätsregeln in GenDifS (Text 2024-09-20).

Beispiel. Wir nehmen an, dass wir als Arbeitgeber in einem Bewerbungsverfahren die Klasse “Person” modellieren wollen. Ein Kollege legt in seiner Excel-Tabelle folgende Spalten an:

Person:

  • Berufsabschluss

  • SteuerID

  • Vorstrafen

  • sexuelle Orientierung

Interpretation:

  • Der Berufsabschluss ist ganz klar ein MUST im Sinne von rfc2119: Ohne einen passenden Berufsabschluss ist ein Bewerbungsverfahren schwierig.

  • Die SteuerID ist ein SHOULD: Wenn es eine solche gibt, muss sie aus Steuergründen mit aufgenommen werden. Wenn wir sie nicht kennen oder erst nachträglich beantragen können, können wir vorläufig einen Dummy-Wert eintragen: Entweder eine Markierung für “unbekannt”, oder einen ad-hoc generierten eindeutigen Wert, den man später dann auf die tatsächliche SteuerID mappen kann.

  • Ein rfc2119-SHOULD NOT ist die Frage nach Vorstrafen: Im allgemeinen ist sie verboten, aber gibt Ausnahmen:

[…] wenn eine Information wesentlich ist für die ausgeschriebene Tätigkeit, dann ist auch eine standardmäßig verbotene Frage möglicherweise erlaubt. So kann für Positionen mit Budgetverantwortung die Frage nach Verurteilungen wegen Betrug, Unterschlagung oder Veruntreuung und ähnliche Straftaten zulässig sein – aber nicht die pauschale Frage nach Vorstrafen. (https://www.agrobrain.de/news/rund-um-die-bewerbung/verbotene-fragen-und-deren-ausnahmen-im-vorstellungsgespraech)

  • Ein klares rfc2119-MUST NOT wäre die Frage nach der sexuellen Orientierung, denn die Persönlichkeitsrechte der Person verbieten diese Information.

Im folgenden eine Skizze, wie rfc2119 in GenDifS interpretiert werden könnte:

MUST, REQUIRED, SHALL#

an absolute requirement of the specification.

GenDifS, normativ: Wenn das Item fehlt, ist der Record fehlerhaft

  • eine Reperatur ist nicht möglich

  • auch Default-Werte sind nicht zulässig

  • Was tun, wenn der Typ nicht stimmt?

    • beim nur einzigen Item: Fehler!

    • bei mehreren Items: Mindestens eines muss stimmen; denn wegen der OWA können wir nicht ausschließen, dass es irgendwo anders noch andere Werte gibt, und das schon gar nicht überprüfen.

MAY, OPTIONAL#

One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.

In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

GenDifS:

  • Wenn ein Item als OPTIONAL markiert wird reklamieren wir, dass es für uns eine bestimmte Bedeutung hat

  • Mitteilung an den Leser (allgemein: an Downstream Agenten), dass wir hier einen Controlled Term haben;

MUST NOT, SHALL NOT#

an absolute prohibition of the specification.

GenDifS:

  • GenDifS, normativ: Wenn das Item vorkommt, ist der Record fehlerhaft

Contents