SPARQL 이해

8 페이지 중 2 페이지 문서 옵션 토론 샘플 코드  제안 및 의견 피드백 튜토리얼 평가 이 컨텐츠를 개선하기 위한 도움을 주십시오.

케이크처럼 쌓은 시맨틱 웹 레이어들

이 절에서는 시맨틱 웹 관련 용어에 대해 정의하고 RDF와 OWL이 무엇인지, 그리고 이것들이 어떻게 동작하는지, 시맨틱 웹 애플리케이션용 도메인 모델을 빌드하기 위해 어떻게 쓸 수 있는지 설명한다.

SPARQL의 역사

SPARQL은 몇 가지 핵심 기술의 상단에서 만들어졌다. 이는 HTTP와 HTML(월드 와이드 웹(WWW)의 토대)이 좀 더 깊고 저수준의 TCP/IP와 같은 시스템 상단에서 만들어졌던 것과 같은 맥락이라 할 수 있다. SPARQL이 무엇인지 알아보기 전에 핵심 표준이 무엇인지, 그 표준들은 왜 거기에 있고, 이제 막 피어나기 시작한 시맨틱 웹 개발자로서 여러분에게 의미하는 바가 무엇인지 들여다 보자.

1997년 팀 버너스-리(Tim Berners-Lee)는 HTML과 월드 와이드 웹이 한계에 봉착했다고 지적했다. 요즘처럼 복잡한 분산 시스템이 만들어내는 건 말할 것도 없거니와, HTML 자체는 동적인 웹 기반 애플리케이션을 위해 고안된 게 아니었다. 당시 우리가 가진 거라곤 FTP가 전부였고 WWW라는 것은 직접적이고 다소 자율적으로 동작하는 기계 간 통신이 될 거라는 점, 그리고 HTML과 HTTP는 그저 그러한 원대한 비전을 향해 (없어서는 안 될) 단계였을 뿐이다.

RDF는 뭐든 기술할 수 있기 때문에 얇은(thin) 레이어에 점점 더 풍부한 내용을 추가해 넣어 레이어를 만들어가는 것을 허용하면서 스스로를 설명할 수 있다. 이러한 씬 레이어 접근 방식은 어휘 스택(vocabulary stack)의 생산을 대상으로 하고 있다. 그림 1의 도표에 W3C가 정의한 레이어를 보였다. 현재 RDF 상위에 있는 레이어들에는 RDFS와 OWL이 포함되어 있다(OWL 상에서 빌드할 향후 작업으로 예정된 것이 있다). RDF 스키마 언어라는 RDFS는 RDF에 클래스(class)와 속성(property)을 추가한 것이다. OWL(웹 온톨로지 언어: Web Ontology Language)은 RDFS를 확장한 것으로 클래스 간 관계를 정의하여 좀 더 풍부한 언어적 기능을 제공한다. 좀 더 풍부한 언어를 쓴다면 좀 더 똑똑한 시스템을 만들기 위해 자동화된 추론 엔진을 사용하는 것이 가능해진다.

다음 절에서는 RDF가 어떻게 구성되는지 살펴보고 이 세상의 모델을 만들어내는 데 RDF를 어떻게 사용할 수 있는지 알아보자.

위로

RDF

RDF는 "메타 기술 언어"라고 불려왔으나 RDF는 그저 뭔가를 기술하는 거라고 이야기하는 표현 방식 중 하나일 뿐이다. RDF는 사람들이 하는 것과 똑같은 방식으로 뭔가를 기술한다. 뭐 이런 식이다. "까마귀가 옥수수를 먹는다(The crow eats corn)" 혹은 "조니는 채치를 좋아해(Joni loves Chachi)"라는 문장처럼 말이다. 각 문장은 주어가 있고(까마귀(crow), 조니(Joni)), 목적어가 있으며(옥수수(corn), 채치(Chachi)), 술어(먹는다(eats), 좋아해(loves))가 있다. RDF에서 이 같은 주어-술어-목적어(subject-predicate-object) 문장을 트리플(triple)이라고 한다. RDF는 뭐든 기술할 때 트리플을 사용한다.

이 트리플을 시각적으로 표현하는 한 가지 방법은 RDF 그래프(RDF Graph)를 사용하는 것이다. RDF 그래프란 RDF로 된 문장의 묶음(collection)이다. 하나의 그래프는 노드(node)와 호(arc)라는 용어로 정의된다. RDF에서 노드는 자원(resource)이고 호는 술어(predicate)다. 즉 이것들은 주어와 목적어 노드 간의 관계에 대한 문장이다. 그 중심에서 RDF 명세는 그래프를 정의하는 게 전부다. 직렬화(serialization) 형식 같은 것은 중요한 문제이긴 하지만 부차적 문제다. 주어와 목적어 요소는 그래프에서 노드를 정의한다(이들은 URI의 목표(target)이기 때문에 자원이라고도 알려져 있다). 각 술어는 트리플이 참조하는 두 노드 간의 관계를 정의한다.

