W3C에 Library Linked Data Incubator Group 런치!

지난 5월 21일 W3C의 인큐베이터 그룹으로 Library Linked Data Incubator Group이 결성되었습니다.

Library Linked Data Incubator Group의 주요 목적은 시맨틱웹 – 특히, Linked Data의 기술을 이용하여 시맨틱웹 환경에서 도서관 데이터의 상호운용성(interoperability)을 증진시키기 위한 것입니다. 이를 위해 관련 분야에 종사하는 사람들이 모여서 협력활동을 통해 해결해야할 주요 이슈들을 정리하고, 관련 표준화 작업을 진행하며, Best Practice를 만들고 전파하는 일을 하고자 하는 것입니다.

시맨틱 웹은 정보는 넘쳐나지만 무질서와 혼돈의 세계인 이전의 문서웹(document web 즉, web 1.0)에서 정보에 그 의미를 태깅(RDF를 통해)하고, 의미가 부여된 링크를 통해 연결된 웹(linked data web)을 추구합니다. 데이터가 의미적으로 상호 호환되기 위해(semantic interoperability) 공통의 어휘(common vocabularies)와 공통의 데이터 모델(또는 스키마, 메타데이터)가 필요합니다. 이 부분은 전통적으로 도서관의 전문 분야이지요. 따라서 시맨틱 웹의 입장에서는 데이터의 유연하고도 일관된, 질서정연한 유통을 위해 이제까지 축적되어 온 도서관의 전문성(메타데이터 모델, 데이터의 품질관리, 라이센스 문제 등)과 지식체계(시소러스, 통제어휘, 전거파일, 분류체계 등)를 시맨틱 웹에서 활용할 필요성이 제기됩니다.

또 Linked Data의 확산을 위해서 매우 중요한 지적 공유재산인 도서관 데이터를 Linked Data화 할 필요가 있습니다. 이제까지 도서관 안에서만 구축되어 온 도서관 데이터의 네트워크를 (시맨틱)웹으로 오픈하고 도서관 외부의 데이터와 연계함으로써, 서지 목록의 상호 교환 뿐만 아니라 다양한 컨텍스트에서 활용할 수 있도록 하는, 도서관 내부에서 제기되는 필요성과도 맞물린다고 생각됩니다.

아래에
Library Linked Data Incubator Group의 주요 멤버와 활동 범위를 옮겨보겠습니다(Library Linked Data Incubator Group Charter 참조)
[주요 멤버]

[활동 범위]

  • Gathering use cases and case studies demonstrating successful implementation of Semantic Web technologies in libraries and related sectors
  • Fostering collaboration among actors (libraries, museums, archives, publishers) interested in porting cultural assets to the Linked Data Web
  • Identifying relevant data models, vocabularies and ontologies and ways to build or improve interoperability among them
  • Identifying the need for the elaboration of new standards, guidelines & best practices
  • Identifying the areas of (Semantic) Web technology that could benefit from the expertise of the communities represented in the Group
  • Proposing a relevant scope and organization for work that follows on the initial effort carried by the Group.

아울러서, 이미 Linked Data로 런칭한 도서관 분야의 주요 프로젝트 두개를 소개합니다.

1. LCSH – Library Congress
2. LIBRIS – National Library of Sweden


시맨틱 웹, 그리고 링크드 데이터

