一生牛步行

• File 클래스는 문서(Document)의 "물리적인 상태 정보"를 나타내는 클래스입니다. 파일 위치(URL), 체크섬(cheksum), 크기(size), 파일 버전(file version) 등의 속성을 포함하고 있습니다.
• 파일 위치를 경로(path)가 아니라, URL 클래스로 선언한 것은 PC 혹은 서버의 로컬 디스크에 존재하는 파일 뿐만 아니라 인터넷 상에 존재하는 파일 위치를 지정할 수 있도록 하기 위해서입니다. checksum 문자열은 파일의 무결성(integrity)와 중복 검사(duplication check) 목적으로 사용됩니다.
• File 클래스 또한 FileVersion 클래스 처럼 방어적 코딩이 포함되어 있습니다.

File.java

• FileVersion 클래스 구현에서 눈여겨 봐야할 점은 생성자(constructor)에서 인자(parameter) 값을 검사하는 로직이다.
  객체지향 프로그래밍이 절차적(혹은 함수형) 프로그램과 다른 점은 데이터(혹은 상태)와 데이터를 조작하는 메소드(혹은 행위)를 결합시킨 구조를 가지고 있다는 점이다. 이러한 구조의 잇점을 최대한 활용하기 위해서는 객체에 값이 설정 혹은 변경될 때 해당 값이 적합한지 여부를 검사하는 로직을 구현해야 한다. 단지, 인터페이스와 클래스를 사용한다고 해서 훌륭한 객체가 되는 것이 아니다.
• 전달되는 값 (인자, parameter)이 유효한 것인지 판정해 잘못된 값이 입력되었을 경우, 즉시 오류를 발생시켜 문제가 발생하더라도 그 원인이 외부에 있음을 알아내기 쉽고, 원인을 빠르고 명확하게 파악할 수 있도록 하는 기법을 방어적 프로그래밍이라 한다.

FileVersion.java

DocAr 에서 수집하는 문서는 웹 페이지(HTML), MS-Office 문서(파워포인트, 워드, 엑셀), 텍스트(text), PDF 등 다양하며 이러한 문서들의 원본 파일 자체와 추출한 색인 정보를 함께 저장해야 한다. 문서의 물리적인 속성을 나타내는 파일(File) 클래스에 대한 설계를 마친 후, 문서 클래스의 색인 속성에 대한 상세 설계를 진행한다. 문서의 색인 속성은 다양하며, 개별 속성에 대한 관련 기능 및 데이터 구조에 대한 설계가 필요하다.

• 제목 : 문서의 제목은 파일 형식(format)에 따라 명시적으로 추출할 수 있는 경우가 있고, 명시적으로 추출할 수 없는 경우가 존재한다. HTML 형식에서는 title 태그를 이용해 문서의 제목을 추출할 수 있지만, 대다수의 문서 형식은 명시적인 필드(field)가 지정되어 있지 않다. 따라서, 파일 형태로 존재할 경우에는 파일의 명칭을 제목으로 사용할 수 있다.
  
  
• 작성자 : 문서의 작성자 정보는 일반적으로 문서 자체에서 추출할 수 없는 정보이다. 따라서, DocAr 에 문서를 등록할 때 작성자 정보를 입력 받거나, DocAr 사용자 정보를 작성자 정보로 활용할 수 있다. 작성자 정보는 하나 이상의 필드 (성명, e-mail 주소, 홈페이지 주소 등)로 이루어져 있으므로 별개의 클래스로 분리하는 것도 고려할 필요가 있다.
  
  
• 작성 일시 : 파일 형태로 존재하는 문서는 파일의 생성(변경) 일시를 작성일시로 설정할 수 있다. 만일 문서의 생성일시를 정확히 확인할 수 없을 경우, DocAr에 등록하는 시점을 생성일시로 사용해야 한다.
  
  
• 키워드 : 문서의 검색 정확도 향상 및 분류에 활용하기 위해 핵심 단어들을 입력 받는다. 문서를 분석해서 키워드를 추출하는 방법과 사용자가 직접 입력하는 방법 등을 고려할 수 있다.
  
  
• 요약 : 검색 결과에 문서의 요약된 정보를 출력할 경우, 사용자가 원하는 문서인지 여부를 빠르게 파악할 수 있다. 문서의 앞 문단을 추출해서 자동으로 요약을 생성하는 방법을 고려해 볼 수 있다.
  
  
• 원본 링크 : 인터넷 등에서 다운로드 받은 문서인 경우, 해당 문서의 출처를 남겨두는 것은 향후에 문서가 갱신되었을 때 다시 다운로드 받을 수 있고, 관련 정보를 찾거나 유용한 웹 사이트 목록을 작성하는데 활용할 수 있다.
  
  
• 문서 형식 : 문서의 포맷(format) 정보는 문서를 조회할 수 있는 프로그램을 선택 및 실행하기 위해 필요하다. 더불어 검색 시 특정 형식의 문서를 제한함으로써 검색의 정확도를 높일 수 있다. 문서 형식은 문자열 필드로 저장할 수도 있지만, 오류 혹은 부정확성를 방지하기 위해 - 예를 들어, html/htm/HTML 등 같은 타입을 다른 문자열로 입력할 수 있음 - 별개의 타입(enum 등)으로 분리하는 것이 낫다.
  
  