그래프가 다른 웹에서도 가용하게끔 하려면 트리플 스토어(다른 말로 하면 그래프를 구성하는 트리플을 저장할 수 있는 장소)에서 RDF 파일을 호스팅해야 한다. RDF 그래프를 트리플 스토어에 저장해 두고 웹에서 접근 가능하도록 노출시켜 두면 다른 이들이 SPARQL을 사용하여 그래프를 질의할 수 있다(그림 2 참조).

RDF에서 각 노드와 술어는 URI에 의해 식별된다. RDF는 URI를 사용하여 식별되지 않는 노드도 허용한다. 이는 빈 노드(Blank Nodes) 혹은 빈 노드 식별자(Blank Node Identifiers)라 부르며 지역적 참조를 위해 임시적, 내부적으로 보이기 위한 식별자로 사용된다. RDF 명세에서는 빈 노드 혹은 빈 노드 식별자가 XML로서 RDF의 직렬화에 대한 표준을 제공해오긴 했지만 이와 동등한 구조를 갖는다면 어떠한 구조든 허용된다고 언급하고 있다. 다음 RDF XML은 저자에 대한 내용을 말하는 트리플에 대한 XML이다(Listing 1 참조).

                    
 <?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:mu="http://aabs.purl.org/music#">
  <rdf:Description rdf:about="http://aabs.purl.org/music#andrew">
    <mu:playsInstrument>
      <rdf:Description rdf:about="http://aabs.purl.org/music#guitar"/>
    </mu:playsInstrument>
  </rdf:Description>
 </rdf:RDF>
 

이 RDF XML에서는 "앤드류(Andrew)가 기타(guitar)를 연주(play)한다" 혹은 좀 더 정확히 말하면 "앤드류(Andrew)로 지칭되는 뭔가가 기타(guitar)라고 지칭되는 악기를 연주(play)한다"라고 이야기하고 있다. 알려주는 정보 최소의 양을 고려한다면 문장이 꽤나 길다는 데에는 동의할 것이다. 다음으로 터틀이라 불리는 언어로 나타낸 동일한 그래프를 보자. 터틀도 W3C에서 관할하고 있다(Listing 2 참조).

                    
@prefix : <http://aabs.purl.org/music#> .
:andrew :playsInstrument :guitar .

훨씬 더 좋다! 가격 대 성능비가 무척 좋아 그것만 갖고도 쓸만한 가치가 충분하다. W3C는 RDF의 생산성을 높이고자 인간이 읽고 쓰기 편한 언어로 터틀을 고안해냈다. SPARQL은 터틀을 사용하며, 따라서 지금부터 모든 예제도 터틀을 사용할 것이다. 트리플의 끝에는 마침표를 나타내는 문자가 있으며 공백이 들어가도 상관 없다(그림 3 참조).

RDF는 RDF 파일 내에 내장 XML용 XML 상수(literal) 타입 말고는 고유의 데이터 타입을 갖고 있지 않다. XML 스키마를 사용하여 정의된 데이터 타입을 쓸 수 있으며 이런 것들이 가장 빈번히 사용되곤 한다.

터틀에서 상수 데이터 타입은 Listing 3처럼 데이터의 끝에 추가된다.

                    
@prefix xsdt: <http://www.w3.org/2001/XMLSchema#>.
@prefix mu: <http://aabs.purl.org/music#>.
:andrew :boughtInstrument "1987-06-13T10:30:00"^^xsdt:dateTime .

^^ 부분이 데이터 타입의 스트링 상수 표현("1987-06-13T10:30:00" 부분)과 데이터 타입 선언(xsdt:dataType 부분) 사이에 붙어 있다. 따라서 이는 "앤드류(Andrew)가 1987년 6월 13일 10시 30분에 기타(guitar)를 샀다(bought)"고 언급하고 있다. 이 규칙에서 예외는 타입에 대해 해결의 실마리를 필요로 하지 않고 명백하게 파싱될 수 있는 타입이라는 것이다. 따라서 5와 같은 있는 그대로의 수는 명백히 정수다. 이와 비슷하게 볼 것도 없이 문자열인 Andrew는 문자열로서만 파싱할 수 있다. 같은 케이스가 boolean이나 decimal 타입에도 적용된다. integer, boolean, decimal은 인용 부호 없이 순수하게 숫자로 주어질 수 있다. 정수로 사용될 수 있는 문장은 이런 것이라 할 수 있겠다. :guitar :timesRestrung 500.

문자열은 인용 부호로 감싸야 한다(팀 버너스-리가 현재 선호하는 언어인 파이썬(Python)의 일반적 규칙에 따르면 그렇다). 이를테면 :guitar :makersModel "GL350"이나 Listing 4처럼 말이다.

                    
:guitar :makersModel """GL350
some more text on a new line (provided you use triple quotes)""" .
 