링크드 데이터는 2006년 웹의 창시자이자 시맨틱웹의 창시자인 Tim Berners-Lee의 Linked Data Design Issue(http://www.w3.org/DesignIssues/LinkedData.html)를 통해 처음 소개되었다. 2009년을 거치면서 몇몇 성공적인 링크드 데이터 구축사례를 통해 (특히, data.gov.uk의 덕분에) 매우 급속하게 시맨틱 웹 진영에 퍼지게 되었고, 아마도 링크드 데이터의 실현이 시맨틱 웹이라는 기술의 성공 여부를 가늠하게 될 것 같다.
그런데, 시맨틱 웹도 잘 모르는데 링크드 데이터라니? 게다가 심심치 않게 데이터 웹, 또는 Web of Data라는 용어까지 등장한다. 각각의 개념과 그 관계를 어떻게 정리할 수 있을까?

2001년에 Tim Berners-Lee, Ora Lassila, 그리고 Jim Hendler가 쓴 유명한 시맨틱웹에 관한 논문 “The Semantic Web”(Scientific American, May 2001)에서 시맨틱웹은 다소 이상적으로 보인다. 데이터의 의미를 알아서 해석하고 이에 따라 자동화된 처리를 알아서 수행하는 웹 에이전트로 그려지는 시맨틱 웹에 대한 개념은 매우 추상적이다. RDF라는 시맨틱웹 표준은 데이터베이스 라는 관게형 데이터 모델에 갇혀 있는 사람들에게 그래프 모델의 확장성과 다양한 데이터의 통합 능력이라는 장점을 이해시키기 어려웠고, 다른 한편으로는 OWL이 가지는 추론 능력에 대한 지나친 기대가 오히려 시맨틱웹은 너무 어렵다는 인상을 낳게 했다.

그런 상황에서 맨 처음 시맨틱웹을 주창했던 Tim Berners-Lee를 비롯한 연구자들은 시맨틱웹이 가진 원래의 목적과 장점을 부각시킴으로써 어떻게 시맨틱웹을 현실화 시킬 것인가 고민했고, 그 대안으로서 Linked Data를 제시한 것이다.

[시맨틱웹은 연결된 데이터(linked data)의 웹이다]

Linked Data Design Issue에서 밝힌 Linked Data의 네가지 원칙을 보면 Linked Data란 무엇인지 파악이 가능하다.

‘Linked Data’의 네가지 원칙

1. 개체를 식별하기 위해서 URIs(Unique Resource Identifiers)를 사용한다.
2. 이들 개체가 이용자에 의해 참조하거나 참조되기 위해 HTTP URIs를 사용한다.
3. URI가 참조되었을 때 그 개체에 대한 유용한 정보를 제공한다.
4. 웹상에서 관련 있는 다른 정보를 발견하기 위해 데이터 내에서 다른 개체로의 링크를 포함한다.

즉, 실세계의 사물(thing)에 대응되는 웹 상의 개체(entity)에 URI를 부여하고 이에 대한 디스크립션(메타데이터, 또는 설명)을 기술한 후, HTTP를 통해 접근할 수 있도록 발행함으로써 HTTP URL과 유사한 방식으로 URI에 대해 “http://~~~”라고 웹에서 요청(request)을 보내면 해당하는 유용한 정보를 리턴하는 것이다.

곧, 이전의 웹에서의 HTML document -> RDF data 로, URL -> URI 로, 단순 링크는 다양한 의미적 속성(property)를 가진 링크로 바뀐 것이다. 이렇게 HTML이라는 문서가 아니라 RDF라는 형식으로 된 데이터는 그 의미를 구별하게 됨으로써(HTML 태그가 아니라 RDF 디스크립션을 통해서), 기계가 이해가능한(machine-readable) 데이터가 되는 것이다.

“시맨틱웹은 단지 데이터를 웹으로 제공하는 것이 아니라, 데이터 간의 링크를 만듦으로써, 인간이나 기계 모두 데이터의 웹을 탐험할 수 있도록 해준다. Linked data를 통해 유용한 데이터를 얻게 되면, 그 데이터에 관계된 데이터로 계속되는 항해가 가능하다.” – Tim Berners Lee, Linked Data Design Issue

TBL의 동료이자 data.gov의 시맨틱 웹 프로젝트(http://www.data.gov/semantic/index)를 이끌고 있는 Jim Hendler의 블로그 포스트(http://blogs.nature.com/jhendler/2010/06/01/linked-open-government-data-and-the-semantic-web)에서 Jim은 시맨틱 웹의 목적은 “현재의 문서 웹과 유사한 ‘데이터의 월드 와이드 웹’을 만들기 위해 웹 상의 데이터베이스들을 서로 연결(link)시킬 수 있는 시스템을 만드는 것”이라고 분명히 밝히고 있다. 그러므로, 링크드 데이터는 원래의 시맨틱 웹의 목적인 “데이터의 웹”을 실현하기 위한 더욱 구체화된 방법이고, 수단이며, 기술이다.

링크드 데이터 < 데이터의 웹 <= 시맨틱 웹?


지난 SemTech 2009에서 Alexandre Passant[1]가 발표한 자료에서는 다음과 같은 그림을 통해 이들 간의 관계를 설명한다. 데이터의 웹은 시맨틱 웹과 정확히 일치하는 같은 개념은 아니며, 포함관계로 설명할 수 있다. 앞에서 말했듯이 링크드 데이터는 데이터의 웹을 구현하기 위한 기술이며, 방법으로서 그 구성요소라고 할 수 있다.

데이터를 기계가 이해가능하도록 RDF화 하고 공통의 어휘(common vocabularies- 예를 들어, SKOS, DBPedia, FOAF 등)이용해 데이터를 디스크립션하고,서로 연결(link)한다. 웹으로 발행함으로써 데이터를 웹에 공개한다. 이러한 링크드 데이터 원칙에 따라 Linked Open Data(LOD, 즉, data cloud)가 형성된다. 이것이 바로 데이터가 거미줄처럼 얽히는 (시맨틱) 데이터의 웹 세상이다.

이러한 데이터의 웹 세상이 되면 내가 만든 데이터 뿐만 아니라 남이 만든 데이터도 링크를 통해 재사용이 가능하다. 따라서 다양한 데이터를 융합한 새로운 데이터를 쉽게 만들어 낼 수 있다(mashup). 이렇게 융합된 데이터는 또다시 웹을 통해 공개되고 발행된다. 이것이 바로 시맨틱 웹이 꿈꾸는 디지털 데이터의 생태계이고 유통환경이다. 그러한 시맨틱 데이터의 생태계가 조성된다면, 한편에서는 시맨틱 데이터를 이용해서 기계와 기계 간의 데이터가 자유롭게 교환되고, 온톨로지 및 규칙 기반의 추론을 통해 그 의미가 해석되고 처리됨으로써 자동화된 서비스로 우리에게 제공되는 궁극적인 시맨틱 웹 세상, 진정한 유비쿼터스 세상이 도래하지 않을까?

[references]

1. Tim Berners-Lee, “Design Issues: Linked Data“, 2006, http://www.w3.org/DesignIssues/LinkedData.html
2. Tom Heath, “Linked Data? Web of Data? Semantic Web? WTF?http://tomheath.com/blog/2009/03/linked-data-web-of-data-semantic-web-wtf/
3. Passant, Alexandre, Tummarello, “Hello, Open Data World!”, Giovanni SemTech 2009, T2_MON_0830_Passant_Alexandre_Tummarello_Giovanni_Color.pdf
4. Jim Hendler, “Linked Open Government data and the Semantic Web”, http://blogs.nature.com/jhendler/2010/06/01/linked-open-government-data-and-the-semantic-web


Open, Linked Data for a Global Community: Berners-Lee at Gov 2.0 Expo 2010

Gov 2.0 Expo 2010에서 Tim Berners-Lee의 Linked Data에 대한 발표가 있었습니다.


SKOS의 Integrity Constraints에 적용해 본 OWL2와 SPIN의 비교

SKOS의 Integrity Constraints를 OWL2와 SPIN으로 구현해 봄으로써 장단점을 비교한 Paul Herman의 블로그 포스트를 관련 블로그들과 함께 정리한 것입니다. (여러 포스트들을 하나로 정리하다 보니 좀 길어졌네요.^^;;;)

SKOS(Simple Knowledge Organization System)

SKOS는 시소러스(Thesaurus), 통제 어휘(Controlled Vocabulary), 택소노미(Taxonomy), 분류 체계(Classification Scheme)과 같은 지식어휘체계를 시맨틱 웹을 통해 공유하고 서로 연결하는 공동 데이터 모델입니다. SKOS가 RDF(Resource Description Framework)에 기반하고 있기 때문에 SKOS로 표현된 지식어휘체계는 기계가 이해 가능하고(machine-readable), 소프트웨어 어플리케이션 간에 상호호환이 가능(interoperable)하며 웹으로 발행(publishing)이 가능합니다. 2005년 W3C Draft로 제정되었고, 2009년 8월 W3C Recommandation이 되었습니다.

SKOS는 URI를 사용해서 개념(concepts)들을 정의하고 label에 관한 property를 통해 표제어를 기술하며, 다양한 note를 기록하고 개념들 간의 시맨틱 관계를 기술(description)할 뿐만 아니라 concept scheme를 기술함으로써 여러 지식어휘체계를 통합할 수 있는 기능을 제공합니다.
(더 자세한 내용은 W3C의 SKOS 홈페이지(http://www.w3.org/2004/02/skos/)를 참고하세요)

SKOS의 Integrity Constraints

SKOS 스펙에는 S1부터 S62까지의 클래스, 프로퍼티 정의 및 무결성 제약 조건(Integrity Constraints) 목록이 있고, 이 중 대부분은 SKOS OWL1(OWL Full 버전이나 OWL DL 버전으로 기술이 가능합니다. 그러나 이중 몇 가지는 OWL 1으로 표현이 어려운데, 다음과 같은 것들입니다.

  • S13: skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties .
  • S14: A resource has no more than one value of skos:prefLabel per language tag .
  • S27: skos:related is disjoint with the property skos:broaderTransitive.
  • S46 : skos:exactMatch is disjoint with each of the properties skos:broadMatch and
    skos:relatedMatch .
  • S55: The property chain (skosxl:prefLabel, skosxl:literalForm) is a sub-property of
    skos:prefLabel.
  • S56: The property chain (skosxl:altLabel, skosxl:literalForm) is a sub-property of
    skos:altLabel.
  • S57: The property chain (skosxl:hiddenLabel, skosxl:literalForm) is a sub-property of
    skos:hiddenLabel.
  • S58: skosxl:prefLabel, skosxl:altLabel and skosxl:hiddenLabel are pairwise disjoint
    properties .

그렇다면 이것들이 최근(2009년) W3C의 제안 권고안이 된 OWL2로는 표현이 가능한가 하는 것이 문제의식의 시작입니다.

Paul은 다음 4가지 경우에 대해 OWL2와 SPIN을 적용, 비교했습니다.

1) S14

S14: A resource has no more than one value of skos:prefLabel per language tag.
“리소스는 skos:prefLabel에는 각 언어 태그 당 하나의 값만을 가져야 한다”는 제약조건 입니다.

예를 들어,

:Concept1 skos:prefLabel "love"@en ;
         skos:prefLabel "adoration"@en .

는 유효하지 않습니다(not valid).

이 제약조건의 유효성을 검사하기 위해 OWL1이나 OWL2를 사용하는 것은 적절하지 않습니다. 왜냐 하면, 이 모델링 언어는 유효성검사(validation)보다는 추론에 초점을 맞추고 있기 때문입니다.
(note: 특히, OWA(Open World Assumption)을 전제로 한 OWL 모델링에서는 어떤 명시(assertion)가 논리적으로 올바르지 않다고 해도 단지 더 이상의 추론을 만들지 않을 뿐, 특별히 에러를 발생시키지는 않습니다.)

그러면 SPIN을 여기에 적용해 볼까요? SPIN은 TopQuadrant의 Holger Knoblouch가 만든 것으로, SPARQL을 이용해서 시맨틱웹 데이터에 대한 제약조건과 추론 규칙을 정의하는 RDF Vocabularies입니다.
(note: SPIN은 TopBraid Composer에서 사용가능하고, SPIN API오픈 소스 Java API로도 사용가능합니다.)

SPIN에서 Boolean 값을 리턴하는 SPARQL ASK 쿼리를 이용하여 false이면 제약조건이 유효(no validation)하고, true이면 제약조건에 위배됨을 검사할 수 있습니다.
이러한 제약조건은 class에 대해 spin:constraint 프로퍼티에 대한 값으로 기술됩니다.

위의 S14 제약조건은 다음과 같은 SPARQL 쿼리로 만들 수 있습니다 :

ASK
{
   {SELECT ?lang (count(?lang) as ?nr )
   WHERE
      {?subject skos:prefLabel ?label .
       LET (?lang := lang(?label))}
    GROUP BY ?lang}
    FILTER (?nr > 1)
}

이 쿼리에서 사실 “count” 기능은 SPARQL 1.0에서는 제공되지 않고 SPARQL 1.1에 포함될 것으로 예상되고 있습니다.(다행히 Jena의 ARQ에서 이미 구현되어 있습니다.)

이 쿼리에 따라서 같은 언어태그를 가진 prefLabel을 하나 이상 입력하면 에러를 발생합니다.(TopBraid Composer에서의 테스트 결과는 Paul의 관련 포스트에서 확인하세요.)

C&P(Clark & Parsia)의 접근방법

Pellet ICV0.4는 Pellet Integrity Constraint Validator로 CWA(closed world assumption)을 이용, RDF 인스턴스 데이터에 대한 유효성 검사를 하는 툴입니다. Pellet ICV에서 제약 조건은 OWL 악시옴으로 표현되고 유효성 검사기는 이것들을 이해해서 SPARQL 쿼리로 생성해낸다고 합니다.
(따라서 OWL을 링크드 데이터를 위한 유효성 검사 언어로 사용가능하다고 합니다 블로그 포스트에 따르면 Pellet ICV를 SKOS 데이터의 유효성 검사에 이용할 수 있고, 이후 ICV 엔진은 PelletDb로 릴리즈된다고 합니다. )

C&P의 블로그 포스트에 따르면 S14는 OWL IC(integrity contstraint)로 표현이 불가능하다고 합니다. 대신 Pellet ICV는 제약 조건들을 SWRL로 핸들링 할수 있고 built-in function으로 확장, 사용이 가능하다는 대안을 제시하고 있습니다.

2) S13

S13:skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.
skos:prefLabel, skos:altLabel 와 skos:hiddenLabel은 각 쌍이 서로 소(disjoint)이어야 한다는 제약조건입니다.

즉,

<skos:Concept rdf:ID="Concept_1">
   <skos:altLabel xml:lang="en">test</skos:altLabel>
   <skos:prefLabel xml:lang="en">test</skos:prefLabel>
   <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"<
>Concept_1</rdfs:label></skos:Concept>

이러한 예는 허용되지 않는다는 규약입니다.

Paul은 이 제약조건에 대해 OWL1, SPIN, OWL2 DL, Pellet ICV로 각각 테스트했습니다.

OWL1

OWL1은 서로소인 프로퍼티가 동시에 같은 개체(individual, 또는 인스턴스)에 연결되면 무결성이 위배된다는 것을 명시하기 위한 도구를 제공하지 않습니다.

SPIN

위의 제약 조건을 ASK 쿼리를 이용하여 표현해 보면 다음과 같습니다.

ASK
WHERE {
   OPTIONAL {?subject skos:prefLabel ?pref.}
   OPTIONAL {?subject skos:altLabel ?alt.}
   OPTIONAL {?subject skos:hiddenLabel ?hidden.}
FILTER (?pref = ?alt || ?alt = ?hidden || ?pref = ?hidden)
}

그리고 skos:Concept 클래스에 spin:constraint로 바꾸어 보면

ASK 
WHERE {
   OPTIONAL {
      ?this skos:prefLabel ?pref .
   } .
   OPTIONAL {
      ?this skos:altLabel ?alt .
   } .
   OPTIONAL {
      ?this skos:hiddenLabel ?hidden .
   } .
FILTER (((?pref = ?alt) || (?alt = ?hidden)) || (?pref = ?hidden)) .
}

이렇게 되고, TopBraid Composer에서 SPIN 제약 조건에 따라 에러를 발생시킵니다.
.(TopBraid Composer에서의 테스트 결과는 Paul의 관련 포스트에서 확인하세요.)

OWL2

OWL2에서는 프로퍼티간에 상호 배타적임을 기술하는 DisjointPRoperties라는 새로운 구성자(construct)를 제공합니다. 이 서로소 프로퍼티 악시옴은 ObjectProperties나 DataProperties에 대해서는 쌍으로 서로소임을 기술할 수 있지만 annotation properties에 대해서는 제공되지 않습니다. :prefLabel, skos:altLabel and skos:hiddenLabel는 annotation properties이므로 OWL2로는 제약조건을 만들 수가 없는 거죠.

어쨌든 (위의 문제를 무시하고) 다음과 같은 악시옴을 사용한다면,

<owl:AnnotationProperty rdf:about="http://www.w3.org/2004/02/skos/core#altLabel">
    <owl:propertyDisjointWith rdf:resource="http://www.w3.org/2004/02/skos/core#prefLabel"/>
    <rdfs:comment xml:lang="en">skos:prefLabel, skos:altLabel and
 skos:hiddenLabel are pairwise disjoint properties.</rdfs:comment>
    <rdfs:label xml:lang="en">alternative label</rdfs:label>
    <skos:definition xml:lang="en">An alternative lexical label for a resource.</skos:definition>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>
    <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
    <skos:example xml:lang="en">Acronyms, abbreviations, spelling variants, and irregular plural/singular forms may be included among the alternative labels for a concept. Mis-spelled terms are normally included as hidden labels (see skos:hiddenLabel).</skos:example>
</owl:AnnotationProperty>

아래의 데이터에 대해,

<skos:Concept rdf:about="http://ec.europa.eu/esco/S13#Concept_1">
    <skos:prefLabel xml:lang="en">aaa</skos:prefLabel>
    <skos:altLabel xml:lang="en">aaa</skos:altLabel>
    <skos:hiddenLabel xml:lang="en">aaaaa</skos:hiddenLabel>
     <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
    >Concept_1</rdfs:label>
</skos:Concept>

OWL2 DL 추론기에서 어떤 결과가 나오는지 보도록 하겠습니다.

Pellet 2(pellet2.1.0)

Consistent: No
Reason: null

라는 결과를 얻게 되고, skos:altlabel을 ‘aaaa’로 바꾸게 되면

Consistent: Yes

라는 결과가 나옵니다.

어쨌든 결론은 OWL2 DL 추론기라면 Annotation properties에 대해 DisjointProperty 악시옴을 쓸 수 없다는 warnining이 나와야 하는데 추론기가 그것을 걸러주지 못하는 문제가 있습니다.

Pellet ICV

다음과 같은 제약조건 파일을 만들어서 실험해보았습니다.

skos:altLabel a owl:AnnotationProperty .
skos:hiddenLabel a owl:AnnotationProperty .
skos:prefLabel a owl:AnnotationProperty .

[ ] a owl:AllDisjointProperties ;
    owl:members (skos:prefLabel skos:altLabel skos:hiddenLabel) .

pellet icv 0.4로 다음의 데이터를 테스트 했습니다.

[] a owl:Ontology ;
           owl:imports <http://www.w3.org/TR/skos-reference/skos.rdf/>.
      <Test_1> a test:Thing.
      <Test_1> skos:prefLabel "test"@en; 
                           skos:altLabel "test"@en; 
                           skos:hiddenLabel "test"@en.

그러면 다음과 같은 제약 조건 위배라는 결과를 얻을 수 있습니다.

Validating 3 integrity constraints
Will stop after 1 constraint violation(s) are found
Validating constraint: disjointProperties prefLabel altLabel hiddenLabel
Constraint violated : Yes
Violating individuals (1): Test_1,
Number of constraint(s) violated: 1

하지만 저자의 말로는 작은 이런저런의 버그로 인해 약간의 매끄럽지 않은 부분이 있다고 합니다.

3) S27

S27: skos:related is disjoint with the property skos:broaderTransitive.
skos:related는 skosboraderTransitive와 서로소(disjoint)이여야 한다는 제약조건입니다.

OWL2

OWL1 은 클래스의 disjointness를 기술할 수 있는 수단을 제공하지 않습니다. 그러나 OWL2는 object properties 및 data properties 간의 서로소를 기술할 수 있도록 합니다.

제약 조건 S27는 다음과 같이 기술이 가능합니다.

<rdf:Property rdf:about="http://www.w3.org/2004/02/skos/core#related">
    <rdfs:comment xml:lang="en">skos:related is disjoint with skos:broaderTransitive</rdfs:comment>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#SymmetricProperty"/>
    <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2004/02/skos/core#semanticRelation"/>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
    <skos:definition xml:lang="en">Relates a concept to a concept with which there is an associative semantic relationship.</skos:definition>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>
    <rdfs:label xml:lang="en">has related</rdfs:label>
    <owl:propertyDisjointWith rdf:resource="http://www.w3.org/2004/02/skos/core#broaderTransitive"/>
  </rdf:Property>

OWL2 DL

그런데, OWL2 DL은 결정가능성(decidability)의 이유로, DisjointObjectProperties의 사용에 몇가지 제약을 주고 있다고 합니다. 다음과 같은 형태로는 사용이 불가능하다고 합니다.

• SubObjectPropertyOf( ObjectPropertyChain( OPE1 … OPEn ) OPE ) with n > 1, or
• SubObjectPropertyOf( ObjectPropertyChain( OPE1 … OPEn ) INV(OPE) ) with n > 1, or
• TransitiveObjectProperty( OPE ), or
• TransitiveObjectProperty( INV(OPE) )

Pellet 2.0

Pellet 2.0.2에서 다음과 같은 결과가 나왔습니다.

WARNING: Unsupported axiom:
Ignoring transitivity and/or complex subproperty axioms for broaderTransitive
31-mrt-2010 14:09:54 org.mindswap.pellet.RBox ignoreTransitivity

SPIN

SPIN에서 제약 조건은 다음과 같은 쿼리로 만들 수 있습니다.

ASK WHERE {
   ?this skos:related ?object1 .
   ?this skos:broaderTransitive ?object2 .
   FILTER (?object1 = ?object2) .
}

(TopBraid Composer에서의 실행결과는 Paul 의 관련 포스트를 참고하세요.)

Pellet ICV 0.4

다음과 같이 제약 조건을 명시합니다.

<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#related">
     <owl:propertyDisjointWith rdf:resource="http://www.w3.org/2004/02/skos/core#broaderTransitive"/>
</rdf:Description>
<rdf:Description rdf:about="http://www.w3.org/2004/02/skos/core#broaderTransitive">
     <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty"/>
</rdf:Description>

제약 조건이 위배됨을 리포트합니다.

c:\Program Files\pellet-2.1.0>pellet-ic –constraints C:\Users\Paul\TBCMEWorkspa
ce\test\s27c.rdf C:\Users\Paul\TBCMEWorkspace\Test\s27.rdf
15-apr-2010 12:43:41 org.mindswap.pellet.jena.graph.loader.DefaultGraphLoader ad
dUnsupportedFeature
WARNING: Unsupported axiom: Ignoring transitivity axiom due to an existing disjo
intness axioms for property broaderTransitive
15-apr-2010 12:43:41 org.mindswap.pellet.RBox ignoreTransitivity
WARNING: Unsupported axiom: Ignoring transitivity and/or complex subproperty axi
oms for broaderTransitive
Validating 2 integrity constraints
Will stop after 1 constraint violation(s) are found

Validating constraint: related disjointPropertyWith broaderTransitive
Constraint violated : Yes
Violating individuals (1): Concept_1,

Number of constraint(s) violated: 1

결론 : SPIN으로 아주 간단히 되는 제약 조건의 기술은 OWL2 DL 의 제한으로 OWL2로는 표현되지 못하지만, CWA를 사용하는 OWL IC(Pellet ICV)에 의해서는 간단히 처리되는 것을 볼 수 있습니다.

4) S55: The Property Chain

S55: The property chain (skosxl:prefLabel, skosxl:literalForm) is a sub-property of skos:prefLabel.
프로퍼티 체인(skosxl:prefLabel, skosxl:literalForm)은 skos:prefLabel의 하위 프로퍼티라는 제약조건입니다.

    • S55: The property chain (skosxl:prefLabel, skosxl:literalForm) is a sub-property of skos:prefLabel.
    • S56: The property chain (skosxl:altLabel, skosxl:literalForm) is a sub-property of skos:altLabel.
    • S57: The property chain (skosxl:hiddenLabel, skosxl:literalForm) is a sub-property of skos:hiddenLabel.

OWL2
OWL2 의 새로운 특징 중 하나가 바로 프로퍼티 체인입니다. 가장 고전적인 예가 바로 :hasParent와 :hasBrother의 조합으로 :hasUncle이라는 프로퍼티를 정의하는 것입니다.

다음과 같은 형식문법으로 표현합니다.

SubObjectPropertyOf( ObjectPropertyChain( OPE1 … OPEn ) OPE ).

이제 SKOS의 제약 조건을 살펴보지요.

  • skosxl:prefLabel은 Object property이다.
  • skos:literalForm은 Data property이다.
  • skos:prefLabel은 Annotation property이다.

이 세가지 타입의 프로퍼티에 대한 조합은 OWL2의 프로퍼티 체인 악시옴에서는 허용되지 않습니다.

(Note: skosxl은 SKOS eXtention for Labels(SKOS-XL)의 네임스페이스입니다. skosxl은 SKOS에서 사전적인 어휘목록을 다루는 skos:prefLabel, skos:hiddenLabel, skos:altLabel의 확장된 기능을 제공합니다.)

어쨌든 계속해 보겠습니다.

skos:prefLabel rdf:type owl:AnnotationProperty.
xl:prefLabel rdf:type owl:ObjectProperty.
xl:literalForm rdf:type owl:DatatypeProperty.

skos:prefLabel owl:propertyChainAxiom (
   xl:prefLabel
   xl:literalForm
).

Pellet 2.1.0은 예상 대로 warning을 내보냅니다.

WARNING: Unsupported axiom: Bnode in owl:propertyChainAxiom axiom is not a valid
property expression.

즉, 이러한 타입의 프로퍼티 체이닝은 OWL2에서 할 수 없습니다.

SPIN

SPIN에서는 다시한번 이 제약조건을 구현하는 것이 무척 간단하게 이루어집니다.

다음의 SPARQL CONSTRUCT 절을 spin:rule에 삽입하면

CONSTRUCT {
   ?this skos:prefLabel ?label .
}
WHERE {
   ?this xl:prefLabel ?prefLabel .
   ?prefLabel xl:literalForm ?label .
}

(TopBraid Composer에서의 실행결과는 Paul의 포스트를 확인하시기 바랍니다.)

결론

위의 네 가지 경우에서 OWL2가 적용될 수 있는 경우는 별로 없습니다. 그러나 SPIN/SPARQL의 경우에는 꽤 쉽고 빠르게 적용이 가능함을 알 수 있습니다.

SKOS Constraint SPIN OWL2 OWL2 IC
S14 Y +
S13 Y + +
S27 Y + +
S55 N +

C&P의 Pellet과 TopQuadrant의 SPIN을 이용한 Constraints Checking에서 다음과 같은 사실을 먼저 명확히 할 필요가 있습니다.

  • SPIN은 제약조건과 구성자를 기술하기 위한 언어(SPARQL로 된)로서, TBC에 구현되어 있으며, 오픈 소스로도 사용이 가능하다.
  • OWA(Open World Assumption)하의 OWL2에 대해 Holger는 유용성에 동의하지 않는다.
  • CWA(Closed World Assumption)하의 OWL2는 Pellet ICV로 구현되었고, 이제 OWL2 IC로 릴리즈 되었다.


SPIN과 Pellet ICV이 동의하는 것과 동의하지 않는 것


동의하는 것

  • OWA하의 OWL2는 많은 유즈케이스에서 비직관적이고 비생산적이다.
  • Closed world하에서 제약조건을 검사하는 데에 SPARQL을 사용하는 것이 가장 좋다.

양쪽은 단지 제약 조건을 검사하기 위한 SPARQL 쿼리를 만들어내는 방법이 다를 뿐입니다.

  • SPIN의 경우는 직접 SPARQL 쿼리를 작성해야 한다.
  • OWL2 IC의 경우는 백그라운드에서 SPARQL 쿼리로 변환되는 OWL 악시옴을 작성한다.

그러나, SPARQL 쿼리를 작성하는 것이 간단치 않고 이것은 Linked Data API()의 개발을 뒷받침하는 근거 중의하나가 되고 있습니다. 또한, SPIN은 단지 제약 조건을 검사하는 언어 이외에도 훨씬 많은 기능을 가지고 있는데, 특히 OWL2로 표현되지 못하는 Property Chain 추론의 솔루션이 될 수 있습니다.

동의하지 않는 것

양쪽은 OWL2의 중요성에 대해 동의하지 않습니다.

TopQuadrant의 입장은 OWL2가 단지 SKOS나, FOAF, 또는 SIOC 같은 수준의 vocabulary들의 목록일뿐이며, SW 애플리케이션 개발에서 부가적인 역할이라는 것입니다. Holger와 마찬가지로 Paul도 OWL2 (DL)은 모델링 하고자 하는 몇 가지의 제약 조건은 구현할 수 있으나 언제나 모든 요구사항에 들어맞지는 않는다는 생각입니다. 따라서 OWL2에 너무 종속적인 툴은 사용하지 말 것을 권하고 있습니다.

Holger는 OWL의 문제점에 대해서 다음과 같이 지적합니다[4].

  • Semantic Web 데이터 모델은 RDF 트리플로 이루어진 그래프 구조로, 이용자가 자신만의 방법으로 데이터와 지식을 자유롭게 표현하므로 단순 트리플 수준을 넘어선 복잡한 그래프 구조가 생기게 된다. 따라서 이런 복잡한 그래프 구조에 대해 제약조건을 검사하거나 룰을 실행하기 위한 추상화된 그래프 매칭 언어의 필요성이 대두된다.
  • OWL은 임의의 RDF 그래프 패턴을 (자유롭게) 표현하지 못하고 OWL의 설계자들이 유용하다고 찾아낸 몇가지 패턴의 하위집합만을 표현할 수 있다(Paul의 예에서 본 것처럼 서로 다른 타입의 프로퍼티들은 프로퍼티 체인으로 허용되지 않는다). DL 기반의 OWL2는 실세계의 유즈케이스를 다루기에는 제한적이고 불충분하다.
  • DL의 목적은 추론 엔진이 질문에 대해 유한한 시간 안에 답할 수 있도록 하는 논리의 “추적가능한” 하위집합을 발견하기 위한 것이다. 그러나 그 “유한한 시간”은 계산 가능하다는 것이지 엄청난 시간이 걸릴 수도 있다. 실제로 DL 추론엔진의 속도에 대한 이용자들의 불만이 많다.
  • RDF 그래프 모델에 제약조건 검사나 룰의 실행에 부합하는 툴은 Where 절로 구사되는 다양한 조건절을 가진 SPARQL이다. SPARQL과 SPIN이 DL 추론 엔진과 같이 매우 느린 쿼리를 만들 수 있지만 적어도 훨씬 유언하고 풍부한 표현이 가능하다.

실제로 개인적인 경험을 비추어 보아도 실세계의 지식을 OWL을 이용해 표현해 내기에는 한계가 너무 많았고, DL 추론을 위해서는 실세계의 사물(things)과 사물간의 관계(relationship)를 그대로 반영하기 보다는 인공적으로 하나의 class를 중심으로 property들을 배치하는 모델링이 될 수 밖에 없고, restriction/교집합, 합집합 선언을 통한 subset 추론 밖에 기대할 수 없었습니다. 애플리케이션 개발에 있어 필요한 Logic의 표현을 위해서는 SPARQL이 매우 유용하다는 생각이 듭니다. Holger가 언급한 것처럼 사실 SPARQL도 아직 많이 느리고, 필요한 기능들도 아직 구현되지 않아서(예를 들어 count, sum과 같은 aggregates, 서브쿼리, 부정문(negation) 등) 불편한 점이 있지만 이런 점을 보완한 SPARQL 1.1이 곧 등장할 예정입니다. 또한 CWA 하의 제약 조건 검사와 규칙 정의에 유용한 것으로 판명된 SPIN에 관심을 가지고 적용해볼 필요가 있겠습니다.

by ymchu

[Reference]
1. http://www.proxml.be/users/paul/weblog/d1855/Where_OWL_fails_another_OWL_arises.html
2. http://clarkparsia.com/weblog/2010/04/14/pellet-icv-0-4-release-using-owl-integrity-constraints-to-validate-skos/
3. http://clarkparsia.com/weblog/2009/02/11/integrity-constraints-for-owl/
4. http://composing-the-semantic-web.blogspot.com/2010/04/where-owl-fails.html


SKOS(Simple Knowledge Organization)

SKOS(Simple Knowledge Organization System) 개요

SKOS(Simple Knowledge Organization System)는 시소러스, 택소노미, 분류체계와 주제명 표목표 같은 지식어휘체계를 표현하기 위한 RDF 용어집(vocabulary)이다. SKOS가 RDF(Resource Description Framework)에 기반하고 있기 때문에 SKOS로 표현된 지식어휘체계는 기계가 이해 가능하고(machine-readable), 소프트웨어 어플리케이션 간에 상호호환이 가능(interoperability)하며 웹으로 발행(publishing)이 가능하다.

시맨틱웹 어플리케이션에서 지식어휘체계로 정의된 용어를 사용하기 위해서는 어플리케이션에서의 참조와 재사용을 증진시키는 방식으로 어휘의 용어들을 정의하고, 문서화하고 발행해야 한다. 다양한 정보원의 데이터를 병합하고 이를 재사용가능하도록 설계된 시맨틱웹의 특성은 SKOS를 기반으로 지식어휘체계를 관리함으로써 다른 시맨틱웹 어휘들과 융복합될 수 있으며 계속적인 확장이 가능하다.

콘텐츠 색인에 있어서 시맨틱웹 온톨로지 또는 어휘를 사용하는 가장 큰 장점으로는 URI를 통해 통일된 방법으로 명확한 개념을 참조할 수 있다는 점이다. 특히, 이용자가 Linked Data로 발행된 지식어휘체계를 URI로 접근할 때, 개념에 대한 부가 정보를 제공할 수 있고 개념간의 관계를 표현하기 때문에 관계를 따라 브라우징과 탐색이 가능하다.

또한, SKOS 데이터 모델은 사용하는 개별 기관이나 이용자의 목적에 따라 확장이 가능하므로 원래의 SKOS 데이터 모델과 일관성을 유지하면서도 개별 도메인에 특화된 특성을 구현할 수 있는 장점이 있다. SKOS 같은 공통 표현모델을 사용하면 여러 지식어휘체계를 하나의 어플리케이션에서 연계하여 사용가능하고 시맨틱웹 환경에서 하나의 지식어휘체계를 여러 어플리케이션에서 공유하는 등 연계ㆍ공유가 쉽고 따라서 재사용이 가능하다.

SKOS는 기존에 존재하는 개념적 지식어휘체계, 즉, 시소러스, 분류체계, 주제어 표목표, 택소노미의 형태로 생산된 각종 어휘들을 대체하기 위한 것이 아니라, RDF 기술을 토대로 한 경량의, 직관적인 개념적 모델링 언어로 새로운 KOS를 개발하고 공유하기 위한 언어이다. 이를 통해 저비용의 마이그레이션 방법을 지원함으로써 기존의 지식어휘체계가 시맨틱웹에 포팅(porting)되고, 재사용성과 상호운용성을 증진할 수 있도록 하는 것이 SKOS의 목적이다.

또한 SKOS는 소셜 태깅 어플리케이션과 같은 웹 기반의 협업 도구에서 사용되는 비구조적이고 비형식적인 태깅 시스템과 OWL과 같이 논리적 형식화가 잘된 온톨로지 언어 사이의 연결고리로서의 역할을 담당한다.

SKOS 모델의 주요 구성요소

SKOS의 개념 모델(concept schema)은 ISO2788 시소러스 표준의 영향을 받아 유사하다. SKOS 개념 모델은 RDF의 구성자(construct)만으로 정의되어 있는데 그 이유는 RDFS/OWL이 의미적 표현이 더 풍부하나, SKOS만으로도 시소러스를 비롯한 지식어휘체계(KOS)를 표현하는데 충분하기 때문이다.

SKOS는 레이어로 구성된다. SKOS Core는 가장 개발이 진행된 부분이고 시소러스 표준에 직접적으로 대응되는 부분이다. SKOS Mapping은 시소러스 개념들을 하나의 정보원에서 다른 정보원으로 매핑시키기 위해 여러 개의 특정한 프로퍼티를 정의하는 SKOS의 확장이다.

가) 개념 정의(Concepts)

