구현 가능한 접근 방식

사람이 읽을 수 있는 메타데이터 제공 방식 예시:

• HTML 웹 페이지의 일부로 메타데이터 제공
• 메타데이터를 별도의 텍스트 파일로 제공

기계가 읽을 수 있는 메타데이터 제공 방식 예시:

• 기계 판독 메타데이터는 Turtle, JSON 등 직렬화 포맷으로 제공하거나, [HTML-RDFA] 또는 [JSON-LD]를 활용해 HTML 페이지에 삽입할 수 있습니다. 여러 포맷을 개별적으로 제공하는 경우, 동일한 URL에서 콘텐츠 협상(content negotiation)을 활용해 제공하고, 파일 확장자를 구분하여 별도의 URI로 제공하는 것이 좋습니다. 여러 포맷을 관리하는 최선의 방법은 메타데이터의 단일 원본에서 각 포맷을 실시간(generated on the fly)으로 생성하는 것입니다.
• 기계 판독 메타데이터 정의 시에는 표준화된 용어와 널리 쓰이는 어휘의 재사용을 적극 권장합니다. 예를 들어, 더블린 코어 메타데이터(DCMI) 용어[DCTERMS]와 데이터 카탈로그 어휘[VOCAB-DCAT]는 설명 메타데이터 제공에 활용할 수 있습니다. 이러한 어휘는 매우 유연하게 설계되었으므로, European Commission의 DCAT-AP처럼 구체적인 프로파일을 사용하는 것도 도움이 될 수 있습니다.

구현 가능한 접근 방식

설명 메타데이터에는 다음과 같은 데이터셋 전체 특성이 포함될 수 있습니다:

• 데이터셋의 제목과 설명
• 데이터셋을 설명하는 키워드
• 데이터셋의 공개일
• 데이터셋 제공에 책임 있는 주체(게시자)
• 데이터셋의 연락처
• 데이터셋의 공간적 범위
• 데이터셋이 포함하는 시간적 범위
• 데이터셋의 최종 수정일
• 데이터셋이 포함하는 주제/카테고리

설명 메타데이터에는 다음과 같은 배포판의 전체 특성이 포함될 수 있습니다:

• 배포판의 제목과 설명
• 배포판의 공개일
• 배포판의 미디어 유형

설명 메타데이터의 기계 판독 버전은 데이터셋 설명에 W3C가 권장하는 Data Catalog Vocabulary [ VOCAB-DCAT]와 같은 어휘를 사용할 수 있습니다. 이를 통해 데이터셋을 추상적 엔터티로 기술하는 프레임워크를 제공합니다.

구현 가능한 접근 방식

사람이 읽을 수 있는 구조적 메타데이터는 보통 데이터셋 스키마의 속성 또는 컬럼 정보를 제공합니다.

기계 판독 구조적 메타데이터는 특정 배포판의 포맷에 따라 별도의 문서로 제공할 수도, 문서 내에 삽입할 수도 있습니다. 상세 내용은 아래 링크를 참고하세요.

• 표형 데이터: 웹상의 표형 데이터 및 메타데이터 모델 참고
• JSON-LD: JSON-LD 1.0 참고
• XML: XML 스키마 참고
• 다차원 데이터: Data Cube 참고

구현 가능한 접근 방식

데이터 라이선스 정보는 사람이 읽을 수 있는 라이선스 계약에 대한 링크 또는 포함된 사본으로 제공할 수 있습니다. 또한, 기계가 읽을 수 있는 라이선스 계약의 링크 또는 포함된 사본으로 제공해 처리가 가능하도록 할 수도 있습니다.

라이선스를 연결할 수 있는 속성을 포함하는 아래 어휘 중 하나를 사용할 수 있습니다:

• Dublin Core [DCTERMS] (dct:license)
• Creative Commons [CCREL] (cc:license)
• schema.org [SCHEMA-ORG] (schema:license)
• XHTML [XHTML-VOCAB] (xhtml:license)