그림 4는 Listing 2, 3, 4의 그래프를 나타낸 화면이다.

RDF는 데이터 구조에 관한 표준을 정의하지 않는다. 일반적인 프로그래밍 언어처럼 RDF 언어 디자이너들도 간단한 구조에서 RDF를 확장해 왔다. RDF에서는 'Bags', 'Sequences', 'Alternates lists'가 있다. 이 구조체들은 트리플을 써서도 구현할 수 있지만 너무 깊이 들어가면 지루할 수 있어 하지 않는다. 좀 더 깊이 파고 들어가고 싶다면 RDF Primer(참고자료 참조)를 보기 바란다. 터틀은 이 데이터 구조에 대한 구문을 자체적으로 지원한다. 리스트가 어떻게 선언되는지 보자: :andrew :child (:emily :thomas).

이는 Listing 5와 동일하다.

                    
:andrew :child :emily .
:andrew :child :thomas .

트리플의 주어로도 리스트를 사용할 수 있다. 이를테면 다음과 같다: (:thomas :emily) :parent :andrew ..

URI를 부여하지 않고 RDF로 자원을 선언하려면 빈 노드, 즉 로컬 참조에 대한 임시 이름을 사용할 수 있다. Listing 6에 JournalEntries 온톨로지에서 예를 보였다.

                    
_:JohnConnor a u:User;
  u:domainLogin "someDomain/john.connor";
  u:displayName "John Connor" .

_:JohnConnor는 빈 노드(밑줄 문자(_)가 맨 앞에 표시되었다)로서 참조를 위해 로컬에서 사용될 수 있다. 여러분 입장에서는 도메인 로그인에 필요한 자원이 LDAP(Lightweight Directory Access Protocol)과 연결되어 있는데 이 LDAP이 정말로 로컬 자원일 수도 있기에 별 이유 없이 ":JohnConnor"보다는 (이건 외부에 보일 수 있으니) 빈 노드 형태로 RDF를 작성하고 싶을지도 모르겠다. 어떤 걸 쓰든 여러분 마음이다.

빈 노드를 사용하는 또 다른 방법은 "[]" 문법을 사용하는 것으로, 로컬 이름을 주고 싶지 않은 자원을 표시할 때 사용한다. 현재 트리플이나 술어-목적어 리스트에만 한정된다(Listing 7 참조).

                    
[] a j:JournalEntry;
  j:date "20080205T09:00:00"^^xsdt:dateTime;
  j:user _:JohnConnor;
  j:notes """Today I learnt how to defraud ATM machines and how to field
    strip a machine gun blindfolded.""";
  j:tag "armaments";
  j:tag "cash".
 

따로 이름을 하나 갖고 있지 않거나 별 의미없는 식별자들로 애플리케이션 이름 공간을 어지럽게 만들고 싶지 않다면 이 관용어를 선택해 봄직하다. 결국 SPARQL을 이용하여 URI라기보다는 관련된 데이터에 의해 자원을 질의할 수 있다. 빈 노드를 사용하면 트리플 스토어는 독립적으로 빈 노드 식별자를 할당할 것이다. 이러한 표기법 형태는 자원 사용이 일회성으로 끝나는 데 이는 자원 정의가 최종적으로 끝난 후에는 직접 연결될 수 없게 되기 때문이다.

위에서 다룬 두 예제에서 알아둬야 할 것은 여러 트리플이 동일한 주어를 공유할 수 있도록 세미콜론(;)을 사용할 수 있다는 점이다. 이는 술어-목적어 리스트로 알려져 있고 자주 사용되는데 이를 통해 하나의 주어에 대해 몇 개의 문장이 함께 만들어지는 게 가능하기 때문이다. 사실 위에서 사용된 빈 노드 표기 방식은 술어-목적어 리스트 표기 방식 없이는 아예 쓸모가 없을 것이다.

위로

RDFS와 OWL

RDF는 좀 더 추상적인 어휘를 통해 자체 계층화된 확장을 지원하고자 의도적으로 설계되었다. 확장된 최초의 방식은 RDF 어휘 기술 언어(Vocabulary Description Language), 좀 더 보편화된 용어를 쓴다면 RDF 스키마 혹은 RDFS를 이용한 것이다. RDFS는 클래스, 속성, 상속(inheritance)을 정의할 수 있도록 RDF를 확장한 것이다. 꽤 완벽한 객체 지향 디자이너인 것이다. OWL은 RDFS를 확장하여 클래스의 속성과 관계를 기술할 풍부한 기능을 담은 툴킷을 제공한다. OWL은 특히 두 클래스 간 관계의 정확한 본질을 기술하기 위한 속성이 과분하리만치 잘 담겨 있다. OWL의 주된 개발 동기는 온톨로지의 시맨틱이 연역적 추론 엔진이 데이터에 관해 참신하고 독창적인 귀납적 추론을 할 수 있도록 하는 확고한 기반을 다지는 것이다.