SKOS 개념 모델의 가장 기본 요소인 skos:Concept 클래스는 지식어휘체계에 존재하는 객체(object), 의미(meaning), 아이디어 또는 이벤트를 표현하는데 사용된다. skos:Concept을 이용하여 주어진 리소스를 개념으로 명시하기 위해서는

1. 개념에 대한 유일 식별자(URI)를 생성(또는 재사용)하고,

2. rdf:type 프로퍼티를 이용하여 RDF 형식으로 표현한다.

예를 들어, RDF로 표현된 다음 구문은

<http://www.example.com/animals>   rdf:type   skos:Concept.

“animals“라는 리소스가 URI로 ”http://www.example.com/animals“를 가지며, skos:Concept 클래스의 인스턴스(즉, animals의 타입이 skos:Concept)임을 나타낸다.

위의 구문을 네임스페이스 prefix ex로 축약해서 표현하면 다음과 같다.

ex:animals   rdf:type   skos:Concept.

나) 레이블 정의(Labels)

skos:Concept로 선언된 개념을 자연어, 즉 인간이 읽을 수 있는 리소스의 이름으로 표현하기 위해 사용하는 것이 rdfs:label이다. SKOS는 rdfs:label을 확장하여 다음과 같은 세가지의 레이블 속성을 제공한다.

