원문은 IPLD Github specs 에서 확인 가능하다. IPLD Content Addressability

Concept: Content Addressability

“Content addressability”는 신뢰할 수없는 식별자로 콘텐츠를 참조 할 수있는 기능을 말한다.

문자열 식별자 또는 URL로 콘텐츠를 참조하는 대신 콘텐츠 주소 지정 시스템(content addressable system)은 콘텐츠를 암호화 해시로 참조한다. 이렇게하면 식별자가 검색 방법을 지정하지 않고 콘텐츠를 확인하는 안전한 방법을 제공하므로 콘텐츠의 완전한 분산을 허용한다.

원문은 IPLD Github specs 에서 확인 가능하다. IPLD block

Concept: Block

IPLD 블록은 해당 CID에 대한 CID 및 이진 데이터 값이다.

short version:

+-----+--------------------------------+
| CID | Data                           |
+-----+--------------------------------+

long version:

+-----------------------------------+------------------+
| CID                               | Binary Data      |
| +------------------------------+  |                  |
| |Codec                         |  |                  |
| +------------------------------+  |                  |
| |Multihash                     |  |                  |
| | +----------+---------------+ |  |                  |
| | |Hash Type | Hash Value    | |  |                  |
| | +----------+---------------+ |  |                  |
| |                              |  |                  |
| +------------------------------+  |                  |
|                                   |                  |
+-----------------------------------+------------------+

원문은 IPLD Github specs 에서 확인 가능하다. IPLD document

IPLD Specifications

IPLD 의 목표는 일반적인 주소 지정이 가능하고 링크로 연결된 분산형 데이터 구조를 가능하게 하여 분산 응용이 가능하도록 하는 것 이다. 이러한 데이터 구조는 HTML 웹 페이지에 대한 URL 및 링크 데이터를 처리할 수 있다.

IPLD 는 단일사양(Single Specification) 이 아니며 일련사양(set of specification) 이다. 즉, IPLD 의 많은 사양은 상호 의존적(inter-dependent) 이다.

1. IPLD Layer Model

계층 모델은 IPLD 개념 및 요구 사항의 단순화 된 구조이다.

+-------------------------------------------------+
|                   Schema Layer                  |
| (multi-block layer 데이터 구조의 advanced type) |
+-------------------------------------------------+
|                  Data Model Layer               |
|  (sigle-block layer 데이터 구조의 basic type)   |
+-------------------------------------------------+
|                    Block Layer                  |
|                (cid, data, codec)               |
+-------------------------------------------------+

1.1 Block Layer (Layer 0)

블록 계층은 모든 content addressed block 포멧을 포함하고 블록 주소 지정 방법, 인코딩/디코딩을 위한 코덱 자체 설명(self-describe) 및 블록간 연결(link) 방법을 지정한다.

이 계층만으로 다양한 형식(eth, bitcoin, git, dag-pb, dag-cbor, etc)의 기본 그래프 복제(basic graph replication) 를 수행할 수 있다.

많은 코덱이 이러한 형식을 원래 형식(native type)으로 변환 할 수 있지만 이 계층은 데이터 구조 또는 형식을 정의하지 않으며 형식 요구 사항이나 블록 계층의 형식에 대한 보증이 없다.

Documents:


Concept: Block	block-layer/block.md
Concept: Content Addressability	block-layer/content-addressability.md
Concept: Multihash	block-layer/multihash.md
Concept: Serialization and Formats	block-layer/serialization-and-formats.md
Specification: CIDs	block-layer/CID.md
Specification: DAG-CBOR	block-layer/codecs/DAG-CBOR.md
Specification: DAG-JSON	block-layer/codecs/DAG-JSON.md
Specification: IPLD Selectors	block-layer/selectors/selectors.md
Specification: Graphsync	block-layer/graphsync/graphsync.md

1.2 Data Model Layer (Layer 1)

데이터 모델 계층은 IPLD 코덱의 서브셋에 의해 구현될 기본 필수 유형 세트(set of base required types) 를 설명한다.

이러한 기본 유형을 사용하여 작성자는 예측 가능한 경로(predictable paths) 및 선택기(selectors)로 읽을 수 있는 다양한 단일 블록 데이터 구조를 만들 수 있다.

데이터 모델 계층만 있으면 여러 데이터 구조를 작성하여 단일 블록에 넣을 수 있다. 이러한 데이터 구조는 서로 연결할 수도 있지만 single collection (Map or List)은 데이터 모델만으로 여러 블록에 분산될 수 없다.

다른 시스템과 전송은 메모리 사용을 제어하기 위해 블록 크기 제한(2MB 이상)을 부과 할 수 있기 때문에 더 큰 컬렉션은 스키마 레이어에서 여러 블록에 걸쳐 분할해야 한다.

Documents:


Specification: IPLD Data Model	data-model-layer/paths.md
Specification: IPLD Paths	data-model-layer/data-model.md

1.3 Schema Layer (Layer 2)

IPLD 스키마는 데이터 모델 레이어(Layer 1)에서 복잡한 레이아웃을 구성하는 인스턴스화 된 데이터 구조에 대한 매핑을 정의한다. 스키마 레이어는 맞춤 번역 추상화를 구현할 필요없이 데이터 소스와의 일반적인 프로그래밍 방식 상호 작용에 필요한 다양한 유형으로 IPLD 데이터 모델을 확장 할 수 있는 기능을 추가한다.

스키마 레이어는 또한 개별 블록 내에서 데이터 모델 사용의 안정성과 일관성을 제공하고 다중 블록 맵(multi-block map), 목록(List) 및 세트(set)와 같은 고급 데이터 레이아웃을 작성하고 상호 작용하는 데 필요한 논리에 대해 정의 된 상호 작용 지점을 제공함으로써 복잡한 다중 블록 데이터 구조의 활성화 레이어 역할을 한다.

Documents:


