sdtl provone
1.0.0
Эта работа устарела из-за модели данных SDTH, к которой можно обращаться с точки зрения концепций подтверждения.
Этот репозиторий использует модель данных ProvONE-SDTL.
Цель модели данных — взять информацию, представленную в SDTL, и преобразовать ее в модель данных ProvONE, позволяя выполнять запросы с использованием синтаксиса ProvONE.
Целевые запросы:
Все эти запросы можно переформулировать в терминах ProvONE.
Одна из основных целей определения схемы идентификаторов — обеспечить более удобочитаемые идентификаторы. Это особенно важно для чтения результатов запроса. Соглашение об именах для идентификаторов было взято из раздела Patterned URIs в «Шаблонах связанных данных».
Общая форма такова,
#camelCaseClass/{current_type_count} . где {current_type_count} — количество конкретного объекта.
Каждый объект должен иметь метку rdfs:label если это возможно и уместно. Объекты верхнего уровня provone:Workflow и provone:Execution могут иметь заранее определенные метки, поскольку они представляют уникальные узлы с определенной целью.
Уровень сценария provone:Program и provone:Execution. Объект также имеет метки, позволяющие любому пользователю узнать, что он наблюдает за объектами, напоминающими файлы сценариев.
Целевой формат — JSON-LD; У rdflib есть плагин для преобразования графовой модели в JSON-LD. Turtle по-прежнему легче всего анализировать на глаз, поэтому примеры в этом документе представлены на Turtle. Примеры в каталоге examples/ находятся как в Turtle, так и в JSON-LD.
Поскольку модель сосредоточена на запросах ProvONE, нацеленных на вопросы о потоке данных, базовая архитектура преимущественно представляет собой ProvONE.
ProvONE имеет возможность представлять рабочие процессы и коллекции выполнения, provone:Workflow и provone:Exection . Чаще всего они используются для обозначения выполнения серии сценариев или существования серии. Обратите внимание, что они неупорядочены.
Каждое представление ProvONE будет иметь аналогичную внешнюю структуру для представления коллекции скриптов. Предполагаемое происхождение собирает каждый узел, представляющий сценарий, в provone:Workflow; ретроспективное происхождение собирает каждый узел выполнения сценария в provone:Execution.
Каждая предполагаемая модель будет иметь provone:Program, представляющую сценарий, проанализированный C2Metadata, и provone:Workflow, к которому принадлежит сценарий. Каждая программа provone:Program на уровне сценария прикрепляется к provone:Workflow.
Рассмотрим два исходных файла в одном пакете данных. Один объект provone:Workflow содержит оба узла, представляющие файл.
Каждая ретроспективная модель будет иметь provone:Execution, который представляет собой гипотетическое выполнение сценария, проанализированного C2Metadata. Каждый объект provone:Execution, представляющий сценарий, будет прикреплен к provone:Execution верхнего уровня.
Ретроспективное происхождение описывается аналогично. Однако в этом случае не существует конкретного типа для обозначения «набора» исполнений. Вместо этого для обозначения группировки можно использовать wasPartOf.
Команды внутри файла сценария определяются с помощью объектов provone:Program и provone:Execution . Объектами, описывающими поток данных между этими объектами, являются стандартные provone:Port и provone:Entity .
Это можно переформулировать: каждый объект SDTL, имеющий базовый класс CommandBase, преобразуется в provone:Program или provone:Execution. Альтернативно: каждый объект объекта JSON, находящийся в массиве «команд» SDTL, сопоставляется с provone:Program или provone:Execution.
Обратите внимание: хотя SDTL может быть упорядочен в отношении выполнения команд, у ProvONE нет объекта, который мог бы кодировать этот порядок.
Команды связаны с provone:Program уровня сценария через provone:hasSubProgram . Возьмем, к примеру, скрипт, содержащий четыре команды. Они смоделированы в ProvONE следующим образом:
Поток данных в будущем ProvONE использовал объекты provone:Port и provone:Workflow . Например, рассмотрим этот фрагмент SDTL, который представляет команду «Загрузить». Обратите внимание, что команда находится в массиве «commands».
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
По типу команды понятно, что используется файл. Этот файл представлен как port/1 . Из producesDataFrame мы можем сделать вывод, что создается новый порт для представления кадра данных, port/2 .
Если добавлена вторая команда, которая использует кадр данных, то объект provone:Channel будет использоваться для подключения объекта порта. Например, рассмотрим приведенный ниже SDTL, который описывает команду «Загрузить», а затем команду, которая использует свой кадр данных и создает новый.
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
},
{
"$type": "Compute",
"consumesDataframe": [
{
"dataframeName": "df",
}
"producesDataframe": [
{
"dataframeName": "df"
}
}
]
Визуально,
Эту форму можно повторять для формирования сколь угодно длинных цепочек потоков данных между командами в сценарии. В форме всегда будет использоваться тип provone:Program для представления команды и тип provone:Port для представления файла или кадра данных.
Ретроспективное происхождение работает аналогичным образом: команды представляются как части выполнения родительского файла сценария.
На следующем изображении показан сценарий, содержащий четыре команды.
Поток данных с ретроспективным происхождением немного сложнее, чем с предполагаемым происхождением.
Используя команду «Загрузить» SDTL, которая использовалась для предполагаемого происхождения,
"commands": [
{
"$type": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
],
}
}
]
На изображении ниже entity/1 представляет файл, используемый командой. entity/2 представляет созданный фрейм данных.
Объекты provone:Port и provone:Entity в разделе выше могут быть более полезны для дополнительных запросов, если некоторые метаданные о фрейме данных сохраняются.
Полное описание фрейма данных содержит информацию о переменных внутри и имени фрейма данных в исходном коде. Рассмотрим команду, которая загружает фрейм данных, содержащий переменные, из файла:
{
"$type": "Load",
"command": "Load",
"fileName": "df.csv",
"software": "csv",
"producesDataframe": [
{
"dataframeName": "df",
"variableInventory": [
"A",
"B"
]
}
],
}
Объект фрейма данных имеет следующее представление RDF в ProvONE. Обратите внимание, что корневым узлом является provone:Port.
Объекты фреймов данных могут быть прикреплены к provone:Port, с которым они связаны. Возьмем, к примеру, следующий SDTL, который загружает кадр данных из файла, а затем читает, использует кадр данных в новой команде.
{
"$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"
]
}
]
}
Обратите внимание, что в этом случае второй кадр данных port/4 имеет те же атрибуты, что и port/2 . Это не означает, что два кадра данных одинаковы. Состояние его переменных может быть разным. Эта модель не заинтересована в том, чтобы спрашивать , чем они отличаются.
Модель ProvONE можно расширить, включив в нее дополнительные свойства из SDTL. Это можно сделать, чтобы предоставить более полный контекст того, что произошло внутри каждой команды. Каждая команда SDTL имеет различную структуру метаданных для типа команды.
Например, команда KeepCases имеет свойство Condition.
Команда renames имеет свойство renames.
Все они подключены к программе provone:Program командного уровня, показанной ниже.
Кажется, что provone:Program, представляющая команду, также может быть SDTL CommandBase. Это позволяет выполнять более плавные гибридные запросы,
Что такое provone:Program, которая также является sdlt:Load?
Какие есть порты для всех команд типа sdtl:Load?
Каковы входные данные provone:Ports для команды sdt:Load со свойством X?
Предлагаемая модель преобразует объекты sdtl:CommandBase в объекты provone:Program, прикрепляет представление фрейма данных к объектам provone:Port и присоединяет выбранные свойства SDTL к provone:Program.
Эта модель позволяет запрашивать поток данных через сценарий с использованием ProvONE. Дополнительные объекты SDTL (SourceInformation, выражение и т. д.) можно запросить с помощью языка SDTL, чтобы получить дополнительную информацию о рассматриваемой команде.