1. skos:prefLabel

skos:prefLabel은 주로 두 가지 용도로 사용된다. 첫 번째는 색인 시스템에서 사용되는 색인어(descriptor)를 지정하기 위하여 사용되고, 두 번째는 다국어 레이블을 지정하기 위한 용도로 사용된다.

ex:animals rdf:type skos:Concept;

   skos:prefLabel “animals”;

   skos:prefLabel “animals”@en;

   skos:prefLabel “animaux”@fr.

2. skos:altLabel

skos:altLabel은 skos:prefLabel 외에 보통 약어 표현이나 동의어 표현과 같은 부가적인 표기가 존재할 때 사용된다.

ex:fao rdf:type skos:Concept;

   skos:prefLabel “Food and Agriculture Organization”@en;

   skos:altLabel “FAO”@en.

3. skos:hiddenLabel

skos:hiddenLabel은 텍스트 기반의 색인, 검색을 위해 기계가 접근할 수 있는 텍스트 데이터를 표현하면서 데이터가 이용자에게는 보이지 않도록 하고 싶을 때 사용한다. 예를 들어, 철자가 틀린 텍스트 데이터를 색인어에 포함시키고자 할 때 사용한다.

ex:animals rdf:type skos:Concept;

   skos:prefLabel “animaux”@fr;

   skos:altLabel “bêtes”@fr;

   skos:hiddenLabel “betes”@fr.

