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는 어느 컨셉의 인스턴스, ...