SPARQL 이해

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

SPARQL로 질의 작성하기

그저 여러분의 첫 질의를 작성하려고 이다지도 넘어야 할 산이 많다. 어쨌든 RDF, RDFS, OWL뿐 아니라 손수 질의를 만들 생각이라면 RDF를 표현하는 최상의 방법일 것 같은 터틀 등 생각을 표현하는 많은 기본 내용을 다루었다. 또한 웹에 퍼블리싱할 수 있도록 어떻게 한 데 넣어 온톨로지를 호스팅할 수 있는지 살펴보았고 어떻게 SPAQRL 엔드포인트를 설정할 수 있는지도 살펴보았다.

마침내 팀 정보 관리 및 추적 시스템으로 가보자. 각 질의는 팀 내 커뮤니케이션을 개선하고 자원 관리자가 고객에 대한 헌신에 한 걸음 더 나아가 일에 대한 적절한 직원을 찾는 데 도움을 주기 위해 제공될 것이다. 개발할 질의 목록은 아래와 같다. 점차적으로 SPARQL 질의 언어의 좀 더 복잡한 기능을 점진적으로 이해할 수 있도록 질의 목록이 나열되었다.

1. 날짜 순서로 모든 등록 기재 사항 얻기
2. 주제어로 모든 정보 관리 목록의 메모 얻기
3. 주어진 사용자에 의해 등록된 기능/기술 목록 얻기
4. 요구되는 특정 기능 분야에서 기능을 보유한 모든 사용자 목록 얻기
5. 날짜 범위에서 기록되어 있는 사용자 목록 얻기
6. 팀과 고객의 현재 상황에 관한 질문에 대답하기

SPARAQL에서는 네 가지 서로 다른 형태의 질의(SELECT, ASK, DESCRIBE, CONSTRUCT)를 지원한다. 몇 개 질의를 설명과 함께 각 질의의 타입을 서로 타른 형태로 하여 문법을 바꿔쓴 것, 형태를 바꾼 것, 질의의 목적이 무엇이었는지를 보여줄 것이다. 각각의 이러한 질의 타입은 많은 공통의 특징을 공유한다. 대부분의 경우 SELECT 형식에서 모든 걸 보여주게 될 텐데, 아마도 가장 빈번히 사용되는 질의 타입이기 때문일 것이다.

SELECT 질의 형식은 표준 질의를 형성하는 데 사용된다. 결과는 표준 SPARQL XML 결과 형식으로 되돌아온다. 여기서 다루는 예제 질의의 대부분에서는 SELECT 질의 사용을 필요로 한다. ASK는 구체적인 걸 제공하는 게 아니라 Listing 33에서 보겠지만 예/아니오의 답을 얻는 데 사용된다. DESCRIBE는 온톨로지 영역뿐 아니라 인스턴스 데이터의 영역을 추출하는 데에서도 사용되고, CONSTRUCT는 질의한 그래프의 결과에 기초한 RDF를 생성한다. 이것들은 일반적으로 잘 사용되지는 않지만 다운로드(Downloads)에서 받을 수 있는 예제 코드에서 이 질의들에 대한 예들을 일부 발견할 수 있을 것이다.

이 튜토리얼에서는 공간을 절약하고자 여러분이 전부 다 보고 싶어하지 않는 이상 첫 번째 결과 두 개만 빼고 나머지는 모두 지운다는 규칙을 따르기로 했다. 대부분의 질의는 두 결과보다 더 많다. 반복만 일삼거나 베개로 삼기 좋은 매뉴얼과 책을 싫어한다면 아마도 여러분만 그런 건 아닐 것이다. 이 튜토리얼은 가능한 한 그러지 않으려고 노력했다. 튜토리얼이 반복한 한 가지 영역은 예제 질의의 PREFIX 부분이다. 이 질의들은 곧바로 사용할 수 있어야 하기 때문에 어쨌든 다 갖춰놓을 필요가 있었다. 마우스로 질 폼을 긁어다가 놓으면 바로 동작할 수 있을 것이다.

질의 쪼개기

