sdtl provone
1.0.0
이 작업은 prov 개념 측면에서 쿼리할 수 있는 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 아래의 각 스크립트 실행 노드를 수집합니다.
모든 예상 모델에는 C2Metadata에 의해 구문 분석된 스크립트를 나타내는 provone:Program과 해당 스크립트가 속한 provone:Workflow가 있습니다. 모든 스크립트 수준 provone:Program은 provone:Workflow에 연결됩니다.
단일 데이터 패키지에 있는 두 개의 소스 파일을 고려하십시오. 단일 provone:Workflow 개체에는 파일을 나타내는 두 노드가 모두 포함됩니다.
모든 회고적 모델에는 C2Metadata에 의해 구문 분석된 스크립트의 가상 실행을 나타내는 provone:Execution이 있습니다. 스크립트를 나타내는 모든 provone:Execution 객체는 최상위 수준 provone:Execution에 연결됩니다.
회고적 출처도 비슷하게 설명됩니다. 그러나 이 경우에는 실행 '컬렉션'을 나타내는 특정 유형이 없습니다. 대신, wasPartOf를 사용하여 그룹화를 나타낼 수 있습니다.
스크립트 파일 내의 명령은 provone:Program 및 provone:Execution 개체로 정의됩니다. 이러한 개체 간의 데이터 흐름을 설명하는 개체는 표준 provone:Port 및 provone:Entity 입니다.
이는 다시 설명할 수 있습니다. 기본 클래스 CommandBase가 있는 모든 SDTL 개체는 provone:Program 또는 provone:Execution으로 변환됩니다. 대안: SDTL "명령" 배열에 있는 모든 JSON 개체는 provone:Program 또는 provone:Execution에 매핑됩니다.
명령 실행과 관련하여 SDTL의 순서가 지정될 수 있지만 ProvONE에는 순서를 인코딩할 수 있는 개체가 없습니다.
명령은 provone:hasSubProgram 통해 스크립트 수준 provone:Program과 관련됩니다. 내부에 4개의 명령이 있는 스크립트를 예로 들어 보겠습니다. 이는 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 사용하여 파일 또는 데이터 프레임을 나타냅니다.
소급 출처는 명령이 상위 스크립트 파일 실행의 하위 실행으로 표시된다는 점에서 비슷한 방식으로 작동합니다.
다음 이미지는 내부에 4개의 명령이 있는 스크립트를 보여줍니다.
소급 출처를 통한 데이터 흐름은 예상 출처보다 조금 더 복잡합니다.
예상 출처에 사용되었던 'Load' 명령 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"
]
}
],
}
데이터 프레임 객체는 ProvONE에서 다음과 같은 RDF 표현을 갖습니다. 루트 노드는 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 명령에는 조건이라는 속성이 있습니다.
renames 명령에는 renames라는 속성이 있습니다.
이들은 모두 아래 표시된 명령 수준 provone:Program에 연결되어 있습니다.
명령을 나타내는 provone:Program 도 SDTL CommandBase일 수 있는 것 같습니다. 이를 통해 보다 원활한 하이브리드 쿼리가 가능합니다.
sdlt:Load이기도 한 provone:Program은 무엇입니까?
sdtl:Load 유형의 모든 명령에 대한 provone:Ports는 무엇입니까?
X 속성을 사용하여 sdt:Load 명령에 대한 입력 provone:Ports는 무엇입니까?
제안된 모델은 sdtl:CommandBase 개체를 provone:Program 개체로 변환하고, 데이터 프레임 표현을 provone:Port 개체에 연결하고, 선택한 SDTL 속성을 provone:Program에 연결합니다.
이 모델을 사용하면 ProvONE을 사용하여 스크립트를 통한 데이터 흐름에 대해 쿼리할 수 있습니다. 추가 SDTL 개체(SourceInformation, 표현식 등)는 SDTL 언어를 사용하여 쿼리하여 해당 명령에 대한 추가 정보를 확인할 수 있습니다.