또한 다음과 같은 여러 기계 판독 권리 언어가 있습니다:

• Creative Commons Rights Expression Language [CCREL]
• Open Digital Rights Language [ODRL-model]
• Open Data Rights Statement Vocabulary [ODRS]

구현 가능한 접근 방식

기계가 읽을 수 있는 데이터 프로비넌스는 정보 기술에 권장되는 온톨로지(예: W3C의 프로비넌스 온톨로지 [PROV-O])를 사용하여 제공할 수 있습니다.

구현 가능한 접근 방식

데이터셋 품질 메타데이터의 기계 판독 버전은 DWBP 워킹 그룹이 개발한 데이터 품질 어휘 [VOCAB-DQV]를 사용해 제공할 수 있습니다.

실행 방안

버전 관리 정보를 제공하는 최적 방안은 맥락마다 다르나, 다음과 같은 기본 지침이 있습니다:

• 데이터셋의 메타데이터에 고유 버전 번호 또는 날짜를 포함하세요.
• 숫자 체계(버전 체계)는 의미 있고 일관된 증분 규칙을 사용하세요. 예시: [SchemaVer].
• 데이터를 API로 제공할 경우, 최신 데이터 요청용 URI는 버전이 바뀌어도 변경되지 않아야 하며, 특정 버전을 명시적으로 요청할 수도 있어야 합니다.
• Memento [RFC7089] 또는 그 구성요소를 활용해, 데이터셋의 시계열 버전을 표현하고 특정 시점에 유효했던 버전에 접근할 수 있습니다. Memento 프로토콜은 아래에 설명된 W3C 명세 버전 URI 할당 방식과 유사합니다.

웹 온톨로지 언어[OWL2-QUICK-REFERENCE] 및 Provenance, Authoring and Versioning Ontology [PAV]에서는 버전 정보에 쓸 수 있는 다양한 주석 속성을 제공합니다.

실행 방안

게시된 버전들의 목록과, 각 버전이 이전 버전과 어떻게 다른지 설명한 변경 요약을 함께 제공하세요. 하나의 전용 URL에서 최신 전체 이력을 조회할 수 있게 하는 API도 구현할 수 있습니다.

실행 방법

URI를 영구적으로 사용하려면 설계 시부터 이를 고려해야 합니다. 관련 자료가 매우 많으며, 예시로 유럽연합 "영구 URI에 관한 연구"[PURI]는 여러 참고 자료를 제공합니다.

발행자가 영구성을 직접 관리할 URI 공간을 확보할 수 없다면, Permanent Identifiers for the Web이나 purl.org 같은 리디렉션 서비스를 활용할 수 있습니다. 이런 서비스를 통해 발행 위치가 바뀌더라도 리디렉션으로 언제든 연결 가능합니다. 해당 서비스의 소프트웨어는 자유롭게 설치·운영할 수도 있습니다.

DOI(Digital Object Identifier)도 대안이 될 수 있습니다. DOI는 웹 기술과 독립적으로 정의되지만, 'URI stub'와 결합해 활용이 가능합니다. DOI는 연구 데이터와 도서관 등 디지털 인프라에서 매우 중요한 역할을 합니다.

실행 방법

이 주제는 워낙 광범위해 본 문서에서는 개략만 다룹니다.

개발자는 자신이 풀려는 문제의 해결책이 이미 타인에 의해 구현된 경우가 많다는 점을 잘 압니다. 마찬가지로, 국가, 통화, 학문분야, 종, 단백질, 도시, 지역, 노벨상 수상자, 상품 등 분명한 주제의 식별자 셋이 이미 존재할 가능성이 높습니다. 기존 어휘 찾기 절차 [LD-BP]도 참고 가능합니다.

• 사용하는 URI 세트가 신뢰받는 조직이나 그룹에서 발행되었는지 확인하세요.
• 해당 URI 세트가 영구 URI인지도 검증하세요.

