더블린 코어(Dublin Core), 15개 요소로 메타데이터를 표준화하는 법

Dublin Core란 무엇인가

도서관·아카이브·연구데이터·콘텐츠 관리 시스템은 저마다 다른 내부 스키마를 쓰지만, 외부와 데이터를 주고받을 때는 공통 언어가 필요하다. Dublin Core(더블린 코어)는 DCMI(Dublin Core Metadata Initiative)가 관리하는 도메인 중립적 메타데이터 표준으로, 15개 핵심 요소(Simple DC)와 확장 요소군(Qualified DC, DCMI Terms)으로 구성된다.

네임스페이스는 두 가지다. 요소 자체는 dc(http://purl.org/dc/elements/1.1/), 확장 용어는 dcterms(http://purl.org/dc/terms/)를 쓴다. 표현 형식은 XML(oai_dc), RDF/XML, Turtle, JSON-LD, HTML 메타태그 등 여러 직렬화를 지원하며, OAI-PMH·IIIF·DCAT 같은 생태계에서 광범위하게 쓰인다. 최신 용어와 URI는 DCMI 공식 문서에서 확인하는 편이 안전하다.

15개 핵심 요소와 확장 메커니즘

dc:title, dc:creator 같은 15개 요소만으로도 기술을 시작할 수 있고, 더 세밀한 기술이 필요하면 dcterms:type, dcterms:created 같은 확장 요소를 적용한다. 도메인별로 필수·선택·제약을 정의하는 응용 프로파일(DCAP)을 만들면 이 최소 코어를 조직 요구에 맞게 확장할 수 있다.

상호운용은 표준 식별자(URI, DOI, ORCID) 연계, 언어 태그(BCP 47), 날짜 형식(ISO 8601), 자료 유형(DCMI Type) 정규화로 확보한다. 전거 통제나 SKOS·LCSH 같은 통제 어휘와 결합하기도 쉽다. OAI-PMH 기반 메타데이터 수확에는 oai_dc가 사실상 표준 형태로 쓰이고, JSON-LD로 배포하면서 schema.org에 매핑하면 검색 엔진 노출도 최적화할 수 있다.

실무 적용: 도메인별 사용법

디지털 아카이브와 도서관에서는 서지·시청각 자료 기술을 Simple DC로 시작해 점진적으로 dcterms를 확장하고, OAI-PMH Provider를 구성해 Europeana 같은 Aggregator에 수확을 제공한다. 인명·주제 전거를 연계하고 dcterms:rights로 권리 정보를 명시하며, dcterms:format으로 파일 형식을 규격화하는 일이 운영의 핵심이다.

연구데이터 저장소는 기관 스키마와 Dublin Core, DataCite 사이의 크로스워크를 정의하고 ORCID(연구자)·ROR(기관)·DOI(식별자) URI로 서로 연결한다. 버전은 dcterms:isVersionOf, 방법론은 dcterms:methodology로 표현하고 CC BY 같은 라이선스를 관리한다.

기업 ECM·문서 관리에서는 dc:title, dc:creator, dcterms:created, dcterms:subject 정도의 최소 세트를 표준화해 Elastic 같은 검색 인덱스와 크로스 인덱싱 키를 설계한다. 보존 기간(dcterms:valid)과 접근 권한 모델을 권리 메타데이터와 일치시키는 관리가 필요하다.

공공데이터·오픈데이터 포털은 DCAT 카탈로그와 Dublin Core 요소를 정렬(매핑)하고 JSON-LD로 배포한다. 데이터 갱신 주기(dcterms:accrualPeriodicity)와 공간·시간 범위(dcterms:spatial, dcterms:temporal)를 명확히 밝히는 것이 포털 운영의 관례다.

구현 절차

원천 스키마를 수집하고 필드 인벤토리와 품질 규칙을 정의하는 데서 시작한다. DC 응용 프로파일을 설계해 매핑·변환한 뒤 정규화·전거 연계를 거쳐 SHACL이나 스키마 검사로 검증하고, 최종적으로 OAI-PMH나 JSON-LD로 배포하며 색인·모니터링 대시보드를 구축한다. 스키마 불일치나 필수 필드 누락, 통제 어휘 미일치가 발생하면 수정 큐에 적재해 재검증한다. 변환-검증-게시는 단일 배치 트랜잭션으로 묶고, 게시 전에는 스냅샷 버전을 관리한다.

⤢✕

DC 응용 프로파일을 만들 때는 필수/선택/반복성, 데이터 타입, 제약(패턴·컨트롤드 보캐블러리)을 명문화한다. 예를 들어 dc:title은 필수·단일·문자열, dcterms:creator는 필수·반복·URI 우선, dcterms:created는 필수·ISO 8601로 정의하는 식이다. 크로스워크에서는 내부 title_kor을 dc:title@ko로, author_id를 dcterms:creator(ORCID URI)로, reg_date를 dcterms:created로 매핑하는 패턴이 흔하다. JSON-LD 1.1과 UTF-8을 전제로 하며 DCMI Terms의 최신 URI를 검증해야 한다.

{
  "@context": {
    "dc": "http://purl.org/dc/elements/1.1/",
    "dcterms": "http://purl.org/dc/terms/",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@id": "https://doi.org/10.1234/example-001",
  "dc:title": [
    { "@value": "예제 보고서", "@language": "ko" },
    { "@value": "Example Report", "@language": "en" }
  ],
  "dcterms:creator": [{ "@id": "https://orcid.org/0000-0002-1825-0097" }],
  "dcterms:publisher": { "@value": "ABC 연구원" },
  "dcterms:created": { "@value": "2024-09-30", "@type": "xsd:date" },
  "dcterms:subject": [
    { "@id": "http://id.loc.gov/authorities/subjects/sh85081656" }
  ],
  "dcterms:type": { "@id": "http://purl.org/dc/dcmitype/Text" },
  "dcterms:language": { "@value": "ko" },
  "dcterms:rights": { "@value": "CC BY 4.0" }
}

표현 방식 선택: Simple DC vs Qualified vs DCTERMS

구분	Simple DC (oai_dc XML)	Qualified/DCMI Terms (XML)	DCTERMS (RDF/JSON-LD)
성능	가벼운 파싱, 대량 수확에 유리	중간, 요소 확장으로 크기 증가	파싱 오버헤드, 캐시·스트리밍 필요
확장성	낮음, 의미 한계	중간, 세부 속성 추가 가능	높음, 링크드데이터·온톨로지 연계
일관성	구현 간 편차 적음	기관별 프로파일 차이 존재	프로파일+SHACL로 강한 일관성
안정성	성숙·안정	안정, 복잡도 증가	성숙, RDF 스택에 의존
운영 편의	간단한 도입·교육 용이	관리 문서 필요	초기 학습·도구 체계 필요

도입 시 트레이드오프와 목표 지표

식별자는 DOI·Handle·URI를 우선하고 로컬 ID는 dcterms:identifier로 보조하는 편이 일관성 유지에 유리하다. 주제·유형·언어는 표준 보캐블러리로 제한하고 자유기술 필드는 최소화한다. 다국어는 언어 태그(@language)를 활용해 표시 문자열과 URI를 병행 저장하고, SHACL이나 JSON Schema로 필수·반복성·패턴 규칙을 CI 파이프라인에서 검증한다. 버전(dcterms:hasVersion)과 변경 이력은 감사 로그로 남기고, 접근권한 정책은 dcterms:rights·rightsHolder와 정합을 맞춰 민감정보 유출을 검토한다.

이런 체계를 도입할 때 흔히 잡는 목표 지표가 있다. 통제 어휘와 언어 태그를 도입하면 검색 재현율이 +10~~20%p, 정확률이 +5~~10%p 개선되는 것을 목표로 잡는 경우가 많고, 템플릿과 전거 자동완성을 적용하면 건당 기술 시간을 20~40% 절감하는 것도 흔한 목표치다. 외부 수확 성공률 99% 이상, 필수 필드 충족률 98% 이상을 SLA로 설정하기도 한다.

다만 Simple DC는 빠르게 도입할 수 있지만 의미 손실이 있을 수 있어 필요하면 DCTERMS나 프로파일을 병행해야 하고, RDF 도입은 링크드데이터의 장점을 얻는 대신 도구·학습 비용이 늘어난다. DataCite나 Schema.org로 매핑했다가 역변환할 때 정보가 손실될 수 있으므로 근거 필드는 원본 그대로 보존해두는 편이 안전하다.