sdtl provone
1.0.0
Ce travail a été rendu obsolète par le modèle de données SDTH, qui peut être interrogé en termes de concepts prov.
Ce référentiel couvre le modèle de données ProvONE-SDTL.
L'objectif du modèle de données est de prendre les informations représentées dans SDTL et de les transformer en modèle de données ProvONE, permettant ainsi d'effectuer des requêtes à l'aide de la syntaxe ProvONE.
Requêtes cibles :
Toutes ces requêtes peuvent être reformulées en termes de ProvONE
L'un des principaux objectifs de la spécification d'un schéma d'identification est de garantir des identifiants plus lisibles par l'homme. Ceci est particulièrement important pour lire les résultats des requêtes. La convention de dénomination des identifiants est tirée de la section Patterned URIs dans Modèles de données liées.
La forme générale est,
#camelCaseClass/{current_type_count} . où {current_type_count} est le nombre de l'objet particulier.
Chaque objet doit avoir une rdfs:label lorsque cela est possible et approprié. Les objets provone:Workflow et provone:Execution de niveau supérieur peuvent avoir des étiquettes prédéfinies car ils représentent des nœuds uniques avec un objectif spécifique.
Les objets provone:Program et provone:Execution au niveau du script ont également des étiquettes, permettant à tout interrogeur de savoir qu'il observe des entités qui ressemblent à des fichiers de script.
Le format cible est JSON-LD ; rdflib dispose d'un plugin pour transformer son modèle graphique en JSON-LD. Turtle est toujours le plus simple à analyser à l'œil nu, c'est pourquoi les exemples de ce document sont fournis dans Turtle. Les exemples du répertoire examples/ sont à la fois en Turtle et en JSON-LD.
Étant donné que le modèle est centré sur les requêtes ProvONE ciblant des questions sur le flux de données, l'architecture sous-jacente est principalement ProvONE.
ProvONE a la capacité de représenter des flux de travail et des collections d'exécutions, provone:Workflow & provone:Exection . Ceux-ci sont le plus souvent utilisés pour représenter l’exécution d’une série de scripts ou l’existence d’une série. Notez que ceux-ci ne sont pas ordonnés.
Chaque représentation ProvONE aura une structure externe similaire pour représenter la collection de scripts. La provenance potentielle collecte chaque nœud représentant le script sous un provone:Workflow ; la provenance rétrospective collecte chaque nœud d'exécution de script sous un provone:Execution.
Chaque modèle potentiel aura un provone:Program qui représente le script analysé par C2Metadata et un provone:Workflow auquel appartient le script. Chaque provone:Program au niveau du script est attaché au provone:Workflow.
Considérez deux fichiers sources dans un seul package de données. Un seul objet provone:Workflow contient les deux nœuds qui représentent le fichier.
Chaque modèle rétrospectif aura une provone:Execution qui représente l'exécution hypothétique d'un script analysé par C2Metadata. Chaque objet provone:Execution qui représente un script sera attaché au niveau supérieur provone:Execution.
La provenance rétrospective est décrite de la même manière. Dans ce cas cependant, il n’existe pas de type spécifique pour désigner un « ensemble » d’exécutions. Au lieu de cela, wasPartOf peut être utilisé pour désigner un regroupement.
Les commandes à l'intérieur d'un fichier de script sont définies avec les objets provone:Program et provone:Execution . Les objets décrivant le flux de données entre ces objets sont les standards provone:Port et provone:Entity .
Cela peut être reformulé : chaque objet SDTL qui a la classe de base CommandBase est traduit en provone:Program ou provone:Execution. Alternativement : chaque objet objet JSON qui se trouve dans le tableau "commandes" SDTL est mappé à un provone:Program ou provone:Execution.
Notez que bien que le SDTL puisse être ordonné en ce qui concerne l'exécution de la commande, ProvONE n'a pas d'objet capable de coder l'ordre.
Les commandes sont liées au niveau du script provone:Program via provone:hasSubProgram . Prenons par exemple un script contenant quatre commandes. Ceux-ci sont modélisés dans ProvONE comme suit :
Le flux de données dans le futur ProvONE utilisait les objets provone:Port et provone:Workflow . Par exemple, considérons cet extrait de SDTL qui représente une commande « Charger ». Notez que la commande est dans le tableau "commandes".
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
D'après le type de commande, il est clair qu'un fichier est utilisé. Ce fichier est représenté par port/1 . De producesDataFrame nous pouvons déduire qu'un nouveau port est créé pour représenter la trame de données, port/2 .
Si une deuxième commande est ajoutée, celle qui utilise la trame de données, alors l'objet provone:Channel sera utilisé pour connecter l'objet port. Par exemple, considérons le SDTL ci-dessous qui décrit une commande « Charger », puis une commande qui utilise sa trame de données et en produit une nouvelle.
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
},
{
"$type": "Compute",
"consumesDataframe": [
{
"dataframeName": "df",
}
"producesDataframe": [
{
"dataframeName": "df"
}
}
]
Visuellement,
Cette forme peut être répétée pour former des chaînes arbitrairement longues de flux de données entre les commandes d'un script. Le formulaire utilisera toujours le type provone:Program pour représenter la commande et le provone:Port pour représenter un fichier ou une trame de données.
La provenance rétrospective fonctionne de la même manière dans la mesure où les commandes sont représentées comme des sous-exécutions de l'exécution d'un fichier de script parent.
L'image suivante représente un script contenant quatre commandes.
Le flux de données avec provenance rétrospective est un peu plus complexe que la provenance prospective.
À l'aide de la commande SDTL 'Charger' qui a été utilisée pour la provenance prospective,
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
Dans l'image ci-dessous, entity/1 représente le fichier utilisé par la commande. entity/2 représente le bloc de données qui a été créé.
Les objets provone:Port & provone:Entity dans la section ci-dessus peuvent être plus utiles pour des requêtes supplémentaires si certaines métadonnées sur la trame de données sont préservées.
Une description complète du bloc de données contient des informations sur les variables à l'intérieur et le nom du bloc de données dans le code source. Considérons une commande qui charge un bloc de données contenant des variables à partir d'un fichier,
{
"$type": "Load",
"command": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
],
}
L'objet de trame de données a la représentation RDF suivante sous ProvONE. Notez que le nœud racine est un provone:Port.
Les objets de trame de données peuvent être attachés au provone:Port auquel il est associé. Prenons par exemple le SDTL suivant qui charge une trame de données à partir d'un fichier, puis lit, utilise la trame de données dans une nouvelle commande.
{
"$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"
]
}
]
}
Notez que dans ce cas, la deuxième trame de données, port/4 a les mêmes attributs que port/2 . Cela ne signifie pas que les deux trames de données sont identiques. L'état de ses variables pourrait être différent. Ce modèle n'est pas intéressé à demander en quoi ils sont différents.
Le modèle ProvONE peut être étendu pour inclure des propriétés supplémentaires du SDTL. Cela peut être fait pour fournir un meilleur contexte sur ce qui s'est passé au sein de chaque commande. Chaque commande SDTL possède une structure de métadonnées différente pour le type de commande.
Par exemple, la commande KeepCases possède une propriété appeléecondition.
La commande renames possède une propriété appelée renames.
Ceux-ci sont tous attachés au programme provone:Program au niveau de la commande, illustré ci-dessous.
Il semble que le provone:Program représentant une commande puisse également être une CommandBase SDTL. Cela permet des requêtes hybrides plus transparentes,
Quel est le programme provone: qui est également un sdlt: Load ?
Quels sont les provone:Ports vers toutes les commandes de type sdtl:Load ?
Quelles sont les entrées provone:Ports de la commande sdt:Load avec la propriété X ?
Le modèle proposé transforme les objets sdtl:CommandBase en objets provone:Program, attache une représentation de bloc de données à ses objets provone:Port et attache les propriétés SDTL sélectionnées au provone:Program.
Ce modèle permet d'interroger le flux de données via le script, à l'aide de ProvONE. Les objets SDTL supplémentaires (SourceInformation, expression, etc.) peuvent être interrogés à l'aide du langage SDTL pour déterminer plus d'informations sur la commande en question.