위와 같은 색인 속성 설계를 통해 확인할 수 있는 통찰(insight)은 다음과 같다.

• 문서(Document) 클래스의 속성 중에서 일부 속성은 기본형(primitive type)으로 정의(선언)할 수 없고, 별개의 타입으로 분리해야 한다.
• 물리적인 파일을 입력 받아 문서를 생성하기 위해서는 다양한 추출/분석/사용자 입력 등의 전처리(preprocessing) 및 가공 작업을 필요로 한다는 것을 알 수 있다. 따라서, 물리적 파일 정보를 인자로 입력 받아 문서 객체를 생성하는 생성자를 만들기 보다는 문서 객체 생성을 수행하는 클래스(빌더, 팩토리 등)를 분리하는 것이 유리하다.
• 속성의 일부를 분리하고, 문서 생성에 필요한 전처리 작업 등 추가 요건이 발생한다 즉, 설계는 한번에 완료되는 것이 아니라, 반복(iteration)을 통해 정교화 시키는 과정을 거쳐야만 한다.
  
  

각 속성에 대한 구체적인 데이터 타입 설계를 진행한다.

• 제목 : 문서의 제목은 문자열(String) 타입으로 충분하다, 자바의 문자열 집합(character-set)은 유니코드(Unicode)를 사용하기 때문에 다국어 지원 또한 문제는 없다. 다만, 직렬화(serialization) 처리 시에는 인코딩(encoding)에 유의해야 한다.
  
  
• 작성자 : 작성자 정보는 성명, ID, 이메일 주소 등의 기본형 데이터 항목들을 구성된 복합(complex type)이므로 별도의 클래스를 선언하는 것이 타당하다. 타입 명칭은 Writer로 선언한다.
  
  
• 작성 일시 : 자바에서 날짜 타입은 java.util.Date 와 java.sql.Date 2가지가 제공된다. util 패키지에 선언된 것은 오로지 날짜만 포함할 수 있고 시/분/초 정보는 담을 수 없다. 작성 시간까지 구분해야 한다면 java.sql.Date 클래스를 사용해야 한다. DocAr 에서는 java.sql 패키지에 포함된 타입을 사용한다.
  
  
• 키워드 : 키워드는 복수의 단어로 구성된다. 하나의 문서에 설정된 키워드들은 중복되지 않아야 하므로, 중복을 허용하지 않고 복수의 문자열을 담을 수 있는 타입을 사용해야 한다. Set<String> 타입을 사용하면 된다.
  
  
• 요약 : 문서의 핵심 내용을 짧게 정리한 요약은 긴 문자열이며, 태그(tag) 등을 포함하지 않는 문자열이어야 한다. String 타입으로 선언한다.
  
  
• 원본 링크 : 외부의 웹 사이트 혹은 내부의 파일 시스템의 파일 주소(혹은 경로)를 모두 포함할 수 있는 주소 체계는 URL이다. java.net.URL 타입으로 선언한다.
  
  
• 문서 형식 : 다양한 문서 타입이 존재하나 현실적으로 모든 유형의 문서 형식을 읽고 쓸 수는 없다. 일반적으로 공개된 문서 형식은 HTML, XML, PDF, MS-Word, MS-Powerpoint, MS-Excel 등이다. 시스템 기능 개선에 따라 향후에 지원할 수 있는 문서 형식이 늘어날 수 있지만, 개선이 빈번하게 발생하는 것은 아니기 때문에 지원 가능한 문서 형식이 고정되어 있다고 여겨도 무방하다. 따라서 문서 형식은 enum 타입으로 선언한다.