Listing 22의 질의는 모든 메모 부분을 얻어 날짜 순서로 반환한다. 이 절에서는 전형적인 SPARQL 질의의 문법을 살펴볼 것이다. 다음 절에서는 여러분이 보낸 질의에 대해 일치하는 내용을 발견해내기 위해 트리플이 사용하는 알고리즘에 대해 알아볼 것이다.

                    
PREFIX :   <http://aabs.purl.org/ont/journal#>

SELECT ?notes
WHERE
	{
	?e a :JournalEntry .
	?e :notes ?notes .
	?e :date ?date .
	}
ORDER BY ?date

SPARQL SELECT 질의 각각은 순서대로 여러 부분이 모여 구성된다. 질의는 선택 사항인 BASE 정의부와 그 뒤에 따라 나오는 PREFIX 정의부를 담는 서두로 시작한다. 그러고 나서 SELECT 파트를 담게 되는데, 이 파트는 그 뒤에 선택 사항으로 어디에 있는 그래프를 검색할지 기술하는 DATASET 파트가 따라오면서 SELECT를 구성한다. 그 뒤로 WHERE 절이 오며 이 절에서는 바라는 결과값을 기술하는 그래프 패턴을 담는다. WHERE 절에서 솔루션 변경자(solution modifiers)가 온 후 ORDER 절, LIMIT 절, 또는 OFFSET 절이 온다. 이 변경자들에 대해서는 차후에 각각 설명하도록 한다.

Listing 23에 결과를 보였다.

                    
notes

"Today I wrote some more content for the great new SPARQL tutorial ...

"Today I learnt about insane asylums"

결과 반환 순서를 역으로 바꾸려면 순서 변경자 ASC()나 DESC()를 써서 순서 변경을 선택할 수 있다. 여기에서는 ORDER BY DESC(?date) 하면 결과 순서가 반대로 된다.

날짜 순서도 변경하면서 다른 변수를 써서 순서를 바꾸고 싶다면 ORDER BY 절에 다른 변수를 추가할 수 있다. 이를테면 다음과 같다: ORDER BY DESC(?date) ASC(?notes).

상위 다섯 개로 결과를 한정짓고 싶다면 LIMIT 연산자(operator)를 사용할 수 있다(Listing 24 참조).

                    
SELECT ?notes
WHERE
     {
     ?e a :JournalEntry .
     ?e :notes ?notes .
     ?e :date ?date .
     }
ORDER BY ?date
LIMIT 5

얻어지는 값이 몇 개가 되든 간에 결과 값을 취하기 전에 일부는 버리고 싶다면 OFFSET 변경자를 사용한다(Listing 25 참조).

                    
SELECT ?notes
WHERE
     {
     ?e a :JournalEntry .
     ?e :notes ?notes .
     ?e :date ?date .
     }
ORDER BY ?date
LIMIT 5
OFFSET 150

SQL 개발을 해봤다면 이런 변경자들은 아주 익숙한 것들일 것이다.

위로

트리플 스토어 검색

그래프 패턴을 사용해 결과를 얻는 과정은 꽤 간단하다. 대부분의 트리플 스토어는 주어나 술어 혹은 목적어에 기반을 두여 질의할 수 있는 트리플들의 메모리 혹은 데이터베이스 내의 저장 내용을 관리한다. SPARQL은 이를 질의 그래프 패턴 형식을 통해 한 집합의 트리플로 표현한다. 이런 가정으로 시작해 보자. 딱 하나의 트리플이 그래프 패턴에 있다고 치자. 이 질의는 주어에 대한 구체적인 URI를 제공할지도 모른다. 그렇다면 트리플 스토어는 주어를 갖지 않은 스토어 내의 모든 트리플을 무시할 수 있다. 그러면 남겨진 것들로부터 그래프 패턴에서 공급되지 않은 술어와 일치하지 않은 모든 술어는 빼버릴 수 있다. 그러고 나서 최종적으로 SPARQL이 구체화된 목적어를 공급한다면 일치하지 않는 트리플을 제거하는 데에 사용될 수 있을 것이다.

