티스토리 뷰

좋은 온톨로지 모델링

온톨로지 모델을 구축하는 방법에는 대략적으로 3가지가 존재한다.
- 구축하고자 하는 요구에 맞는 모델을 웹에서 찾아내어 사용하는 방법
  이미 웹에서 사용 가능한 것이라면 그것을 왜 만들려고 하는가??
- 이미 조직 내에서 가치를 가지고 있는 정보 자산을 발전시키는 방법
  대부분의 조직은 정보 스키마, 통제 어휘집, 시소러스 또는 정형화된 정보원을 제공할 수 있는 정보 조직체를 보유하고 있다.
- 처음부터 하나의 모델을 개발하는 방법
  요구 사항 정의와 테스트 케이스 등 개발 지침에 따라 개발한다.


좋은 모델링

'좋은 모델링은 무엇인가?' 에 대한 의문은 모델링을 하는 사람이라면 누구나 한번쯤은 가져보았을 것이라고 생각된다. 구축하고자하는 모델이 구축하는 사람의 의도나 목적을 어떻게 표현하고 어떤 것을 만족하는지 판단할 수 있는 방법에 대해서 생각해보아야 한다. 의도나 목적을 표현하기 위한 방법은 모델을 처음부터 구축하는 경우와 웹 상에서 가져온 모델 또는 새로운 모델을 위한 기초로 사용한 다른 정보 자산을 사용할 때를 각각 생각해봐야 한다.

모델을 처음부터 구축하는 경우에는 구축하고자 하는 모델에 대한 요구 사항을 결정하고 그것에 맞도록 모델을 확장 가능하도록 구축한다. 그러나 구축하고자하는 모델의 요구 사항이 명확해도 웹 상에서 가져온 모델 또는 새로운 모델을 위한 기초로 사용한 다른 정보 자산을 사용하여 구축하는 경우에는 웹 상에서 가져온 모델이 구축되면서 반영된 요구사항을 정확히 알수가 없을 수도 있기 때문에 구축하고자하는 모델의 요구사항을 충족시키기 위해서는 모델러가 웹 상에서 가져온 모델을 검토함으로 모델이 무엇을 할 수 있는지를 스스로 결정해야 하는 경우가 있다. 또한 시맨틱웹에서는 모델이 종종 생각지도 못한 정보원으로부터 온 다른 정보와 병합될 수 있다. 이는 온톨로지 모델의 설계가 반드시 알려진 요구사항에 대해 만족하는 것 뿐만 아니라 구축하는 모델과 병합될 수도 있는 다른 정보를 어느 정도 예상하는 변형성을 담아내야 한다. 이것은 시맨틱웹에서의 모델리이 다른 엔지니어링 모델링과 다른 점이다. 특정한 엔지니어링 환경을 위한 모델링을 해야하는 것 뿐만 아니라 예상되는 환경의 다양성을 위한 모델링도 해야 한다.

그렇다면 구축된 모델이 어떻게 의도나 목적을 만족하는지 판단할 수 있을까?

모델러가 자기가 표현하고자 하는 바를 모델의 클래스나 프로퍼티의 이름으로 나타낸다. 직관적인 방법으로 이름을 붙이고 사용하지만 모델이 의미하는 바를 정확히 알 수는 없다. 이를 위해서 객관적인 방법으로 의도나 목적을 만족하는지를 알아내야 한다. 이 방법은 두가지가 있다.

하나는 데이터베이스와 유사한 접근방식으로 데이터를 직접 찾아보는 방법이다. 자신이 표현하고자 하는 개념에 실제적으로 그 개념에 포함되는 인스턴스가 들어가 있는지를 확인하는 것이다. 이 방법은 누구나 할 수 있는 방법이고 매우 간단하리라 생각된다. 
두번째 방법은 위에서 언급한 것처럼 변형성을 담아내는 모델을 구축할 때 특별히 적용되어 진다. 이 방법은 추론이라는 방법을 통해 객관적으로 모델에 대한 판단 기준을 제공해준다. 모델의 의도나 목적을 판단하기 위한 질문에 대한 대답의 일관성이 추론을 통해 표현되고 유지가 된다.


재사용을 생각하는 모델링

온톨로지 모델러가 모델링을 하면서 생각해야 할 것은 '재사용' 이라는 것이다.
내가 만든 모델이 예상하지 않은 새로운 컨텐스트에서 누군가에 의해 사용될 수 있다는 것을 염두해 두고 모델링을 해야 한다. 다르게 말하면 지금 만들고 있는 모델을 사용할 수도 있는 사람이 당면할 수 있는 문제들을 고려해서 설계를 해야 한다. 그러면 '지금 내가 만들고 있는 모델로 생각할 것이 많은데 어떻게 그사람들의 문제를 신경을 쓴단 말인가?' 이렇게 반문할 지도 모르겠다. 물론 모든 것을 다 만족시켜줄 수는 없다. 다만 우리가 몇가지만 염두해 두고 모델링을 한다면 이러한 작업들을 쉽게 할 수 있다. 염두해 두어야 할 것은 이름을 짓는 것과 클래스 혹은 인스턴스 생성에 대한 것이다.

이름 짓기