Specification: IPLD Schemas	schema-layer/schemas/schemas.md
Concept: IPLD Multi-block Collections	schema-layer/data-structures/multiblock-collections.md

2. Specification document status

이 저장소(repository)의 사양 문서(Specification documents)는 두 가지 범주 중 하나에 적합하며 세 가지 상태 중 하나를 가진다.

Prescriptive
- Exploratory
- Draft
- Final
Descriptive
- Draft
- Final

Prescriptive(규정) 사양은 향후 구현을 설명하거나 경우에 따라 기존 구현을 변경하기위한 것이다.

Descriptive(설명) 사양은 기존 동작을 설명한다. 대부분의 경우 이러한 사양은 새로운 구현을 유도하기위한 것이 아니며 기존 동작을 이해하기 위해 작성된 것이다.

이 저장소의 “Specification(사양)”이라고 표시된 문서에는 카테고리와 상태를 나타내는 설명자가 표시된다. 예: “Status: Prescriptive - Draft” or “Status: Descriptive - Final”.

Introduction to Linked Open Data

1. Overall Concept

1.1 추진배경 및 목적

Big Data, Linked Data, Open Data 등은 현재 사람이 읽고 이해하는 것을 바탕으로 한 정보생태계와 달리 Data 자체에 초점을 둔 새로운 트랜드이다.

핵심은 ‘Data’ 에 있으며 이를 해결하기 위한 IT Infra 외 Data 자체의 양적 증가, 복잡성, 활용성 등의 해결과제를 가짐

특히, LOD (Linked Open Data) 는 개방형 데이터 (Open Data) 요구와 맞물려 있으며 기존의 거대한 정보 생태계인 WEB 의 기술과 핵심 개념을 그대로 활용한다는 점에서 주목받고 있다.

2. Semantic Web & Linked Open Data

LOD 는 자연스럽게 ‘Semantic Web (의미론적 웹)’ 과 연결된다. “Linked Open Data 는 Semantic Web 을 실현시키지 위한 방법이자 기술적 접근점” 이라고 할 수 있다. Web 의 창시자인 팀 버너스-리 (Tim Berners-Lee) 는 Semantic Web 을 다음과 같이 정의하였다.

Semantic Web 은 현재 Web 이 확장된 형태로, 잘 정의된 의미를 정보에 부여함으로써 사람과 컴퓨터의 협업을 보다 원활하게 할 수 있도록 하는 것¹

즉, Semantic Web 은 현재 Web 의 한계와 문제점을 보완하는 새로운 형태를 의미하는 것은 아니다. 현재 Web 은 정보가 생성되고 전달, 확산, 소멸되는 생태계로 성장하고 있다. 문제는 현재의 Web 은 사람이 읽고 활용할 수 있는 문서의 Web 이라는 점에서 한계가 존재한다.

Web 을 구성하는 정보들이 담겨있는 데이터베이스 (구조화된 데이터) 를 Web 에서 활용할 수 있다면, 즉 Web 을 모두가 함께 사용할 수 있는 데이터베이스처럼 만든다면 사람이 읽고 이해하는 정보를 컴퓨터가 자동으로 처리하는 것이 가능할 것이다.

모두가 함께 사용할 수 있는 데이터베이스로 만들기 위해서는 Web 에 개방되는 데이터들의 의미와 활용 범위 등을 명확히 해주어야 한다. 즉, Web 에서 데이터가 상호운용성을 갖기 위해서는 Web 에 기술된 데이터 (객체) 가 명확해야 한다.

Semantic Web 을 만들 수 있는 기술은 Web 에 데이터를 저장하고 조작할 수 있는 규칙들을 만들 수 있어야 하는데, Linked Data 핵김 기술 요소인 RDF, SPARQL, OWL, SKOS 가 이러한 개념들을 실제로 구축가능하게 한다.²

물론 Semantic Web 을 구현하기 위한 유일한 방법이 Linked Open Data 라고 할 수 없으나 가장 활발하게 연구개발이 이루어지고 있는 분야가 Linked Open Data 인 것이다.

3. Linked Open Data (Linked Data + Open Data)

Linked Open Data 는 Linked Data 와 Open Data 의 합성어이다. Linked Data 는 기술적인 면이 강한 반면 Open Data 는 문화적인 면이 강하다.

Open Data 는 누구나 자유롭게 사용, 재사용하고 재배포할 수 있는 데이터를 의미하는데, 다음의 조건을 만족하여야 한다 (Open Knowledge Foundation, 2012)³:

Availability and Access (가용성과 접근성)
- Data 는 인터넷을 통하여 다운로드 받을 수 있어야 하고, 합리적인 비용으로 Raw Data 를 변환하거나 새로운 Data 생산이 가능하여야 함 (데이터는 편리하게 수정 가능한 형태로 제공해야 함)
Reuse and Redistribution (재사용과 재배포)
- Data 는 다른 Data Set 과 조합하여 사용하는 것을 포함한 재사용, 재배포가 가능한 형태여야 함
Universal Participation (모두의 참여)
- 모든 사람이 사용, 재사용, 재배포할 수 있어야 함 (이용의 제한이 없어야 함)

Linked Data 는 현재 Web 에 구조화된 데이터를 연결하고 publishing (발행) 하기 위한 방법으로 발행된 데이터들은 서로 연결되어 유용하게 사용될 수 있다.

Linked Data 는 HTTP, RDF, URI 와 같은 표준 기술을 활용하고 자동적으로 컴퓨터가 읽고 처리할 수 있는 (machine readable and processable) 방식으로 정보를 공유
Linked Data 는 서로 다른 출처의 Data 들이 서로 연결되고 또한 질의가 가능함