만약 변수가 질의의 주어나 술어 혹은 목적어 내에서 사용된다면 일치하지 않는 트리플을 제거하는 대신 트리플 스토어는 변수에 대해 이 모두를 잠재적으로 일치하는 것으로 예약해둘 것이다. 위의 예제에서 첫 번째 트리플은 ?e a :JournalEntry .을 읽는다. a는 rdfs:type의 줄임 표현이기에 트리플 스토어는 술어 rdfs:type을 가진 것 말고는 모두 무시할 수 있다. 나머지 중 :JournalEntry의 목적어가 없는 것들을 제거할 수 있다. 남겨지는 것은 주어로서 ?e에 대한 결과가 갖춰질 수 있는 가능한 트리플들이다.

위의 질의는 여러 트리플을 지닌 그래프 패턴을 제공했다. 따라서 트리플 스토어는 변수들을 서로 결합하기 전에 다른 트리플들과 동일한 절차를 따를 필요가 있다. 만약 변수가 여러 장소에서 발견된다면 동일값이 교차하는 모든 트리플을 사용할 수 있다. 위의 예제에서 모든 일치하는 트리플은 하나의 일치하는 주어를 갖는다. 트리플이 여기에 들어맞지 않으면 폐기되며 결과 집합은 남는 모든 트리플이다. 변수를 일치시키는 방법은 여러 가지가 있을지도 모르겠다. 만약 그렇다면 여러 결과를 얻게 될 것이다. 마지막 단계는 트리플 스토어가 결과 집합에서 필요로 했던 해당 변수들에 기반하여 결과 집합을 생성하는 것이다.

검색 끝 부분에서 트리플 스토어는 (?e, ?notes, ?date)를 포함한 결과 집합을 얻는다. 이는 세 가지 내용이 질의 내에 정의된 모든 변수이기 때문이다. 만약 SELECT 질의가 "SELECT ?date ?notes" 같이 이뤄졌다면 ?e는 반환되지 않을 것이다. 질의에서 핵심이어도 말이다.

위에서 기술한 절차는 어떤 일이 벌어지는 추상적인 형태다. 여러 방식으로 속도를 붙여볼 수 있다(예를 들어 한 방에 여러 개를 일치한다든가 하는 식으로). 어쨌든 내부적으로 진행되어야 하는 일 측면에서 보면 사실 다 똑같다.

위로

날짜 순으로 모든 등록 기재 사항 얻기

Listing 22의 질의를 쓰면 각 메모가 간단한 마이크로 블로그 형태의 날짜 순으로 표시되도록 만들 수 있다. 그게 거기서 하는 전부다. 이 질의는 동일한 형태를 따르며, 날짜 순으로 모든 등록 기재 사항 목록을 얻을 수 있게 해준다. 신규 프로젝트를 진행하기 위해 팀을 꾸리려 할 때 등록된 직원들을 걸러낼 수 있도록 하는 데 필수적인 질의다.

Listing 26에서는 EmployeeBooking, Customer, User와 같은 몇 개의 클래스들로부터 데이터를 조인(join)해야 함을 보여주고 있다. SQL은 두 테이블 간의 조인을 표현하는 데 꽤나 귀찮은 문법을 갖고 있다. SPARQL은 고맙게도 그렇지는 않다. 이런 종류의 조인을 하는 데에 딱 들어맞게 되어 있어 아주 쉽다. 돌려줄 필요가 있는 각 클래스로부터 모든 속성을 정의하는 그래프 일치 패턴을 정의할 필요가 있다. 트리플 세계에서 조인이란 그저 또 다른 트리플일 뿐이다. Listing 26에 질의를 나타내었다.

                    
PREFIX u:   <http://aabs.purl.org/ont/users#>
PREFIX j:   <http://aabs.purl.org/ont/journal#>
PREFIX b:   <http://aabs.purl.org/ont/avail#>

SELECT ?dn ?custName ?startDate ?endDate 
WHERE
{
?booking a b:EmployeeBooking ;
  b:startDate ?startDate ;
  b:endDate ?endDate ;
  b:employee ?dl ;
  b:with ?cust .
?cust a b:Customer ;
  b:name ?custName .
?emp a u:User ;
  u:domainLogin ?dl ;
  u:displayName ?dn .
}
ORDER BY ?startDate

시작 부분에서 각각 세 개의 이름 공간을 나타내는 PREFIX를 정의한다. 각각 사용자(users)를 뜻하는 u, 정보 관리(journals)를 뜻하는 j, 등록 기재(bookings)를 뜻하는 b다. 그러고 나서 조세키에게 변수 ?dn, ?cusName, ?startDate, ?endDate에 대해 일치하는 내용에 관심이 있음을 알려준다. ?dn은 '표시 이름(display name)'을 줄여 쓴 것일 뿐이고 질의 후에 뭘 담을지를 나타낸다.