위로

RDF 클래스와 속성

RDFS는 하나의 타입인 자원을 기술하는 rdfs:type이라 불리는 트리플 술어를 정의한다. 또한 어떤 클래스인 자원이 다른 클래스로부터 전해진 것이라고 선언하는 것을 허용하기도 한다. Listing 8에 타입 선언의 예를 나타내었다.

                    
:HeavenlyBody rdfs:type rdfs:Class.
:Planet, :Asteroid, :Comet, :Meteor rdfs:subClassOf :HeavenlyBody.

그림 5에서는 클래스 계층에 대해 작게나마 정의했다.

클래스 인스턴스(instance) 정의는 클래스 선언과 아주 흡사하다. RDFS는 클래스 선언 트리플과 주어가 클래스이긴 하지만 인스턴스는 아니라는 것을 가리키는 데 사용되는 rdfs:subClassOf 술어를 갖는 클래스 멤버십을 구별한다(Listing 9 참조).

                    
:Mercury, :Venus, :Earth, :Mars rdfs:type :Planet.
:Ceres, :Vesta rdfs:type :Asteroid
# ...

터틀에서는 타입 선언을 좀 더 쉽게 해주는 간편한 표기법을 제공한다(Listing 10 참조).

                    
:GasGiant rdfs:subClassOf :Planet.
:Jupiter, :Saturn, :Uranus, :Neptune a :GasGiant.

a는 그저 rdfs:type의 단축형이다. 특별한 뜻은 없다.

또한 RDFS는 클래스에서 속성을 제공한다. Listing 11에서 어떻게 선언하는지 보였다.

                    
:massKg
  rdfs:domain :HeavenlyBody ;
  rdfs:range xsdt:double .
  

:HeavenlyBody에서 double 값으로 매핑한 :massKg라는 속성을 선언했다. 다른 말로 하면 모든 지상의 모든 물체(hanvenly bodies)들은 질량(mass)을 가질 수 있다는 말을 선언한 것이다. 이전 인스턴스의 선언은 이제 다시 쓰일 수 있다(Listing 12 참조).

                    
:Earth a :Planet;
  :massKg "5.9742e24"^^xsdt:double.

RDFS는 OWL에 비하면 꽤나 빈약하다. OWL은 두 클래스 간 관계의 미묘한 내용을 구체화하는 방법도 방대하게 제공한다. 정말 제대로 표현해낼 수 없을 만치 방대하긴 하지만 OWL로 해낼 수 있을 일들을 여기에 몇 가지 정도 소개했다(Listing 13 참조).

                    
:hasUsedSkill a owl:ObjectProperty ;
  rdfs:domain :User ;
  rdfs:range :Skill;
  owl:equivalentProperty :hasSkill;
  owl:inverseProperty :hasBeenUsedBy .
  

이것은 :hasUsedSkill 속성이 :User와 :Skill 타입의 두 목적어와 관련이 있음을 말해주고 있다. 또한 :hasSkill 속성을 사용하는 것과 동일하다(이것들은 똑같은 의미다). 다른 데에서 사용된다면 기술(skill)이 누군가에 의해 사용되어 왔다는 것(:hasBeenUsedBy)은 누군가 기술을 갖고 있다는 것(:hasSkill)이고 사용해 왔다는 것(:hasUsedSkill)을 의미하기도 한다. 다른 말로 하면 OWL은 추론 엔진이 온톨로지에서 정의된 다양한 속성에서 암묵적으로 동일한 의미를 알도록 지시를 내릴 수 있다는 말이다. OWL에서 훨씬 더 많긴 하지만 이 튜토리얼은 추론 엔진 사용을 다루지는 않기 때문에 지금까지는 RDFS를 사용할 수 있다.

여기서는 다루지 않지만 또 다른 주제가 있긴 한데, 데이터 모델링에 대한 객체 지향적인 접근이 우월한가 그렇지 않은가에 대한 해묵은 논쟁이다. 지금까지는 객체 지향이 애플리케이션 개발 세계를 지배해 왔음은 명백한 사실이기에, 온톨로지 영역과 객체 영역 사이의 가능한 쉬운 매핑이 있음은 중요한 점이다. LinqToRdf 같은 시스템들은 그런 매핑이 진정으로 가능함을 보여주고 있고, 여러분이 직면할 수 있는 실제 이슈들은 OWL 온톨로지에서 여러분이 위치시킬 수 있는 정보들의 완전한 부(wealth)다. 이는 겉으로 보기엔 불행해 보이지만 행복한 것이다.