Linked Open Data 는 사람 위주의 현재 Web 을 컴퓨터가 사람처럼 데이터를 이해하고 자동으로 처리할 수 있는 데이터 중심의 Web 으로 구축하는 것이다. 어떤 분야에 어떻게 활용될 수 있는지 명확하게 정의되어야 한다. 데이터 중심의 Web 이 구현되면 Open Data 의 조합으로 누구나 다양하고 새로운 서비스를 개발할 수 있다. 이런 의미로 LOD 는 기존의 정보 개방 혹은 데이터 개방과 다르게 새로운 서비스 실현을 가능하게 하는 형태라고 볼 수 있다.

4. Web is Linked Open Data Platform

LOD 가 구현 및 활용되는 플랫폼⁴은 Web 이다. 즉, LOD 를 만들기 위한 핵심 기술요소는 Web 에서 활용되는 기술과 개념을 활용한다.

또한 LOD 를 통해 구축, 발행되는 데이터는 Web 을 통하여 발행되어 있고 이를 활용하기 위해서는 Web 과 지속적인 연결성을 가져야 한다.

현재 Web 을 만들고 유지하는 핵심 개념과 기술은 Hypertext, HTML, HTTP, URI 이다.

URI: http://linkeddata.org/

HTML 문서가 열리게 되며 HTML 문서의 내용은 Hypertext 와 Hyperlink 로 구성되어 있다.

+[HTML: index.html]-------------------+
|                                     |
| hyptertext                          |
| hyptertext                          |
| hyptertext                          |
| hyptertext                          |
| hyptertext                          |
| hyptertext <hyperlink> hyptertext   |
|                                     |
+-------------------------------------+

Hypertext 는 문서의 특정 문자나 이미지, 동영상 등과 같은 정보 객체가 관련된 다른 문서 혹은 위치로의 이동을 가능하게 한다. HTML 은 하이퍼텍스트 문서를 만들 수 있는 언어다. Web 을 통하여 보고 있는 문서들은 모두 HTML 로 구성되어 있다.

HTML 로 구성된 웹의 문서들에 접근하고 활용하기 위해서는 웹 서버와 클라이언트 (웹 브라우저) 간에 약속된 규칙이 필요한데 HTTP 프로토콜이 이 역할을 수행한다.

인터넷 주소 또는 웹 주소라고 일반적으로 이야기하는 URL 은 URI 의 일종이다. URI 는 인터넷에 있는 자원을 유일하게 식별 가능하도록 하는 식별자 (identifier) 이다.

LOD 의 플랫폼은 웹이고 현재 웹의 핵심 개념과 기술요소 (Hypertext, HTML, HTTP, URI) 를 사용한다. LOD 에서는 잘 정리된 문서 정보 (document) 를 웹에 발행하고 활용하는 대신 특정 개념이나 객체에 대한 구조화된 정보를 발행한다. 그리고 이 개념과 관련된 다른 개념과 연결하여 데이터를 좀 더 명확하고 풍부하게 한다.

문서가 아닌 데이터를 표현하고 연결하기 위해서 LOD 는 Hypertext, HTML 대신 새로운 표현방식과 연결방식을 활용한다. 흔히 RDF 로 표현되는 새로운 정보 표현방식과 상호연결 (interlinking) 이 대표적이다.

현재의 HTML 문서 중심의 웹을 ‘Web of documents’ 로 표현하는 반면 데이터 중심의 새로운 웹을 ‘Web of data’ 라고 한다.

+-------[index.html]-------+
|                          |
| hyptertext               |        +----[hyperlink01.html]----+
| hyptertext <hyperlink01> | -----> | hyptertext hyptertext    |
| hyptertext               |        +--------------------------+
| hyptertext               |
| hyptertext               |        +----[hyperlink02.html]----+
| hyptertext <hyperlink02> | -----> | hyptertext <hyperlink03> |
|                          |        +--------------------------+
+--------------------------+                     |
                                                 V
                                    +----[hyperlink03.html]----+
                                    | hyptertext hypertext     |
                                    +--------------------------+

문서 중심의 웹에서는 HTML 로 작성된 문서가 포함하고 있는 특정 키워드가 관련된 또 다른 HTML 문서로 연결되어 있는 모습이다.

+----------------------------------+
|  Ontology (도시_City)              | 1) 서울은 도시의 한 유형으로 도시를 정의
|                                  |    도시가 갖는 값의 범위등을
|  type: City (class)               |    명확히 하는 Ontology
|  definition: 정치,경제,문화의         |
|  중심 지역                           | 2) 서울 데이터를 설명하고 있는 공식명칭,
|  동일개념 ontology:                  |    국가, 관련산, 관련강, 지형 등 용어 설명
|  http://schema.org/City          |
|  City 활용 가능 영역: 국가              | 3) 서울 데이터가 포함하고 있는 내용중
|  City 활용 범위: 인구,별명,관련산           |    대한민국 데이터로 이동
+----------------------------------+
                  Λ
                  | 1)
                  +-------+
                          |
              +----------------------+      +-----> +--------------------+
              | 서울 Data             |   3) |       | 대한민국 Data        |
        2)    |                      |      |       |                    |
     +------- | 공식명칭: 서울특별시      |      |       | 수도: 서울특별시       |
     |        | 국가: 대한민국          | -----+       | 면적: 100,210km^2    |
     |        | 관련산: 북한산          |              | 인구: 50,912,264명   |
     |        | 관련강: 한강            |              | 통화: 원             |
     |        | 지형: 분지             |              +--------------------+
     |        +----------------------+
     V
+-----------------------------+
| 용어집                        |
|                             |
| 공식명칭: 공식명칭은 '도시'       |
|  특정 도시를 칭하는 명칭          |
|  행정구역을 표현                |
+-----------------------------+

데이터 중심의 웹에서 데이터가 연결되고 공유되는 방식은 표면적으로는 하나의 HTML 문서가 관련된 다른 HTML 문서로 연결되는 모습과 유사하다. 하지만 LOD 는 완성된 HTML 형태 문서를 제공하는 것이 아니고 특정 개념 (사람이 생각할 수 있고 존재하는 모든 것) 과 개념이 갖는 특성 (속성) 을 구조적으로 제공하는 것이다. 모두가 이 데이터를 이용하고 컴퓨터가 처리하기 위해서는 엄격하고 명확한 정의가 필요하다.