기본 그래프 패턴에서 등록 기재 사항(?booking), 시작 날짜와 종료 날짜(각각 ?startDate와 ?endDate)를 정의한다. 지금 이야기하고 있는 건 타입 b:EmployeeBooking의 그래프에서 정의된 몇 개의 인스턴스가 있다는 것이다. 타입 b:EmployeeBooking 중 일치하는 걸 발견할 때마다 타입 b:startDate와 b:endDate의 속성을 갖고 있을 것이다. 일치하는 것들은 변수 ?startDate와 ?endDate로 넣어질 수 있을 것이다.

질의 결과 정의에서는 직원의 u:displayName과 이 직원과 함께했던 고객의 b:name을 얻어야만 한다고 언급하고 있다. 질의는 정확한 일치 내용을 얻기 위해 이 속성이 누구인지 혹은 무엇인지 정의해야 한다. 그러므로 ?emp와 ?cust 인스턴스와 이 인스턴스의 속성을 정의한다. 질의는 등록 기재, 사용자, 고객 클래스의 인스턴스를 서로 잇는 트리플을 소개하기 위해 서로 링크할 필요가 있다. EmployeeBooking은 특정 사용자 인스턴스에 연결하기 위해 b:employee 객체 속성을 갖는다. 또한 Customer 클래스에 링크하는 b:with 속성을 갖는다.

'b:with ?cust' 트리플을 추가하는 것으로서 (주어는 여전히 ?booking이라는 점을 기억하자) ?booking에 대해 반환된 결과에 일치하는 ?cust에 대한 결과를 원한다는 것을 SPARQL에게 이야기하고 있다(표 1 참조). 이는 SPARQL에서 조인이다. 동일한 내용이 :User 클래스에 적용된다.

조인이 얼마나 쉬운지 알겠는가? 그저 두 클래스의 인스턴스 간에 관계가 있다는 것만 언급하면 되고 SPARQL은 그런 관계가 어디에 존재하는지에 대해 일치 내용만 반환한다.

위로

모든 사용자 얻기(직원들)

이번 질의는 전에 했던 것과 꽤나 비슷하다. Listing 27에 보인 질의는 단일 온톨로지로부터 URI를 다루므로 기본 PREFIX를 사용한다. 클래스와 객체 속성에 대한 URI를 가정할 수 있기 때문에 콜론(:)으로 접두사를 붙일 수 있다.

                    
PREFIX :   <http://aabs.purl.org/ont/users#>

SELECT DISTINCT ?dl ?dn
WHERE {
  ?u a :User ;
    :domainLogin ?dl ;
    :displayName ?dn .
}
ORDER BY ?dn

표 2에서 Listing 27의 질의에 대한 결과를 보였다.

위로

주제어로 걸러진 모든 정보 관리 목록의 메모 얻기

회사 내에서 다른 직원들에 대한 서비스로서 저자가 정보 관리 목록에 붙인 태그에 기반하여 정보 관리 목록을 모아둘 수도 있을 것이다. 이렇게 하면 RDF의 흐름에 흠뻑 취해볼 수 있고, 말하자면 혹은 자바 개발에도 한 번 빠져볼 수도 있다. RDF 관련 작업이 어떻게 진행중인지 알고 싶은 관심많은 독자라면 이런 추세를 잘 파악해볼 수도 있겠다.

이번 질의는 흥미로운 데 FILTER 키워드를 소개할 것이기 때문이다. FILTER는 일치 변수의 속성을 정의하는 데에 표현에 기반을 둔 방식을 제공한다. 이번 질의에서 이것을 써서 메모 내에 SPARQL이라는 단어를 갖고 있는 것만 가리키는 데에 사용해볼 것이다.