다) 개념 간의 의미관계 표현(Semantic Relationships)

지식어휘체계에서 개념 정의를 하는데 의미관계는 중요한 역할을 한다. 개념의 의미는 레이블로 표현되는 자연어로서가 아니라 어휘체계 안에서 다른 개념들과의 관계를 통해 나타내지기 때문이다.

 

1. 협의어/광의어(Broader/Narrower 관계)

skos:broader와 skos:narrower는 개념들 간의 계층관계, 즉, 어떤 분류체계 내에서의 상/하위 관계, 부분/전체 관계를 표현하는데 사용된다.

ex:animals   rdf:type   skos:Concept;

   skos:prefLabel   “animals”@en;

   skos:narrower   ex:mammals.

ex:mammals   rdf:type   skos:Concept;

   skos:prefLabel   “mammals”@en;

   skos:broader ex:animals.

2. 관련어(skos:related)

두 개념 간의 수평적인 연관 관계를 표현하는 데는 skos:related가 사용된다. 이것은 대칭 프로퍼티(symmetric property)로서, 즉 A skos:related B 이면 B skos:related A가 추론된다.

ex:birds   rdf:type   skos:Concept;

   skos:prefLabel   “birds”@en;

   skos:related   ex:ornithology.

ex:ornithology   rdf:type   skos:Concept;

   skos:prefLabel   “ornithology”@en.