데이터를 설명하는 요소들을 명확하게 하는 방법은 요소들이 의미하는 바를 명확하게 하는 것이다. 예를들어 ‘공식명칭’ 이라는 요소는 ‘특정 개념을 대표할 수 있는 것으로 약어, 속어 등을 사용하지 않고 법제도적으로 인증된 이름’ 으로 그 범위를 명확하게 하는 것이다.

‘서울’ 이라는 개념은 ‘도시’ 라는 개념에 속하는 것으로 예시와 같이 ‘도시’ 라는 개념이 의미하는 바가 무엇이고 어떤 영역에서 사용이 가능한 것인지 상세하게 표현한 설계서(Ontology) 를 참조한다.

5. LOD implement

LOD 는 HTML 구문 (syntax) 에 의존해서 특정 정보를 기술 (description) 하는 방식이 아니라 정보들을 구성하고 있는 개념, 객체 (예: 도시, 국가, 자동차, 사람, 장소 등 사람이 생각하고 표현할 수 있는 모든 것) 들을 각각의 데이터로 표현하고 공유하는 방식이다.

사람들이 대화하는 것처럼 컴퓨터들도 서로 정확한 개념을 공유하고 이 개념을 나타낼 수 있는 설명, 표현, 속성 (예: 사과는 색깔, 크기, 모양, 맛, 생산지, 생산자 등 다양한 속성으로 설명할 수 있음) 을 웹에서 공유해서 소통할 수 있도록 하는 것이다.

Linked Open Data 는 Linked Data 와 Open Data 의 핵심 개념을 포괄하는 것으로 Linked Data 발행 원칙에 맞추어 데이터를 개방하는 것을 의미한다. 팀 버너스-리는 Five Star Open Data⁵) 에서 별점을 이용해 데이터 개방의 단계와 효과에 대해서 설명하고 있다.

OL (1 star): On-Line; 온라인 상에서 활용 가능한 상태
RE (2 star): machine Readable; 컴퓨터가 읽을 수 있는 상태
OF (3 star): Open Format; 개방형 데이터 형태
URI (4 star): URI 로 객체를 식별
LD (5 star): Linked Data

1 star (OL: On-Line)

데이터를 웹에 개방형 라이센스 (포멧에 상관없이) 하에 공개한 상태를 의미한다.
- 예) PDF 형태로 일기 예보를 제공

2 star (OL, RE: machine REadable)

구조화된 형태로 데이터를 제공하는 것을 의미하는데 컴퓨터가 데이터를 처리할 수 있는 형태를 의미한다.
- 예) microsoft 엑셀을 활용하여 데이터를 편집, 가공할 수 있는 형태로 제공

3 star (OL, RE, OF: Open Format)

비독점적 포멧, 개방형 포멧으로 데이터를 개방하고 있는 상태를 의미한다.
- 예) 메모장 등 특정 회사, 특정 소프트웨어 제품에 자유로운 CSV 파일 형태로 제공

4 star (OL, RE, OF, URI: On-Line)

사람들이 객체를 식별할 수 있도록 URI 를 사용하고 있는 상태를 의미한다.
- RDF 로 구성된 파일 (HTML 태그를 사용하지만 객체가 의미를 지니고 있음)
- 예)
```
<h1 property=" dcterms:title">대전 기온 예보</h1>
<div id=" data" about=" #Daejeon" typeof=" meteo:Place">
```
  - ‘대전 (Daejeon)’ 이라는 개념이 ‘도시 (metro)’ 라는 용어집의 ‘장소 (place)’ 에 해당
  - ‘기상’ 관련 사전이 존재하고 ‘기상’ 을 설명, 구성하는 요소 중 하나가 ‘장소’ 이고 ‘대전 (Daejeon)’ 은 장소임
```
  <tr rel="meteo:forecast" resource="#forecast20120205">
    <td>
      <div about="#forecast20120205">
        <span property="meteo:predicted" content="2012-02-05T00:00:00Z" datatype="xsd:dateTime">2012년 2월 5일 일요일</span>
      </div>
    </td>
    <td rel="meteo:temperature">
      <div about="#temp20120205">
        <span property="meteo:celsius" datatype="xsd:decimal">-4</span>
      </div>
    </td>
  </tr>
```
  - ‘예보날짜’ 가 ‘resource=#forecast20120205’ 라는 별도의 URI 로 식별 가능하도록 구성되고 예보일은 ‘기상 (metro)’ 이라는 용어집에 정의되어 있는 ‘예보일 (predicted)’ 을 사용해서 데이터 표현이 가능한데, 이 데이터는 시간을 나타내는 표준형식인 ‘xsd:dateTime’ 을 사용하여 시간을 표현

5 star (OL, RE, OF, URI, LD: Linked Data)

데이터의 문맥과 배경을 제공하기 위해 다른 데이터와 연결되어 있는 상태를 의미한다.
- 화면 인터페이스는 <4 star> 와 동일하지만 구성방식의 차이
- 예)
```
<h1 property="dcterms:title">서울 기온 예보</h1>
  <div id="data" about="#Seoul" typeof="meteo:Place">
    <span rel="owl:sameAs" resource="http://dbpedia.org/resource/Seoul"></span>
```
  - <4 star> 와 유사하지만 ‘서울’ 이 dbpedia 에서 정의하고 있는 서울과 동일한 것임을 표시하여 모호성을 제거함
