sdtl provone
1.0.0
Diese Arbeit wurde durch das SDTH-Datenmodell überholt, das im Hinblick auf Prov-Konzepte abgefragt werden kann.
Dieses Repository basiert auf dem ProvONE-SDTL-Datenmodell.
Der Zweck des Datenmodells besteht darin, in SDTL dargestellte Informationen in das ProvONE-Datenmodell umzuwandeln, sodass Abfragen mithilfe der ProvONE-Syntax durchgeführt werden können.
Zielabfragen:
Alle diese Abfragen können in Bezug auf ProvONE neu formuliert werden
Eines der Hauptziele bei der Festlegung eines Identifikatorschemas besteht darin, für besser lesbare Identifikatoren zu sorgen. Dies ist besonders wichtig für das Lesen von Abfrageergebnissen. Die Namenskonvention für Bezeichner wurde dem Abschnitt Patterned URIs in „Linked Data Patterns“ entnommen.
Die allgemeine Form ist:
#camelCaseClass/{current_type_count} . Dabei ist {current_type_count} die Anzahl des jeweiligen Objekts.
Jedes Objekt sollte, wenn möglich und angemessen, ein rdfs:label haben. Die Objekte provone:Workflow und provone:Execution der obersten Ebene können vordefinierte Beschriftungen haben, da sie eindeutige Knoten mit einem bestimmten Zweck darstellen.
Die Objekte provone:Program und provone:Execution auf Skriptebene verfügen ebenfalls über Beschriftungen, sodass jeder Abfrager weiß, dass er Entitäten beobachtet, die Skriptdateien ähneln.
Das Zielformat ist JSON-LD; rdflib verfügt über ein Plugin zur Umwandlung seines Diagrammmodells in JSON-LD. Turtle lässt sich immer noch am einfachsten mit dem Auge analysieren, daher werden die Beispiele in diesem Dokument in Turtle bereitgestellt. Beispiele im Verzeichnis examples/ sind sowohl in Turtle als auch in JSON-LD verfügbar.
Da sich das Modell auf ProvONE-Abfragen konzentriert, die auf Fragen zum Datenfluss abzielen, ist die zugrunde liegende Architektur überwiegend ProvONE.
ProvONE hat die Fähigkeit, Workflows und Sammlungen von Ausführungen darzustellen, provone:Workflow & provone:Exection . Diese werden am häufigsten verwendet, um die Ausführung einer Reihe von Skripten oder die Existenz einer Reihe darzustellen. Beachten Sie, dass diese ungeordnet sind.
Jede ProvONE-Darstellung verfügt über eine ähnliche äußere Struktur zur Darstellung der Skriptsammlung. Prospective Provenance sammelt jeden script-representing-node unter einem provone:Workflow; Retrospective Provenance sammelt jeden Skriptausführungsknoten unter einer provone:Execution.
Jedes zukünftige Modell verfügt über ein provone:Program, das das von C2Metadata analysierte Skript darstellt, und einen provone:Workflow, zu dem das Skript gehört. Jedes provone:Programm auf Skriptebene ist an den provone:Workflow angehängt.
Betrachten Sie zwei Quelldateien in einem einzigen Datenpaket. Ein einzelnes provone:Workflow Objekt enthält beide Knoten, die die Datei darstellen.
Jedes retrospektive Modell verfügt über eine provone:Execution, die die hypothetische Ausführung eines Skripts darstellt, das von C2Metadata analysiert wurde. Jedes provone:Execution-Objekt, das ein Skript darstellt, wird an die oberste Ebene von provone:Execution angehängt
Die retrospektive Provenienz wird ähnlich beschrieben. In diesem Fall gibt es jedoch keinen spezifischen Typ, der eine „Sammlung“ von Hinrichtungen bezeichnet. Stattdessen kann wasPartOf zur Bezeichnung der Gruppierung verwendet werden.
Befehle innerhalb einer Skriptdatei werden mit den Objekten provone:Program und provone:Execution definiert. Die Objekte, die den Datenfluss zwischen diesen Objekten beschreiben, sind die Standardobjekte provone:Port und provone:Entity .
Dies kann anders ausgedrückt werden: Jedes SDTL-Objekt mit der Basisklasse CommandBase wird in ein provone:Program oder provone:Execution übersetzt. Alternativ: Jedes JSON-Objektobjekt, das sich im SDTL-Array „commands“ befindet, wird einem provone:Program oder provone:Execution zugeordnet.
Beachten Sie, dass die SDTL zwar in Bezug auf die Befehlsausführung angeordnet werden kann, ProvONE jedoch kein Objekt hat, das die Reihenfolge kodieren kann.
Befehle beziehen sich über provone: provone:hasSubProgram Program. Nehmen Sie zum Beispiel ein Skript, das vier Befehle enthält. Diese werden in ProvONE wie folgt modelliert:
Der Datenfluss im zukünftigen ProvONE nutzte die Objekte provone:Port und provone:Workflow . Betrachten Sie beispielsweise dieses SDTL-Snippet, das einen „Load“-Befehl darstellt. Beachten Sie, dass sich der Befehl im Array „commands“ befindet.
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
Aus der Art des Befehls ist ersichtlich, dass eine Datei verwendet wird. Diese Datei wird als port/1 dargestellt. Aus producesDataFrame können wir schließen, dass ein neuer Port erstellt wird, um den Datenrahmen darzustellen, port/2 .
Wenn ein zweiter Befehl hinzugefügt wird, der den Datenrahmen verwendet, wird das provone:Channel Objekt verwendet, um das Port-Objekt zu verbinden. Betrachten Sie beispielsweise die folgende SDTL, die einen „Lade“-Befehl beschreibt, und dann einen Befehl, der seinen Datenrahmen verwendet und einen neuen erzeugt.
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
},
{
"$type": "Compute",
"consumesDataframe": [
{
"dataframeName": "df",
}
"producesDataframe": [
{
"dataframeName": "df"
}
}
]
Visuell,
Diese Form kann wiederholt werden, um beliebig lange Datenflussketten zwischen Befehlen in einem Skript zu bilden. Das Formular verwendet immer den Typ provone:Program zur Darstellung des Befehls und den provone:Port zur Darstellung einer Datei oder eines Datenrahmens.
Die retrospektive Herkunft funktioniert auf ähnliche Weise, indem Befehle als Unterausführungen der Ausführung einer übergeordneten Skriptdatei dargestellt werden.
Das folgende Bild zeigt ein Skript, das vier Befehle enthält.
Der Datenfluss bei retrospektiver Provenienz ist etwas komplizierter als bei prospektiver Provenienz.
Mithilfe des „Laden“-Befehls SDTL, der für die prospektive Herkunft verwendet wurde,
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
In der Abbildung unten stellt entity/1 die Datei dar, die vom Befehl verwendet wird. entity/2 stellt den Datenrahmen dar, der erstellt wurde.
Die Objekte provone:Port und provone:Entity im obigen Abschnitt können für zusätzliche Abfragen nützlicher sein, wenn einige der Metadaten über den Datenrahmen erhalten bleiben.
Eine vollständige Datenrahmenbeschreibung enthält Informationen zu den darin enthaltenen Variablen und den Namen des Datenrahmens im Quellcode. Stellen Sie sich einen Befehl vor, der einen Datenrahmen aus einer Datei lädt, der Variablen enthält.
{
"$type": "Load",
"command": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
],
}
Das Datenrahmenobjekt hat unter ProvONE die folgende RDF-Darstellung. Beachten Sie, dass der Wurzelknoten ein provone:Port ist.
Die Datenrahmenobjekte können an den provone:Port angehängt werden, mit dem sie verknüpft sind. Nehmen Sie zum Beispiel die folgende SDTL, die einen Datenrahmen aus einer Datei lädt und dann liest und den Datenrahmen in einem neuen Befehl verwendet.
{
"$type": "Load",
"command": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
]
},
{
"$type": "Compute",
"command": "Compute",
"consumesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
],
"producesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
]
}
Beachten Sie, dass in diesem Fall der zweite Datenrahmen, port/4 dieselben Attribute wie port/2 hat. Dies bedeutet nicht , dass die beiden Datenrahmen gleich sind. Der Status seiner Variablen kann unterschiedlich sein. Dieses Modell ist nicht daran interessiert zu fragen, wie sie sich unterscheiden.
Das ProvONE-Modell kann um zusätzliche Eigenschaften aus der SDTL erweitert werden. Dies kann durchgeführt werden, um einen besseren Kontext darüber bereitzustellen, was in jedem Befehl passiert ist. Jeder SDTL-Befehl hat eine andere Metadatenstruktur für den Befehlstyp.
Beispielsweise verfügt der Befehl „KeepCases“ über eine Eigenschaft namens „condition“.
Der Befehl „renames“ verfügt über eine Eigenschaft namens „renames“.
Diese sind alle an das unten gezeigte provone:Programm auf Befehlsebene angehängt
Es scheint, dass das provone:Program, das einen Befehl darstellt, auch eine SDTL CommandBase sein kann. Dies ermöglicht nahtlosere Hybridabfragen,
Was ist das provone:Programm, das auch ein sdlt:Load ist?
Was sind die provone:Ports für alle Befehle vom Typ sdtl:Load?
Was sind die Eingabeprovone:Ports für den Befehl sdt:Load mit der X-Eigenschaft?
Das vorgeschlagene Modell wandelt sdtl:CommandBase-Objekte in provone:Program-Objekte um, fügt eine Datenrahmendarstellung an seine provone:Port-Objekte an und hängt ausgewählte SDTL-Eigenschaften an das provone:Program an.
Dieses Modell ermöglicht die Abfrage des Datenflusses durch das Skript mithilfe von ProvONE. Die zusätzlichen SDTL-Objekte (SourceInformation, Ausdruck usw.) können mithilfe der SDTL-Sprache abgefragt werden, um weitere Informationen zum betreffenden Befehl zu ermitteln.