라) 지식어휘체계 명시(Concept Schemes)

skos:ConceptScheme은 이 개념 어휘들이 속해 있는 지식어휘체계를 기술하도록 한다. 시소러스나 분류체계 명을 기술하거나 작성자 등을 표현하는데는 더블린 코어(Dublin Core)의 프로퍼티를 이용할 수 있다.

ex:animalThesaurus   rdf:type   skos:ConceptScheme;

   dct:title “Simple animal thesaurus”;

   dct:creator   ex:antoineIsaac.

 

마) 지식어휘체계 간의 매핑(Mapping Concept Schemes)

SKOS가 제공하는 여러 프로퍼티를 사용하면 여러 지식어휘체계를 서로 연계한 네트워크를 구성할 수 있다. 서로 다른 지식어휘체계의 개념들이 서로 연결됨으로써 분산적이고, 이형적인 글로벌한 지식어휘체계를 형성하게 된다. 지식어휘체계의 웹은 지식어휘체계 간의 의미적 네비게이션을 가능하게 함으로써 새로운 어플리케이션을 만드는 기반이 된다.

SKOS는 다양한 지식어휘체계 간의 개념을 서로 매핑하는 여러 프로퍼티를 제공하는데, skos:exactMatch는 어떤 개념에 정확히 대응되는 관계를 정의할 때, skos:closeMatch는 근접한 유사어를 정의할 때 사용된다. 이 외에도 skos:broadMatch, skos:narrowMatch, 그리고 skos:relatedMatch이 사용 가능하다.