```
  <div about="#temp">최저
    <a rel="rdfs:seeAlso" href="http://ko.wikipedia.org/wiki/기온"
            resource="http://dbpedia.org/resource/Temperature">기온</a>
            (<span rel="owl:sameAs"
            resource="http://dbpedia.org/resource/Celsius">°C
            </span>)
  </div>
```
  - 최저라는 것이 ‘기온’ 을 나타내고 wikipedia, dbpedia 에서 관련 정보를 확인할 수 있으며 기온을 나타내는 단위 ‘℃’ 가 dbpedia 의 Celsius 와 동일한 것임을 표현하여 모호성을 제거
  - 위의 예제는 “내가 지금 서울의 기온에 대해서 설명을 하는데 2012년 2월 5일 일요일은 최저기온이 -4℃ 이다” 라는 설명이 표 형식으로 나열된 것
  - 이런 표에 들어가 있는 ‘텍스트’ 는 사람이 보면 그 의미를 알 수 있지만 기계는 ‘서울’ 이 무엇인지 ‘℃’ 가 무엇인지 알 수 없음
  - 컴퓨터가 소통한다는 의미는 기계가 처리할 수 있는 형식으로 소통한다는 의미
  - 사람은 ‘서울’ 이라는 텍스트만으로도 한국의 수도 서울을 떠올리지만 컴퓨터에게 서울은 ‘도시’ 이고 ‘도시’ 는 한글명칭, 영문명칭, 로마자 명칭 등 다양한 표현법이 존재하고 ‘도시’ 는 한글로 표현된 값임을 명시하고 있지 않으면 컴퓨터에게 ‘서울’ 은 의미 없는 문자열에 불과

<4 star> 는 보다 구체적이고 명시적으로 표현하는 데이터에 대해 설명을 하고 있고 <5 star> 는 이 보다 더 상세하게 데이터를 표현하는 것뿐만 아니라 여기서 설명하는 개념, 객체 (서울) 가 다른 곳에서 정의한 서울과 동일한 것임을 나타냄으로써 서울은 도시 이름이라는 것을 명확하게 한다. <5 star> 의 경우 모호성, 동의성을 제거하여 해당 개념, 객체가 유일하고 고유한 것으로 구별할 수 있도록 한다.

컴퓨터가 어떤 개념, 객체에 대해서 이해하기 (처리하기) 위해서는 그것이 무엇인지, 특징이 무엇인지, 비슷한 것, 동일한 것은 무엇인지 등을 명확하게 해주어야 한다.

6. meaning of 5 star ranking

5 개의 별점으로 표시된 영역이 LOD 와 관계된 수준으로 공개된 데이터로써의 활용 가치와 재사용성에 있어서 가장 높은 수준의 개방 형태임을 의미한다.

이미 많은 정보관리기관이나 일반적인 웹사이트에서 정보를 공개하고 공유하는 방식은 1 ~ 3개 별점 단계 수준에 해당하는데 이런 유형의 데이터는 새로운 애플리케이션 혹은 서비스, 비즈니스 모델 창출을 위해서 원천 데이터의 가공과 정제 등에 많은 노력을 기울여야 한다. 또한 서로 다른 정보원으로부터 동일 개체 식별에 많은 기술, 비용 노력이 필요하다.

예를 들어 영화정보를 제공하는 A 기관의 데이터베이스와 B 기관의 데이터베이스에 존재하는 정보를 통합해서 새로운 통합 검색 서비스를 준비한다고 가정하면 두 기관에는 동일한 영화, 영화배우, 배급사 등 정보가 따로 존재한다. 두 기관이 이 정보들을 관리하는 정보기술 환경도 상이할 것이고 무엇보다 이 정보를 관리, 표현하는 메타데이터가 상이할 것이다.

필드명	설명	<비교내용>	필드명	설명
name	배우이름	동일한 내용을 입력하지만 필드명 (메타데이터) 이 다른 경우	fullname	배우이름
sex	성별	동일한 내용을 입력하지만 필드명 (메타데이터) 이 다른 경우	gender	성별
birthday	0000-00-00	필드명 (메타데이터) 은 같지만 표현방식이 다른 경우	birthday	0000년 00월 00일

A 기관 B 기관은 동일한 영화배우 데이터베이스가 존재하지만 이 둘을 통합하여 서비스하기 위해서는 같은 값을 갖는 배우이름, 성별에 대해서 서로 다르게 표현하고 있는 필드명 (메타데이터) 을 일치시키거나 혹은 이 둘을 동일시할 수 있는 기술적 조치가 필요하다. 또한 생년월일 정보는 동일한 필드명을 갖지만 표현방식은 서로 상이하다. 이 또한 일치시키기 위한 기술적인 노력이 필요하다.

LOD 가 구현되고 실제로 데이터의 운용이 일어나는 곳은 웹이다. LOD 가 무엇인가를 단순화시켜서 이야기할 때 웹을 글로벌 데이터베이스 (Global Database) 화하여 모두가 함께 활용할 수 있는 데이터 플랫폼을 만드는 일이라고 한다.

지금의 웹처럼 누구나 자유롭게 활용할 수 있는 개방된 공간에 개방된 데이터베이스를 구축한다면 데이터를 공급하는 사람이나 이용하는 사람 그리고 이 데이터를 처리하는 컴퓨터 간에 서로 이해하고 소통할 수 있도록 기본적으로 지킬 약속이 필요하다.

7. Linked Data Principle

팀 버너스-리는 Linked Data 구축의 4 원칙⁶ 을 제시하였다. 이는 Web of Data 에서 누구나 지켜야할 원칙이다. 기술적인 원칙은 기존의 웹 (web of documents) 에서 활용되고 지금의 웹 생태계를 가능하게한 핵심기술을 그대로 사용한다.

7.1.1 ❮개체 식별을 위한 URI 사용❯

Web of Data 의 객체, 개념들에게 의미 있고 유일한 name
개별 데이터를 식별하기 위함

- 대전의 URI: dbpedia.org/page/Daejeon
- 컴퓨터의 URI: dbpedia.org/page/Computer

7.1.2 ❮HTTP 를 활용한 데이터 접근 허용❯