이제까지 이 정도면 이론은 충분했다. 이제 SPARQL에 초점을 맞출 만큼 RDF에 대해 충분히 알았다. 이번에 간단히 알아본 소개 내용에서는 세계적으로 실제 인기를 얻고 있는 온톨로지들, 이를테면 FOAF, SIOC, 더블린 코어(Dublin Core) 같은 RDF에서 빌드한 레이어들에 대해서는 거의 다루지 않았다. 추론 엔진의 매력적인 세계로 깊이 빠져들지도 않았고 마크업 언어를 규정하거나 위대한 힘과 약속을 가진 모든 것을 공식화하지도 않았다. 아마도 각각의 주제는 다른 튜토리얼들에서 따로 다룰만한 내용일 것이다. 이제 좀 더 실질적인 것으로 옮겨가자. 여러분은 트리플 스토어와 SPARQL 엔드포인트를 설정할 필요가 있다. 그러고 나면 몇 가지 온톨로지 개발을 시작할 수 있을 것이다.

위로

OWL로 온톨로지 정의하기

이 튜토리얼은 간단한 프로그램을 개발하여 여러분이 하는 것을 기술하는 정보 관리 목록을 정의할 수 있도록 한다. 차후에는 SPARQL 질의를 개발하여 가상 회사에 있는 누가 무엇을 하는지에 대해 다양한 질의를 하도록 할 것이다.

튜토리얼 초반부에 이 정보 관리 목록이 트위터 류의 마이크로 블로그라고 언급했다. 튜토리얼 예제의 모든 부분에 대한 설명이 상식적으로 어디로 갈지 알아야 할 필요가 있다. 정보 관리 시스템은 목록을 표시할 UI가 필요할 것이다. 대다수 개발자에게는 친숙한 영역이므로 여기서는 다루지 않을 것이고, developerWorks 다른 튜토리얼에서 자세히 다뤄질 것이다(참고자료 부분 참조).

온톨로지는 생성할 데이터의 형식을 정의할 것이다. 온톨로지는 속성을 지닌 클래스를 정의할 것이다. 마이크로 블로그 목록은 온톨로지를 따르는 터틀 코드로 쓰여질 것이다. 그리고 나서 트리플 스토어에 저장되면 데이터는 SPARQL을 사용하여 질의가 가능해진다. SPARQL 질의를 통해 얻어진 결과는 질의에 일치되는 변수들을 패키지한 XML 결과 형식이다. XML로부터 쉽게 정보를 추출하여 쉽게 웹에 표시할 수 있다.

우선 정보 관리 온톨로지를 정의할 필요가 있다(Listing 14 참조). 이건 정말 간단하다. 딱 클래스 두 개다. JournalEntry와 User라는 클래스 두 개를 정의한다. 각 User는 원하는 만큼 정보 관리 목록을 정의할 수 있고, 각 정보 관리 목록은 날짜, 사용자에 대한 참조, 태그에 대한 집합을 담을 수 있다.

                    
@prefix log: <http://www.w3.org/2000/10/swap/log#> .
@prefix string: <http://www.w3.org/2000/10/swap/string#>.
@prefix os: <http://www.w3.org/2000/10/swap/os#>.
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix j: <Journal.n3#>.
@prefix : <#>.
 
#JournalEntry class
:JournalEntry a owl:Class .
:date
  rdfs:domain :JournalEntry;
  rdfs:range xsdt:datetime;
  owl:cardinality 1.
:user
  rdfs:domain :JournalEntry;
  rdfs:range :User ;
  owl:cardinality 1.
:notes
  rdfs:domain :JournalEntry;
  rdfs:range xsdt:string;
  owl:cardinality 1.
:tag
  rdfs:domain :JournalEntry;
  rdfs:range xsdt:string .
 
#User class
:User a owl:class .
:domainLogin
  rdfs:domain :User;
  rdfs:range :xsdt:string ;
  owl:cardinality 1.
:displayName
  rdfs:domain :User;
  rdfs:range xsdt:string ;
  owl:maxCardinality 1 .
 

이제 JournalEntries.n3 파일에서 JournalEntry 요소 몇 개를 정의할 것이다. 우선 할 일은 :User 인스턴스를 정의하는 것이다(Listing 15 참조).

                    
_:AndrewMatthews a :User;
  :domainLogin "someDomain/andrew.matthews";
  :displayName "Andrew Matthews" .
  

이 목록이 Journal.n3의 정의에 따르고 있음을 볼 수 있다. 이제 사용자 목록을 갖고 정보 관리 목록 몇 가지를 정의할 수 있다(Listing 16 참조).

                    
[] a :JournalEntry;
  :date "20080204"^^xsdt:datetime;
  :user _:AndrewMatthews;
  :notes """Today I wrote some more content for the
    great new SPARQL tutorial that I've been preparing. I used
    some N3 to do it in, and I defined a simple ontology for 
    defining journal entries.
 
    This is an example of one of those entries!""";
  :tag "N3";
  :tag "RDF";
  :tag "OWL";
  :tag "tutorial".
 
 
