DCAT은 웹에 게시된 데이터 카탈로그 간의 상호운용성을 촉진하도록 설계된 RDF 어휘입니다.
이 문서는 그 스키마를 정의하고 사용 예제를 제공합니다.
DCAT은 게시자가 표준 모델과 어휘를 사용하여 카탈로그 안의 데이터셋과 데이터 서비스를 설명할 수 있게 하며,
이는 여러 카탈로그에서 메타데이터를 소비하고 집계하는 것을 촉진합니다.
이는 데이터셋과 데이터 서비스의 발견 가능성을 높일 수 있습니다.
또한 데이터 카탈로그를 게시하는 데 분산형 접근 방식을 취할 수 있게 하고, 동일한 질의 메커니즘과 구조를 사용하여
여러 사이트의 카탈로그 전반에 걸쳐 데이터셋에 대한 연합 검색을 가능하게 합니다.
집계된 DCAT 메타데이터는 디지털 보존 과정의 일부로 매니페스트 파일 역할을 할 수 있습니다.
DCAT 용어의 네임스페이스는 http://www.w3.org/ns/dcat#입니다
DCAT 네임스페이스에 제안되는 접두사는 dcat입니다
이 문서의 상태
이 절은 이 문서가
게시된 시점의 상태를 설명합니다. 현재 W3C
간행물 목록과 이 기술 보고서의 최신 개정판은
https://www.w3.org/TR/의 W3C 기술
보고서 색인에서 확인할 수 있습니다.
이 문서는 이전 어휘 개발 과정에서 고려할 수 없었던 사용 사례, 요구사항 및 커뮤니티 경험에 대응하여
DCAT 2 어휘([VOCAB-DCAT-2])의 주요 개정판을 정의합니다.
이 개정판은 데이터 설명과 데이터셋 교환에 대한 다양한 접근 방식을 지원하면서 커뮤니티 관행에 맞추어
DCAT 표준을 확장합니다. DCAT 어휘의 주요 변경 사항은 다음과 같습니다:
DCAT은 foaf:homepage 및 dcterms:title과 같이 안정적이고 적절한 의미를 가진 용어를
찾을 수 있는 경우 기존 어휘의 용어를 통합합니다.
편의를 위해 외부에서 정의된 용어의 비공식 요약 정의가 DCAT 어휘에 포함되어 있으며,
권위 있는 정의는 규범 참고문헌에서 확인할 수 있습니다.
참고문헌의 정의가 변경되는 경우, 그 변경 사항은 이 명세에서 제공된 요약보다 우선합니다.
DCAT에 대한 적합성(4.
적합성)은 DCAT 어휘 명세에 있는 용어만의 사용과 관련되므로,
다른 외부 정의의 가능한 변경은 DCAT 구현의 적합성에 영향을 주지 않습니다.
의견을 보내 주십시오
작업 그룹은 게시자에게 이 문서에 설명된 개정판 DCAT으로 자신의 카탈로그와 데이터셋을 설명하고,
개정 DCAT 구현 보고 지침에 따라
구현을 보고하도록 초대했습니다. 이 정보와 후속 분석은
구현 보고서에 게시되어 있습니다.
W3C 권고안은 광범위한
합의 형성 후
W3C와 그 회원들의 승인을 받으며,
작업 그룹 구성원으로부터 구현에 대해
로열티 없는 라이선스
약속을 받은 명세입니다.
이 문서는
W3C
특허
정책에 따라 운영되는 그룹에 의해 작성되었습니다.
W3C는
해당 그룹의 산출물과 관련하여 이루어진
모든 특허 공개의 공개 목록을 유지합니다.
그 페이지에는 특허 공개를 위한 지침도 포함되어 있습니다.
어떤 특허가
필수 청구항을 포함한다고
실제로 알고 있는 개인은
W3C 특허 정책 제6절에 따라
그 정보를 공개해야 합니다.
서로 다른 조직, 연구자, 정부 및 시민 사이에서 데이터 리소스를 공유하려면 메타데이터의 제공이 필요합니다.
이는 데이터가 공개되어 있는지 여부와 무관합니다.
DCAT은 웹에서 데이터 카탈로그를 게시하기 위한 어휘이며, 원래는
data.gov 및 data.gov.uk와 같은
정부 데이터 카탈로그의 맥락에서 개발되었지만,
다른 맥락에도 적용 가능하며 실제로 사용되어 왔습니다.
DCAT 3은 추가 사용 사례와 요구사항 [DCAT-UCR]을 지원하도록 이전 버전을 확장했습니다.
여기에는 데이터셋 외에도 데이터셋 시리즈와 같은 다른 리소스를
카탈로그화할 수 있는 가능성이 포함됩니다. 이 개정판은 리소스의 버전 관리를 설명하는 것도 지원합니다.
역방향 속성을 사용하는 방법에 대한 지침도 제공됩니다.
DCAT은 데이터셋과 데이터 서비스를 설명하여 카탈로그에 포함할 수 있게 하는 RDF 클래스와 속성을 제공합니다.
표준 모델과 어휘를 사용하면 여러 카탈로그에서 메타데이터를
소비하고 집계하기 쉬워지며, 이는 다음을 가능하게 할 수 있습니다:
데이터셋과 데이터 서비스의 발견 가능성을 높입니다
여러 사이트의 카탈로그 전반에서 데이터셋에 대한 연합 검색을 허용합니다
카탈로그에 설명된 데이터는 스프레드시트부터 XML 및 RDF, 다양한 특수 형식에 이르기까지 여러 형식으로 제공될 수 있습니다.
DCAT은 데이터셋의 이러한 직렬화 형식에 대해 어떤 가정도 하지 않지만,
추상적인 데이터셋과 그 서로 다른 표현 또는 배포는 구분합니다.
데이터는 기존 데이터의 추출물, 하위 집합 또는 조합을 선택하거나,
어떤 데이터 처리 함수에 의해 생성된 새 데이터를 선택하도록 지원하는 서비스를 통해 제공되는 경우가 많습니다.
DCAT은 데이터 접근 서비스의 설명을 카탈로그에 포함할 수 있게 합니다.
보완 어휘는 DCAT과 함께 사용되어 더 자세한 형식별 정보를 제공할 수 있습니다.
예를 들어, VoID 어휘 [VOID]의 속성은
데이터셋이 RDF 형식인 경우 해당 데이터셋에 대한 다양한 통계를 표현하기 위해 DCAT 안에서 사용할 수 있습니다.
이 문서는 DCAT으로 표현된 데이터 카탈로그를 배포하는 특정 방법을 규정하지 않습니다.
DCAT 정보는 SPARQL 엔드포인트를 통해 접근 가능한 RDF, [HTML-RDFa]로 HTML 페이지에 포함된 형태,
또는 RDF/XML [RDF-SYNTAX-GRAMMAR], [N3],
[Turtle], [JSON-LD] 또는 기타 형식으로 직렬화된 형태를 포함하여
많은 형태로 제공될 수 있습니다.
이 문서의 예제에서는 가독성 때문에 [Turtle]을 사용합니다.
2. 변경의 동기
이 절은 비규범적입니다.
2014년 1월에 게시된 원래 권고안 [VOCAB-DCAT-1]은
데이터셋을 설명하기 위한 기본 프레임워크를 제공했습니다. 이 권고안은 추상적 개념으로서의 데이터셋과
데이터셋의 표현 형태로서의 배포 사이에 중요한 구분을 두었습니다. DCAT은 널리 채택되었지만,
원래 명세에는 유럽연합 집행위원회의 DCAT-AP [DCAT-AP]와 같은
프로파일 메커니즘을 통해 추가되었거나,
Healthcare and Life Sciences Community Profile [HCLS-Dataset], Data Tag Suite
[DATS]
등처럼 기본 표준을 어느 정도 기반으로 삼은 더 큰 어휘의 개발을 통해 추가된
여러 필수 기능이 부족했다는 점이 분명해졌습니다. DCAT 2 [VOCAB-DCAT-2]는
서로 다른 커뮤니티의 경험을 통해 드러난 특정한 부족한 점을 해결하기 위해 개발되었으며,
목표는 이러한 더 큰 어휘의 산출물 사이의 상호운용성을 개선하는 것이었습니다.
예를 들어 DCAT 2는 식별자, 데이터셋 품질 정보,
및 데이터 인용 문제를 다루기 위한 클래스, 속성 및 지침을 제공했습니다.
이 개정판인 DCAT 3은 명세 전체를 갱신합니다. 2014년 권고안 및 DCAT 2로부터의 중요한 변경 사항은
본문 안에서 "참고" 절을 사용하여 표시되며, D. 변경 이력에도 설명되어
있습니다.
3. 네임스페이스
DCAT의 네임스페이스는 http://www.w3.org/ns/dcat#입니다.
DCAT은 또한 다른 어휘, 특히 Dublin Core [DCTERMS]의 용어를 광범위하게 사용합니다.
DCAT은 자체적으로 최소한의 클래스와 속성 집합을 정의합니다.
dcat:Dataset는 단일 에이전트 또는 식별 가능한 커뮤니티가
게시하거나 큐레이션한 데이터의 모음을 나타냅니다. DCAT에서 데이터셋의 개념은 넓고 포괄적이며,
모든 커뮤니티에서 발생하는 리소스 유형을 수용하려는 의도를 가집니다. 데이터는 숫자, 텍스트, 픽셀,
이미지, 소리 및 기타 멀티미디어를 포함한 많은 형태와 잠재적으로 다른 유형으로 제공되며,
그중 어떤 것이든 데이터셋으로 모일 수 있습니다.
dcat:DataService는 하나 이상의 데이터셋 또는 데이터 처리 함수에
접근할 수 있게 하는 인터페이스(API)를 통해 접근 가능한 작업의 모음을
나타냅니다.
dcat:DatasetSeries는 별도로 게시되지만
이들을 묶는 몇 가지 특성을 공유하는 데이터셋의 모음을 나타내는 데이터셋입니다.
dcat:CatalogRecord는 카탈로그의 메타데이터 레코드를
나타내며, 주로 누가 언제 레코드를 추가했는지와 같은 등록 정보에 관한 것입니다.
그림 1
DCAT 모델의 개요로, Catalog의 구성원이 될 수 있는 리소스 클래스와
그들 사이의 관계를 보여줍니다. 특별히 명시된 경우를 제외하고 DCAT은
카디널리티 제약을 제공하지 않습니다.
참고
DCAT에서 데이터셋은 "단일 에이전트가 게시하거나 큐레이션하고,
하나 이상의 직렬화 또는 형식으로 접근 또는 다운로드할 수 있는 데이터의 모음"으로 정의됩니다.
데이터셋은 개념적 엔터티이며, 전송을 위해 데이터셋을 직렬화하는 하나 이상의 배포로
표현될 수 있습니다.
데이터셋의 배포는 데이터 서비스를 통해 제공될 수 있습니다.
데이터 서비스는 일반적으로 서비스에 로컬로 호스팅되거나 원격에 있을 수 있는 데이터셋에 대해
선택, 추출, 조합, 처리 또는 변환 작업을 제공합니다.
데이터 서비스에 대한 모든 요청의 결과는 데이터셋 또는 카탈로그의 일부 또는 전체에 대한 표현입니다.
데이터 서비스는 특정 데이터셋에 묶여 있을 수도 있고, 그 원천 데이터가 요청 시점 또는 실행 시점에
구성될 수도 있습니다.
데이터 배포 서비스는 데이터셋 또는 하위 집합의 배포를 선택하고 다운로드할 수 있게 합니다.
데이터 발견 서비스는 클라이언트가 적절한 데이터셋을 찾을 수 있게 합니다.
다른 종류의 데이터 서비스에는 좌표 변환 서비스, 재표본화 및 보간 서비스와 같은 데이터 변환 서비스,
그리고 시뮬레이션 및 모델링 서비스를 포함한 다양한 데이터 처리 서비스가 있습니다.
DCAT의 데이터 서비스는 데이터에 대한 접근을 제공하는 작업 또는 API의
모음이라는 점에 유의하십시오.
API 작업에 대한 편리한 접근을 제공하기 위해
대화형 사용자 인터페이스가 제공되는 경우가 많지만, 그 설명은 DCAT의 범위 밖입니다.
특정 데이터 서비스 엔드포인트의 세부 사항은 DCAT 어휘 자체의 범위를 보완하는
표준 서비스 유형에 적합한 설명을 통해 지정되는 경우가 많습니다.
데이터셋과 데이터 서비스의 설명은 카탈로그에 포함될 수 있습니다.
카탈로그는 구성원 항목이 데이터셋과 데이터 서비스의 설명인 데이터셋의 한 종류입니다.
다른 유형의 리소스도 카탈로그화될 수 있지만, DCAT의 범위는 현재 데이터셋과 데이터 서비스로 제한됩니다.
카탈로그의 범위를 데이터셋과 데이터 서비스 너머로 확장하려면 DCAT 프로파일 또는
기타 DCAT 애플리케이션에서 dcat:Resource의
추가 하위 클래스를 정의하는 것이 권장됩니다.
서비스 설명의 범위를 데이터 배포 서비스 너머로 확장하려면 DCAT 프로파일 또는 기타 DCAT 애플리케이션에서
dcat:DataService의 추가 하위 클래스를
정의하는 것이 권장됩니다.
RDF는 리소스가 전역 식별자(IRI)를 갖거나 빈 노드가 되는 것을
허용합니다.
빈 노드는 리소스에 IRI로 명시적으로 이름을 붙이지 않고
리소스를 나타내는 데 사용할 수 있습니다.
이들은 트리플의 주어 및 목적어 위치에 나타날 수 있습니다 [RDF11-PRIMER].
예를 들어 많은 실제 DCAT 카탈로그에서 배포는 관련 데이터셋 설명 안에 중첩된 빈 노드로 표현됩니다.
빈 노드는 일부 사용 사례에 유연성을 제공할 수 있지만, Linked Data 맥락에서는 빈 노드가
데이터를 협력적으로 주석 처리할 수 있는 능력을 제한합니다.
빈 노드 리소스는 링크의 대상이 될 수 없으며, 새로운 출처의 새 정보로 주석 처리될 수도 없습니다.
Linked Data 접근 방식의 가장 큰 이점 중 하나가 "누구나 어디서든 무엇이든 말할 수 있다"는 것이므로,
빈 노드의 사용은 RDF 모델의 광범위한 채택에서 얻을 수 있는 일부 장점을 약화합니다.
단일 애플리케이션 데이터셋의 닫힌 세계 안에서도, 새로운 데이터를 통합할 때 빈 노드의 사용은 빠르게
제한적이 될 수 있습니다 [LinkedDataPatterns].
이러한 이유로 DCAT 주요 클래스의 인스턴스는 전역 식별자를 갖는 것이 권장되며,
RDF로 DCAT을 인코딩할 때 빈 노드의 사용은 일반적으로 권장되지 않습니다.
이 문서의 모든 RDF 예제는 Turtle 구문 [Turtle]으로 작성되어 있으며,
많은 예제는 DXWG 코드
저장소에서 사용할 수 있습니다.
참고
5.3 기본 예제
이 예제는 DCAT이 정부 카탈로그와 그 데이터셋을 표현하는 데 어떻게 사용될 수 있는지에 대한
간단한 개요를 제공합니다. 언어 태그의 사용을 보여주기 위해 제목, 레이블 및 키워드가
영어와 스페인어 둘 다로 제공됩니다.
먼저, 카탈로그 설명입니다:
카탈로그의 게시자는 상대 IRI ex:transparency-office를
가집니다.
게시자에 대한 추가 설명은 예제 2와 같이 제공할 수 있습니다:
카탈로그는 dcat:dataset 속성을 통해 각 데이터셋을 나열합니다. 예제
1에서는 예시 데이터셋이
상대 IRI ex:dataset-001로
언급되었습니다.
DCAT을 사용한 그 가능한 설명은 아래에 표시되어 있습니다:
데이터셋에 대한 의견과 피드백을 보낼 수 있는 연락 지점이 제공됩니다.
이메일 주소 또는 전화번호와 같은 연락 지점에 대한 추가 세부 사항은
vCard [VCARD-RDF]를
사용하여 제공할 수 있습니다.
데이터셋 ex:dataset-001-csv의 한 표현은 5kB CSV 파일로 다운로드할 수 있습니다.
이는
dcat:Distribution 유형의 RDF 리소스로 표현됩니다.
5.4 데이터셋을
주제별로 분류하기
카탈로그는 상대 IRI ex:themes로 표현되는
도메인 집합에 따라 데이터셋을 분류합니다. SKOS [SKOS-REFERENCE]를
사용하여 사용된 도메인을 설명할 수 있습니다:
이 데이터셋이 상대 IRI ex:accountability로 표현되는
도메인 아래에 분류되어 있다는 점에 유의하십시오.
카탈로그 도메인을 설명하는 데 사용된 IRI ex:themes로 식별되는
개념 체계의 일부로 이 개념을 정의하는 것이 권장됩니다. SKOS 설명 예제:
다음 예제에서는 (개념상의) 데이터셋이 서로 다른 어휘의 값을 사용하여 별도로 분류됩니다.
하나의 설명 안에 여러 분류가 존재하는 것도 가능합니다.
5.6 카탈로그
레코드 메타데이터 설명하기
카탈로그 게시자가 자신의 레코드(즉, 데이터셋을 설명하는 메타데이터를 포함하는 레코드)를 설명하는
메타데이터를 보관하기로 결정한 경우, dcat:CatalogRecord를 사용할 수 있습니다. 예를 들어,
ex:dataset-001은 2011-12-05에 발행되었지만, Imaginary Catalog의 해당 설명은
2011-12-11에 추가되었습니다. 이는 예제 9와 같이 DCAT으로 표현할
수 있습니다:
5.7 일부 웹 페이지
뒤에서만 제공되는 데이터셋
ex:dataset-002는 CSV 파일로 제공됩니다. 그러나 ex:dataset-002는
사용자가 데이터를 접근하기 전에 일부 링크를 따라가고, 일부 정보를 제공하며, 일부 확인란을 선택해야 하는
어떤 웹 페이지를 통해서만 얻을 수 있습니다.
dcat:landingPage의 사용과
dcat:Distribution 인스턴스의 정의에 유의하십시오.
5.8
다운로드로
제공되고 일부 웹 페이지 뒤에도 있는 데이터셋
반면, ex:dataset-003는 어떤 랜딩 페이지를 통해 얻을 수 있으며,
알려진 URL에서도 다운로드할 수 있습니다.
다운로드 가능한 배포에는 dcat:downloadURL을 사용했으며, 랜딩 페이지를 통해 접근 가능한
다른 배포는 별도의 dcat:Distribution 인스턴스로 정의할 필요가 없다는 점에 유의하십시오.
5.9 서비스를 통해
제공되는 데이터셋
ex:dataset-004는 서로 다른 서비스에서 서로 다른 표현으로 배포됩니다.
각 dcat:Distribution의 dcat:accessURL은 서비스의
dcat:endpointURL에 대응합니다.
각 서비스는 dcterms:type을 사용하여 일반 유형으로 특징지어지며(여기서는 INSPIRE 공간 데이터 서비스 유형 어휘의 값을 사용),
구체적인 API 정의는
dcterms:conformsTo를 사용하고,
개별 엔드포인트 매개변수와 옵션의 자세한 설명은
dcat:endpointDescription을 사용하여 연결됩니다.
6. 어휘 명세
6.1 RDF 표현
편집자 참고
(개정된) DCAT 어휘는 RDF로 제공됩니다.
기본 산출물인 dcat.ttl은
핵심 DCAT 어휘의 직렬화입니다.
그와 함께 다음을 포함한 추가 정보를 제공하는 다른 RDF 파일 집합이 있습니다:
DCAT은 여러 다른 어휘의 요소를 사용할 것을 요구합니다.
또한 DCAT은 일반적인 RDFS [RDF-SCHEMA] 및 OWL2 [OWL2-OVERVIEW]
규칙과 패턴에 따라 외부 어휘의 추가 요소로 확장될 수 있습니다.
6.2.1 보완 어휘
여러 보완 어휘의 요소는 DCAT과 함께 사용되어 더 자세한 정보를 제공할 MAY 있습니다.
예를 들어: VoID 어휘 [VOID]의 속성은
DCAT으로 설명된 데이터셋이 RDF 형식인 경우 해당 데이터셋에 대한 다양한 통계를 설명할 수 있게 하며;
Provenance ontology [PROV-O]의 속성은
데이터셋 또는 서비스를 생성한 워크플로 및 관련 활동과 에이전트에 대한 더 많은 정보를 제공하는 데 사용할 수 있고;
Organization Ontology [VOCAB-ORG]의 클래스와 속성은 책임 있는
에이전트의 추가 세부 사항을 설명하는 데 사용할 수 있습니다.
언어에 대해 ISO 639-1
(두 글자) 코드가 정의되어 있으면, 그에 해당하는 IRI가 사용되는 것이 SHOULD 됩니다; ISO 639-1 코드가
정의되어 있지 않으면, IRI는
ISO 639-2
(세 글자) 코드에 해당하는 것이 사용되는 것이 SHOULD 됩니다.
사용 참고:
리소스가 여러 언어로 제공되는 경우 이 속성을 반복하십시오.
사용 참고:
카탈로그의 구성원(즉, 데이터셋 또는 서비스)에 제공된 값은 충돌하는 경우
카탈로그에 제공된 값을 재정의합니다.
사용 참고:
데이터셋의 표현이 각 언어별로 별도로 제공되는 경우, 각 언어에 대해
dcat:Distribution 인스턴스를 정의하고 각 배포의 특정 언어를
dcterms:language를 사용하여 설명하십시오(즉, 데이터셋은 여러
dcterms:language 값을 가지며 각 배포는
dcterms:language 속성의 값으로 하나만 가집니다). 다국어 배포의 경우
배포는 여러 dcterms:language 값을 가질 것입니다.
이러한 통제 어휘의 일부 구성원은 데이터셋 또는 데이터 서비스에 엄밀히 적합하지 않습니다
(예: DCMI Type Event, PhysicalObject; [ISO-19115-1]
CollectionHardware, CollectionSession, Initiative, Sample,
Repository), 하지만 DCAT 프로파일 또는 애플리케이션에서 정의된
다른 종류의 카탈로그 맥락에서는 사용될 수 있습니다.
사용 참고:
리소스의 파일 형식, 물리 매체 또는 치수를 설명하려면
dcterms:format 요소를 사용하십시오.
많은 기존 및 레거시 카탈로그는 데이터셋의 일부로 함께 묶이는 데이터셋 구성 요소, 표현,
문서, 스키마 및 기타 리소스를 구분하지 않습니다.
dcterms:relation은
더 정확한 관계를 표현하는 여러 더 구체적인 속성의 상위 속성이므로,
dcterms:relation의 사용은 더 구체적인 의미론으로 이후 재분류하는 것과
일관되지 않은 것은 아니지만, 가능하다면 데이터셋을 구성 요소 및 보충 리소스에 연결하는 데
더 특화된 하위 속성이 사용되는 것이 SHOULD 됩니다.
간행물과 같이 카탈로그화된 리소스를 참조하거나, 인용하거나, 그 밖의 방식으로
가리키는 관련 리소스.
사용 참고:
데이터 인용 사용 사례와 관련하여, 카탈로그화된 리소스가 데이터셋인 경우
dcterms:isReferencedBy 속성은 데이터셋을
해당 데이터셋을 인용하거나 가리키는 리소스(예: 학술 간행물)와 연결할 수 있게 합니다.
여러 dcterms:isReferencedBy 속성을 사용하여 데이터셋이
여러 간행물 또는 기타 리소스에 의해 참조되었음을 나타낼 수 있습니다.
사용 참고:
이 속성은 리소스를 해당 문제의 리소스(dcat:Resource 유형)와
연결하는 데 사용됩니다. 이 속성으로 다루지 않는 리소스와의 다른 관계에는
더 일반적인 속성 dcat:qualifiedRelation을
사용할 수 있습니다. 15.
한정 관계도 참조하십시오.
이 속성은 버전이 지정되지 않았거나 추상적인 리소스를
여러 버전 지정 리소스, 예를 들어 스냅샷과 관련짓기 위한 것입니다 [PAV].
이 속성에서 사용되는 버전의 개념은 리소스 생명 주기의 일부로
리소스에 발생한 개정에서 비롯된 버전으로 제한됩니다. 따라서 그 의미론은
상위 속성인 dcterms:hasVersion보다
더 구체적이며,
이 상위 속성은 판본과 개작을 포함하는 더 넓은 버전 개념을 사용합니다.
이 클래스는 선택 사항이며 모든 카탈로그가 이를 사용하는 것은 아닙니다. 이는
데이터셋 또는 서비스에 관한 메타데이터와
데이터셋 또는 서비스에 관한 카탈로그 안의 항목에 관한 메타데이터를
구분하는 카탈로그를 위해 존재합니다. 예를 들어
데이터셋의 게시일 속성은
정보가 게시 기관에 의해 원래 이용 가능하게 된 날짜를 반영하는 반면,
카탈로그 레코드의 게시일은 데이터셋이 카탈로그에 추가된 날짜입니다.
두 날짜가 다른 경우 또는 후자만 알려진 경우에는 게시일이
카탈로그 레코드에 대해서만 지정되는 것이 SHOULD 됩니다.
W3C PROV Ontology [PROV-O]는
데이터셋 또는 그 등록의 특정 변경에 관여한 프로세스와 에이전트의 세부 사항과 같은
추가 출처 정보를 설명할 수 있게 한다는 점에 유의하십시오.
카탈로그가 명명된 그래프를 가진 RDF Dataset([SPARQL11-QUERY]에서 정의됨)으로 표현되는 경우,
각 데이터셋에 대한 설명
(dcat:Dataset, dcat:CatalogRecord 및
그 dcat:Distribution들을 언급하는 모든 RDF 트리플로 구성됨)을
별도의 명명된 그래프에 두는 것이 적절합니다. 해당 그래프의 이름은 카탈로그 레코드의
IRI가 되는 것이
SHOULD 됩니다.
라이선스 및 권리에 관한 정보는 Distribution 수준에서 제공되는 것이 SHOULD 됩니다.
라이선스 및 권리에 관한 정보는 해당 Dataset의 Distribution에 대해 제공되는 정보에 더하여
Dataset에 대해 제공될 MAY 있지만, 이를 대신해서는 안 됩니다.
해당 Dataset의 Distribution에 대해 제공된 정보와 다른 라이선스 또는 권리 정보를 Dataset에 제공하는 것은
법적 충돌을 일으킬 수 있으므로 피하는 것이 SHOULD 됩니다.
이 클래스는 개념적 데이터셋을 설명합니다. 서로 다른 스키마 구조와 형식 또는
직렬화를 가진 하나 이상의 표현이 제공될 수 있습니다.
사용 참고:
이 클래스는 데이터셋 제공자가 게시한 실제 데이터셋을 설명합니다. 실제 데이터셋과
카탈로그 안의 그 항목을 구분할 필요가 있는 경우(수정일과 같은 메타데이터가 다를 수 있으므로),
후자에는 dcat:CatalogRecord 클래스를 사용할 수 있습니다.
사용 참고:
DCAT에서 데이터셋의 개념은 넓고 포괄적이며, 모든 커뮤니티에서 발생하는
리소스 유형을 수용하려는 의도를 가집니다. 데이터는 숫자, 텍스트, 픽셀, 이미지,
소리 및 기타 멀티미디어를 포함한 많은 형태와 잠재적으로 다른 유형으로 제공되며,
그중 어떤 것이든 데이터셋으로 모일 수 있습니다.
데이터셋이 이미지 또는 격자인 경우 이는 항목 간격에 해당해야 합니다.
다른 종류의 공간 데이터셋의 경우, 이 속성은 일반적으로 데이터셋 안의 항목 사이
가장 작은 거리를 나타냅니다.
이 속성의 범위는 미터 단위 길이를 나타내는 숫자입니다.
이는 데이터의 공간 해상도에 대한 요약 표시를 단일 숫자로 제공하려는 것입니다.
공간 정밀도, 정확도, 해상도 및 기타 통계의 다양한 측면에 대한 더 복잡한 설명은
Data Quality Vocabulary [VOCAB-DQV]를
사용하여 제공할 수 있습니다.
prov:Activity 활동은
일정 기간에 걸쳐 발생하고 엔터티에 작용하거나 엔터티와 함께 작용하는 어떤 것입니다;
여기에는 엔터티의 소비, 처리, 변환, 수정, 재배치, 사용 또는 생성이 포함될 수 있습니다.
사용 참고:
데이터셋 생성과 관련된 활동은 일반적으로 이니셔티브, 프로젝트, 미션, 조사,
지속 활동("business as usual") 등입니다. 여러 prov:wasGeneratedBy
속성을 사용하여 다양한 세분성 수준에서 데이터셋 생산 맥락을 나타낼 수 있습니다.
사용 참고:
데이터셋과 활동 사이의 관계에 관한 추가 세부 사항, 예를 들어 프로젝트의 생애 동안
데이터셋이 생성된 정확한 시간을 첨부하려면 prov:qualifiedGeneration을
사용하십시오
참고
프로젝트, 이니셔티브, 지속 활동, 미션 또는 조사와 같이 데이터셋을 생성한 활동을
설명하는 방법에 대한 세부 사항은 이 문서의 범위 밖입니다.
prov:Activity는
시작 및 종료 시간, 관련 에이전트 등과 같은 일부 기본 속성을 제공합니다.
추가 세부 사항은 애플리케이션에서 정의된 클래스를 통해 제공될 수 있습니다.
프로젝트를 설명하기 위한 여러 온톨로지가 제공됩니다. 예를 들어
학술 연구 프로젝트용 VIVO [VIVO-ISF],
소프트웨어 프로젝트용 DOAP (Description of a Project) [DOAP],
그리고
일반 프로젝트용 DBPedia [DBPEDIA-ONT]가 있으며,
이들은 서로 다른 애플리케이션에 적합할 것으로 예상됩니다.
라이선스 및 권리에 관한 정보는 Distribution 수준에서 제공되는 것이 SHOULD 됩니다.
라이선스 및 권리에 관한 정보는 해당 Dataset의 Distribution에 대해 제공되는 정보에 더하여
Dataset에 대해 제공될 MAY 있지만, 이를 대신해서는 안 됩니다. 해당 Dataset의
Distribution에 대해 제공된 정보와 다른 라이선스 또는 권리 정보를 Dataset에 제공하는 것은
법적 충돌을 일으킬 수 있으므로 피하는 것이 SHOULD 됩니다.
9. 라이선스 및 권리 명세의
지침도 참조하십시오.
dcterms:rights의 하위 속성인 dcterms:license는
배포를 라이선스 문서에 연결하는 데 사용할 수 있습니다. 그러나
dcterms:rights는 라이선스 정보뿐 아니라 저작자 표시와 같이
라이선스를 보완하는 기타 정보도 포함할 수 있는 권리 명세로 연결할 수 있게 합니다.
라이선스 및 권리에 관한 정보는 Distribution 수준에서 제공되는 것이
SHOULD 됩니다. 라이선스 및 권리에 관한 정보는
해당 Dataset의 Distribution에 대해 제공되는 정보에 더하여 Dataset에 대해
제공될 MAY 있지만, 이를 대신해서는 안 됩니다. 해당 Dataset의
Distribution에 대해 제공된 정보와 다른 라이선스 또는 권리 정보를 Dataset에
제공하는 것은 법적 충돌을 일으킬 수 있으므로 피하는 것이
SHOULD 됩니다. 9. 라이선스 및
권리 명세의 지침도 참조하십시오.
데이터셋이 이미지 또는 격자인 경우 이는 항목 간격에 해당해야 합니다.
다른 종류의 공간 데이터셋의 경우, 이 속성은 일반적으로 데이터셋 안의 항목 사이
가장 작은 거리를 나타냅니다.
사용 참고:
대체 공간 해상도는 서로 다른 데이터셋 배포로 제공될 수 있습니다
이 속성의 범위는 미터 단위 길이를 나타내는 숫자입니다.
이는 데이터 배포의 공간 해상도에 대한 요약 표시를 단일 숫자로 제공하려는 것입니다.
공간 정밀도, 정확도, 해상도 및 기타 통계의 다양한 측면에 대한 더 복잡한 설명은
Data Quality Vocabulary [VOCAB-DQV]를
사용하여 제공할 수 있습니다.
데이터셋을 분류하는 데 사용되는 모든 skos:Concept에는
그것이 속한 개념 체계로 연결하기 위해 skos:inScheme 또는
skos:topConceptOf 중 하나를 사용하는 것이 권장됩니다. 이 개념 체계는 일반적으로
dcat:themeTaxonomy를 사용하여 카탈로그와 연결됩니다.
time:hasBeginning 속성을 사용하면
dcterms:temporal 속성의 값이 [OWL-TIME]의
time:TemporalEntity 클래스 구성원임을 함의합니다. 이 맥락에서는
dcterms:PeriodOfTime이 하위 클래스 time:ProperInterval와
동등하다는 의미로 받아들일 수 있습니다
time:hasEnd 속성을 사용하면
dcterms:temporal 속성의 값이 [OWL-TIME]의
time:TemporalEntity 클래스 구성원임을 함의합니다. 이 맥락에서는
dcterms:PeriodOfTime이 하위 클래스 time:ProperInterval와
동등하다는 의미로 받아들일 수 있습니다
과학 및 데이터 제공자 커뮤니티는 간행물, 저자 및 데이터에 대해 다양한 식별자를 사용합니다.
DCAT은 주로 식별자를 실행 가능하게 만드는 효과적인 방법으로 지속적인 HTTP IRI에 의존합니다. 특히, 상당수의 식별자 체계는
역참조 가능한 HTTP IRI로 인코딩될 수 있으며, 그중 일부는
기계 판독 가능 메타데이터도 반환합니다(예: DOI
[ISO-26324] 및
ORCID).
그럼에도 데이터 제공자는 여전히 레거시 식별자, HTTP가 아닌 역참조 가능한 식별자,
로컬에서 발급된 식별자 또는 제3자가 제공한 식별자를 참조해야 할 수 있습니다. 이러한 경우
[DCTERMS]와
[VOCAB-ADMS]가 유용할 수 있습니다.
예제 15는 해당 체계를 사용하여
식별자를 할당하고 유지관리하는 책임 기관(예: Zenodo)을 표현하지 않습니다. 등록자를 명명하는 것은 DOI의
철학에 반하기 때문입니다. DOI에서는 하위 공간이 이를 등록한 조직으로부터 추상화되어,
조직이 변경되거나 해당 하위 공간의 책임이 다른 곳으로 넘어가도 DOI가 변경되지 않는 장점이 있습니다.
예제 15는 데이터셋 작성자에 대해 로컬에서 발급된 식별자
(예: https://dcat.example.org/PoelenJorritHID)와 이에 대응하는 ORCID 식별자
(예: https://orcid.org/0000-0003-3138-4118)를 보여줍니다.
HTTP 역참조 가능한 ID가 데이터셋에 대한 RDF/OWL 설명을 반환하는 경우,
owl:sameAs의 사용을 고려할 수 있습니다. 예:
미디어 유형 text/turtle로 역참조될 때,
https://doi.org/10.5281/zenodo.1486279는 데이터셋에 대한
[SCHEMA-ORG] 설명을
반환하며, 이는 https://dcat.example.org/id에서 제공한 설명을 동적으로 보강할 수 있습니다.
참고
DCAT 안에서 데이터셋의 기본 식별자와 대체(또는 레거시) 식별자를 구별해야 한다는 요구가
제기되어 왔습니다. 그러나 이는 매우 애플리케이션별 사안이며, 일반 접근 방식을 의무화하기보다는
DCAT 프로파일에서 다루는 것이 더 적절합니다.
등록된 IRI 유형이 사용되는 경우
([RFC3986],
§ 3.1
Scheme을 따름), 식별자 체계는 IRI의
일부입니다. 따라서 'type'에 별도의
식별자 체계를 나타내는 것은 중복입니다. 예를 들어 DOI는 info
IRI 체계 [IANA-URI-SCHEMES]의 네임스페이스로
등록되어 있으므로(DOI FAQ #11 참조), [RFC3986]에 따르면
예제 18처럼
인코딩되어야 합니다.
리소스에 대한 접근 및 재사용 조건을 표현하는 올바른 방법을 선택하는 것은 복잡할 수 있습니다.
구현자는 설명되는 리소스에 어떤 조건이 적용되는지 결정하기 전에 항상 법률 자문을 구해야 합니다.
이 명세는 세 가지 주요 상황을 구별합니다:
어떤 명세가 명시적으로 'license'로 선언된 리소스와 연결되는 경우;
둘째, 명세가 접근 권리만을 나타내는 리소스와 연결되는 경우;
셋째, 다른 모든 경우, 즉 라이선스 조건 및/또는 접근 권리와 관련되지 않은 명세
(예: 저작권 명세)를 포괄하는 경우입니다.
참고
이러한 시나리오를 다루기 위해 dcterms:rights 속성과 그 하위 속성
dcterms:license 및 dcterms:accessRights를 사용할 것이 권장됩니다.
더 정확히는:
버전 관리는 Catalogs, Catalog Records, Datasets, Distributions를 포함한 모든 DCAT 1급
시민 리소스에 적용될 수 있음을 주목하는 것이 중요합니다.
또한 다음 절에서 설명하는 DCAT 접근 방식은 특정 리소스 유형에서 이미 사용되는 방식
(예: [OWL2-OVERVIEW]는
온톨로지를 위한 버전 관리 속성 집합을 제공함) 및 특정 도메인과 커뮤니티에서 사용되는 방식과
보완적으로 사용되도록 의도되었음에 유의하십시오. DCAT 버전 관리 접근 방식과 다른 어휘의 접근 방식 사이의
비교는 11.4 버전 관리에 대한
보완적 접근 방식을 참조하십시오.
참고
11.1 버전 간 관계
DCAT은 버전 간 다음 종류의 관계를 지원합니다:
버전 체인과 계층(버전 이력)을 나타내는 관계.
어떤 버전이 다른 버전에 의해 대체/폐지되는지를 나타내는 관계.
11.1.1 버전 체인과
계층
DCAT은 해당 [PAV] 속성과
정렬된, 버전 이력을 설명하기 위한 특정 속성을 정의합니다:
dcat:previousVersion 속성은 주어진 버전에서 첫 번째 버전까지 거꾸로 탐색할 수 있는
버전 체인을 구축하는 데 사용됩니다. 이는 가장 일반적인 사용 사례, 즉 카탈로그에서 별개의 리소스로
게시된 서로 다른 버전을 연결하는 경우를 반영합니다.
이 외에도 dcat:hasVersion 속성은 추상 리소스를 그 버전들과 연결하여
버전 계층을 지정하는 데 사용할 수 있습니다.
필요하다면, 버전 계층은 특정 속성으로 더 자세히 설명될 수 있습니다. 더 정확히는,
dcat:hasCurrentVersion 속성은 추상 리소스를 내용의 현재 버전에 해당하는 스냅샷으로
연결하는 반면, dcat:isVersionOf(dcat:hasVersion의 역방향)는
버전에서 추상 리소스로 되돌아가는 링크를 지정할 가능성을 제공합니다(이 속성의 사용은
7. 역방향 속성의 사용 참조).
참고
버전 체인과 계층을 지정하는 데 필요한 유일한 속성은 각각 dcat:previousVersion과
dcat:hasVersion입니다. 다른 속성들을 사용할지 여부는 관련 사용 사례의 요구사항에
달려 있습니다.
다음 예제는 [DWBP]의
§ 8.6 Data
Versioning에 있는 예제를 재사용하고, 이 절에서 설명한 속성을 사용하여 버스 정류장 데이터셋의
버전 체인과 계층을 지정하는 방법을 보여주도록 수정합니다.
11.1.2 다른 버전에 의해
대체된 버전
또 다른 유형의 관계는 주어진 버전이 다른 버전을 대체/폐지하는지 여부와 관련됩니다.
이를 위해 DCAT은 관련 [DCTERMS] 속성, 즉
dcterms:replaces와,
되돌아가는 링크를 제공해야 하는 경우 그 역방향
dcterms:isReplacedBy를 재사용합니다.
이러한 속성은 그 자체로 버전 체인을 나타내는 것이 아니라는 점에 유의할 필요가 있습니다.
즉, 어떤 버전이 반드시 자신의 직전 선행 버전을 대체하는 것은 아닙니다.
다음 예제는 예제 33의
MyCity 버스 정류장 데이터셋 설명을 재사용하여, 대체된 버전을 DCAT에서 지정하는 방법을 보여줍니다.
11.2 버전 정보
이전 절에서 설명한 관계 외에도, 버전이 지정된 리소스는 예를 들어 원본 리소스와의 차이
(버전 "delta"), 버전 식별자 및 공개일을 설명하는 추가 정보와 연결될 수 있습니다.
리소스의 생명 주기는 버전 관리와 직교하는 측면이며, 때로는 매우 밀접하게 관련됩니다.
리소스가 그 생명 주기를 따라(구상에서 생성 및 게시까지) 진화하면 새 버전이 생길 수 있지만,
항상 그런 것은 아닙니다(예: 승인 워크플로가 있는 경우, 개정이 필요하지 않다면 리소스는 아무 변경도
겪지 않을 수 있습니다). 마찬가지로 새 버전의 생성이 반드시 상태 변경으로 이어지지는 않을 수 있습니다
(예: 변경이 실질적이지 않거나, 아직 개발 중인 리소스에 구현되는 경우). 또한 리소스가 개정
(오류 수정, 새 콘텐츠 추가 등) 때문에 대체되는 경우, 다른 생명 주기 상태(예: 폐기 또는 철회)로
이동될 수 있습니다.
리소스의 생명 주기와 관련한 상태는 데이터 제공자와 데이터 소비자 양쪽의 관점에서 그 자체로
중요한 정보인 경우가 많다는 점에 유의할 필요가 있습니다. 데이터 소비자에게는 리소스가 아직 개발 중인지,
그리고 폐기되었거나 철회되었는지(그런 경우 사용해야 할 새 버전이 있는지)를 아는 것이 중요합니다.
한편 데이터 제공자에게는 리소스에 생명 주기 상태를 표시하는 것이 데이터 관리 워크플로의 올바른
운영에 기본적입니다. 예를 들어 리소스는 게시되기 전에 안정적이어야 할 수 있고, 승인됨 및/또는 등록됨으로
표시되어야 할 수도 있습니다. 마지막으로 리소스의 실제 상태 외에도, 리소스가 다른 상태로 이동한
시점(예: 생성, 검토, 승인, 게시 시점)도 유용한 정보입니다.
버전 관리와 마찬가지로, 리소스 생명 주기는 커뮤니티 관행, 데이터 관리 정책 및 적용 중인 워크플로에
의존합니다. 또한 서로 다른 리소스 유형(예: 데이터셋과 카탈로그 레코드)은 서로 다른 생명 주기 상태를
가질 수 있습니다.
생명 주기 상태의 지정에 대해 DCAT은 adms:status 속성 [VOCAB-ADMS]과 적절한
[DCTERMS] 시간 관련 속성
(dcterms:created, dcterms:dateSubmitted, dcterms:dateAccepted,
dcterms:dateCopyrighted, dcterms:issued, dcterms:modified,
dcterms:valid)을 함께 사용합니다. 그러나 DCAT은 특정 생명 주기 상태 집합의 사용을
규정하지 않으며, 관련 애플리케이션 시나리오에 적합한 기존 표준과 커뮤니티 관행을 참조합니다.
참고
11.4 버전 관리에 대한
보완적 접근 방식
DCAT 버전 관리 접근 방식은 특정 커뮤니티, 도메인 및 리소스 유형에서 사용되는 기존 버전 관리 관행과
공존할 수 있습니다.
예로, 다음 표는 DCAT 버전 관리 속성과 유사한 개념을 지정하는 데 가장 자주 사용되는 어휘,
즉 온톨로지용 OWL, [DCTERMS], 그리고 [PROV-O]
사이의
대응 관계를 보여줍니다.
DCAT, OWL, [DCTERMS],
및 [PROV-O]의 유사하지만 동등하지 않은
버전 관리 속성
대응이 동등성을 의미하지는 않는다는 점에 유의하십시오. 이러한 속성은 서로 다른 범위와 의미론을 가지므로
서로를 보완할 수는 있지만 대체할 수는 없습니다. 특히 OWL 속성은 owl:Ontology로
유형 지정될 수 있는 리소스에 사용되도록 의도된 반면, [DCTERMS]의 속성은 매우 넓은 버전 개념
(판과 개작 포함)을 사용합니다. 반면 DCAT 버전 관리 속성은 카탈로그의 모든 리소스에 사용되도록
의도되며, 11.
버전 관리의 서두에서 설명한 것처럼 매우 구체적인 버전 개념을 사용합니다.
마지막으로 [PROV-O] 속성
prov:wasRevisionOf는 dcat:previousVersion과 의미론적으로 유사하지만,
버전 체인을 구축하는 데 사용되도록 명시적으로 의도된 것은 아닙니다. 반면
prov:generalizationOf 및 prov:specializationOf는 각각 그 하위 속성인
dcat:hasVersion 및 dcat:isVersionOf보다 의미론적으로 더 넓습니다.
다음 예제는 [VOCAB-DCAT-2]의 버전 관리에
DCAT과 OWL을 보완적으로 사용할 수 있는 방법을 보여줍니다.
12. 데이터셋 시리즈
이 절은 비규범적입니다.
"데이터셋 시리즈"란 어떤 방식으로든 서로 관련되어 있지만 별도로 게시되는 데이터를 가리킵니다. 예를 들면
단일 데이터셋으로 제공하는 대신 연도 및/또는 국가별로 나뉜 예산 데이터가 있습니다.
데이터셋 시리즈는 [ISO-19115]에서 공통 특성을 공유하는
데이터셋의 모음 […]으로 정의됩니다. 그러나 그 사용은 지리공간 데이터에 한정되지 않으며,
다른 도메인에서는 다르게 명명될 수 있고(예: 시계열, 데이터 슬라이스), 더 엄격하거나 덜 엄격하게
정의될 수 있습니다(예: [VOCAB-DATA-CUBE]의
"dataset slice" 개념 참조).
데이터셋을 시리즈로 묶는 이유와 기준은 다양하며, 예를 들어 데이터 특성, 게시 프로세스 및
일반적인 사용 방식과 관련될 수 있습니다. 예를 들어 크기가 매우 큰 데이터(지리공간 데이터 등)는
더 작은 단위로 나누면 데이터 제공자와 데이터 소비자 모두가 더 쉽게 다룰 수 있습니다. 또 다른 예는
매년 공개되는 데이터로, 일반적으로 시리즈의 첫 번째 데이터셋에 새 데이터를 덧붙이는 대신 별도의
데이터셋으로 게시됩니다.
데이터셋 시리즈를 언제 만들어야 하고 어떻게 구성해야 하는지 결정하기 위한 공통 규칙과 기준이
도메인 전반에 존재하지 않으므로, DCAT은 특정 접근 방식을 규정하지 않고 지침 및 도메인·커뮤니티
관행을 참조합니다. 이 절의 목적은 데이터셋 시리즈를 DCAT에서 어떻게 지정할 수 있는지에 관한
지침을 제공하는 데 한정됩니다.
12.1 데이터셋 시리즈 지정 방법
참고
DCAT은 dcat:Dataset의 하위 클래스로 정의된 새 클래스
dcat:DatasetSeries를 발급함으로써,
데이터셋 시리즈를 데이터 카탈로그의 일급 시민으로 만듭니다.
데이터셋은 dcat:inSeries 속성을 사용하여 데이터셋 시리즈에 연결됩니다.
데이터셋 시리즈도 계층적일 수 있으며, 하나의 데이터셋 시리즈가 다른 데이터셋 시리즈의 구성원이 될 수
있다는 점에 유의하십시오.
데이터셋 시리즈는 시간이 지남에 따라 새 데이터셋을 획득하면서 발전할 수 있습니다. 예를 들어 연도별
예산 데이터에 관한 데이터셋 시리즈는 매년 새 하위 데이터셋을 획득합니다. 이러한 경우에는
첫 번째, 이전, 다음, 최신 항목을 지정하는 관계로 연도별 릴리스를 연결하는 것이 중요할 수 있습니다.
이러한 시나리오에서 DCAT은 각각 dcat:first,
dcat:prev, 및 dcat:last 속성을 사용합니다. dcat:next에
대해서는 7. 역방향
속성의 사용을 참조하십시오.
시리즈 안의 데이터셋은 물론 버전 관리될 수 있습니다. 이러한 경우 데이터셋은
11.1.1 버전 체인과 계층에서 설명한 접근 방식을
사용하여
그 버전에 연결될 수 있으며, 이는 예제 39에 표시되어
있습니다.
참고
12.2 데이터셋 시리즈 메타데이터
데이터셋 시리즈에 관한 속성은 두 그룹으로 분류할 수 있습니다.
첫 번째 그룹은 데이터셋 시리즈 자체를 설명하는 속성에 관한 것입니다. 예를 들어
dcterms:accrualPeriodicity 속성이 이에 해당하며,
그 값은 새 하위 데이터셋이 추가되는 빈도에 대응해야 합니다.
두 번째 그룹은 상위 방향 상속, 즉 하위 데이터셋의 속성 값이 그 부모(데이터셋 시리즈)에
상속되는 방식을 통해 하위 데이터셋 메타데이터에 설명된 차원을 반영하는 속성에 관한 것입니다.
일반적으로 이는 관련 각 속성에 대해 데이터셋 시리즈가 하위 데이터셋에 지정된 값들의 합집합을
값으로 가진다는 것을 의미합니다. 예:
하위 데이터셋의 시간 범위가 서로 다른 연도(예: 2018, 2019, 2020)라면, 시리즈의 시간 범위는
2018년부터 2020년 사이의 시간 기간이 됩니다.
하위 데이터셋이 공간 범위로 서로 다른 지리적 경계 상자를 가진다면, 시리즈의 공간 범위는
이러한 경계 상자의 합집합(즉, 하위 데이터셋의 경계 상자를 포함하는 경계 상자)이 됩니다.
각 하위 데이터셋이 서로 다른 공간 참조 시스템을 사용한다면, 데이터셋 시리즈는 여러 공간 참조
시스템을 가지게 됩니다.
마지막으로, 하위 데이터셋의 일부 주석 속성도 데이터셋 시리즈 수준에서 고려해야 할 수 있습니다.
특히 하위 데이터셋의 생성 / 게시 / 갱신일과 관련된 속성은 시리즈의 대응 속성에 영향을 줄 수 있습니다.
이러한 속성에 대해 DCAT은 다음 접근 방식을 권장합니다:
데이터셋 시리즈의 생성일(dcterms:created)은 하위 데이터셋의 가장 이른 생성일에
대응해야 합니다.
데이터셋 시리즈의 게시일(dcterms:issued)은
하위 데이터셋의 가장 이른 게시일에 대응해야 합니다.
데이터셋 시리즈의 갱신일(dcterms:modified)은
하위 데이터셋의 가장 늦은 게시일 또는 갱신일에 대응해야 합니다.
참고
12.3 기존
DCAT 구현에서의 데이터셋 시리즈
기존 DCAT 구현은 데이터셋 시리즈를 지정하기 위해 두 가지 주요 대안 접근 방식을 채택합니다:
데이터셋 시리즈는 dcat:Dataset으로 유형 지정되고, 그 하위 데이터셋은
dcat:Distribution으로 유형 지정됩니다.
데이터셋 시리즈와 그 하위 데이터셋 모두가 dcat:Dataset으로 유형 지정되며,
둘은 보통 [DCTERMS] 속성
dcterms:hasPart / dcterms:isPartOf를 사용하여 연결됩니다.
이러한 선택지는 DCAT과 형식적으로 호환되지 않는 것은 아니므로, DCAT 3으로 업그레이드하는 동안
dcat:DatasetSeries와 공존할 수 있습니다.
13. 데이터 인용
이 절은 비규범적입니다.
데이터셋 인용은 식별된 요구사항 중 하나입니다.
데이터 인용은 서지 참고문헌을 제공할 때와 유사한 방식으로 데이터를 참조하여,
모든 조사 과정에서 데이터를 일급 산출물로 인정하는 관행입니다. 데이터 인용은 데이터를 생산한 사람에게
적절한 귀속과 공로를 지원하고, 데이터 발견을 촉진하며, 데이터의 영향과 재사용 추적을 지원하고,
데이터의 협업과 재사용을 가능하게 하며, 데이터에 기반한 결과의 재현성을 가능하게 하는 등
여러 이점을 제공합니다.
데이터 인용을 지원하려면 데이터셋 설명에는 최소한 데이터셋 식별자, 데이터셋 작성자,
데이터셋 제목, 데이터셋 게시자 및 데이터셋 게시 또는 공개일이 포함되어야 합니다.
이러한 요소는 연구 데이터에 대해 [DataCite]가
할당한 지속 식별자(Digital Object Identifiers 또는 DOI)와 연결된 메타데이터인
DataCite 메타데이터 스키마 [DataCite]에서 요구하는 요소입니다.
각 유형의 품질 정보는 소비자와 관련 있는 품질 특성인 하나 이상의 품질 차원과 관련될 수 있습니다.
품질을 다차원 공간으로 보는 관행은 품질 관리 분야에서 품질 관리를 처리 가능한 단위로 나누기 위해
확립되어 있습니다. DQV는 품질 차원의 규범적 목록을 정의하지 않습니다. 이는
ISO/IEC 25012 [ISO-IEC-25012] 및 [ZaveriEtAl]에서 제안한 품질 차원을
두 가지 가능한 출발점으로 제공합니다. 또한 후자에서 정의된 품질 차원과 범주에 대한
RDF 표현도 제공합니다. 궁극적으로 구현자는 자신의 필요에
가장 잘 맞는 품질 차원의 모음을 직접 선택해야 합니다.
다음 절은 데이터셋과 배포의 품질을 설명하기 위해 DCAT과 DQV를 어떻게 결합할 수 있는지 보여줍니다.
포괄적인 소개와 추가 사용 예제는 [VOCAB-DQV]를 참조하십시오.
참고
14.1 품질 정보 제공
데이터 소비자(ex:consumer1)는 제노바의 지리 참조된 버스 정류장 목록을 포함하는
데이터셋 ex:genoaBusStopsDataset의 품질을 설명합니다. 그/그녀는 데이터 완전성
(ldqd:completeness)에 관한 DQV 품질 참고
(ex:genoaBusStopsDatasetCompletenessNote)로 데이터셋에 주석을 달아,
데이터셋이 30000개 정류장 중 20500개만 포함한다는 점을 경고합니다.
활동 ex:myQualityChecking은 서비스 ex:myQualityChecker를 사용하여
ex:genoaBusStopsDataset 데이터셋의 품질을 확인합니다. 지표
ex:completenessWRTExpectedNumberOfEntities는 데이터셋 완전성
(ldqd:completeness)을 측정하기 위해 적용되며, 그 결과 품질 측정값
ex:genoaBusStopsDatasetCompletenessMeasurement가 생성됩니다.
네임스페이스 IRI가 아니라 표준 / 명세의
IRI를 사용하십시오. 예를 들어
dcat:CatalogRecord의 DCAT 적합성을 표현하려면 사용할
IRI는
http://www.w3.org/ns/dcat#가 아니라
https://www.w3.org/TR/vocab-dcat/입니다.
정식의 지속적인 IRI를 사용하십시오.
이는 보통 문서 자체에 지정되어 있습니다. 확실하지 않다면 해당 표준 / 명세의 서지 인용에
포함된 것을 사용하십시오.
버전 없는 IRI를 사용하십시오.
표준 / 명세의 특정 버전에 대한 적합성을 표현해야 하는 경우에는 버전 없는
IRI와 버전 있는
IRI를 모두 사용하십시오. 예를 들어
dcat:CatalogRecord가 DCAT 2에 적합함을 명시적으로 나타내야 하는 경우,
https://www.w3.org/TR/vocab-dcat/와
https://www.w3.org/TR/vocab-dcat-2/를 모두 사용하십시오.
예제 45는 위 규칙을 따라
특정 카탈로그 레코드가 DCAT에 적합함을 지정하는 방법을 보여주기 위해
예제 9를 확장합니다.
14.2.2 적합성 정도
일부 법적 맥락에서는 적합성 정도를 지정해야 합니다. 예를 들어 INSPIRE 메타데이터는
완전한 준수 외에도 부적합성과 미평가를 표현하기 위해 특정 통제 어휘
[INSPIRE-DoC]를
채택합니다. 유사한 통제 어휘는 다른 맥락에서도 정의될 수 있습니다.
예제 47은 적합성 정도
(즉, conformant, not conformant)를 나타내는 새로 발급된 몇 가지 개념을 지정하고,
적합성 테스트 결과를 표시하기 위한
dcterms:type를
선언합니다. [GeoDCAT-AP]에서
사용된 패턴을 따라, 이 예제는 적합성 테스트(예:
ex:testResult)를 모델링하기 위해 prov:Entity를,
테스트 활동(예: ex:testingActivity)을 모델링하기 위해 prov:Activity를,
전체 모범 사례 집합을 확인하기 위해 Data on the Web Best Practices [DWBP]에서 파생된
prov:Plan(예: ex:conformanceTest)을 사용합니다. 한정 PROV 연관은
테스트 활동을 적합성 테스트에 결합합니다.
참고
또한 [VOCAB-DQV]는
특정 표준에 대한 준수를 측정하는 데 배포될 수 있습니다. 예제
48에서
ex:levelOfComplianceToDWBP는 [DWBP]에 대한 데이터셋의 준수를 통과한
준수 테스트의 백분율로 측정하는 품질 지표입니다. 예제
48은 ISO/IEC
25012 [ISO-IEC-25012]에 정의된 품질 차원 및
범주를 표현하는 네임스페이스 접두사로 iso를 가정합니다.
품질 측정 ex:measurement_complianceToDWBP는 데이터셋 ex:Dataset에
대한 준수 수준, 즉 지표 ex:levelOfComplianceToDWBP의 측정을 표현합니다.
준수 테스트의 일부만 성공한 경우(예: 준수 테스트의 절반),
측정은 예제 49와
같이 보일 수 있습니다.
14.2.3 적합성 테스트 결과
테스트에 관한 추가 정보는 EARL [EARL10-Schema]을
사용하여 제공될 수 있습니다. EARL은 테스트 활동을 설명하기 위한 특정 클래스를 제공하며, 이는
[PROV-O]와 함께 채택될 수 있습니다.
예제 50은
prov:Activity의 한정 연관 대신 Testing activity ex:testingActivity를
earl:Assertion으로 설명합니다. earl:Assertion은 데이터셋
ex:Dataset이 적합성 테스트 ex:conformanceTest로 테스트되었고,
ex:testResult에 설명된 대로 테스트를 통과했다고 명시합니다.
예제 51은 하위 테스트
ex:testq1이 실패했을 경우 설명이 어떻게 보였을지를 보여줍니다. 특히
dcterms:description 및 earl:info는 사람이 읽을 수 있는 형식의
추가 경고 또는 오류 메시지를 제공합니다.
테스트에 관해 필요한 세부 수준에 따라, [VOCAB-DQV]도
테스트 활동과 오류를 표현할 수 있습니다. 예제 52에서
ex:error는 이전 오류를 표현하는
품질 주석이고, ex:testResult는 출처 정보를 제공하는 위 주석과 준수 측정을
수집하기 위한 dqv:QualityMetadata로 정의됩니다.
물론 위 모델링 패턴은 표준에 대한 적합성뿐 아니라 모든 품질 테스트를 표현할 수 있습니다.
15. 한정 관계
이 절은 비규범적입니다.
DCAT에는 데이터셋과 데이터 서비스의 여러 측면에 대한 설명을 지원하는 요소가 포함되어 있습니다. 그럼에도
일부 관계의 의미론을 완전히 표현하려면 추가 정보가 필요합니다. 예를 들어
[DCTERMS]가 리소스를 책임 있는 당사자 또는 에이전트에
귀속하기 위한 표준 역할 creator,
contributor 및 publisher를 제공하지만,
다른 잠재적 역할도 많이 있습니다. 예를 들어 [ISO-19115-1]의
CI_RoleCode
값을 참조하십시오.
마찬가지로, [DCTERMS] 및 [PROV-O]가
was derived from, was quoted from, is
version of, references 및 그 밖의 여러 관계를 포함하여 리소스 사이의 관계를 포착하는
일부 속성을 제공하지만, [ISO-19115-1]의
DS_AssociationTypeCodes,
IANA Link Relations 레지스트리 [IANA-RELATIONS], DataCite 메타데이터
스키마 [DataCite]
및 MARC relators 목록에서는 많은 추가 관심사가
나타납니다. 이러한 관계는 dcterms:relation, dcterms:contributor 등의
추가 하위 속성으로 포착될 수 있지만, 이는 속성 수의 폭발적 증가로 이어지며, 어쨌든 잠재적인
역할과 관계의 전체 집합은 알려져 있지 않습니다.
[PROV-O]의 많은 한정 용어는 카탈로그 안의 리소스
설명과 관련이 있지만, PROV-O가 활동 중심 관점을 취하기 때문에 불완전합니다. 일부 간극을 해결하기 위해,
명시적 활동을 포함하지 않는 요구사항을 충족하는 추가 형식이 DCAT 어휘에 포함되어 있습니다.
이는 그림
6에 요약되어 있습니다:
그림 6
한정 관계는 리소스를 에이전트 또는 다른 리소스와 관련짓는 확장 가능한 역할 집합을 지원합니다
이러한 한정 형식의 초점은 관계에 추가적인 역할을 허용하는 것이지만, 적용 가능한 시간 간격과 같은
관계의 다른 측면도 이처럼 관계를 설명하기 위해 특정 노드를 사용할 때 쉽게 첨부할 수 있다는 점에
유의하십시오(일부 예는 [PROV-O]의
Influence relations 차트 참조).
예제 53에서 역할은
[ISO-19115-1]의
CI_RoleCode
코드 목록에 대한 비규범적이고 역참조 불가능한 표현의 IRI
(예: urn:example:isotc211/CI_RoleCode와 같은 URN)로 표시됩니다.
Linked Data의 역참조 가능하고 규범적인 표현이 사용 가능하다면 이를 선호해야 합니다.
DCAT-2014 어휘 [VOCAB-DCAT-1] 및 DCAT 2 [VOCAB-DCAT-2]는 서로 다른 도메인의
데이터 카탈로그에 적용하기 위해 확장되어 왔습니다.
이러한 새 명세 각각은 DCAT 프로파일, 즉 DCAT을 기반으로 하는 명명된 제약 집합을 구성합니다
(4. 적합성 참조). 경우에 따라
프로파일은 참조 DCAT 프로파일에서 다루지 않는 메타데이터 필드를 위한 클래스와 속성을 추가하여
DCAT 프로파일 자체 중 하나를 확장합니다.
DCAT 어휘는 개인 정보 또는 비공개 정보를 포함할 수 있는 데이터셋을 지원합니다. 또한
DCAT으로 표현된 메타데이터 자체가 리소스 작성자, 게시자,
그리고 한정 관계를 통해 설명되는 다른 당사자 또는 에이전트와 같은
개인 정보 또는 비공개 정보를 포함할 수 있습니다.
이러한 어휘 용어를 생성, 유지관리, 게시 또는 소비하는 구현자는 보안 및 개인정보 보호 고려사항이
처리되도록 조치를 취해야 합니다. 민감한 데이터와 메타데이터는 관련 데이터 유형의 법적 및 기능적
요구사항에 따라 안전하게 저장되고 권한 있는 당사자에게만 제공되어야 합니다. 웹 콘텐츠를 보호하고
사용자를 인증하는 방법을 상세히 설명하는 것은 DCAT의 범위를 벗어납니다.
일부 데이터셋은 무결성과 진정성에 대한 보장을 요구합니다(예: 소프트웨어 취약점에 관한 데이터).
이러한 경우 체크섬은 검증의 한 유형으로 기능할 수 있습니다.
DCAT은 DCAT 배포의 무결성과 진정성을 보장하기 위해 [SPDX]에서
spdx:Checksum 클래스를 차용합니다.
게시자는 배포 안의 각 리소스에 대해 체크섬 값(해시)과 해시를 생성하는 데 사용된 알고리즘을
제공할 수 있습니다. 그러나 체크섬은 그것이 합산하는 데이터와는 별도의 경로를 통해 제공되어야 합니다.
이는 데이터와 함께 제공되는 메타데이터에 포함될 수 있습니다(예: 배포용 파일과 배포 파일에 대한
체크섬을 포함하는 메타데이터용 파일을 포함하는 tarfile). 그러나 그렇다면 데이터와 함께 체크섬을
조작하려는 공격자를 막기 위해 체크섬 또는 메타데이터에 대한 체크섬도 별도로 제공되어야 합니다.
DCAT 메타데이터에 제공된 체크섬은 메타데이터의 무결성과 진정성도 보장되지 않으면 기대한 보장을
제공하지 못합니다.
DCAT 데이터의 무결성과 진정성은 궁극적으로 출처의 신뢰성에 의존합니다. DCAT 제공자는 애플리케이션
수준과 전송 수준에서 무결성과 진정성을 처리해야 합니다. 예를 들어, 자신의 API 및 다운로드
엔드포인트의 무결성과 진정성을
보장하고, 권위 있는 HTTPS origin에서 DCAT 데이터와 메타데이터 파일을 다운로드할 수 있게 하며,
그것이 나타내는 데이터와 별도의 채널을 통해 체크섬을 제공해야 합니다.
18. 접근성 고려사항
DCAT 어휘는 데이터 카탈로그를 설명하기 위한 모델을 제공합니다. 카탈로그 안의 데이터 성격은
특정 적용 도메인에 따라 달라지며, 비텍스트 데이터를 포함할 수 있습니다. 가능한 경우, 데이터에 대한
접근성을 개선하기 위해 DCAT 프로파일 메커니즘 또는 그러한 데이터의 생성 및 편집을 지원하는 시스템을
통해 비텍스트 데이터 리소스에 대체 텍스트를 강제하는 것이 중요합니다. 큰 글자, 점자, 음성, 기호 또는
더 단순한 언어처럼 사람들이 필요로 하는 다른 형식으로 변환될 수 있는 모든 비텍스트 콘텐츠에
텍스트 대안을 제공하는 관행은 [UNDERSTANDING-WCAG20]에 포함된 접근성 지침을 준수합니다.
A. 감사의 글
편집자들은 이 문서에 기여한 워킹 그룹의 모든 구성원, 특히 다음 분들께
깊이 감사드립니다.
Annette Greiner,
Antoine Isaac,
Dan Brickley,
Karen Coyle,
Lars G. Svensson,
Makx Dekkers,
Nicholas Car,
Rob Atkinson,
Tom Baker.
편집자들은 또한 의견을 제공해 주신 다음 분들께 감사드립니다:
Addison Phillips,
Alex Nelson,
Andreas Geißner,
Andreas Kuckartz,
Anna Odgaard Ingram,
Aymen Charef,
Bart Hanssens,
Becky Gibson,
Bert van Nuffelen,
Bob Coret,
Brian Donohue,
Chavdar Ivanov,
Claus Stadler,
Cristiano Longo,
Christophe Dzikowski,
Dimitris Zeginis,
Dominik Schneider,
Emidio Stani,
Ivo Velitchkov,
Jakob Voß,
Jakub Klímek,
Jan Voskuil,
Jim J. Yang,
Joep Meindertsma,
Joep van Genuchten,
Katherine Anderson Aur,
Ludger A. Rinsche,
Marielle Adam,
Martial Honsberger,
Mathias Bonduel,
Mathias Richter,
Matthias Palmér,
Nancy Jean,
Nuno Freire,
Øystein Åsnes,
Paul van Genuchten,
Pieter J. C. van Everdingen,
Renato Iannella,
Rajaram Kaliyaperumal,
Robin Gower,
Sabine Maennel,
Sebastian Hellman,
Simson L. Garfinkel,
Siri Jodha S. Khalsa,
Stefan Ollinger,
Stephen Richard,
Stian Soiland-Reyes,
Stig B. Dørmænen,
Susheel Varma,
Sidney Cox,
Thomas Francart,
Vittorio Meloni,
Wouter Beek,
Yves Coene.
편집자들은 또한 이 워킹 그룹의 의장 Caroline Burle 및 Peter Winstanley,
그리고 스태프 연락 담당자 Philippe Le Hégaret 및 Pierre-Antoine Champin께 감사드립니다.
개정된 DCAT(이 문서)에서 [SCHEMA-ORG] 버전 3.4로의
권장 매핑은 RDF 파일로 제공됩니다.
이 매핑은 rdfs:subClassOf,
rdfs:subPropertyOf, owl:equivalentClass, owl:equivalentProperty,
skos:closeMatch 술어를 사용하고,
또한 [SCHEMA-ORG] 의미론과 맞추기 위해 주석 속성
sdo:domainIncludes 및 sdo:rangeIncludes를 사용하여 공리화되어 있습니다.
정렬은 아래 표에 요약되어 있으며, 접두사 sdo는 http://schema.org/로 간주됩니다.
여러 속성이 인용 및 제목 안을 포함하여 출처 정보를 포착하지만, 프로젝트의 형식적 설명으로 이어지는
기본 링크는 prov:wasGeneratedBy를 통해 이루어집니다.
프로젝트의 간결한 설명은 prov:Activity로 표시되지만,
이것이
반드시 같은 카탈로그의 일부일 필요는 없습니다.
프로젝트가 진행 중이므로 해당 활동에는 종료일이 없다는 점에 유의하십시오.
추가 출처 정보는 PROV의 다른 시작점 속성, 특히
prov:wasAttributedTo(데이터셋
생산과 관련된 에이전트로 연결) 및 prov:wasDerivedFrom(선행
데이터셋으로 연결)을 사용하여 제공될 수 있습니다. 이 둘은 DCAT에서 이미 사용되는 Dublin Core 속성을
다음과 같이 보완합니다:
prov:wasAttributedTo는 프로젝트 후원자, 관리자, 데이터셋 소유자 등
dcterms:creator, dcterms:contributor 또는
dcterms:publisher로는 올바르게 특징지을 수 없는 모든 종류의 관련 에이전트로
일반 링크를 제공합니다.
prov:wasDerivedFrom은 반드시 이전 데이터셋일 필요는 없는 dcterms:source와
비교하여 입력 또는 선행 데이터셋에 대한 더 구체적인 관계를 지원합니다.
리소스 귀속과 상호관계를 위한 한정 속성 사용의 추가 패턴은
15.
한정 관계에 설명되어 있습니다.
C.3 데이터셋과 간행물 연결
데이터셋은 종종 간행물(학술 논문, 보고서 등)과 연관되며, DCAT은 데이터셋에 관한 간행물을
데이터셋에 연결하는 방법을 제공하기 위해
dcterms:isReferencedBy 속성에 의존합니다
데이터 서비스는 DCAT을 사용하여 설명될 수 있습니다.
분류자 dcterms:type, dcterms:conformsTo 및
dcat:endpointDescription의 값은 서비스에 관한 점진적으로 더 자세한 정보를 제공하며,
실제 엔드포인트는 dcat:endpointURL로 제공됩니다.
첫 번째 예제는 European Environment Agency (EEA)가 호스팅하는 데이터 카탈로그를 설명합니다.
이는 dcat:DataService로 분류되며,
공간 데이터 서비스 유형의 INSPIRE 분류 [INSPIRE-SDST]에서 온
"discovery"로
dcterms:type가 설정되어 있습니다.
OpenAPI Specification. Darrell Miller; Jason
Harmon; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Tony Tam; Uri Sarid. OpenAPI
Initiative. URL: https://www.openapis.org/
