OBID의 문제

OBID의 초기 모습은 병원에서 사용하는 양식들을 온토롤지 표현하고 표현된 스키마에 따라 사용자 인터페이스를 동적으로 생성시켜주고, 병원양식의 인스턴스들을 재사용 하도록 도와주는 지원도구였다. 그리고 그런 지원도구를 개발하는 것이 초기 목적이었다.

사실 몇가지 문제가 있었다.
1) 분산된 Resource의 문제들
2) 페이지 생성에 필요한 Mediator?
3) Object Property의 Range를 표현할 Page셋팅
4) Multi-user문제
5) so What? 뭐 어쩌라고?

어떤 한 개념(Class)의 인스턴스를 BaseURI가 http://local.com#인 곳에 생성하려 한다면 해당 개념의 attr, type, restriction등을 가져와야 한다. (물론, 온톨로지를 구축하는 사람은 해당 개념의 타입정도는 알 수 있다, 하지만 지금은 Knowledge Acqusition의 자동생성을 하는 관점에서 얘기하는 것이고, 타입을 모른다면 인터페이스가 자동으로 생성될 수 없다.)
요건 인터페이스가 생성되기 위해 attr, type, restriction들이 제공된다는 가정으로 해결될 수 있다.

페이지를 동적으로 생성된다고는 하지만 사실 사람이 페이지에 표현될 항목들을 하나하나 추가하는 것이다. 그래도 table, form, input태그같은 html을 추가하지 않고(WISWIG방식은 좀더 편리하겠지만) 입력화면의 항목들을 쉽게 편집한다는 것은 어느정도 메리트가 있다고 본다. 입력 인터페이스가 어느정도의 많이 생성이되고 자주 바뀔지는 모르겠지만 기존의 웹페이지만드는 방식에 비하면 그정도 cost는 감수해도 될 것 같다. 그래도! 그래도~ 좀 불편하다.
그래서 생각했던것이 페이지 생성에 필요한 Mediator이다. Henrik Eriksson은 온톨로지의 컨셉, 속성에 따라 입력 컨트롤의 타입을 결정할 수 있게 했다. 이게 Protege의 widget의 모태가 되었던것 같다.

ObjectType property는 어느 컨셉의 인스턴스, 리소스를 갖는다. 그렇기 때문에 이 Range값을 표현할 또 다른 페이지정의가 필요하다. OBID는 쉽게말해 컨셉을 다각적인 방면에서 인스턴스를 입력할 수 있게 도와주는 WebPage이다. Range값을 표현하는 다른 페이지의 정의가 있어야지만 objectProperty의 Range를 입력할 수 있는 페이지가 생성될 수 있다는 말이다. 예를 들어보자, “Person hasJob Job”란 Statement가 있고, hasJob은 objectProperty로 Person클래스를 Domain으로, Job클래스를 Range로 가지고 있다. 홍길동이라는 사용자가 Person컨셉의 인스턴스를 입력하면서 hasJob의 값으로 Job의 인스턴스를 넣어야하는데 Job은 컨셉이다. 이 Job을 보여줄 페이지가 따로 있어야 한다는 말이다.
이 문제는 하나의 Control이 ObjectProperty일때, hasPage란 속성도 가지고 있도록 하여 해결하였다.

웹의 특징중 하나인 S/C환경을 뽑을 수 있는데 이는 Multi-user를 지원한다. 현재 OBID의 경우, 하나의 모델을 static으로 띄어놓고 skelton방식으로 객체를 가져온다. 만약 2명의 사용자가 모델을 서로 가지고 갔다. 그런후 같은 컨셉을 입력하고 있다고 치자, 그리고 서로 다른 시간대로 Commit을 한다면 분명 Conflict가 일어날것이다.
이 문제는 아예 1user로 가는 방법(좀 웃긴다), 모델에 Sync를 걸어주는 방법, 모델에 Commit시 Valid체킹하는 방법등으로 해결할 수 있겠다. 아무래도 마지막 방법이…ㅋ

근데 뭐 어쩌라고…

origin source : http://chord.snu.ac.kr/~kskim/wp/?p=8