[] a :JournalEntry;
  :date "20080205"^^xsdt:datetime;
  :user _:AndrewMatthews;
  :notes """Today, I wrote some more content for the tutorial
    I wrote a section that describes how you set up Joseki."""
  :tag "N3";
  :tag "Java";
  :tag "Joseki";
  :tag "configuration";
  :tag "Jena".
  

어쨌든 이번에 이름이 주어지지 않았고, 그저 :JournalEntry 클래스의 클래스 정의에 부합하는 익명 인스턴스를 정의했다. 튜토리얼 소스 코드 파일에서 이런 목록들을 좀 더 찾아볼 수 있을 것이고 따라서 질의가 좀 더 즐거울 것이다.

소스 코드 내에서 온톨로지 정의 및 필요한 모든 것을 지원하는 나머지 정보 관리 목록들을 찾게 될 것이다.

1. 튜토리얼 최상위에 zip 파일을 다운로드한다.
2. .bat 파일을 조세키 디렉터리에 복사한다.
3. 설정 파일을 조세키 디렉터리로 복사한다. 이 때 기존 설정 파일인 Joseki.ttl은 덮어 쓴다.
4. 조세키를 다운로드했던 위치로 RunJoseki.bat 파일의 경로를 수정한다.
5. 트리플 스토어와 SPARQL 서버를 시작하려면 RunJoseki.bat 배치 파일을 더블 클릭하면 된다.

나타나는 콘솔 화면은 초기에는 Listing 17과 비슷할 것이다.

                    
Starting Joseki
12:19:17 INFO  Configuration        :: ==== Configuration ====
12:19:17 INFO  Configuration        :: Loading : <joseki-config.ttl>
12:19:18 INFO  ServiceInitSimple    :: Init: Example initializer
12:19:18 INFO  Configuration        :: ==== Datasets ====
12:19:18 INFO  Configuration        :: New dataset: JournalDataset
12:19:18 INFO  Configuration        ::   Default graph : Journal.n3
12:19:18 INFO  Configuration        :: ==== Services ====
12:19:18 INFO  Configuration        :: Service reference: "sparql"
12:19:18 INFO  Configuration        ::   Class name: org.joseki.processors.SPARQL
12:19:18 INFO  SPARQL               :: SPARQL processor
12:19:18 INFO  SPARQL               :: Locking policy: none
12:19:18 INFO  SPARQL               :: Dataset description: true // Web loading: true
12:19:18 INFO  Configuration        :: Dataset: JournalDataset
12:19:18 INFO  Configuration        :: ==== Bind services to the server ====
12:19:18 INFO  Configuration        :: Service: <sparql>
12:19:18 INFO  Configuration        :: ==== Initialize datasets ====
12:19:19 INFO  Configuration        :: ==== End Configuration ====
12:19:19 INFO  Dispatcher           :: Loaded data source configuration: joseki-config.ttl
12:19:19 INFO  log                  :: Logging to 
                                         org.slf4j.impl.Log4jLoggerAdapter@29d65b via 
                                         org.mortbay.log.Slf4jLog
12:19:19 INFO  log                  :: jetty-6.1.4
12:19:19 INFO  log                  :: NO JSP Support for /, did not find 
                                         org.apache.jasper.servlet.JspServlet
12:19:19 INFO  log                  :: Started SocketConnector@0.0.0.0:2020

이제 SPARQL 질의를 할 준비가 다 되었다. 조세키에는 자체 웹 서버가 들어 있어 SPARQL 질의 폼을 호스팅할 수 있다. 이 폼은 http://localhost:2020/sparql.html에 위치할 것이다. 조세키 구동을 시작하고 나서 이 링크를 클릭하면 SPARQL 질의 폼이 나타날 것이다(그림 6 참조).

조세키는 HTTP 엔드포인트로서 SPARQL 질의를 받아서 응답한다. 조세키는 트리플 스토어 기능을 제공하는 제나 시맨틱 웹 프레임워크의 상단에 위치하고 있다. 또한 조세키는 웹 엔드포인트를 호스팅하는 간단한 자바 서블릿 엔진 기능도 제공한다. 조세키는 이를 이용하여 여러분이 손수 질의를 표현할 수 있도록 하는 웹 질의 폼을 렌더링한다. 실 서비스용으로 동작하는 코드에서는 이 질의 폼을 쓰진 않을 것이다. 대신 SPARQL API(제나 프레임워크가 제공하는 류의 API)를 사용하여 프로그램에 따라 질의를 표현한다. 사실 굳이 웹으로 가지 않고도 SPARQL을 사용할 수도 있다. 로컬 트리플 스토어를 갖고 있다면 SPARQL을 사용하여 직접 대화가 가능하다. SPARQL 프로토콜은 웹 상에 나타낸다고 할 때 어떻게 통신할지에 대해 정의한다.

