sdtl provone
1.0.0
Este trabalho foi obsoleto pelo modelo de dados SDTH, que pode ser consultado em termos de conceitos de prov.
Este repositório aborda o modelo de dados ProvONE-SDTL.
O objetivo do modelo de dados é pegar as informações representadas em SDTL e transformá-las no modelo de dados ProvONE, permitindo que consultas sejam feitas usando a sintaxe ProvONE.
Consultas alvo:
Todas essas consultas podem ser reformuladas em termos de ProvONE
Um dos principais objetivos da especificação de um esquema de identificadores é garantir identificadores mais legíveis por humanos. Isto é particularmente importante para ler os resultados da consulta. A convenção de nomenclatura para identificadores foi retirada da seção Patterned URIs em Linked Data Patterns.
A forma geral é,
#camelCaseClass/{current_type_count} . onde {current_type_count} é a contagem do objeto específico.
Cada objeto deve ter um rdfs:label quando possível e apropriado. Os objetos provone:Workflow e provone:Execution de nível superior podem ter rótulos predefinidos porque representam nós exclusivos com uma finalidade específica.
O objeto provone:Program e provone:Execution no nível de script também possui rótulos, permitindo que qualquer questionador saiba que está observando entidades que se assemelham a arquivos de script.
O formato de destino é JSON-LD; rdflib possui um plugin para transformar seu modelo gráfico em JSON-LD. O Turtle ainda é o mais fácil de analisar a olho nu, portanto os exemplos neste documento são fornecidos no Turtle. Os exemplos no diretório examples/ estão em Turtle e JSON-LD.
Como o modelo é centrado em consultas ProvONE direcionadas a questões sobre fluxo de dados, a arquitetura subjacente é predominantemente ProvONE.
ProvONE tem a capacidade de representar fluxos de trabalho e coleções de execuções, provone:Workflow & provone:Exection . Eles são mais comumente usados para representar a execução de uma série de scripts ou a existência de uma série. Observe que eles não estão ordenados.
Cada representação ProvONE terá uma estrutura externa semelhante para representar a coleção de scripts. A proveniência prospectiva coleta cada nó que representa o script em um provone:Workflow; a proveniência retrospectiva coleta cada nó de execução de script sob um provone:Execution.
Cada modelo potencial terá um provone:Program que representa o script que foi analisado por C2Metadata e um provone:Workflow ao qual o script pertence. Cada provone:Program em nível de script é anexado ao provone:Workflow.
Considere dois arquivos de origem em um único pacote de dados. Um único objeto provone:Workflow contém ambos os nós que representam o arquivo.
Todo modelo retrospectivo terá um provone:Execution que representa a execução hipotética de um script que foi analisado por C2Metadata. Cada objeto provone:Execution que representa um script será anexado ao provone:Execution de nível superior
A proveniência retrospectiva é descrita de forma semelhante. Neste caso, porém, não existe um tipo específico para denotar uma “coleção” de execuções. Em vez disso, wasPartOf pode ser usado para denotar agrupamento.
Os comandos dentro de um arquivo de script são definidos com os objetos provone:Program e provone:Execution . Os objetos que descrevem o fluxo de dados entre esses objetos são o padrão provone:Port e provone:Entity .
Isso pode ser reafirmado: todo objeto SDTL que possui a classe base CommandBase é traduzido em um provone:Program ou provone:Execution. Como alternativa: todo objeto JSON que está na matriz de "comandos" do SDTL é mapeado para um provone:Program ou provone:Execution.
Observe que embora o SDTL possa ser ordenado em relação à execução do comando, ProvONE não possui um objeto que possa codificar o pedido.
Os comandos estão relacionados ao provone:Program em nível de script via provone:hasSubProgram . Tomemos por exemplo um script que contém quatro comandos. Eles são modelados no ProvONE como,
O fluxo de dados no ProvONE prospectivo utilizou os objetos provone:Port e provone:Workflow . Por exemplo, considere este trecho de SDTL que representa um comando "Carregar". Observe que o comando está na matriz "comandos".
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
Pelo tipo de comando, fica claro que um arquivo está sendo usado. Este arquivo é representado como port/1 . A partir de producesDataFrame podemos inferir que uma nova porta é criada para representar o quadro de dados, port/2 .
Se um segundo comando for adicionado, um que use o quadro de dados, então o objeto provone:Channel será usado para conectar o objeto de porta. Por exemplo, considere o SDTL abaixo que descreve um comando 'Carregar' e um comando que usa seu quadro de dados e produz um novo.
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
},
{
"$type": "Compute",
"consumesDataframe": [
{
"dataframeName": "df",
}
"producesDataframe": [
{
"dataframeName": "df"
}
}
]
Visualmente,
Este formulário pode ser repetido para formar cadeias arbitrariamente longas de fluxos de dados entre comandos em um script. O formulário sempre usará o tipo provone:Program para representar o comando e o provone:Port para representar um arquivo ou quadro de dados.
A proveniência retrospectiva funciona de maneira semelhante, pois os comandos são representados como subexecuções da execução de um arquivo de script pai.
A imagem a seguir mostra um script que contém quatro comandos.
O fluxo de dados com proveniência retrospectiva é um pouco mais complicado do que a proveniência prospectiva.
Usando o comando SDTL 'Load' que foi usado para procedência prospectiva,
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
Na imagem abaixo, entity/1 representa o arquivo que está sendo utilizado pelo comando. entity/2 representa o quadro de dados que foi criado.
Os objetos provone:Port & provone:Entity na seção acima podem ser mais úteis para consultas adicionais se alguns dos metadados sobre o quadro de dados forem preservados.
Uma descrição completa do quadro de dados contém informações sobre as variáveis contidas e o nome do quadro de dados no código-fonte. Considere um comando que carrega um quadro de dados que contém variáveis dentro de um arquivo,
{
"$type": "Load",
"command": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
],
}
O objeto de quadro de dados possui a seguinte representação RDF em ProvONE. Observe que o nó raiz é um provone:Port.
Os objetos do quadro de dados podem ser anexados ao provone:Port ao qual estão associados. Tomemos por exemplo, o seguinte SDTL que carrega um quadro de dados de um arquivo e depois lê, usa o quadro de dados em um novo 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"
]
}
]
}
Observe que, neste caso, o segundo quadro de dados, port/4 possui os mesmos atributos que port/2 . Isso não significa que os dois quadros de dados sejam iguais. O estado de suas variáveis pode ser diferente. Este modelo não está interessado em perguntar como eles são diferentes.
O modelo ProvONE pode ser estendido para incluir propriedades adicionais do SDTL. Isso pode ser feito para fornecer maior contexto sobre o que aconteceu em cada comando. Cada comando SDTL possui uma estrutura de metadados diferente para o tipo de comando.
Por exemplo, o comando KeepCases possui uma propriedade chamada condição.
O comando renames possui uma propriedade chamada renames.
Todos eles estão anexados ao provone:Program em nível de comando, mostrado abaixo
Parece que o provone:Program que representa um comando também pode ser um SDTL CommandBase. Isso permite consultas híbridas mais integradas,
Qual é o provone:Program que também é um sdlt:Load?
Quais são as provone:Ports para todos os comandos do tipo sdtl:Load?
Quais são as entradas provone:Ports para o comando sdt:Load com propriedade X?
O modelo proposto transforma objetos sdtl:CommandBase em objetos provone:Program, anexa uma representação de quadro de dados aos seus objetos provone:Port e anexa propriedades SDTL selecionadas ao provone:Program.
Este modelo permite consultar o fluxo de dados através do script, utilizando ProvONE. Os objetos SDTL adicionais (SourceInformation, expressão, etc.) podem ser consultados usando a linguagem SDTL para determinar mais informações sobre o comando em questão.