요구에 부합하는 식별자집이 없다면, 직접 새로 설계해야 하며, 다른 이들이 내 데이터를 링크해 부가가치를 올릴 수 있도록 URI 영속성 규칙을 준수해야 합니다.

실행 방법

W3C 문서 버전 관리를 좋은 예로 들 수 있습니다. (영구) URI https://www.w3.org/TR/2016/PR-dwbp-20161215/는 해당 일자 문서의 스냅샷입니다. '최신 버전'용 URI https://www.w3.org/TR/dwbp/는 일련의 유사 문서군을 가리키며, 향후 문서가 갱신될 때마다 '최신버전' URI는 갱신된 문서로 포워딩되고, 일자형 URI는 불변입니다.

구현 가능한 접근 방식

CSV, XML, HDF5, JSON 및 RDF 직렬화 문법(RDF/XML, JSON-LD, Turtle 등)을 포함하되 이에 제한하지 않고, 쉽게 파싱 가능한 표준 기계가독 데이터 형식으로 데이터를 제공하세요.

구현 가능한 접근 방식

대부분의 일반적인 데이터 직렬화 형식은 지역 중립적입니다. 예를 들어, XML 스키마 타입 xsd:integer, xsd:date 등은 지역 중립적인 데이터 교환을 위한 것입니다. 지역 중립적 표현을 사용하면 복잡한 파싱이나 오해 걱정 없이 값을 정확하게 처리할 수 있고, 데이터 소비자 환경에 맞는 표기로도 쉽게 보여줄 수 있습니다. 예를 들어, "€2000,00"을 문자열로 저장하기보다 아래와 같은 데이터 구조로 교환하는 것이 강력히 권장됩니다:

…
"price" {
    "value": 2000.00,
    "currency": "EUR"
}
…

일부 데이터셋에는 지역 중립적으로 전환할 수 없는 값이 있을 수 있습니다. 특히 자연어 텍스트 값이 그런 경우입니다. 지역/언어에 따라 달라지는 데이터를 위한 각 필드에는 해당 언어와 지역을 표시하는 언어 태그가 필요합니다. 이 정보는 데이터 파싱, 데이터 소비자 측의 올바른 표시 및 처리를 도와줍니다. BCP47 [BCP47]은 언어와 지역 식별 표준이고, CLDR [CLDR]은 특정 로케일 포맷 및 참조값의 소스 역할을 합니다.

구현 가능한 접근 방식

필요 가능성이 높은 데이터 형식을 고려하고, 미래에 유용할 법한 대안도 염두에 두세요. 데이터 제공자는 여러 형식으로 제공하는 데 드는 노력과 그 효과 간의 균형을 맞춰야 합니다. 최소 한 개의 대안 형식만 추가로 제공해도 데이터의 활용성은 크게 늘어납니다. 여러 형식으로 데이터를 제공하려면 모범 사례 – 다중 형식용 콘텐츠 협상(Content Negotiation)에서 설명한 방법을 활용할 수 있습니다.

참고: 데이터셋 내의 로컬 식별자(local identifier)는 URI의 fragment로 노출될 수 있으므로 형식 간 일관성이 반드시 유지되어야 합니다.

구현 방법

W3C의 링크드 데이터 출판 모범 사례 [LD-BP]의 어휘(Vocabularies) 절은 기존 어휘의 탐색, 평가, 선택에 관한 지침을 제공합니다.

OGC(Open Geospatial Consortium), ISO, W3C, WMO, 도서관, 연구 데이터 서비스 등은 모두 공용 코드, 용어, Linked Data 어휘 목록을 제공합니다. 핵심은 데이터셋/문서에서 사람이든 기계든 그 값의 표준화된 의미를 파악할 수 있는 충분한 맥락 정보를 제공해야 한다는 점입니다. 웹에서는 표준 어휘 리소스의 명확한 웹 식별자(URI)를 활용하면 효율적입니다(같은 URI에 다국어 레이블을 부여해 더 나은 국가 간 상호운용성도 가능). EU의 다국어 시소러스인 Eurovoc가 대표적입니다.