ex1:referenceAnimalScheme   rdf:type   skos:ConceptScheme;

   dct:title   “Extensive list of animals”@en.

   ex2:eggSellerScheme   rdf:type   skos:ConceptScheme;

   dct:title   “Obsessed egg-seller’s vocabulary”@en.

ex1:platypus   skos:broadMatch   ex2:eggLayingAnimals.

ex1:platypus   skos:relatedMatch   ex2:eggs.

ex1:animal   skos:exactMatch   ex2:animals.

개념 간의 매핑을 통해 서로 다른 두 지식어휘체계를 연계하는 것 뿐만 아니라 시맨틱웹 상에서는 리소스의 URI를 이용하여 분산 방식의 공유와 재사용이 가능하다. 따라서 어떤 하나의 개념이 동시에 여러 지식어휘체계에 소속되는 것이 가능하고 SKOS 관리자는 새로운 개념을 선언할 때 어떤 스키마에 존재하는 개념인지 skos:inScheme 프로퍼티를 이용하여 선언함으로써 이미 존재하는 개념을 차용하여 재사용할 수 있다.

ex1:referenceAnimalScheme   rdf:type   skos:ConceptScheme;

   dct:title   “Reference list of animals”@en.

ex1:cats   rdf:type   skos:Concept;

   skos:prefLabel   “cats”@en;

   skos:inScheme   ex1:referenceAnimalScheme.

 참고 : SKOS Primer(http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/)


SPIN overview

 http://spinrdf.org/

SPIN – SPARQL Inferencing Notation

December 31, 2008

SPIN은 SPARQL을 이용해서 제한(constraints)과 추론 규칙을 정의하는 RDF로 된 vocab  이다. 이를 이용하여 SPARQL  function 과 query templates을 정의할 수 있다. SPIN을 이용하면 다음과 같은 것이 가능하다.

  • 어떤 프로퍼티에 의한 다른 프로퍼티의 값 계산 : 예를 들어, 생년월일에 따른 나이계산, firstname과 surname의 concatenation 등…
  • 제한사항(constraints) 체크 : 예를 들어, 어떤 입력 값에 대한 constraints 설정에 따른 불일치성(inconsistency) 자동 체크
  •  특정 조건하에서 실행되어져야 하는 규칙 집합을 고립 – 예를 들어 증분 추론(incremental reasoning)을 위해서 어떤 리소스가 처음 만들어질 때 특정 값을 초기화한다던지, 또는 interactive application 으로 유도

 SPIN은 다양한 애플리케이션 목적에 맞도록 SPARQL의 빠른 퍼포먼스와 풍부한 표현성을 향상시키기위한 프레임워크를 제공한다. SPIN은 SPARQL을 위한 RDF 스키마를 제공하는데 그 결과로  SPARQL 쿼리는 RDF  트리플로 RDF 도메인 모델과 함께 저장될 수 있다. 이를 통해 RDF 리소스를 관련된 SPARQL 쿼리와 함께 연결시킬 수 있을 뿐 아니라 SPARQL 쿼리의 공유와 재사용도 가능하다. SPARQL을 위한 RDF vocab은 SPIN 프레임워크의 첫번째 레이어이다.