Listing 28에서 모든 정보 관리 목록을 얻는 질의는 그저 메모 내의 용어를 얻는 것이다. 텍스트에 빠져 허우적대고 싶어하진 않을 것이다. 이는 FILTER 키워드를 사용하는 첫 번째 질의다. FILTER는 일치하는 결과의 속성을 정의하기 위해 비 그래프 지향적인 방법을 제공한다. 아래 예제에서는 SPARQL이라는 낱말을 담고 있는 목록을 찾고자 정규 표현식을 사용하고 있다.

                    
PREFIX :   <http://aabs.purl.org/ont/journal#>

SELECT ?notes
WHERE
	{
	?e a :JournalEntry .
	?e :notes ?notes .
	FILTER regex(?notes, "today")
	}
ORDER BY ?date

이 질의에서는 기본 이름 공간에 대한 접두어로 콜론(:)을 사용한다. 질의는 하나 이상의 온톨로지에서 정의된 개체를 참조하지 않는다. 따라서 술어와 타입의 의미에 혼동의 여지는 없다. FILTER 표현에서는 SPARQL이라는 낱말을 담고 있는 정보 관리 목록을 가리키고자 정규 표현식을 사용한다. Listing 29에서 두 개의 결과를 보였다.

                    
notes

"Went to work on the SPARQL tutorial today. I seem to have a terminator
fixation."

"Today I wrote some more content for the great new SPARQL tutorial that
I've been preparing. I used some Turtle, and I defined a simple
ontology for defining journal entries. This is an example of one of
those entries!"

정규 표현식에는 사용될 수 있는 함수와 연산자가 아주 많다. 정규 표현식은 XPath와 XQuery 시스템에서 차용되었다. FILTER 표현은 삽입사, 접두사 형태의 연산자 그리고 소괄호 형태의 삽입구 등 일반적인 문법을 지원하며 따라서 Listing 30과 같은 형태처럼 쓰일 수 있다.

                    
  FILTER (?t = "RDF" || ?t = "OWL" || ?t = "cash")

  FILTER (
    (?start > "2008-03-05T09:00:00"^^xsdt:dateTime && 
     ?start < "2008-03-07T09:00:00"^^xsdt:dateTime)||
    (?start < "2008-03-05T09:00:00"^^xsdt:dateTime && 
     ?end >  "2008-03-05T09:00:00"^^xsdt:dateTime)
  )
  

연산자, 함수, 타입 호환성에 대해 자세한 내용을 보려면 SPARQL 문서를 참조하기 바란다.

위로

요구되는 기능을 보유한 모든 사용자 목록 얻기

팀을 꾸릴 때(튜토리얼 예제를 위해), 여러분이 데려다 쓸 기술적으로 기능을 보유한 사람들이 누구인지 그 목록이 필요할 것이다. 이들이 누구인지 검색하려면 찾고자 하는 모든 기능이나 기술 그리고 각 기능에 대해 일치하는 사람이 누구인지 찾아내는 방법을 알 필요가 있다. 이 질의에는 UNION 연산자가 사용된다는 점에서 흥미롭다. UNION을 쓰면 각기 분리된 질의의 결과를 한 데 합칠 수 있게 해준다. 여러분은 각 기술에 대한 개개의 질의를 한 데 합치는 데 이를 사용하게 될 것이다.

이번 예제에서는 RDF나 OWL 또는 SPARQL을 이용해 태깅된 정보 관리 목록을 쓴 모든 사용자의 표시 이름을 얻는다. UNION 연산자를 쓰면 그래프 패턴을 번갈아서 결과를 합칠 수 있다.

일반적으로 모든 그래프 패턴은 결과가 반환되기 전에 일치시켜야 한다. UNION을 이용한다면 어떤 서브 그래프 패턴의 결과라도 충분하다. Listing 31의 질의에서 {?e j:tag "RDF".}, {?e j:tag "OWL".}, 혹은 {?e j:tag "SPARQL".} 중 어떤 것이든 결과가 받아들여질 수 있도록 일치시킬 수 있다. 이는 OR 연산자와 동등하며 짧게 말한다면 || 연산자가 어떻게 동일한 효과를 수행할 수 있는지 알게 될 것이다.

                    
PREFIX u:   <http://aabs.purl.org/ont/users#>
PREFIX j:   <http://aabs.purl.org/ont/journal#>

SELECT DISTINCT ?dn
WHERE
{
?u a u:User;
  u:displayName ?dn .
?e a j:JournalEntry;
  j:user ?u .
  {
    {?e j:tag "RDF".} UNION 
    {?e j:tag "OWL".} UNION 
    {?e j:tag "SPARQL".}
  }
}