• 객체(혹은 인스턴스)를 생성하는 기법
• 객체를 생성하는 기법은 여러가지가 있으나 크게 2가지로 분류할 수 있다. 생성자를 이용하는 것과 그외의 방법.
• 생성자 메소드를 이용하는 방법
  : 다수의 클래스는 생성자 메소드를 제공하며, new 연산자와 생성자 메소드를 조합하여 객체를 생성할 수 있다. 이 때, 객체의 초기 값(initial value)은 생성자 메소드의 인자(parameter)로 전달한다.
• 인스턴스를 생성하는 클래스를 제공하는 방법
  : 특정 클래스의 객체를 생성하고 초기 값을 설정하는 절차를 해당 클래스의 외부에서 수행한다. 팩토리 패턴(factory pattern), 빌더 패턴(builder pattern) 등 디자인 패턴(design pattern)에서 소개하는 객체 생성 기법을 사용하는 것이다. 객체를 임의로 생성하지 못하도록 제한해야 하거나, 객체를 생성하는 절차 혹은 계산 작업이 복잡한 경우에 사용된다.
  
  
• File 객체 생성 기법 선택
• File 객체 내에 포함되는 속성들은 '위치', '크기', '체크섬', '버전정보' 등이다.
• '위치'와 '크기'는 물리적인 파일 정보를 통해 손쉽게 얻어낼 수 있다.
• 그러나, 체크섬은 파일의 컨텐트(content)를 이용해 계산해야 한다. 
• 버전 정보는 파일을 포함하고 있는 문서의 상태(state)를 바탕으로 계산해야 한다.
• 따라서, File 클래스의 객체를 생성하는 기법은 'File 클래스의 인스턴스'를 생성하는 클래스를 별개로 만들거나, File 객체를 포함하는 Document 클래스에 기능을 부여하는 방법을 고려해야 한다. 둘 중에서 어떤 방식을 사용할 것인지는 Document 클래스 설계 단계에서 구체화하도록 한다.

• 파일(file) 클래스는 문서(document) 객체에 포함되는 객체이다. 그리고, 버전 정보는 파일에 포함되는 속성이다.
  '버전 정보'는 객체로 봐야 하는가? 혹은 기본형 데이터 타입(primitive type)의 집합으로 정의해야 하는가? 이에 대해 답을 하기 위해 몇가지 문제를 검토해 봐야 한다.
  
  
• 기본형과 객체형의 차이
• 객체지향 프로그래밍 언어에서 기본형 데이터는 정수 및 실수 값을 나타내는 숫자형(number type), 문자형(character type), 부울린형(boolean type), 바이트형(byte type) 등이 있다. 기본형과 객체형의 차이는 기본형은 데이터 만을 담을 수 있고, 메소드(기능)은 포함하지 못한다는 점이다.
• 기본형 타입은 하나의 값(value) 만을 담을 수 있고, 객체형 혹은 클래스는 복수의 속성 혹은 값들을 담을 수 있다.
  
  
• 동적인 측면에서의 설계
  버전 정보는 버전 순번(version sequence), 버전 생성일시(generation time), 버전 설명(description) 등 3가지 항목으로 구성된다. 각각의 항목은 버전 정보가 생성된 이후에 수정되어서는 안된다. 즉, 버전 정보는 읽기 전용 (read-only) 혹은 불변(immutable 타입)이다. 따라서, 필요한 기능은 생성자와 조회 메소드 (read-only access methods) 뿐이다. 객체 혹은 클래스를 소프트웨어의 동적인 부품(part)으로 보는 관점에서는 버전 정보를 굳이 클래스로 식별(혹은 분리)하는 것이 좋은 선택은 아니다. 파일 객체 내에 버전 객체를 포함시키면, 버전 숫자를 얻기 위해 파일 객체에서 버전 객체를 꺼낸 후에 다시 버전 객체에서 버전 숫자 조회 메소드를 호출해야 하는 번거로움이 있다.
  
  
• 정적인 측면(구조적인 측면)에서의 설계
  객체지향 설계의 목적은 주어진 문제를 최대한 빠르게 풀어내는 프로그램을 제작하는 것이 아니다. 최대한 빠르거나, 최소한의 자원(메모리/네트워크 사용량 등)을 사용하는 프로그램을 작성하는 기법을 연구하는 것은 '알고리즘'의 고유 영역이다. 객체지향 설계의 목적은 '인간'의 사고 체계를 바탕으로(응용하여) 현실 세계의 문제를 가상 공간(컴퓨터)내에 이식하는 것이다.
  버전 정보를 앞서 제시한 3개의 항목으로 분리하여 표현하는 것보다, 버전 정보라는 하나의 객체로 표현하는 것이 인간이 소프트웨어 구조를 인지(recognition)하는데 있어서 유리하다. 달리 말해, 직관적인 구조라고 할 수 있다.
  
  