데이터에 대한 정보의 요청과 응답에 활용

- 대전의 HTTP URI: http://dbpedia.org/page/Daejeon
- 컴퓨터의 HTTP URI: http://dbpedia.org/page/Computer

7.1.3 ❮RDF, SPARQL 사용 및 제공❯

URI 정보로 찾았을 때 RDF, SPARQL 과 같은 표준을 사용하여 유용한 정보를 제공

RDF (Resource Description Framework)

LOD 데이터를 표현하기 위한 가장 기본적인 구문 약속
기존 HTML (구문, Syntax) 은 데이터의 의미를 표현하기 어려움
Resource 는 URI 를 부여할 수 있는 모든 객체, 개념을 의미
Description 은 Resource 를 상세하게 설명함을 의미

RDF 는 SPO (주어, 술어, 목적어) 라는 기본적인 구조로 구성

RDF의 구조 = 주어 (Subject) - 술어 (Predicate) - 목적어 (Object)

설명하고 싶은 무엇인가
(예: '무한도전')
         |                            채택된 '술어'에 적합한
   +-----+                    +-----> 또다른 정보객체 혹은 적합한 값
   |                          |       예; 무한도전 술어 '제작자' 에는
   V                          |       '김태호' 라는 목적어를 입력
+------+      +------+      +-------+
|  주어  | ---> |  술어  | ---> |  목적어  |
+------+      +------+      +-------+
                Λ
                |
                +---- '주어'를 설명할 수 있는 요소, 흔히 속성으로 표현
                      예; '무한도전' 을 설명하기 위해 '프로그램 영문명',
                      '제작자', '출연진', '방송시간' 등의 요소 채택 가능

RDF 의 기본 구조 및 그래프 모델

   주어         술어 (Predicate)        목적어
( Subject ) ------------------------> ( Object )

                     제작자           +--------+
(무한도전) -------------------------> | 김태호 |
                                      +--------+

LOD 로 제공하려는 서비스의 성격이나 의도에 따라서 혹은 변환대상이 되는 원천데이터의 상태에 따라서 다양해질 수 있음

[위 내용을 조금 더 LOD 원칙에 맞추어 보면]

+--------------------+         dc:creator          +--------+
| http://www.mbc.com | --------------------------> | 김태호 |
| /Infinite_Challenge|                             +--------+
+--------------------+

첫 번째로 ‘무한도전’ 이라는 명칭을 URI를 갖는 하나의 객체로 표현
두 번째로 ‘무한도전’ 이라는 객체를 설명할 수 있는 다양한 속성 중에 ‘제작자’ 를 표현하기 위해서 가장 일반적으로 많이 사용하는 더블린코어 메타데이터의 ‘creator’ 를 술어로 채택하고 더블린코어 메타데이터의 ‘creator’ 를 채용했음을 ‘dc:creator’ 로 표현
마지막으로 ‘dc:creator’ 라는 술어에 합당한 값인 ‘김태호’ 를 목적어 부분에 표현

            제작자             연출작품    +------+
(무한도전) --------> (김태호) -----------> |논스톱|
     |                   |                 +------+
     |                   +---------------> +------------------+
     |                        홈페이지     |http://homepage.kr|
     |                                     +------------------+
     |   방송분량    +----------+
     +-------------> |1시간 30분|
     |               +----------+
     |
     |                               +-----> ( )
     |   방송국가                    |
     +-------------> (대한민국) -----+-----> ( )
     |                               |
     |                               +-----> ( )
     |
     |   웹사이트    +---------------------------+
     +-------------> |http://www.imbc.com/board  |
                     |/tv/ent/challenge/main.html|
                     +---------------------------+

SPARQL (Simple Protocal and RDF Query Language)
- LOD 원칙을 준수해서 웹에 공개된 데이터들은 거대한 데이터베이스와 같은 형태
- 데이터 웹에서 필요한 정보들을 조회하고 반출하기 위해 SPARQL 표준 활용

7.1.4 ❮Link❯

기존 웹에서 문서들이 hyperlink 로 연결되어 정보 확장
Web of Data 인 LOD 에서도 데이터 객체 간의 연결은 Web of Data 를 풍성하게 만들 수 있는 중요한 개념

8. Summary

LOD 가 이미 우리에게 너무나 익숙한 웹 (Web) 이라는 플랫폼을 그대로 활용하고 있고 지금의 웹을 가능하게 한 핵심적인 기술요소와 특징을 그대로 채용하고 있다.

LOD 원칙하에 RDF 기술규칙을 준수하는 데이터들은 사람이 아니라 컴퓨터간에 의미적인 상호운용이 가능하게 하는 것이고 이 과정이 사람, 특히 어린아이가 처음 사물들을 보고 개념화하고 말을 하고 표현하는 것과 같은 과정이다.

RDF 는 가장 기본적인 표현방법인데 과연 주어, 술어, 목적어의 트리플 (triple) 구조만으로 컴퓨터간의 의미적 소통이 가능한가 하는 의문이 생긴다. 이런 일이 가능하려면 설명하고자 하는 개체, 개념에 대한 아주 구체적이고 명확한 정의가 필요하다.

"홍길동이 산을 먹는다"

위 문장은 분명히 잘못된 것이다. 정확하게 사람은 ‘먹는다’ 는 ‘홍길동’ 이라는 사람과 ‘산’ 이라는 객체 사이에서는 부적절한 표현이라는 것을 알고있다. 컴퓨터도 이런 의미를 파악할 수 있게 하려면 무엇을 해야 할까? 우리가 자연스럽게 저 문장이 맞지 않는다는 판단을 할 수 있을 정도의 정보를 컴퓨터가 이해 (처리) 할 수 있을 정도로 아주 상세하게 정의 내려주어야 한다.

             먹는다
(홍길동) --------------> (산)