구현 방법

동료들이 이미 뭘 쓰는지 보세요. 대개 현재 요구와 맞거나 거의 맞는 어휘가 있을 겁니다―그걸 쓰는 게 좋습니다.

마음에 드는 어휘가 도메인/범위 제약 등 내 케이스에 안 맞는 제한을 가진 경우, 어휘 발행자에게 연락해 해소할 수 있는지 문의해보세요. 보통 제한을 풀거나 더 다양한 활용사례 가이드도 받을 수 있습니다.

W3C는 public-vocabs@w3.org [archive]에서 어휘 사용/개발 관련 토론을 진행합니다.

직접 어휘를 만든다면, 의미적 제약(제한)을 최소화하여 타인이 재사용 가능성을 높이세요. 예를 들어 SKOS(가장 널리 쓰이는 온톨로지 중 하나) 설계자들은 제안된 형식적 공리 대부분을 비판적으로 바라보고, 많은 경우 응용과 충돌 가능성을 우려해 도입하지 않았습니다. 예) skos:broader 속성은 많은 시소러스에서 위계 링크를 정의하는 데 적합함에도 불구하고, 전이적(transitive) 성질은 정의하지 않았습니다 [SKOS-DESIGN 참조]. 이런 '광폭 설계(design for wide use)' 내역을 고려해서 어휘를 선택하세요.

이런 ‘광폭 설계’ 예로 schema.org도 있습니다. 2011년 등장한 schema.org는, 타입의 사용가능 대상(프로퍼티의 사용 범위 등)을 규정할 때 강제보다 안내(권장, informative approach)를 해 폭발적으로 채택되었습니다. 예) author 속성의 값은 Organization 혹은 Person이어야 한다고 기대(expect)할 뿐, 실제로는 CreativeWork 등에서도 사용할 수 있고 엄격 제약이 아닙니다. 이런 설계 덕분에 schema.org는 데이터 공유용 어휘로 좋은 선택이 됩니다.

구현 방법

데이터의 성격과 소비자의 필요에 따라 다음과 같은 방식이 포함될 수 있습니다:

• 데이터셋이 처음부터 여러 파일로 존재하는 경우, 데이터를 하나의 파일로 미리 처리(preprocessing)하여 하나의 URI에서 다운로드할 수 있도록 제공. 대용량 데이터셋의 경우 파일을 압축할 수도 있습니다.
• 일괄 다운로드와 동적 쿼리 기능을 모두 지원하는 API 제공. 이 접근법은 동적 데이터의 전체 스냅샷을 캡처하는 데 유용합니다.
• 아주 대용량 데이터셋의 경우 http 이외의 방식(예: bbcp 또는 GridFTP)을 통해 일괄 파일 전송을 지원할 수 있습니다.

일괄 다운로드에는 데이터셋을 설명하는 메타데이터도 포함해야 합니다. 발견 메타데이터[VOCAB-DCAT]는 일괄 다운로드 외부에도 제공해야 합니다.

구현 방법

데이터셋의 예상 사용사례를 고려하여 어떤 유형의 부분집합이 가장 유용할지 판단해야 합니다. API는 일반적으로 부분집합 데이터를 제공하는 가장 유연한 방식으로, 전송할 데이터의 커스터마이즈가 가능해 어떤 상황에서도 필요한 데이터만 받을 수 있게 합니다. 세분화 수준은 웹 애플리케이션 접근 속도에 적합해야 합니다. (예: API 호출이 1초 내 응답된다면 자연스러운 상호작용이 가능, 10초 이상 걸리면 사용자는 실패로 인식할 수 있습니다.)