SPARQL RDF 구문을 이용해  SPIN은 도메인 모델러들이 추론 규칙(SPARQL Construct 쿼리로서)을 덧붙이고 RDFS나  OWL  클래스 정의에 constraint chects/unit tests를 (Construct나 Ask 쿼리로서) 할 수 있도록 간단한 RDF 프로퍼티의 집합을 정의한다.

  • SPIN 추론 규칙은 따라서 클래스의 인스턴스에 존재하는  RDF 구문으로부터 새로운 RDF 구문을  도출하는데 사용될 수 있다.
  • 특별한 종류의 추론 규칙 – 생성 시에 기본값(default value)으로 리소스를 초기화하는데 사용될 수 있는 constructors 라고 불리는 – 이 있다.
  •  SPIN constraints는 클래스의 모든 멤버가 반드시 지켜야 하는 조건을 명시하는 데 사용될 수 있다.

클래스에 규칙과 제한(constraints)을 지정하기 위한 프로퍼티는 SPIN  Vocab에 의해 제공되며 이것이 SPIN 프레임워크의 두번째 레이어이다. 이를 통해 SPIN은 객체지향 모델링 패러다임을 지원하지만 완벽히 시맨틱웹 스페이스에 embed됨으로써  다양한 정보원으로부터 온 데이터들의 통합을 위해 웹 리소스들을 연결시킬 수 있다.

SPIN은 또한 기존의 SPARQL 표현식에 기반하여 새로운 SPARQL function을 정의할 수 있도록 하는 메타모델링 매카니즘을 제공한다. 이에 따라 cardinalities와 값의 범위를 제한하는 템플릿과 function을 가진 자주 사용되는 모델링 패턴의 라이브러리를 제공하는데 이 모듈 라이브러리가 SPIN 프레임워크의 세번째 레이어 이다.

 SPINLayer.bmp

TIP !!!

SPIN과 SWRL의 차이점?(http://stage.vambenepe.com/archives/496, 댓글 9번)

  • 이 둘다 온톨로지에 규칙을 내장하기 위한 RDF 구문을 가지고 있고 비슷한 표현성을 가짐.
  • Holger는 SWRL에 비해 가지는 SPIN의 우월성에 대하여 다음과 같이 말함.
    • SPIN은 SPARQL로 되어 있어서(즉, 더욱 풍부한 filter 표현과 named graph를 통한 쿼리의 일부로써 시맨틱웹을 진정으로 사용할 수 있음) 더욱 표현력이 뛰어남.
    •  SPARQL은 여러 툴을 가진 활동적인  W3C 표준이므로 지속적으로 발전하고 있고 이에 따라 SPIN도 이익을 받게 될 것.  SWRL은 RIF 매핑과 별도로는 지금 당장 어떤 활동적인 움직임이 없음.
    • SPIN은 확장성이 좋음(즉, 자신만의 function과 template을 만들 수 있음). SWRL은 hard-code로 된 엔진에 의해 제공되는 실행 라이브러리에 한정됨.
    • constraint checking을 명시적으로 지원
    • 객체 지향적이고 따라서 쉽게 유지보수가 가능. 

이 글은 스프링노트에서 작성되었습니다.


LinkedOpenData

 http://artofsystems.blogspot.com/2009/03/linked-data-end-user-applications.html

 

Linked Data: End-User Applications?

LinkedData는 웹에 데이터를 퍼블리쉬하는 데 있어 거시적 시맨틱웹(big-Semantic Web) 기술을 어떻게 사용할 것인지에 대한 합의된 규칙(common sense rules)이다.

 

  • RDF로 데이터를 퍼블리시
  • HTTP URI를 사용해서 RDF 데이터에 있는 리소스에 이름을 붙이기
  • URI를 역참조(dereferencable)할 수 있게 만들고
  • 표준 스키마 언어(OWL) 을 이용하는 것.

 

Linked Data는 최근  비로소 시맨틱웹의 실제적인 버전을 가진 한 종류로서 추진력을 받게 되었다. 상대적으로 적은 노력으로 퍼블리시 된 데이터의 양이 많아졌지만, 실험실 외부에 존재하는 그 데이터를 사용하는 애플리케이션은 그리 많지 않다.

 

반면에 기업에서 Linked Data를 사용한 예가 있는데, BBC에서 하고 있는 몇가지 작업들(http://blogs.talis.com/nodalities/2009/01/building-coherence-at-bbccouk.php)이 바로 그것이다.

 이 포스트는 Linked Data의 장점을 취하는 현실적인 End-user 애플리케이션에 대한 것이다. “real”이 의미하는 것은 이용자가 자신의 데스크탑이나, 또는 핸드폰, 웹 브라우저등에서 풍부한 유저 인터페이스를 통해 어떤 태스크를 할 수 있게되는 것을 의미한다.

몇번의 trial-and-error를 통해 다음과 같은 사항들을 정리해 보았다:

  • 애플리케이션이 고정된 데이터 셋 이외의 것을 다룰 수 있도록 만들어지는지?. 예를 들어 Marbles같은 브라우저는 모든 가능한 Linked Data를 네비게이트할 수 있는 반면, 다른 시스템은 내부의 데이터로 한정된다.
  • 링크가 이용자에게 보여질 수 있는지? 예를 들어, 일반적인 브라우저는 이용자가 링크를 보고 다른 곳으로 이동하기 위해 선택할 수 있다. 한편, 소셜 네트워크 브라우저는 자동적으로 FOAF 네트워크를 어떻게 확장할 것인지 선택할 수 있고 여러 정보원으로부터 온 데이터를 포함하는 요약 뷰를 보여 준다.
  • 추론이 중요한지?? 즉, raw data를 이용자에게 제시할 것인지 아니면 추론을 사용해서 새로운 트리플을 생성(또는 필터링)할 것인지?

 

 

  • 추론에 대해서 : 새로운 트리플을 융합할 것인지?{Yes, No}
  • 네비게이션? {user-visible links, invisible links}
  • 확장성? {Yes, Somewhat, NO} 다른 온톨로지 fragment와의 조합(온톨로지를 완전히 이해하지 못하더라도)

 

 “National Register Radar”라는 iPhone 애플리케이션 – 지리적 위치와 U.S. National Register of Historic Places Database의 Linked Data 버전을 이용하여 이용자가 자신 주변의 장소에 대한 역사에 “상황적 인식(situational awareness)”를 가지도록 도와주는 애플리케이션으로 특정 종류의  Linked Data인 hardcoded 지식을 사용하며 low-level 링크는 감추며 summary view를 제공하면서 추론은 하지 않고 발견한 데이터만 제시함.

저자는 초기 버전인 이러한 애플리케이션의 개발을 위해서는 하드코딩이 필요하며(특히, non-x86 프로세서와 non Java 기반의 모바일 기기에 대한 고려가 필요하다고) external library가 요구된다고 주장. 특히 휴대폰에 탑재된(on-phone) 트리플 스토어나 Sparql 쿼리는 필요하지 않으며 전통적인 애플리케이션 개발 기법이 적용된다고 함.

저자는 Linked Data가 End-User 레벨 보다는 기업내부의 인프라스트럭처가 될 것이라고 전망.

 

이 글은 스프링노트에서 작성되었습니다.


팔로우

모든 새 글을 수신함으로 전달 받으세요.