sdtl provone
1.0.0
Este trabajo ha quedado obsoleto por el modelo de datos SDTH, que puede consultarse en términos de conceptos de prueba.
Este repositorio analiza el modelo de datos ProvONE-SDTL.
El propósito del modelo de datos es tomar información representada en SDTL y transformarla en el modelo de datos ProvONE, permitiendo realizar consultas utilizando la sintaxis ProvONE.
Consultas de destino:
Todas estas consultas se pueden reformular en términos de ProvONE.
Uno de los principales objetivos de especificar un esquema de identificador es garantizar identificadores más legibles por humanos. Esto es particularmente importante para leer los resultados de la consulta. La convención de nomenclatura para los identificadores se tomó de la sección Patterned URIs en Patrones de datos vinculados.
La forma general es,
#camelCaseClass/{current_type_count} . donde {current_type_count} es el recuento del objeto en particular.
Cada objeto debe tener una rdfs:label cuando sea posible y apropiado. El objeto de nivel superior provone:Workflow y provone:Execution puede tener etiquetas predefinidas porque representan nodos únicos con un propósito específico.
Nivel de script provone:Program y provone:El objeto de ejecución también tiene etiquetas, lo que le permite a cualquier solicitante saber que está observando entidades que se parecen a archivos de script.
El formato de destino es JSON-LD; rdflib tiene un complemento para convertir su modelo gráfico en JSON-LD. Turtle sigue siendo el más fácil de analizar a simple vista, por lo que los ejemplos de este documento se proporcionan en Turtle. Los ejemplos en el directorio examples/ están tanto en Turtle como en JSON-LD.
Debido a que el modelo se centra en consultas ProvONE dirigidas a preguntas sobre el flujo de datos, la arquitectura subyacente es predominantemente ProvONE.
ProvONE tiene la capacidad de representar flujos de trabajo y colecciones de ejecuciones, provone:Workflow y provone:Exection . Se utilizan más comúnmente para representar la ejecución de una serie de guiones o la existencia de una serie. Tenga en cuenta que estos están desordenados.
Cada representación de ProvONE tendrá una estructura exterior similar para representar la colección de guiones. La procedencia prospectiva recopila cada nodo que representa el script bajo un provone:Workflow; La procedencia retrospectiva recopila cada nodo de ejecución de script bajo un provone:Execution.
Cada modelo potencial tendrá un provone:Programa que representa el script analizado por C2Metadata y un provone:Workflow al que pertenece el script. Cada provone:Program a nivel de script se adjunta al provone:Workflow.
Considere dos archivos fuente en un único paquete de datos. Un único objeto provone:Workflow contiene ambos nodos que representan el archivo.
Cada modelo retrospectivo tendrá un provone:Ejecución que representa la ejecución hipotética de un script analizado por C2Metadata. Cada objeto provone:Execution que representa un script se adjuntará al nivel superior provone:Execution
La procedencia retrospectiva se describe de manera similar. Sin embargo, en este caso no existe un tipo específico que denote una "colección" de ejecuciones. En cambio, wasPartOf se puede utilizar para indicar agrupación.
Los comandos dentro de un archivo de script se definen con los objetos provone:Program y provone:Execution . Los objetos que describen el flujo de datos entre estos objetos son el estándar provone:Port y provone:Entity .
Esto se puede reformular: cada objeto SDTL que tiene la clase base CommandBase se traduce en un provone:Program o provone:Execution. Alternativamente: cada objeto JSON que se encuentra en la matriz de "comandos" SDTL se asigna a un provone:Program o provone:Execution.
Tenga en cuenta que aunque el SDTL puede ordenarse con respecto a la ejecución del comando, ProvONE no tiene un objeto que pueda codificar la orden.
Los comandos están relacionados con el nivel de script provone:Program a través de provone:hasSubProgram . Tomemos, por ejemplo, un script que tiene cuatro comandos en su interior. Estos están modelados en ProvONE como,
El flujo de datos en ProvONE potencial utilizó los objetos provone:Port y provone:Workflow . Por ejemplo, considere este fragmento de SDTL que representa un comando "Cargar". Tenga en cuenta que el comando está en la matriz "comandos".
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
Por el tipo de comando, está claro que se está utilizando un archivo. Este archivo se representa como port/1 . De producesDataFrame podemos inferir que se crea un nuevo puerto para representar el marco de datos, port/2 .
Si se agrega un segundo comando, uno que usa el marco de datos, entonces el objeto provone:Channel se usará para conectar el objeto de puerto. Por ejemplo, considere el SDTL a continuación que describe un comando 'Cargar' y luego un comando que usa su marco de datos y produce uno nuevo.
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
},
{
"$type": "Compute",
"consumesDataframe": [
{
"dataframeName": "df",
}
"producesDataframe": [
{
"dataframeName": "df"
}
}
]
Visualmente,
Esta forma se puede repetir para formar cadenas arbitrariamente largas de flujos de datos entre comandos en un script. El formulario siempre utilizará el provone:Program para representar el comando y el provone:Port para representar un archivo o marco de datos.
La procedencia retrospectiva funciona de manera similar en el sentido de que los comandos se representan como subejecuciones de la ejecución de un archivo de script principal.
La siguiente imagen muestra un script que tiene cuatro comandos en su interior.
El flujo de datos con procedencia retrospectiva es un poco más complicado que el de procedencia prospectiva.
Utilizando el comando 'Cargar' SDTL que se utilizó para la posible procedencia,
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
En la imagen siguiente, entity/1 representa el archivo que utiliza el comando. entity/2 representa el marco de datos que se creó.
Los objetos provone:Port & provone:Entity de la sección anterior pueden ser más útiles para consultas adicionales si se conservan algunos de los metadatos sobre el marco de datos.
Una descripción completa del marco de datos contiene información sobre las variables internas y el nombre del marco de datos en el código fuente. Considere un comando que carga un marco de datos que tiene variables dentro de un archivo,
{
"$type": "Load",
"command": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
],
}
El objeto de marco de datos tiene la siguiente representación RDF en ProvONE. Tenga en cuenta que el nodo raíz es un provone:Port.
Los objetos del marco de datos se pueden adjuntar al provone:Puerto al que está asociado. Tomemos, por ejemplo, el siguiente SDTL que carga un marco de datos de un archivo y luego lee el marco de datos en un nuevo comando.
{
"$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"
]
}
]
}
Tenga en cuenta que en este caso, el segundo marco de datos, port/4 tiene los mismos atributos que port/2 . Esto no significa que los dos marcos de datos sean iguales. El estado de sus variables podría ser diferente. A este modelo no le interesa preguntar en qué se diferencian.
El modelo ProvONE se puede ampliar para incluir propiedades adicionales del SDTL. Esto se puede hacer para proporcionar un mayor contexto sobre lo que sucedió dentro de cada comando. Cada comando SDTL tiene una estructura de metadatos diferente para el tipo de comando.
Por ejemplo, el comando KeepCases tiene una propiedad llamada condición.
El comando renames tiene una propiedad llamada renames.
Todos estos están adjuntos al programa provone:Programa de nivel de comando, que se muestra a continuación
Parece que el provone:Programa que representa un comando también puede ser una CommandBase SDTL. Esto permite consultas híbridas más fluidas,
¿Cuál es el provone:Program que también es un sdlt:Load?
¿Cuáles son los provone:Ports para todos los comandos de tipo sdtl:Load?
¿Cuáles son los puertos de entrada provone:Ports para el comando sdt:Load con propiedad X?
El modelo propuesto transforma objetos sdtl:CommandBase en objetos provone:Program, adjunta una representación de marco de datos a sus objetos provone:Port y adjunta propiedades SDTL seleccionadas al provone:Program.
Este modelo permite consultar sobre el flujo de datos a través del script, utilizando ProvONE. Los objetos SDTL adicionales (SourceInformation, expresión, etc.) se pueden consultar utilizando el lenguaje SDTL para determinar más información sobre el comando en cuestión.
