의미론적 웹 기술을 다양한 프로젝트에 적용해 본 경험을 바탕으로, 그 장점과 한계, 그리고 오늘날 데이터 관리와 지식 그래프 시대에서 얻은 교훈을 돌아본다.
2019년 12월 12일 — got
머리말: 이 영어 텍스트는 2019년 12월 12일 보르도(2019년 12월 11~13일)에서 열린 컨퍼런스 «Linked Pasts V»에서 Vincent Razanajao와 Alberto Dalla Rosa의 초청으로 제가 기쁘게도 맡았던 기조연설(keynote) 원고입니다. 이 글은 Emmanuelle Bermès가 번역했으며, 이 작업에 대해 다시 한 번 깊이 감사드립니다. 또한 이 블로그에 이미 게시된 여러 글의 내용을 상당 부분 재사용했습니다. 본문 앞에는 발표 당시 사용한 슬라이드가 함께 있습니다.
Why I don't use Semantic Web technologies anymore, event if they still influence me ? from Gautier Poupeau
저는 2005년에 의미론적 웹 기술에 관심을 갖기 시작했습니다. 이 주제에 대한 첫 발표는 2006년 파리에서 열린 Digital Humanities 컨퍼런스에서였습니다. 이후 2007년에 King's College의 CCH가 수행한 프로젝트에서 실제로 이를 대규모로 시험해 볼 기회가 있었습니다. 하지만 2008년에 시작된 프랑스 국립도서관(BnF)의 SPAR 프로젝트에서 저는 이 기술들이 지닌 엄청난 약속과 동시에 그 한계를 본격적으로 체감하기 시작했습니다. 2008년부터 2014년까지 저는 다양한 맥락에서 여러 사용 사례를 다루며 이를 배포할 기회가 있었습니다. 예컨대 데이터 발행, 웹 페이지에 내장된 데이터 수집, 내부 사일로 연결과 데이터 일관성 확보, 데이터 풍부화, 그리고 매시업(mashup) 등이었습니다. 오늘 저는 이 경험을 다음 두 가지 목표로 여러분과 나누고자 합니다.
하지만 먼저, 이러한 기술의 역사로 되돌아가 보고 싶습니다. 결국 역사는 사물을 관점 속에 놓는 훌륭한 방법이니까요….
웹의 초기 목적은 제네바 CERN 연구자들과 연계 연구소들이 자신들의 컴퓨터에 들어 있는 요소들에 빠르고 쉽게 접근하여 동료들과 교환할 수 있게 하는 것이었습니다. 그렇다면 연구자들의 컴퓨터에는 무엇이 들어 있었을까요?
팀 버너스-리(Tim Berners-Lee)를 중심으로 한 웹의 선구자들은 먼저 문서의 교환과 연결을 위한 구성 요소를 개발하는 데 집중했습니다. 이를 위해 그들은 성숙한 기술과 원칙의 묶음에 의존했습니다.
문서 웹(Web of documents)의 성공에는 여러 요인이 있습니다.
그 결과 문서 웹을 위한 표준의 개발과, 이를 대규모 커뮤니티가 자기 것으로 만드는 과정은 비교적 순탄했습니다. 하지만 데이터의 경우 상황은 훨씬 더 복잡했습니다. 1990년대에는 이 영역에서 구현을 위한 기술적 합의가 없었습니다. 1994년 9월 제1회 WWW 컨퍼런스에서 팀 버너스-리는 W3C의 향후 방향을 제시하며 "웹을 위한 의미(semantics)의 필요"를 시연합니다. 오늘날 우리는 더 이상 ‘의미론적 웹’이라는 표현을 거의 쓰지 않고 ‘지식 그래프(knowledge graph)’를 말합니다. 그 사이 이 기술들은 기술적 기반을 유지한 채 여러 번 재정의되었습니다.
세 시기를 구분할 수 있습니다.
의미론적 웹 시대(Semantic Web era): 1994~2004년. RDF와 OWL 같은 주요 의미론적 웹 표준을 개발하는 데 전념한 첫 시기.
링크드 데이터 시대(Linked Data era): 2006~2014년. 채택(adoption)에 초점을 맞춘 시기. Linking Open Data라는 새로운 이니셔티브가 등장합니다. SPARQL이 개발되고, Google·Bing·Yahoo 같은 대형 산업 플레이어들이 Schema.org 어휘를 공개하며 참여합니다. Wikidata가 기여자에게 개방되고, RDF·JSON·SPARQL의 새 버전이 릴리스됩니다.
지식 그래프 시대(Knowledge graph era): 오늘날 우리는 세 번째 시기, 지식 그래프 시기에 있다고 볼 수 있습니다. 이는 Google이 Knowledge Vault를 발표하면서 시작되었고, 산업에서 더 적합하게 쓰일 수 있는 그래프를 위한 새로운 사실상 표준(de facto standard)이 부상한 것이 특징입니다.
세 시기, 의미론적 웹 기술이 무엇인지에 대한 세 번의 재정의. 하지만 기술은 동일합니다. 이것이 이 기술들에 문제가 있다는 신호가 아닐까요?
제 주장을 설명하기 위해, 제가 참여했던 몇몇 프로젝트에 대한 피드백을 제공하고자 합니다. 의미론적 웹 기술을 선택하게 된 이유, 우리가 직면한 한계, 그리고 얻은 교훈에 초점을 맞추겠습니다.
프랑스 국립도서관(BnF)의 “Scalable Preservation and Archiving Repository” (SPAR) 프로젝트는 디지털 컬렉션에 대한 접근의 장기적 연속성을 보장하는 것을 목표로 합니다. 시스템은 OAIS 모델(Open Archival Information System)의 원칙을 아키텍처 수준에서까지 엄격히 따릅니다. 즉 OAIS 모델의 각 기능 엔티티가 애플리케이션 모듈로 구현됩니다: Ingest, Data Management, Storage, Access, Administration.
메타데이터를 저장하고 질의하는 “Data Management” 모듈은 다양한 문제에 답해야 했습니다.
당시(2008년)에는 RDF 모델과 SPARQL 질의 언어가 이런 이슈들에 가장 적합한 해답으로 보였습니다.
그래서 우리는 “Data Management” 모듈 전체를 RDF 모델로 구현하고, API로서 SPARQL 엔드포인트를 노출하기로 결정했습니다. 이를 위해 Dbpedia에서 이미 2년간 사용되던 Virtuoso 소프트웨어를 배포했습니다.
결과적으로 SPAR에서 메타데이터는 다음과 같이 처리됩니다. 제출 정보 패키지는 다음을 포함하는 zip 아카이브입니다.
Ingest 모듈은 패키지를 참조 데이터(대상 에이전트, 포맷 등)와 대조하여 검사합니다. Ingest가 끝나면 파일은 Storage 모듈에 저장되고, 메타데이터는 RDF로 변환되어 Data Management 모듈에 색인됩니다.
이 RDF 변환에 사용된 온톨로지는 기존 모델(Dublin Core, OAI-ORE, 자체 온톨로지)을 바탕으로 임시(ad hoc)로 만들었습니다.
첫 문제는 성능 테스트에서 나타났습니다. 모델은 기대한 만큼 유연했고, 질의 언어의 표현력도 충분했습니다. 하지만 시스템은 성능과 확장성이 부족했습니다.
우리는 아키텍처를 조정해야 했습니다. 용도에 따라 서로 다른 메타데이터 집합을 담는 Virtuoso 인스턴스를 여러 개 만들었고, 모든 메타데이터를 담는 인스턴스도 별도로 두었습니다. 결과는 처음 계획보다 훨씬 복잡해졌습니다. 또한 중복 정보를 제외하여 색인 메타데이터의 양을 줄이기도 했습니다. 마지막으로, 모든 메타데이터를 담는 인스턴스의 사용자는 매우 적습니다(두 손가락으로 꼽을 수 있을 정도).
10년이 지난 지금도 시스템은 여전히 운영 중입니다. BnF는 확장성을 위해 Virtuoso의 오픈(무료) 버전에서 유료 버전으로 옮겼습니다. 제가 알기로 그들은 이 선택이 옳았다고 여깁니다. 저 개인적으로는 이 경험을 ‘미친 내기’로 기억할 것입니다(몇몇은 밤새 이것이 옳은 해법인지 자문하곤 했습니다…). 다행히도 이 프로젝트에서는 응답 속도와 사용자 수가 핵심 이슈가 아니었습니다. 하지만 저는 많은 사용자와/또는 대량 데이터를 대상으로 하는 프로덕션 서비스를 ‘검색 가능한 RDF 데이터베이스 + SPARQL’ 위에 직접 구축하기는 어렵다고 여전히 생각합니다.
Isidore는 2008년에 시작된 연구 인프라 Huma-Num이 주도하는 프로젝트입니다. 2010년부터 인문·사회과학 분야의 오픈 액세스 리소스를 검색하는 온라인 플랫폼을 제공합니다. 오늘날 6,400개 이상의 데이터 소스에서 거의 600만 건의 리소스를 집계합니다.
Isidore의 아키텍처는 세 부분으로 구성됩니다.
이 프로젝트에서 의미론적 웹 기술은 여러 방식으로 사용됩니다.
Isidore는 메타데이터와 콘텐츠를 세 가지 방식으로 수집하는데, 그 중 하나가 RDFa입니다. RDFa를 사용해 웹 페이지에 RDF 문장을 내장하고, Sitemap 프로토콜로 나열된 웹 페이지들로부터 메타데이터를 수집합니다. 당시 우리는 데이터 노출에 자주 쓰이던 OAI-PMH 프로토콜이 큰 단점을 갖고 있다고 확신했습니다.
우리 관점에서 RDFa는 생산자들을 의미론적 웹 기술로 이끄는 간단한 방법이었고, OAI-PMH의 한계를 넘어서는 수단이었습니다. 비교적 제한된 투자로 2008년에 OAI-PMH의 한계를 해결하기 위해 만들어진 RDF 어휘 OAI-ORE와 Dublin Core terms를 사용하여 더 큰 기술 능력을 제공할 수 있다고 보았습니다.
Isidore에서 풍부화를 수행하기 위한 참조 데이터는 RDF로 표현되며 링크로 연결됩니다.
또한 데이터 소스에서 수집되거나 Isidore의 풍부화 메커니즘으로 생성된 모든 메타데이터는 RDF로 변환되어 RDF 데이터베이스에 저장됩니다. 그리고 Linked Data 원칙에 따라 발행됩니다.
Open Data를 둘러싼 새로운 움직임들에 영감을 받아, 우리는 되돌려 주는 차원에서 데이터 공개가 필수라고 느꼈습니다. 목표는 다음과 같았습니다.
이런 여러 이니셔티브에 대해 결론을 내리기에 저는 최적의 위치에 있지는 않습니다. 시간이 흐른 지금, 그리고 제 현재의 관점에서 보자면, 도전은 반쯤만 충족된 것 같습니다. 당시의 선택은 분명 그 시점에서는 좋은 것이었습니다. 노출된 데이터 재사용, 의미론적 웹 기술 활용, 더 일반적으로는 연구 데이터 상호운용성 측면에서 전진하는 데 본보기가 되었습니다.
하지만 실제 재사용은 여전히 드뭅니다. 이런 종류의 데이터가 반드시 재사용에 적합하지 않을 수도 있지만, 무엇보다 이를 활용하려면 큰 학습 곡선이 필요합니다. 연구자들은 단순하고 접근 가능한 것을 원합니다. 연구기관과 문화유산기관의 관계를 다룬 2017년의 한 연구회에서, data.bnf.fr의 제품 매니저 Raphaëlle Lapotre는 다음과 같이 확인했습니다.
“연구자들과는 보통 데이터에 문제가 생겼을 때 연락하게 됩니다. 그리고 여러 이유로 문제가 자주 발생하죠. 하지만 실제로는 이런 표준들이 연구자들을 힘들게 한다는 문제가 있었습니다 […] 그들은 이렇게 말합니다: 굳이 당신들의 의미론적 웹 일을 하느라 애쓰지 말고, 그냥 csv를 쓰면 안 되나요?”
이는 Open Data 세계에서의 일반적 관찰입니다. 데이터가 복잡할수록 재사용은 줄어듭니다.
RDFa의 경우, 이 형식은 예상보다 다루기가 훨씬 복잡하다는 것이 드러났습니다. 당시에는 이를 일관되게 구조화할 이니셔티브나 어휘가 없었습니다. 우리는 Dublin Core terms를 권장했는데, 이런 유형의 데이터에 가장 적합해 보였기 때문입니다. 그 후 Schema.org가 등장했고, 점차 RDFa는 Json-LD로 대체되었습니다. 물론 오늘날이라면 저는 이 조합( Schema.org + JSON-LD )에 더 무게를 둘 것입니다.
마지막으로, 결점이 있음에도 OAI-PMH는 여전히 Isidore가 데이터를 수집하는 주요 채널이라는 점을 언급해야 합니다… 표현력보다 단순함의 승리일까요? 어쨌든 OAI-ORE가 10주년을 맞는 지금, 이는 기억해야 할 교훈입니다.
Tim Berners-Lee, Ora Lassila, James Hendler는 2001년 Scientific American에 실린 기념비적 논문에서 제안의 구체적 예를 제시합니다. 한 소프트웨어 에이전트가 웹의 다양한 데이터 소스를 검색하고, 이를 실시간으로 결합하여 진료 예약을 잡는 사례입니다. 이 사용 사례는 데이터 발행의 가능성과 의미론적 웹 기술이 이질적 데이터를 연결해 추론으로 정보를 도출하는 방식을 보여주는 것으로 의도되었습니다. 결국 분산(탈중앙화), 상호운용성, 추론이 의미론적 웹의 세 가지 핵심 목표입니다.
같은 원리를 따라, RDF(또는 다른 방식)로 노출된 이질적 데이터 소스를 섞어, 서로 다른 소스의 최신 데이터를 실시간으로 결합하는 새로운 애플리케이션을 만들 수 있습니다. 이것이 매시업의 원리입니다.
하지만 이론과 실무 사이에는 간극이 있습니다.
우리가 역사적 기념물에 관한 것처럼 여러 매시업을 개발했을 때, 일반 원리와 의미론적 웹 기술의 위치는 동일했습니다. 우리는 이를 두 가지 방식으로 사용했습니다.
2001년 논문에 제시된 사용 사례와의 첫 번째 분명한 차이는 데이터 수집입니다. 네트워크 회복탄력성 문제까지 고려하면, 빠르고 확장 가능한 애플리케이션을 만들려면 데이터를 비동기적으로 가져와 처리한 뒤 로컬 DB에 저장해야 합니다. 이는 실시간 갱신이 불가능한 무거운 업데이트 메커니즘을 요구하며, 탈중앙화라는 아이디어 자체를 흔듭니다.
이런 작업에서 일관된 데이터셋을 준비하는 일은 의미론적 웹 기술을 쓰든 말든 그 자체로 복잡합니다. 여기에 추가로 두 가지 도전을 더 마주하게 됩니다.
그렇다면 RDF로 변환해 저장하는 단계가 정말 유용할까요? 수집 단계에서 바로 처리하여 검색 엔진에 저장할 수도 있습니다. 이 선택의 주요 장점은, 데이터를 ‘활용 방식’으로부터 분리한다는 점입니다. 이 경우 모델의 서로 다른 엔티티에 초점을 둔 다양한 뷰를 쉽고 빠르게 만들 수 있습니다. 그래프를 탐색하는 방식에 따라 새로운 탐색 방법을 발명할 수도 있죠. 물론 이는 재사용자가 그래프 구조를 완벽히 이해하고 의미론적 웹 기술을 숙달했다는 전제 하에서입니다…
맞습니다. 유연하긴 합니다. 하지만 RDF 매핑과 RDF 저장을 개발·자동화하는 데 쓰는 시간과, 데이터 활용에서 얻는 시간 이득을 비교하면, 이런 기술을 쓰는 즉각적 이점은 거의 없습니다. 오히려 반대일 수도 있습니다. 이런 노력은 시간이 흐른 뒤(보장되지는 않지만) 실제로 서로 다른 활용 또는 뷰가 만들어질 때에만 (아마도) 정당화될 것입니다.
Antidot에서 우리가 추진하려 했던 ‘Linked Enterprise Data’ 개념은, 조직의 레거시 정보시스템에 대한 데이터 매시업과 비슷합니다. 기존 사일로에서 데이터를 해방하고, 데이터를 사용으로부터 분리하며, 모든 데이터 소스를 연결하고 일관성을 부여함으로써 조직의 데이터 자산을 활용/탐색하는 새로운 방식과 새로운 용도를 제안하는 것입니다.
서지 데이터 공급을 전문으로 하는 Electre의 경우, Linked Enterprise Data의 구현은 서로 다른 사일로에 흩어진 데이터를 재중앙화하고, 공통 모델로 일관성을 부여하고 링크로 연결하며, 풍부화하는 데 기여했습니다. 목표는 데이터 재사용을 단순화하는 것이었습니다.
매시업과 마찬가지로 목표는 달성됩니다. 하지만 대가는 무엇일까요? 모든 데이터 소스를 RDF로 변환하고, 시스템에서 변경이 발생할 때마다 거의 실시간으로 트리플 스토어 내 일관성을 보장해야 했습니다. 이는 시간이 지날수록 감독과 유지보수가 매우 복잡해졌습니다. 이 경우 RDF 매핑의 실질적 이점은 분명하지 않습니다. RDF로 새로운 데이터 사일로를 구축하는 것은 정보시스템의 더 큰 아키텍처 문제를 드러내는 신호일 수 있으며, 더 나쁘게는 그 문제를 정면으로 보지 않기 위한 방법일 수도 있습니다.
우리는 조직에서 이런 비전을 구현할 기회가 많지 않았습니다. 기술적 이슈(확장성, 성능, 사일로에서 데이터 꺼내기, RDF 매핑, RDF 트리플의 맥락화 문제) 외에도 조직적 이슈에 부딪혔기 때문입니다. 조직은 데이터 자체를 관리하는 데 관심이 부족한 경우가 많고, 특히 투자 대비 효과(ROI)가 명확하지 않으면 더 그렇습니다. 때로는 IT 부서가 조직 내에서 횡단적 시각을 취할 정당성이 없기도 합니다.
마지막으로, 개발자 역량 부족은 특히 중요한 결함입니다. 이는 구현, 운영, 유지보수 가능성을 좌우합니다. IT 인력은 장기적으로 유지할 수 있다고 확신하지 못하는 해법으로는 결코 움직이지 않습니다.
이러한 경험들은 의미론적 웹 기술이 두 측면에서 제공하는 이점을 보여줍니다.
이제 각 주제에 대해 의미론적 웹 기술의 기여와 한계를 보여주고, 이를 극복하는 방법을 설명하겠습니다.
관계형 데이터베이스의 경직성(그것이 실제든 인상이든)과 비교하면, RDF 그래프는 절대적 자유처럼 보입니다.
이는 표 모델이 해결하지 못했던 것을 가능하게 합니다. 즉, 이질적 엔티티를 타입이 지정된 링크로 직접 연결하거나, 참조 데이터로 연결하는 방식으로 손쉽게 연결할 수 있고, 데이터 구조 또한 데이터의 일부로 포함할 수 있습니다.
전체 논리 모델을 편집하지 않고도 그래프는 시간에 따라 진화할 수 있으며, 성장은 잠재적으로 무한합니다.
네, 이러한 약속은 의미론적 웹 기술(특히 RDF와 SPARQL)이 실제로 지켜 냈습니다.
하지만 RDF 모델의 구조 자체는 다양한 정보 조각의 프로버넌스(provenance) 관리와 트리플의 맥락화에 한계를 드러냈습니다. 이 문제는 팀 버너스-리의 의미론적 웹 구상에도 이미 존재했지만, 지금도 완전히 해결되지 않았습니다. 해법들이 등장했지만 완전히 만족스럽지는 않습니다. 이 관점에서 RDF 1.1은 ‘놓친 약속’입니다.
한편, “프로퍼티 그래프(property graph)”라는 또 다른 모델이 등장했습니다. 이는 이 한계에 대한 해답을 제시합니다. 이 모델은 오늘날 주요 업체들이 제안하는 그래프 데이터베이스 기술의 핵심입니다. 예컨대 IBM, Microsoft, Amazon (원칙적으로 Blazegraph 기반이며, 해당 회사가 아마존에 인수된 것으로 보인다는 이야기도 있습니다), Google 등이 있고, 신규 플레이어로 Huawei, Datastax, Neo4j 또는 OrientDB도 있습니다.
따라서 그래프 모델은 잘 나가고 있습니다. 이유는 분명합니다. 구조화된 데이터 조작과 이질적 데이터의 교차 질의에서 탁월한 유연성을 제공하기 때문입니다. 하지만 산업계의 다수 플레이어는 프로퍼티 그래프 모델을 구현하는 선택을 했고, 저장 시스템과 상호작용하기 위해 Apache Tinkerpop 프레임워크와 Gremlin 질의 언어를 채택하여 사실상 표준이 되었습니다.
그래프 시스템에서의 유지보수성과 데이터 관리
RDF의 한계를 인정한다고 해서, 그동안 의미론적 웹 기술이 가져온 모든 것을 포기하자는 뜻은 아닙니다. 특히 RDF* / SPARQL*를 통해 프로퍼티 그래프와 RDF 사이의 화해도 가능합니다. 데이터를 웹에 발행할 필요가 없다면, 프로퍼티 그래프 사용은 제게 좋은 생각으로 보입니다.
이 기술들과 함께 일하면서 우리는 데이터 거버넌스에 대해서도 생각하게 되었습니다. 모든 데이터의 ‘전역 지도’를 만드는 것은 좋은 출발점일 수 있습니다. 또한 프로젝트의 첫 단계이자 개발 전 과정에서 개념 모델링에 집중해야 합니다.
마지막으로 시작할 때 스스로에게 물어보세요. 정말 그래프 모델이 필요한가? 유행이라는 이유만으로 의미론적 웹 기술을 써서는 안 됩니다. Dan Brickley가 말하듯, 자기 시스템 내부에서는 원하는 대로 하면 됩니다. RDF는 아키텍처의 핵심에 반드시 써야 하는 표준이 아니라, 데이터를 교환하기 위한 도구로 보아야 합니다.
사실 의미론적 웹 기술의 가장 큰 강점(어쩌면 유일한 강점)은 공통 모델(트리플)을 제공함으로써 구조화된 데이터의 상호운용성을 보장하는 데 있습니다. 이 관점에서 약속은 완벽히 지켜졌습니다. 데이터 수준의 상호운용성을 설계한다면, 의미론적 웹 기술은 현재로서는 최선의 해법이며, 이 문제에 대한 우리의 사고에 깊은 영향을 미쳤습니다.
비록 이것만으로 광범위한 채택이 이뤄지지는 않았지만, 이 기술들은 미지의 기술적 가능성을 열어 상호운용성에 대한 성찰을 가속했습니다. 이질적 데이터를 연결하기 위한 조건을 더 잘 이해하게 했고, 멀게 보이거나 양립 불가능해 보였던 세계 사이에 다리를 놓는 방법을 알려주었습니다(발표자료도 참조). 의미론적 웹 기술은 상호운용성을 구상하는 새로운 방식을 가능하게 했습니다.
또한 Wikidata의 사례처럼, SPARQL은 RDF를 모델로 사용하든 말든 데이터를 질의하는 강력한 도구입니다.
하지만 이 영역에서도 주요한 결함이 있습니다.
데이터는 그 성격, 가능한 사용, 목표 사용자에 맞게 발행되어야 합니다.
또한 단순하고 사용하기 쉬운 온톨로지에 집중해야 합니다. 요컨대 데이터 노출에는 schema.org가 좋습니다. data.bnf.fr 모델을 이해하려고 시간을 허비해 본 적이 없는 사람이 있을까요? 혹은 CIDOC-CRM을 엄격히 따르는 데이터 모델 때문에 영국박물관 SPARQL 엔드포인트의 미로에서 길을 잃은 적은요?
이 정도 수준의 상호운용성이 정말 필요한가? 현실을 직시해야 합니다. 증가하는 데이터의 규모 앞에서, 하나의 모델로 문법적/구조적 상호운용성을 생산·저장·활용 전반에서 달성하겠다는 생각은 포기해야 합니다. 다만 정보시스템 전체에서 공통으로 쓰이는 독립적인 식별자를 사용한다든지, 서로 다른 정보 조각들 사이의 일정한 연결을 제공하는 것은 여전히 가능합니다. 이것이 조직 간 상호운용성이 유토피아라는 뜻은 아닙니다. 다만 그것은 데이터의 저장에서의 전역 상호운용성보다는, 데이터 처리를 통한 시스템 종단 간(end-to-end) 상호운용성에 더 의존합니다.
의미론적 웹 기술을 사용하지 않고도, 횡단적 데이터 거버넌스를 배치하고 ‘사용’이 아니라 데이터 자체의 논리에 기반해 데이터 모델을 설계함으로써 조직의 다양한 데이터에 전역적 일관성을 부여하는 것을 상상할 수 있습니다. 한마디로, 데이터를 제대로 관리하는 것입니다. 이 질문의 답은 기술만이 아닙니다… 의미론적 웹 기술과 함께한 수년의 경험은 이러한 관찰과 결합되어, 우리가 결국 프랑스 국립 시청각 연구소의 새로운 정보시스템을 설계한 방식으로 이어졌습니다.
우리 프로젝트의 주요 방향은 다음과 같습니다.
비즈니스 애플리케이션과 독립적인 기술적 데이터 저장·처리 인프라를 구축하여, 기술적으로 데이터를 사용과 분리
기관이 다루는 모든 유형의 데이터를 관리하고, 사용이 아닌 논리 관점에서 데이터 모델을 재고하며, 생산/저장을 위한 모델과 데이터 발행을 위한 별도 모델들이 존재함을 인정함으로써 기능적으로도 데이터를 사용과 분리
저장(정형·반정형·비정형)과 활용 요구를 충족하기 위해 5가지 데이터베이스 유형을 사용
단일 중앙 인프라 안에 다섯 저장 시스템, 처리·동기화 계층(시스템의 진정한 핵심이자 실제로 상호운용성을 보장하는 요소), 그리고 비즈니스 애플리케이션으로부터 아키텍처를 추상화하는 배포(디세미네이션) 계층을 포함
따라서 현재 의미론적 웹 기술은 Wikidata에서 데이터를 수집·처리하여 사람과 장소에 대한 참조 어휘를 풍부화하는 데만 사용됩니다. 필요가 생기거나 정치적 의지가 있다면, 데이터의 전부 또는 일부를 Linked Data로, 그리고 SPARQL 엔드포인트로 노출하는 것을 고려할 수 있습니다. 하지만 그 외에는 데이터 재사용을 높이기 위해 단순한 형식의 덤프를 선호할 것입니다. 즉, 의미론적 웹 기술이 제공한 성찰과 기여에 깊이 영향을 받았음에도, 우리 프로젝트는 더 이상 그것들을 사용하지 않습니다.
정보관리 RDF 의미론적 웹 정보시스템 SPARQL 웹 수다 디지털 인문학 RDFa 링크드 데이터
블로그 보존 디지털 인문학 포크소노미 역사 색인 링크드 데이터 정보관리 검색 엔진 브라우저 디지털화 도구 OWL 개인 RDF RDFa 인문사회 SPARQL 구조화 정보시스템 TEI 휴가 검증 웹 웹 서비스 의미론적 웹 위키 위키백과 XHTML XML Xquery XSLT 비평판 전자 출판