• 위와 같은 이유 (컴퓨터보다는 인간 지향)로 파일 클래스를 '파일'과 '버전' 클래스로 분리한다.
  
  

• 파일 클래스의 역할(role)은 문서의 바이너리 형식 데이터(binary formatted data)를 표현(묘사)하는 것이다.
  표현(represent) 한다는 용어를 사용한 이유는 파일 객체는 물리적인 파일 그 자체가 아니기 때문이다. 달리 말해 파일 객체는 물리적 파일의 제한적인 특성만을 담고 있는 것이다.
  
  
• 파일(file) 클래스는 문서(document) 객체에 포함되는 객체이다. (has-a relationship)
  객체는 상태(state)와 행위(behavior)로 구성된다. 따라서, 파일 클래스를 설계하기 위해 필요한 상태와 행위들을 정의한다.
  
  
• 파일 클래스에 포함되어야 하는 '상태(state)' 혹은 속성(property)들은 다음과 같다.
• 위치(location) : 물리적인 저장 매체(storage media) 내에서 실제 파일 데이터가 존재하는 주소(address). 주소 체계(addressing scheme)는 별도의 설계가 필요하다.
• 크기 (size) : 바이너리 데이터의 길이, 64 bit 정수로 표현해야 함.
• 체크섬 (check sum) : 바이너리 파일의 지문(finger print), 파일의 중복 검사에 이용된다. DocAr 내에서 동일한 내용을 가진 파일이 중복해서 존재하는 것을 막기 위해 모든 파일에 대한 디지털 지문을 생성하고, 새로운 파일 등록을 수행할 때마다 이미 등록되어 있는 파일들의 디지털 지문과 대조하여 이미 존재하는 파일인지 검사하고, 중복을 방지한다.
• 버전 정보 (version info) :문서 내에서 파일 내용이 여러 번 변경되었을 경우, 현재 파일의 변경된 순서(혹은 순번), 최초 등록된 파일은 1번을 부여받는다. 또한 버전 정보에는 해당 버전에 대한 변경 일자와 간단한 설명(comment)이 포함될 수 있다.
  
  
• 파일 클래스에 포함되어야 하는 '행위(behavior)' 혹은 메소드(method)들은 다음과 같다.
• 파일 인스턴스를 생성하는 생성자(constructor)
• 속성값을 반환하는 getter 메소드들 (location, size, checksum, version)
  
  
•  '객체의 정의'를 적용하기(applying definition of object : self-contained entity)
  
  
• 객체는 데이터와 데이터를 조작하는 프로시져로 구성된 필요한 모든 것을 자체적으로 담고 있는 독립체이다. 
  an object is a self-contained entity that consists of both data and procedures to manipulate the data.
  좋은 객체(혹은 잘 설계된 객체)는 자기 자신을 초기화하고, 데이터를 조작하기 위해서 외부의 도움(혹은 조작)을 필요로 하지 않아야 한다. 객체를 사용(혹은 호출)하는 프로그램이나 프로그래머는 특정 객체를 사용할 때, 다른 클래스를 사용하지 않고도 해당 객체를 제어할 수 있어야 한다는 말이다. (현실적으로 완벽히 지키기 어렵다. 설계자가 지향해야 하는 자세라고 생각하는 것이 타당하다.)
  
  