온톨로지는 개념과 개념간의 관계를 나타낸다. 온톨로지에서 이름, 즉 어휘는 어떤 자연언어로 사용되고 있는 개념의 호칭(라벨)으로서만 의미를 가지고 있다. 다시말하면 개념을 표현하기 위한 하벨로서의 기능인 것이다. 이런 단순한 기능을 가지고 있는 이름을 만드는 것에도 신중한 선택이 필요하다. 어쩌면 단순한 기능을 가지고 있기 때문에 더 신중하게 선택해야할 수도 있을 것 같다.
모델을 설계할 때 자신이 만든 모델을 링크해서  그 안에 있는 것이 무엇인지 알려고 하는 사람들뿐만 아니라, 나중에 자신을 포함해서 그 모델을 유지, 관리하거나 확장해야 할 사람들을 위해서도 이름을 선택해야 한다. 따라서 자신이 만든 모델이 다른 사람에 의해 읽힐 것이라는 생각을 염두고 두는 것은 좋은 습관이다. 이러한 습관을 바탕으로 이름을 선택하여 사용하더라도, 다른 커뮤니티에서는 그 이름을 의미가 없다거나 잘못 지어졌다고 할 수도 있다. 따라서 rdfs:label, rdfs:comment, rdfs:seeAlso 등과 같은 어노테이션 프로퍼티를 사용하여 완화시키는 방법이 있다.

한 예로
ex:Mammals skos:broader ex:Animals .
skos:broader는 시소러스 관리에 백그라운드를 가진 사람들에게는 광의어에 협의어를 연결시키기 위해 사용되는 것으로 이해된다. 다시말하면 skos:broader는 '광의어를 가지고 있다' 로 읽혀져야 하지만 다른 사람들은 이것을 '포유류는 동물보다 광의어이다'라고 읽을 수도 있고, 의미를 혼란스러워하거나 잘못 사용할 수도 있다. 그러나 rdfs:label을 적절히 사용하여
skos:broader rdfs:label "has broader term".
으로 명시하면 그 의미를 명확히 설명해 줌으로서 혼란을 완화시킬 수 있다.

이 외에 이름을 짓는 단순한 규칙이 존재하고 있다. 이 규칙들은 W3C에 의해 지켜지고 있는 것들이다.

- CamelCase의 사용(복합어로된 이름은 첫 글자를 대문자로 하며 단어 간 공백이 없이 쓰이는 명명 스타일)
  rdfs:subClassOf
- 클래스 이름은 대문자로 시작한다.
  owl:Class, owl:Restriction
- 프로퍼티 이름은 소문자로 시작한다.(첫번째 문자를 제외하고 나머지 이름은 CamelCase에 따름)
  owl:inverseOf, rdfs:subClassOf
- 인스턴스 이름은 대문자로 시작한다.
  ex:Mammals, ex:Animals
- 클래스 이름은 단수 명사로 쓰인다.
  owl:DatatypeProperty, ex:Woman


 클래스와 인스턴스

모델을 설계하다보면 어떤 것을 클래스로 해야할지, 인스턴스로 해야할지 결정해야 하는데 막상 쉽지 않는 경험을 해 볼 것이다. 온톨로지 모델의 재사용을 고려할 때 어떤 컨텍스트에서는 클래스가 되어야 한다고 생각하는 반면에 다른 컨텍스트에서는 인스턴스가 되어야 한다고 생각할 수 있다. 어떤 것이 클래스로 할지 인스턴스로 모델링할지를 경정하기 위한 엄격한 규칙은 존재하지 않는다. 하지만 그 프로세스를 조직화하는 일반적인 지침이 도움을 줄 수 있다.

첫번째 지침은 클래스들이 인스턴스들의 집합으로 보일 수 있다는 가능성이 있는가를 보는 것이다.
만약 무언가가 클래스로서 모델링된다면 적어도 그 클래스가 인스턴스를 가질 수 있다는 가능성이 존재해야 한다. 제안된 그 클래스의 멤버가 어떤 인스턴스가 될 수 있을지 상상할 수 없다면 그것은 그 클래스가 클래스로 모델링되어서는 안된다는 것을 의미한다.클래스에 대한 인스턴스를 상상할 수 있다면 인스턴스의 성격이 명확히 드러나도록 클래스의 이름을 생성하는 것이 좋다. 혼란을 피할 수 있는 일반적인 단계는 모델링되어야 하는 것이 무엇인지를 결정하고, 그 다음에 이것이 클래스가 되어야 할지 인스턴스가 되어야 할지를 결정한 다음에 마지막으로 이것을 반영하는 적절한 이름을 선택하도록 한다.

두번째 지침은 모델링 되는 것을 기술하는 프로퍼티를 살펴보는 것이다.
모델링 되는 것을 기술하는 프로퍼티에 대한 특정한 값들을 알고 있는지 아니면 일반적인 어떤 값이 존재한다는 것만 알고 있는지를 살펴야 한다. 특정한 값들을 알고 있다면 인스턴스로 모델링 하는 것이 더 효과적일 수 있다.

 


온톨로지 개발자를 위한 시맨틱웹

'Y:::Modeling' 카테고리의 다른 글

Y_6. Time Ontology 예시  (0) 2012.06.05
Y_5. Ontology 모델 설계 실습 2  (0) 2012.05.04
Y_4. Ontology 모델 설계 실습 1  (2) 2012.05.04
Y_2. 다른 방법론  (0) 2012.04.27
Y_1. Ontology Development 101 방법  (0) 2012.04.27
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함