데이터셋을 작은 단위로 나눈 후, 그 단위를 개별적으로 다운로드하거나 조회할 수 있도록 하는 것도 하나의 방법입니다.

또한 데이터셋 내부에 각 섹션(또는 예상 사용 목적에 따라 더 작은 단위)에 별도의 처리가 가능하도록 마크업을 추가하는 것도 도움이 됩니다. 예를 들어 RDF Data Cube Vocabulary를 사용해 "슬라이스"를 표시하는 방법이 있습니다.

구현 방법

실현 방법은 웹서버를 설정하여 요청된 자원의 콘텐츠 협상 기능을 활성화하는 것입니다.

자원의 구체적 표현 형식은 URI 또는 HTTP 요청의 Content-type을 통해 접근할 수 있습니다.

구현 방법

정보 제공자가 웹 서비스를 구성하여 실시간 데이터가 도착하면 즉시 소비자가 polling 또는 streaming으로 받을 수 있게 하는 방법입니다.

소비자가 데이터를 자주 확인하지 않을 때는 API를 통해 소비자 요청 시 가장 최신 데이터를 polling 방식으로 읽도록 할 수 있습니다. 정보 제공자는 이러한 조회(read-only) 요청을 위해 API를 제공합니다.

소비자가 데이터를 자주 확인한다면, 데이터가 API를 통해 실시간으로 push되는 streaming 데이터 구현이 더 적합할 수 있습니다. 스트리밍 기술에는 Server-sent Events, WebSocket, EventSourceAPI 등 여러 표준 프로토콜이 있습니다.

구현 방법

정기적으로 데이터셋의 새 버전을 웹에 게시하는데, 이때 데이터 버전 관리 최고 권장사항을 따라야 합니다. 웹 게시를 데이터 새 버전 출시 절차의 일부로 포함하거나 담당자를 지정하면 데이터가 구버전으로 머무르는 것을 방지할 수 있습니다. 앞으로의 업데이트에 대한 기대치를 명확하게 하기 위해 업데이트 빈도를 명시한 텍스트와, 빈도를 표시한 기계 판독 가능한 메타데이터를 함께 제공할 수 있습니다.

구현 방법

기계/사람 맥락에 따라 다양한 제공불가 표시 방법이 있습니다. 데이터 제공자는 HTML 문서로 사람이 읽을 수 있는 설명을 제공할 수 있습니다. 기계 인터페이스에서는 관련 HTTP 상태 코드와 맞춤형 메시지를 사용할 수 있습니다. 예시: 303(See Other), 410(영구 삭제됨), 503(데이터 제공 서비스 불가) 등이 있습니다.

구현 방법

다음 두 가지 시나리오를 고려해야 합니다:

1. 리소스가 완전히 삭제되어 어떤 경로로도 이용할 수 없음
2. 리소스가 보관되어 있으며, 아카이브 요청을 통해서만 접근 가능함

첫 번째 경우, 서버는 410(Gone) HTTP 코드로 응답하도록 설정해야 합니다. 명세에서는 다음과 같이 설명합니다:

410 응답은 주로 웹 유지 관리를 보조하기 위한 것으로, 해당 리소스가 의도적으로 이용 불가함을 알리고 서버 소유자가 외부 링크를 제거하도록 권장하는 데 사용됩니다.

두 번째로 데이터가 보관된 경우, 데이터를 보관 중인 아카이브 및 접근 방법에 대한 정보를 제공하는 웹 페이지로 리디렉션하는 것이 더 적절합니다.

두 경우 모두, 원래 URI는 계속해서 리소스를 식별하며 데이터가 더 이상 직접적으로 제공되지 않아도 유용한 정보로 연결이 유지됩니다.

구현 방법

사용된 리소스가 모두 어딘가 이미 보존되어 있거나, 보존 대상 데이터셋과 함께 제공되어야 하는지 점검하세요.

구현 방법