위로

SPARQL의 실제 사용

RDF, OWL, 터틀뿐 아니라 조세키 SPARQL 서버를 다운로드하여 설치하는 과정까지 다루었다. 이제 SPARQL이 실전에서 어떻게 사용되는지 보자. 질의를 만들어 테스트하기 위해 SPARQLer 질의 페이지를 사용할 것이다. 아무래도 질의 개발에는 파이어폭스(Firefox)를 쓰는 게 최고일 것 같다. 파이어폭스는 SPARQLer의 질의와 결과 페이지 사이를 왔다갔다할 때 질의를 지우지 않기 때문에 그러하다. 지금부터 개발된 질의는 예제 애플리케이션과 관련될 것이다. 정보 관리 예제에서 일부 데이터를 추출할 질의를 생성할 것이다.

SPARQL을 이용하면 RDF 데이터베이스(혹은 트리플 스토어)에서 트리플에 대해 질의하는 것이 가능하다. 겉으로 보기엔 관계형 데이터베이스에서 데이터를 얻는 데 사용되는 SQL(Structured Query Language)과 닮았다. 이같은 유사성 때문에 데이터베이스에 친숙한 개발자들에겐 더욱 더 도움이 되는데, 역설적이게도 트리플 스토어와 관계형 데이터베이스는 근본적으로는 전혀 다른 녀석이기 때문이다. 관계형 데이터베이스는 테이블 기반으로서 이는 데이터가 고정된 테이블에 열(row) 간의 관계를 정의한 참조키(foreign key)를 갖는 고정된 테이블 형태로 저장됨을 의미한다. 트리플 스토어는 단지 트리플을 저장하며, 무언가를 기술하면서 원하는만큼 높이 트리플을 쌓아둘 수 있다. 관계형 데이터베이스에서는 데이터베이스의 설계에 한정될 수 밖에 없다.

RDF는 참조키와 기본키(primary key)를 쓰지 않고 대신 월드 와이드 웹용 표준 참조 형식인 URI를 사용한다. URI를 사용함으로써 트리플 스토어는 어떤 트리플 스토어에의 어떠한 다른 데이터에 대해서라도 링크를 걸 수 있는 잠재성을 갖게 된다. 이는 웹의 분산화라는 강점으로 작용한다.

트리플 스토어가 비조직적인 거대한 트리플의 집합이기 때문에 SPARQL은 그래프 패턴(Graph Pattern)이라 부르는 트리플 일치에 대한 템플릿을 정의함으로서 질의를 한다. RDF와 그래프에 대한 절에서 언급했듯 트리플 스토어의 트리플은 자원의 집합을 기술하는 그래프를 구성한다. SPARQL을 사용하여 트리플 스토어에서 데이터를 얻으려면 그래프에서 문장과 일치하는 패턴을 정의할 필요가 있다. 이런 류의 질문이 될 것이다. '기타를 연주한다(plays guitar)'라고 이야기하는 모든 문장의 주어를 찾으시오. Listing 18에서는 Listing 1에서 음악에 대해 온톨로지 사용을 정의했던 데이터에 대한 질의를 보이고 있다.

                    
PREFIX : <http://aabs.purl.org/music#>
SELECT ?instrument
WHERE {
    :andrew :playsInstrument ?instrument .
}

터틀은 이 튜토리얼에서도 사용되는데 SPARQL 그 자체는 질의 그래프 패턴을 표현하는 데에 터틀의 표현 형식을 사용하기 때문이다. 질의는 "주어로 :andrew를, 술어로 :playsInstrument를 갖고 있는 모든 트리플을 찾은 후, 일치하는 트리플의 목적어를 얻어서 반환하시오"다. 물론 SPARQL에는 이보다 더 많은 게 있긴 하지만 트리플 스토어가 구동되고 나면 터틀로 갈 것이다. 너무 많은 이론은 가급적 빨리 집어치우고 생산적인 일에 매진하고 싶겠지만 온톨로지 없이 트리플 스토어를 돌릴 수는 없고, 트리플 스토어 없이는 질의를 테스트할 수가 없다. 그래서 우선 온톨로지를 정의하고 난 후 호스팅한 다음 질의를 만들게 된다. 이제 온톨로지를 정의했고 이를 기반으로 인스턴스 데이터를 일부 정의했으니 데이터를 이용해 조세키를 설정할 준비가 되었다.

위로

정보 관리 데이터셋에 대해 조세키 설정하기

이 튜토리얼은 조세키 SPARQL 서버를 사용한다. 자유롭게 사용 가능하고 오픈 소스인 데다가 널리 사용되는 인기있는 플랫폼이기 때문이다. 온톨로지를 호스팅하고 질의를 구동하기 위해 다른 다른 트리플 스토어와 SPARQL 엔드포인트를 쓰는 건 여러분 선택이다.