• 파일 객체가 '바이너리 데이터'를 표현 한다는 것은 바이너리 데이터를 사용(조작)하는 관점에서 필요한 정보와 기능을 모두 제공해야 한다는 말이다. 파일 객체를 생성하는 수단 (엄밀히 말하자면 생성 시 외부에서 주어진 데이터를 이용해 스스로를 초기화하는)으로 생성자 메소드, 그리고 파일에 대한 각종 속성 정보를 조회할 수 있는 메소드와 바이너리 데이터를 제공하는 메소드를 선언한다.
  
  
• 객체의 행위에 대한 설계 리뷰(review)
  
  
• 파일 객체를 변경(수정)하는 메소드가 필요한가? DocAr 내에서 파일 객체는 물리적인 바이너리 데이터라는 실체에 대한 그림자이지, 그 자체를 나타내는 것이 아니다. 실체(물리적 파일)이 변경될 경우, 새로운 파일 객체를 생성해야 하며, 내용이 변경된 파일은 다른 버전의 파일이 된다. 따라서, setter 메소드는 선언하지 않는다. (설계자의 사상 혹은 의도를 반영하는 것이기에 모든 데이터를 다루는 객체가 변경 메소드를 제공하지 않는다고 이해해서는 안된다.) 달리 설명하자면, DocAr의 File 인스턴스는 읽기 전용(read-only) 인스턴스라고 말할 수 있다.
  
  
• 파일 객체를 삭제하는 메소드가 필요한가? JDK에서 제공하는 java.io.File 클래스는 delete 메소드를 제공한다. 그렇다면, DocAr의 File 클래스 또한 delete() 메소드를 제공해야 하는가? 얼핏 보기에 그럴듯 하지만, DocAr의 File 인스턴스는 Document 인스턴스에 종속되어 있다. Document 내에 서로 다른 버전의 파일 객체가 존재할 수 있으며, Document 인스턴스는 하나 이상의 File 인스턴스를 소유해야 한다. 즉, File 인스턴스와 File에 연결된 물리적인 파일이 삭제될 경우, Document 인스턴스의 상태가 변경되거나, Document 인스턴스가 함께 삭제되어야 한다. 삭제 행위를 File 클래스와 Document 클래스 양쪽에 두는 것보다 Document 클래스에서만 제공하는 것이 구현의 복잡도를 낮출 수 있으며, File과 Document를 이용해 코딩하는 사용자(개발자)에게 보다 단순한 관점(view)을 제공한다.

• DocAr 시스템 설계는 상향식(bottom-up)으로 진행하는 것을 원칙으로 한다. 가장 기본이 되는 작은 모듈(혹은 컴포넌트)를 선정하고 해당 컴포넌트에 대한 충분한 설계가 진행된 후에 보다 큰 모듈을 설계하는 것이다. 가장 먼저 설계하는 대상은 '문서(document)이다. (원칙적으로는 상향식 설계를 진행하나, 특정 컴포넌트 혹은 클래스를 세분화 해야 할 필요가 있을 경우, 하향식 설계가 중간에 진행될 수 있다.)
  
  
• 용어에 대한 정의 : DocAr(Document Achieve) 에서 문서(document)란 '수집', '보관 및 분류', '정보 추출' 및 '검색'의 대상이 되는 모든 전자적 데이터(electronic data)를 의미한다. 각 문서는 독립적이어야 하며, 다른 문서에 대한 참조(reference)를 가질 수 있지만, 다른 문서의 일부가 되어서는 안된다.
  
  
• 메타 데이터의 개념 이해 (위키피디아 발췌 및  번역)
  Metadata is "data about data".[1] There are two "metadata types;" structural metadata, about the design and specification of data structures or "data about the containers of data"; and descriptive metadata about individual instances of application data or the data content.
  메타 데이터는 "데이터에 대한 데이터"이다. [1] "메타 데이터 유형;"은 두 가지가 있다.  구조적 메타 데이터(structural metadata)는 데이터 구조에 대한 디자인 및 사양(specification) 또는 "데이터 컨테이너에 대한 데이터"이며, 서술적 메타 데이터(descriptive metadata)는 개별 응용 데이터 인스턴스 혹은 컨텐츠에 관한 데이터이다.
  
  Metadata was traditionally in the card catalogs of libraries. As information has become increasingly digital, metadata are also used to describe digital data using metadata standards specific to a particular discipline. By describing the contents and context of data files, the usefulness of the original data/files is greatly increased. 
  메타 데이터는 전통적인 형태는 도서관의 카드 카탈로그였다. 정보가 점자 디지털화되면서, 메타 데이터는 특정 분야의 메타 데이터 표준에 따라 디지털 데이터를 설명하는데 사용되고 있다. 컨텐츠와 데이터 파일의 맥락(context)을 설명함으로써 원래 데이터의 활용도(유용성)은 크게 증가된다.
  
  For example, a webpage may include metadata specifying what language it is written in, what tools were used to create it, and where to go for more on the subject, allowing browsers to automatically improve the experience of users. Wikipedia encourages the use of metadata by asking editors to add category names to articles, and to include information with citations such as title, source and access date.
  예를 들어, 웹 페이지가 어떤 언어로 씌여진 것인지, 어떤 툴(tool)을 이용해 작성되었는지, 어떤 주제를 포함하는가 등의 메타 데이터를 포함한다면 브라우자가 자도으로 사용자의 경험을 향상시킬 수 있다. 위키 백과는 편집자들이 기사에 카테고리 이름을 추가하고, 제목, 원본, 작성 일자와 참고문헌 등의 메타 데이터를 적극 활용하도록 권장한다.
  
  The main purpose of metadata is to facilitate in the discovery of relevant information, more often classified as resource discovery. Metadata also helps organize electronic resources, provide digital identification, and helps support archiving and preservation of the resource. Metadata assists in resource discovery by "allowing resources to be found by relevant criteria, identifying resources, bringing similar resources together, distinguishing dissimilar resources, and giving location information."
  메타 데이터의 주요 목적은 관련 정보를 탐색하기 용이하도록 하며, 탐색 과정에서 분류가 잘 될 수 있도록 하는 것이다. 메타 데이터는 전자 문서를 조직화하는데 도움을 주며, 디지털 식별자를 제공할 뿐 더러 문서를 보관하고, 보존하는데 도움을 준다. 메타 데이터를 문서를 탐색하는데 있어, "관련 있는 분류하고, 자원을 식별하며, 유사한 자원들을 묶어 주거나, 관련이 없는 문서를 구분하고, 문서의 위치 정보를 제공하는 등"의 도움을 준다.
  
  