문의 양식, 클릭식 데이터 품질 평가 버튼, 댓글 박스 등 하나 이상의 피드백 방식을 제공하세요. 받은 피드백을 최대한 활용하려면, 각 항목을 데이터베이스에 저장해 정량화 및 분석이 가능한 추적 시스템과 연계하는 것이 좋습니다. 피드백 유형(예: 편집, 분류[평가], 댓글, 질의 등 동기)을 함께 기록하면 Dataset Usage Vocabulary [VOCAB-DUV]을 활용해 피드백 항목을 표현할 수도 있습니다.

구현 방법

피드백은 HTML 웹페이지의 일부로 공개할 수도 있지만, Dataset Usage Vocabulary [VOCAB-DUV]을 활용해 기계판독형으로 제공할 수도 있습니다.

구현 방법

데이터 고도화 기법은 매우 복잡하며 이 문서에서 다루는 범위를 넘어갑니다. 여기서는 가능성만 간략히 언급합니다.

머신러닝은 데이터 고도화에 많은 부분 적용할 수 있습니다. 카테고리 분류, 모호성 제거, 엔터티 추출, 감성 분석, 토픽 구축 등 다양한 방법이 있습니다. 기존 열에 대해 수식계산만으로도 새 값을 산출할 수 있습니다. 시각 분석을 통한 공간 데이터 feature 식별, 인구통계 정보 결합도 대표적 예입니다. 마지막으로, 고도화가 수요 기반일 수도 있는데 이 경우 누락값을 계산 등 직접적으로 보완하기도 합니다.

추론 기반 기법으로 추가된 값은 반드시 그렇게 산출되었음을 명확하게 표시해야 하며, 고도화로 대체된 원본 값도 여전히 조회 가능해야 합니다.

라이선스가 허용된다면, 데이터 고도화에 사용된 코드는 데이터셋과 함께 공개하세요. 과학 데이터의 경우, 코드 공유는 특히 중요합니다.

고도화 우선순위는 데이터 소비자에게의 가치와 소요 노력에 따라 결정하세요. 사용자의 요구는 설문, 직접요청 기록 등 수요 측정으로 평가 가능하며, 이러한 수요 분석 방법 자체도 함께 문서화해야 데이터 가치 향상이 입증될 수 있습니다.

타인의 데이터에 대해 고도화 작업을 했다면, 그 결과를 원 제공자에게 환류하는 것도 권장됩니다.

구현 방법

가장 쉬운 방법은 홈페이지 등에 데이터 해석 요약본을 제공하는 것입니다. 그래프나 표로 요약정보를 함께 제공하면 사용자가 데이터를 빨리 이해할 수 있습니다.

인터랙티브 시각화나 웹 애플리케이션을 만들 수 있는 역량이 있다면, 데이터를 좀 더 쉽게 이해하고 패턴을 찾을 수 있도록 제공할 수 있습니다. 이는 데이터가 효율적으로 처리될 수 있음을 보여주며, 재사용도 촉진합니다.

구현 방법

새 제품에서 데이터셋을 사용할 때는 제공자의 연락처, 사용한 데이터셋의 URI, 연락일자를 기록해두세요. 이를 데이터셋 활용 코드의 주석으로 남길 수 있습니다. 제공자의 피드백 요청 경로를 따라 피드백을 제공하세요. 따로 안내가 없다면 데이터가 올라간 웹사이트의 연락처를 확인해 사용하세요.

구현 방법

원본 라이선스를 읽고, 그 요건을 지켜야 합니다. 파생 저작물에 특정 라이선스 적용을 요구한다면, 그에 맞는 라이선스를 선정하세요. 별도의 라이선스가 없다면, 원래 제공자에게 문의해 라이선스 정보를 받아야 합니다.

구현 방법

사용자 인터페이스에 원본 출처에 대한 인용문과 작동하는 링크를 함께 보여줄 수 있습니다.