위 문장을 RDF화 한다면 간단하게 그래프로 표현할 수 있다. 형태적으로 보면 오류 없이 RDF 화한 예로 볼 수 있다. 이것이 오류임을 확인하려면 컴퓨터는 ‘홍길동’ 이 ‘사람’ 의 유형이라는 것을 알고 있어야 한다.

(사람) <----- 먹는다? -----> (자연)
  Λ                             Λ
  |                             |
  | 유형                   유형 |
  |                             |
  |            먹는다           |
(홍길동) --------------------> (산)

다시 말해 기계적인 처리를 위해서는 ‘홍길동’ 이라는 객체를 공유하고 상호운용성 확보를 위해서 ‘홍길동’ 은 ‘사람’ 의 하나의 유형이다 라는 정의가 웹에 존재해야 한다는 것을 의미한다. 또 ‘사람’, ‘홍길동’ 이 어떤 속성 (술어) 들로 구성이 되는지에 대한 온톨로지(설계정보) 역시 존재해야 한다. 마찬가지로 ‘산’ 에 대해서 어떤 개체의 하위개체 혹은 유형인지를 명확히 정의해 주어야 한다. 같은 이유로 ‘먹는다’ 라는 술어 (속성) 는 어떤 상황 (어떤 주어부와 어떤 목적어부 사이에서) 에서 적용될 수 있는 술어라는 것을 명확히 구분해 주고 웹에 정의해야 한다. RDFS (RDF Schema), OWL (Web Ontology Language) 같은 표준들이 이런 표현이 가능하도록 도와주고 명확하게 RDF, RDFS, OWL 등의 기술 규칙을 준수하여 객체를 표현함으로써 컴퓨터간의 명확한 데이터 소통이 가능하도록 한다.

하지만 “홍길동이 산을 먹는다” 라는 표현이 타당한 경우도 존재한다. 만약 웹에 발행하는 데이터가 아이들을 위한 ‘동화’ 를 도메인으로 한다면 ‘사람’ 이라는 객체가 ‘산’ 이라는 객체에 대해서 ‘먹는다’ 라는 술어 (속성) 을 사용한 것은 타당하다.

[도메인: 동화]

             +--------+
(사람) <---- | 먹는다 | ----> (자연)
  Λ          |   OK   |         Λ
  |          +--------+         |
  |                             |
  | 유형                   유형 |
  |                             |
  |            먹는다           |
(홍길동) --------------------> (산)

LOD 를 활용해 웹에 데이터를 발행하고자 하는 기관들은 기본적으로 특정 도메인 혹은 특정 객체 (책, 영화, 음악 등) 에 대해 기존에 관리하고 있는 데이터들이 존재한다. 이런 데이터들을 웹에 발행할 때는 어떤 목적 하에 어떤 데이터들을 어떤 표준 기술용어를 사용했는지 등에 대한 정보도 함께 전달할 수 있어야 한다.

LOD 로 데이터를 발행하는 것은 단순히 RDF, RDFS, OWL 등의 표준만 준수하면 누구나 쉽게 할 수 있다. 그러나 열린 공간인 웹에 누구나 자유롭게 사용할 수 있는 데이터를 공개한다는 것은 상호운용성을 보장할 수 있는 다양한 조건들이 필요하다.

9. Conclusion

데이터의 중요성에 대한 이야기들이 여기저기에서 나오고 있다. Big Data, Linked Data, IoT, Open Data, Gov3.0 등 최근 이슈가 되고 있는 정보기술 용어들의 핵심은 데이터이다.

LOD 는 이미 거대한 정보 생태계를 구축하고 있는 웹과 익숙한 기술요소들을 그대로 활용한다는 점에서 가장 큰 주목을 받고 있다. LOD 는 공급자와 사용자, 사람과 컴퓨터(기계, machine), 컴퓨터와 컴퓨터간의 의미 있는 소통과 활용을 가능하게 한다.

10. LOD, Is it a Tool?

LOD가 현재 세계적으로 주목받고 있고 이를 구축, 활용하기 위한 노력이 지속되고 있다. 주목해야 할 부분은 ‘현재의 웹’, ‘새로운’ 이라는 키워드이다.

‘현재의 웹’ 이 주는 의미는 아직까지도 웹이라는 플랫폼은 현재 진행형이고 우리의 정보 생활과 밀접한 관계를 갖고 있는 중요한 요소라는 점과 LOD를 통해서 지금보다 더욱 진보할 수 있다는 점이다. 만약 LOD를 활용한 새로운 데이터 생태계로의 참여를 생각하고 있다면 그 데이터가 살아가야하는 생태계가 여전히 웹이라는 사실을 잊지 말아야 한다.

‘새로운’ 은 지금까지와는 다른 형태와 특징들을 가지고 있다는 것을 의미한다. 지금까지 내용으로 LOD 가 갖는 또 다른 면, 새로운 특징이 무엇인지 알 수 있다. 이는 새로운 데이터 생태계에서는 지금까지의 정보를 다루던 것과 다른 방식의 데이터 생성, 관리, 유지, 확산, 활용, 서비스 방식이 필요함을 의미한다.

LOD와 관련된 일을 준비하고 계획하고 있다면 단순히 새로운 기술이고 트렌드이기 때문이 아니라 분명한 목적이 존재해야 한다. 그리고 목적은 반드시 웹을 실마리로 (데이터를 제공하거나 데이터를 활용하는 행위를 통해서) 실현하려는 노력이어야 한다는 점과 기존의 웹 기술 개념을 활용하고 있지만 근본적으로 ‘데이터’ 를 처리하기 위한 새로운 정보기술 인프라가 필요하다는 점을 기억해야 한다.