보통은 작업하는 온톨로지의 이름 공간을 정의하고 관심있는 변수를 정의한다. 그리고 나서 일치시키길 원하는 사용자의 속성을 정의한다. 이번 경우에서는 조인하고자 하는 두 인스턴스를 정의한다(사용자에 대해서는 ?u, 정보 관리 목록에 대해서는 ?e). 이 둘을 조인하기 위해 정보 관리 목록에서 j:user 속성을 기술한다. 인스턴스와 둘의 관계가 정의된 후 정보 관리 목록에 붙은 태그들에 일치시킨 것들을 서로 합친 또다른 그래프 패턴이 소개된다(표 3 참조).

똑같은 질의를 표현하는 또 다른 방법이 있다면 FILTER를 사용하는 것이다.

Listing 31의 간단한 질의는 정보 관리 인스턴스와 사용자 클래스 인스턴스를 조인하는 것이다. 이번 질의(Listing 32)에서는 트리플 패턴 <?e j:tag "RDF">의 객체로서 문자열 상수를 소개한다. 의미는 상당히 명확해야 하겠지만 튜토리얼 초반부에서 RDF와 터틀의 소개 부분을 보지 않았다면 지금이 적기다.

                    
PREFIX u:   <http://aabs.purl.org/ont/users#>
PREFIX j:   <http://aabs.purl.org/ont/journal#>

SELECT DISTINCT ?dn
WHERE
{
?u a u:User;
  u:displayName ?dn .
?e a j:JournalEntry;
  j:user ?u ;
  j:tag ?t .
  FILTER (?t = "RDF" || ?t = "OWL" || ?t = "SPARQL")
}

FILTER의 논리적 의미는 위의 질의에 기반을 둔 UNION과 꼭 같다. 다만 다중 그래프 패턴의 의미에 아직 익숙하지 않다면 이해하기엔 더 쉬울지도 모르겠다.

위로

주어진 날짜에 어떤 직원이 고객과 시작했는지 여부

여러 질의에 대해 데이터의 개요를 얻을 필요가 있거나 혹은 광범위한 질문, 이를테면 "이번 주에 누군가가 X에서 일하게 하나요?"와 같은 물음에서 예/아니오 답변을 주는 것도 있다. SPARQL은 ASK 질의 타입을 사용하여 이런 류의 질문에 대한 해답을 제공할 수 있다.

Listing 33에 보인 질의는 3월 18일에 IBM에서 누군가가 일을 시작하는지 여부를 질의한다. 그게 누군지는 상관없고 그저 여부만 알고 싶을 뿐이다.

                    
PREFIX b: <http://aabs.purl.org/ont/avail#>
PREFIX u: <http://aabs.purl.org/ont/users#7>
PREFIX xsdt: <http://www.w3.org/2001/XMLSchema#>
 
ASK
{
  ?x a u:User;
    u:displayName ?dn;
    u:domainLogin ?dl.
  ?c a b:Customer;
    b:name "IBM".
  ?b a b:EmployeeBooking;
    b:with ?c;
    b:employee ?dl;
    b:startDate "2008-03-18T09:00:00"^^xsdt:dateTime.
}

ASK 질의는 단지 결과 발견 여부만을 반환한다. 따라서 필요없는 반환 데이터를 줄여 대역폭을 아껴준다. 질의 형식은 SELECT와 비슷하다. 다만 변수가 반환되지 않기에 반환 변수를 정의하지 않는다. 대신 질의는 질의(만약 질의가 SELECT 였다면)가 반환되는 데이터를 갖고 있는지 여부를 가리키는 참 혹은 거짓을 반환할 것이다(Listing 34 참조).

                    
ASK => true

이 질의들을 예제로서 사용하여 이제는 SPARQL에 대해 좀 더 확고한 내실을 다지게 되었을 것이다. 깊게 내용을 다룰 수는 없었지만 정보 관리 예제에서 데이터를 가져오는 다양한 방법을 다룬 질의를 담은 예제 코드들을 다운로드 부분에서 받을 수 있으니 살펴보기 바란다.

위로

	8 페이지 중 3 페이지