조세키와 제나는 자바 언어로 작성되었지만 이 튜토리얼에서는 그에 대한 코드를 직접적으로 알 필요는 없다. 그저 파일을 제 위치에 놓도록 서버를 적절히 설정하여 어떤 그래프를 만들어야 하는지 알려줄 수 있는 정도면 된다(조세키 설정에 대한 링크는 참고자료 참조). 조세키 설정 파일은 제공 그래프를 기술한 자원 정의 터틀 파일이다. 데이터 파일을 기술하고 필요에 따라 RDF에 정의된 규칙을 처리할 추론 엔진을 정의할 수 있다. 실 세계의 애플리케이션에서는 SQARQLer 질의 페이지를 사용하지 않을 것이다. 대신 API를 써서 프로그램에 따라서 조세키에 질의를 보내고 프로그램 내에서 사용하기 위한 결과를 디코딩하도록 할 것이다(그림 7 참조).

우선 서비스할 데이터를 호스팅할 서비스를 정의한다. 이를 "JournalService"라고 부르자. 설정 파일은 Listing 19와 비슷할 것이다.

                    
[] rdf:type            joseki:Service ;
  rdfs:label          "SPARQL on the Professional Journal model" ;
  joseki:serviceRef   "journal" ;
  joseki:dataset      _:JournalDataset ;
  joseki:processor    joseki:ProcessorSPARQL_FixedDS .
 

제나와 조세키(이 튜토리얼에서 사용하는 도구들) 둘 다 설정에 터틀을 사용한다. 간단히 말해 이 짦막한 부분에서 "SPARQL on the Professional Journal model."이라고 명명한 joseki:Service 타입의 개체(entity)를 정의하였다. 설정 파일의 다른 개체들은 joseki:serviceRef "journal"에 의해 간접적으로 참조되고 있다. 이것은 뒷 부분에 정의되고 _:JournalDataset이라 부르는 데이터셋을 호스팅할 것이다.

이제 이전에 _:JournalDataset으로 참고된 데이터셋을 정의해야 한다. 이를 하기 위해 Listing 20처럼 ja:RDFDataset 타입의 개체를 정의한다.

                    
_:JournalDataset   rdf:type ja:RDFDataset ;
  ja:defaultGraph    _:JournalGraph ;
  rdfs:label "JournalDataset" ;
  ja:namedGraph
    [ ja:graphName <http://aabs.purl.org/ontologies/2007/11/journal> ;
    ja:graph _:JournalGraph ] ;
.

이 RDF에서는 _:JournalGraph로 정의된 기본 그래프를 갖고 _:JournalDataset으로 식별되는 RDFDataset을 정의한다. 이것은 그래프에서 데이터를 액세스할 수 있는 URI를 정의하며 또한 데이터셋의 내용에 대한 기본 액세스를 입증했다. 마지막으로 작업중인 온톨로지와 그에 기반을 둔 데이터에 대한 그래프를 정의할 필요가 있다. 이전에 _:JournalGraph로 그래프에 참조했다. Listing 21에서 어떻게 정의되었는지 보여주고 있다.

                    
_:JournalGraph  rdf:type ja:MemoryModel ;
  rdfs:label "JournalGraph" ;
  ja:content [ja:externalContent <file:C:/dev/sparqlTutorial/Joseki/Journal.n3>] ;
  ja:content [ja:externalContent <file:C:/dev/sparqlTutorial/Joseki/JournalEntries.n3>].

이 마지막 요소에서는 하나의 그래프를 정의한다. 이 그래프는 여러분 자신의 GGG(Giant Global Graph)다. 팀 버너스-리가 최근 시맨틱 웹에 이름을 붙이려고 했기에 GGG라는 용어를 썼다. 기억하자. 모든 RDF는 단지 그래프를 정의하기 위함이다. 그리고 나면 트리플 스토어의 설정이 데이터를 찾아 그래프에 넣거나 이 그래프를 세상 밖으로 드러내는 방법을 구체화하는 것이 전부라는 게 그리 놀라울 일이 아니다.

튜토리얼 파일의 압축을 푸는 곳이 어디든 ja:content의 URI가 가리치는 위치가 된다는 점을 기억하자. Journal.n3와 JournalEntries.n3라 불리는 디스크 상의 두 개 외부 파일에 링크된 JournalGraph라 부르는 메모리 모델 객체를 정의할 것이다. 이 두 파일은 이 다음에 주목해야 할 파일들이다. 이 파일에 여러분의 온톨로지(프로그래머들이 객체 혹은 도메인 모델을 지칭하는 시맨틱 웹 용어)를 저장하고 있다.

위로

	8 페이지 중 2 페이지