1.
Einleitung ^
2.1.
Allgemeine Bedeutung ^
Unter Abstraktion2 versteht man allgemein einen induktiven Denkprozess, der sich mit dem Weglassen von unwesentlichen Details befasst. Das Charakteristische, das Wesentliche, sowie Gesetzmäßigkeiten, werden dabei aus einer Menge von Individuen, also Dingen oder Beobachtungen, abgeleitet3. Der Duden führt zum Verb «abstrahieren» dementsprechend die Bedeutungen «aus dem Besonderen das Allgemeine entnehmen, verallgemeinern» und «von etwas, von sich absehen, auf etwas verzichten» aus. Die Beurteilung ob ein bestimmtes Detail wesentlich ist oder nicht, hängt in hohem Maße von Zweck und Ziel sowie vom Benutzerkreis der Abstraktion ab.
2.2.
Abstraktion in der Gesetzgebung ^
Um von der abstrakten, generellen Norm zur Anwendbarkeit in einem bestimmten Fall zu gelangen, muss der Rechtsanwender also zuerst den intellektuellen Vorgang der Interpretation durchführen. Zu diesem Zweck steht ihm der gesamte Kanon der juristischen Interpretationsmethoden zur Seite4.
Besondere Bedeutung erlangen diese Methoden bei unbestimmten Gesetzesbegriffen5, deren Anwendung eine juristisch und methodisch korrekte Interpretation im Einzelfall voraussetzt. Derartige unscharfe Begriffe kommen in Gesetzen auch in der Form von sogenannten «Härteklauseln» vor6, die danach trachten in Fällen «besonderer Härte» einen sozial gerechten Ausgleich zu schaffen. An den Rechtsanwender werden in solchen Fällen besonders hohe Anforderungen gestellt, was im Hinblick auf die Rechtssicherheit durchaus Probleme aufwerfen kann.
Solche Unschärfen des Gesetzes sind jedoch keinesfalls immer ein Versehen des Gesetzgebers. Vielmehr dienen derartige Klauseln als eine Art Sonderfall und sollen nach der Vorstellung des Gesetzgebers im Einzelfall für Gerechtigkeit sorgen. Die Behörde (oder das Gericht) ist jedoch dabei keinesfalls völlig ungebunden bei der Entscheidung, sondern ist dem Gemeinwohl und den Zielen des jeweiligen Gesetzes verpflichtet7.
2.3.
Abstraktion in der Softwareentwicklung ^
Wesentlich ist die Erkenntnis, dass die Grundlage jeder Software ein Modell ist, dessen Zweck die Abbildung und Lösung von Problemen des jeweiligen Fachbereichs8 ist. Dieses Modell besteht aus einer Vielzahl von Konzepten, die gerade jene Informationen des ursprünglichen Fachbereichs abbilden, die für die Lösung der vorhandenen Probleme relevant sind.
Dabei lassen sich verschiedene Ebenen der Abstraktion unterscheiden. Die bereits beschriebene Abstraktion auf Ebene des Softwaredesigns gewährleistet die möglichst effiziente Erstellung von Klassen9 und anderen Programmstrukturen.
Andererseits werden in serviceorientierten Architekturen mithilfe der Abstraktion jene Funktionalitäten identifiziert, die potentiell als Webservices implementiert werden können. Durch Abstraktionsvorgänge werden spezifische Details entfernt und aus einer Fülle von Funktionen jene identifiziert, die von allgemeiner Nützlichkeit sind. Diese gemeinsam verwendbaren Funktionalitäten werden dann schließlich in Form von Webservices10 implementiert. Die einzelnen Serviceschnittstellen sind dabei abstrakt beschrieben und definieren sozusagen einen Vertrag, an den sich jeder Verwender der Schnittstelle halten muss, will er mit dieser kommunizieren. Die konkrete Implementierung hinter dem Webservice bleibt vor dem Verwender verborgen.
3.1.
Allgemeine Problembeschreibung ^
3.2.
Bisherige Lösungsansätze ^
Der letzte Stand der Technik in der Softwareentwicklung ist die Verwendung von objektorientieren Programmiersprachen wie Java. Unterstützend werden dabei oft Sprachen wie UML12 eingesetzt, um zuerst ein grobes Modell einer Software – das im Wesentlichen die Klassen und Interfaces, sowie deren Attribute enthält – zu erstellen. Aus diesem Modell kann dann der Code der gewünschten Programmiersprache, z.B. Java, generiert werden.
Folgende Problemkreise lassen sich aus den bisherigen Ansätzen identifizieren:
- Juristen und Sachbearbeiter bedienen sich einer unterschiedlichen Syntax und Semantik als Softwareexperten13
- Die Sprachen zur Modellierung sind zu ausdrucksschwach um auch detaillierte Probleme wie z.B. Subsumtionsregeln, etc. zu modellieren.
- Die erstellten Modelle, z.B. UML Modelle, sind nicht direkt ausführbar. Erst in einem (automatisierten) Übersetzungsvorgang wird aus diesen der Programmcode generiert.
3.2.1.
Unterschiedliche Syntax und Semantik ^
3.2.2.
Mangelnde Ausdrucksstärke von Modellen ^
3.2.3.
Fehlende direkte Ausführbarkeit von Modellen ^
4.
Der ontologische Lösungsansatz ^
Eine Ontologie besteht im Wesentlichen aus Begriffen, wobei Beziehungen und Eigenschaften derselben durch einen Formalismus16 eindeutig spezifizierbar sind. So kann die Terminologie und Struktur des Gesetzes weitgehend direkt in das ontologische Modell übernommen werden. Den Juristen könnte so ermöglich werden, ein direkt ausführbares Modell des Gesetzes zu erstellen.
Durch Abstraktion erfolgt die Bildung und Kategorisierung von Begriffen in der Ontologie aus der normativen Grundlage. Zur besseren Strukturierung des ontologischen Modells, wird dieses zum einen aus einer Ontologie bestehen, die die Begrifflichkeit abbildet und aus einer zweiten, auf dieser aufsetzenden Ontologie, die Beschreibungen von Fällen und Normen enthält17.
5.
Schlussfolgerungen ^
6.
Literatur ^
[1] Püttner, Günter, Ermessen und Ermessensausübung, Gedanken zur Weiterentwicklung der Ermessenslehre. In: Zeitschrift für öffentliches Recht, Heft 63, S. 345–357 (2008).
[2] Bullinger, Martin, Das Ermessen der öffentlichen Verwaltung. In: Juristen Zeitung, Heft 39, S. 1001-1048 (1984).
[3] Bydlinski, Franz, Grundzüge der juristischen Methodenlehre, WUV, Wien (2005).
[4] Van de Ven, Saskia, Hoekstra, Rinke, Breuker, Joost, Wortel, Lars, El-Ali, Abdallah, Judging Amy: Automated Legal Assessment using OWL 2. Leibnitz Center for Law, University of Amsterdam (2008).
[5] Fiedler, Herbert, Formalisierung im Recht. In: Schweighofer, Erich, Liebwald, Doris, Kreuzbauer, Günther, Menzel, Thomas (Hersg.), Informationstechnik in der juristischen Realität, Verlag Österreich, Wien, S. 28-37 (2004).
[6] Bron, Mark, Eli-Ali, Abdallah, Ji, Xingrui, Klarman, Szymon, Modeling Nomic in LKIF-Core Ontology, Leibniz Center for Law, University of Amsterdam (2007).
[7] Breuker, Joost, Hoekstra, Rinke, Boer, Alexander (Hersg.), Van den Berg, Kasper (Hersg.), Deliverable 1.4, OWL Ontology of Basic Legal Concepts (LKIF-Core), ESTRELLA Project (2007).
[8] Bloch, Joshua, Effective Java, Second Edition, Addison-Wesley (2008).
[9] Freeman, Eric, Freeman, Elisabeth, Head First Design Patterns, O’Reilly (2004).
[10] Gosh, Debasish, DSLs in Action, Manning (2011).
[11] Brook, Andrew, Approaches to abstraction: A commentary. In: International Journal of Educational Research, Heft 27(1), S. 77-88 (1997).
[12] Goldstein, Robert, Storey, Veda, Data abstractions: Why and how? In: Data & Knowledge Engineering, Heft 29, S. 293-311 (1999).
Johannes Scharf, Dissertant, Universität Wien, Arbeitsgruppe Rechtsinformatik.
- 1 BGBl. Nr. 152/1957.
- 2 Wikipedia, Abstraktion. http://de.wikipedia.org/wiki/Abstraktion aufgerufen 10.1.2013.
- 3 Siehe [11].
- 4 Vgl. [3], S. 11 ff.
- 5 Auch «Generalklauseln» genannt.
- 6 Vgl. § 76 KOVG.
- 7 Siehe [1] und [2].
- 8 Im Kontext der Dissertation sind dies vor allem das KOVG und die auf dessen Grundlage erlassenen Verordnungen.
- 9 Eine «Klasse» ist in diesem Kontext der wohl wesentlichste Bestandteil in der objektorientieren Programmierung. Eine Software kann daher letztendlich als eine Vielzahl von Klassen verstanden werden, die auf gewisse Art und Weise miteinander interagieren.
- 10 Ein «Webservice» ist eine Schnittstelle einer Software, die einen der verfügbaren Standards für die Datenübertragung (zumeist SOAP oder REST) verwendet.
- 11 Bei «Weisungen» handelt es sich um behördeninterne Anweisungen, die u.a. anordnen, wie in bestimmten Sachverhalten zu verfahren ist. Sie konkretisieren also unter Umständen Gesetze und Verordnungen näher.
- 12 Unified Modeling Language.
- 13 Vgl. insbes. [10], S. 3 ff.
- 14 A core ontology of basic legal concepts. http://www.estrellaproject.org/?page_id=3 aufgerufen: 10.1.2013.
- 15 Siehe [7].
- 16 In diesem Fall OWL 2.
- 17 Vgl. insbes. [4].
- 18 «Schlussfolgerung».