• 문서의 속성 : 문서는 파일(file)과 메타 데이터(meta data or index)로 구성된다.. 파일은 해당 문서 내용(content)을 담고 영구 저장 매체 (디스크 등)에 기록된 전자적 데이터를 의미한다. 메타 데이터는 문서의 제목(title, but optional), 작성자, 작성 및 변경 일자, 키워드 및 인덱스 정보, 원본 링크 (웹 링크), 문서의 형식(파일 확장자 혹은 파일 형식, 포맷), 문서에서 추출된 색인 등 문서를 분류하고 검색하는데 활용되는 문서에 연관된 데이터들을 말한다.
  
  
• 제목(title) : 원본 파일의 명칭 혹은 문서의 첫 단락에 표시된 제목, HTML의 title tag 혹은 게시물의 제목들이 문서 제목의 후보가 될 수 있다. 이중에서 게시물의 제목 혹은 HTML의 title tag 등이 우선순위가 높고, 파일 명칭은 우선 순위가 낮다. 만일, 제목을 추출할 수 없을 경우에 제목은 비울 수 있다.
• 작성자(author) : 문서의 최초 작성자 정보. 이름, ID, e-mail, homepage (facebook 등) 정보를 포함할 수 있다.
• 작성일시 및 변경일시 : 문서 자체의 생성 일시 정보를 사용하거나, 만일 작성 일시 정보를 파악할 수 없다면, DocAr 에 문서를 등록한 시점을 작성일시로 설정한다. 문서에 새로운 버전이 추가된 경우, 변경 일시를 업데이트 한다.
•  키워드(keyword) : 문서의 핵심 혹은 요약된 정보를 나타내는 복수의 명사 단어를 키워드라고 한다. 문서를 등록한 사람이 직접 입력하거나, 자동으로 추출할 수 있다.
• 요약(abstract) : 문서의 핵심 부분 혹은 축약된 내용을 말한다.
• 인덱스(index) : 문서 검색을 위한 단어의 집합
• 원본 링크 (original link) : 웹 상에서 다운로드한 문서일 경우 웹 문서에 대한 링크, 다운로드 문서가 아닐 경우 원본 링크가 존재하지 않는다.
• 문서 형식 (format) : XML, PDF, Word 등 문서의 바이너리 데이터 형식을 의미한다.
• 텍스트 (text) : 그래픽 출력을 위한 양식(layout) 정보를 제거한 순수 텍스트 형태의 데이터.
  
  
• 문서와 물리적인 속성의 관계 : 일대다(1:n)의 관계를 가실 수 있다. 문서의 내용(content)와 위치 정보 및 버전 정보 (버전 번호, 변경 시각)를 결합한 것을 '파일'이라고 정의한다. 따라서 문서는 하나 이상의 파일을 가질 수 있다. 하나의 문서에 포함된 복수의 파일이 같은 내용과 버전 번호를 가질 수 있다. 백업 및 공유 등의 이유로 복수의 저장소(repository)에 동시에 존재할 수 있기 때문이다.
  
  
• 문서와 색인 속성 간의 관계 : 일대일(1:1) 관계를 가진다. 만일 문서의 파일이 버전업되면 색인 속성도 갱신되어야 한다.