LOD 는 당장 눈에 보이는 가시적인 효과는 드러나지 않을 수 있습니다. 하지만 잘 만들어진 데이터 (LOD) 는 트렌드와 상관없이 유용하게 활용될 것이다. 연결이라는 특징은 여러 데이터가 융합되어 지금은 생각지도 못한 새로운 가치를 창출할 것으로 기대할 수 있다.

Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The semantic web. Scientific american, 284(5), 28-37. ↩
http://www.w3.org/standards/semanticweb/ ↩
Open Knowledge Foundation. (2012). Open Data Handbook Documentation. Retrieved from http://opendatahandbook.org/en/ ↩
플랫폼은 LOD 가 구축, 활용, 사용자들의 지속적인 참여로 새로운 가치 창출이 일어나는 기반 구조 ↩
원본 사이트: http://5stardata.info/, 한글버전: http://5stardata.info/kr/ ↩
http://www.w3.org/DesignIssues/LinkedData.html ↩

What Exactly is a DAG?

데이터 엔지니어링에서 친숙한 두가지 용어가 있는데 다음과 같다:

Data Pipeline: 애널리스트/마케터/비즈니스 중심의 경우
DAG: 엔지니어

두 용어는 모두 기본적으로 동일한 메커니즘을 반영한다.

용어만 볼 때 Data Pipeline 은 매우 간단하다. 일반적 (예: 배관공사) 인 의미 외 볼 수 없는 프로세스는 무엇인지 알아보면 다음과 같다. 데이터는 말 그대로 한쪽에서 시작하여 다른쪽으로 나오는 단일 튜브 모양이 아니라 시간동안 다른 데이터와 분리되어 있으며 고속 데이터는 실행되는 서버에 많은 스트레스를 줄 수 있다.

1. So what exactly is a DAG and what does it tell us that the term “pipeline” cannot?

DAG 의 문자만 해석하면 다음과 같다:

Directed Acyclic Graph

Graph 란 데이터 엔지니어링의 그래프는 노드를 연결하는 노드(점)와 꼭지점(선)의 유한 집합을 의미한다. DAG 의 경우 노드는 각각의 데이터 처리 작업을 나타낸다.

‘Node A’ 는 API 에서 데이터를 가지고 올 수 있는 코드일 수 있다.
‘Node B’ 는 데이터를 익명화하고 모든 IP 주소를 삭제하는 코드일 수 있다.
‘Node D’ 는 중복 레코드 ID 가 없음을 확인하는 코드일 수 있다.
‘Node E’ 는 해당 데이터를 데이터베이스에 넣을 수 있다.
‘Node F’ 는 새로운 테이블에서 SQL 쿼리를 실행하여 대시보드를 업데이트 할 수 있다.

           +-------------------+
           |                   |
           |                   V
+-+       +-+       +-+       +-+       +-+
|A| ----> |B| ----> |C| ----> |E| ----> |F|
+-+       +-+       +-+       +-+       +-+
           |                   Λ
           V                   |
+-+       +-+                  |
|G| ----> |D| -----------------+
+-+       +-+

Pipeline 처럼 보인다. Task 는 분기하여 새로운 input 과 함께 다시 연결된다. 그럼 왜 “Data Pipeline” 이라는 말이 적용되는가? 그것은 Directed, Acyclic 이 들어오는 것이다.

위 그래프에서 각 꼭지점 (선) 은 다른 노드를 연결하는 특정 방향 (화살표로 표시) 을 가진다. 데이터는 꼭지점의 방향을 따라서 이동한다. 즉, 데이터가 A 에서 B 로 갈 수 있지만 B 에서 A 로 이동할 수 없음을 의미한다. 그래프가 아무리 복잡해도 이 원리는 적용된다. 이전 노드 다음에 오는 노드는 “upstream” 노드 및 “downstream” 노드라고 한다.

데이터가 한 방향으로 이동하는 것 외에도 노드는 절대로 자기 참조가 되지 않는다. 즉, 무한루프를 만들 수 없다. 따라서 데이터는 A 에서 B 에서, C/D/E 로 갈 수 있지만 일단 데이터가 그래프 아래로 이동하면 후속 프로세스로 A/B/C/D/E 로 돌아갈 수 없다. 새로운 소스 G 에서 오는 데이터는 노드 중 하나로 이어질 수 있지만 후속 프로세스 노드로 전달될 수 없다.

+----+              +----+
|    | -----------> |    |
+----+              +----+
   Λ                   |
   |      +----+       |
   +----- |    | <-----+
          +----+

Directed: 여러 task 가 있는 경우 각 task 에 하나 이상의 upstream (이전단계) 또는 downstream (다음단계) 이 있어야 한다.
Acyclic: 어떤 task 도 자신을 참조하는 데이터를 작성할 수 없다. 즉, 무한루프는 존재하지 않는다.
Graph: 모든 task 는 명확한 구조로 배치되어 있으며 개별 프로세스와 task 에 대한 명확한 관계가 있다.

uni2u's etcLand

Network Simple??? Simple!!

IPLD - Concept: Content Addressability

Concept: Content Addressability

IPLD - Concept: Block

Concept: Block

IPLD - Specifications

IPLD Specifications

1. IPLD Layer Model

1.1 Block Layer (Layer 0)

1.2 Data Model Layer (Layer 1)

1.3 Schema Layer (Layer 2)

2. Specification document status

LOC - introduction

Introduction to Linked Open Data

1. Overall Concept

1.1 추진배경 및 목적

2. Semantic Web & Linked Open Data

3. Linked Open Data (Linked Data + Open Data)

4. Web is Linked Open Data Platform

5. LOD implement

6. meaning of 5 star ranking

7. Linked Data Principle

7.1.1 ❮개체 식별을 위한 URI 사용❯

7.1.2 ❮HTTP 를 활용한 데이터 접근 허용❯

7.1.3 ❮RDF, SPARQL 사용 및 제공❯

7.1.4 ❮Link❯

8. Summary

9. Conclusion

10. LOD, Is it a Tool?

DAG - introduction

What Exactly is a DAG?

1. So what exactly is a DAG and what does it tell us that the term “pipeline” cannot?

About Me

Copyright Notice

Recent Posts

Categories

Tags

Archives