글

라벨이 ontology & KR인 게시물 표시

OpenRDF - Sesame Benchmark

이미지
Sesame 은 RDF데이터를 처리(쿼리, 추론, 저장)하는 Open Framework입니다. 여러 모듈들이 합쳐저 있지만 그 중에서 단연 밀고있는건 Htttp통신을 이용한 RDF데이터 전달이 아닌가 싶습니다. Sesame 내부에는 openrdf-sail이나 openrdf-rio등과 같은 수많은 모듈들이 사용되는데 http://www.aduna-software.org에서 Open소스로 관리되고 있습니다. 살펴보면 쓸만 한 API들이 꽤 됩니다. 아래 그림처럼 HTTP를 이용해서 RDF데이터를 주고 받습니다. 각각의 컴포넌트들은 모듈별로 관리되고 있습니다. (http://www.aduna-software.org/projects 뭐 가도 많은 정보는 없네요. ^^) Repository 는 SailRepository와 HTTPRepository가 있는데요. SailRepository는 독립적인 Repository를 만들수 있게 해주고 HttpRepository는 원격에 있는 Repository의 Connection을 가져와 처리할 수있게 합니다. Repository myRepository = new HTTPRepository("http://localhost:8080/sesame_server", repositoryID); //원격에 있는 서버 연결 Repository mySailRepository = new SailRepository(new MemoryStore(tempDir)); //로컬의 RDF파일을 이용해 Repository생성 HTTPRepository를 이용 주력으로 밀고있는 HTTPRepository를 이용하는 방법을 알아보죠. Sesame server 설치방법 http://www.openrdf.org/download.jsp Sesame 2.0 beta releases를 다운 (tar나 zip을 다운받는다.) 압축 해제 openrdf-sesame-2.0-beta6/war/에 두개의  war파일이 존재 openrdf-...
댓글 4개
자세한 내용 보기

SOFA (Simple Ontology Framework API)

SOFA (Simple Ontology Framework API) - Jena와 비슷한 역할을 하는 Open Source API입니다. Jena에 비하면 작은 규모이지만 간단하게 있을껀 다 있습네다~ 그리고 GraphViz 를 이용해서 SVG, PNG, GIF, JPEG형식으로 Output이 가능합니다. - Getting started
댓글 1개
자세한 내용 보기

Ontology/SemanticWeb Summer Camp 소개(가칭)

어제 김홍기 교수님을 만나 온톨로지/시맨틱웹에 관심이 있어하는 사람들간의 커뮤니티 형성을 위한 캠프형식의 워크샵?에 대해 논의하고 왔습니다. 교수님께서는 Semantic Web 2.0 Conference 에 참석하셨던 연구/개발자들간의 정기적인 만남을 이어가야한다고 말씀하셨었죠. 취지는 Daum Dev Night 의 것과 비슷합니다. 단지, 관심분야의 중심이 Web2.0이 아닌 온톨로지, 시맨틱웹이란 것이지요. (중심일 뿐이지 다른 어느것을 배제한다는 것은 아닙니다.) 진행방식은 토이 프로젝트를 만드는 것입니다. BikeLab 에서 프로젝트에 대한 몇몇 주제들을 제공할 예정이고요. Dev Night때 처럼 만들어 보고 싶은 프로젝트를 제안해도 됩니다. 일단, 무척 기대됩니다. 같은 주제를 가지고 연구/개발하는 사람들을 만날수있는 좋을 자리가 될 수 있을것 같습니다. 제 블로그 제목에도 그럿듯 정말 시맨틱한 무언가가 서비스되는 그날까지..고고싱~ 아. 상품(상금)도 있을거랍니다. 후후 아직 정확한 일정이나 프로그램이 결정된 상태는 아니고요. 새로운 소식이 있으면 바로 소개해드리겠습니다.
댓글 쓰기
자세한 내용 보기

JenaRDB로 Sparql수행하는 예제

funtheory님의 질문에 포스팅합니다. 우선 온톨로지를 JenaDB로 만들었고, 모델을 가져올 수 있다는 가정하에 함 보죠. 물론 Sparql도 안다는 가정. OntModel model = getOntModel("모델URI"); //모델을 가져옵니다. //getOntModel메소드 추가합니다. private Model getOntModel(String urn){       PersistentOntology po = new PersistentOntology();       ModelMaker maker = po.getRDBMaker(s_dbURL, s_dbUser, s_dbPw, s_dbType, false);             Model model = maker.getModel(urn);         return model;   } 가져온 모델을 이용해 Sparql을 돌려보죠. (온톨로지에는 Person클래스와 nameOfPerson이라는 String타입의 프로퍼티가 있다고 가정할께요.) private void runSPAQL(OntModel model){       //Query query1 = QueryFactory.read("test.rq", "ko");        //이렇게 파일로 만들어도 되요. 메모장에서 utf-8로 저장해야할겁니다. 가물~             Query query1 = QueryFactory.create("PREFIX dc: <http://purl.org/dc/elements/1.1/#>\n" +               "PREFIX owl: <http:/...
댓글 3개
자세한 내용 보기

Ontology를 사용하면 '사용자'에게 어떤 이득이 있나요?

작년까지 학교에 있었고, 현재 업체에 있는 나의 경우, 답하기 힘든 질문중에 하나는... "Ontology를 사용하면 사용자에게 어떤 이득이 있나요?" 학교에 있을때야 돈이 안되도 그냥 관심가는 분야였고, 뭔가 될거라는 막연한 생각도 했던것 같다. 예전에 어디서 연락을 받고 왔는지는 모르겠지만 다른 업체에서 2006년도 수행했던 과제결과물에 대한 관심을 보이며 관련정보를 보여달라고 찾아왔었다. (작년 과제는 온토롤지 구축과 기반 서비스 프로토타입 시스템 개발이였다. ) 아는건 별로 없지만 예제도 보여주고 구현된 결과물도 보여주면서 성심성의것 답변 해주었다. 답변이 끝나갈 무렵, 그 분이 한 질문이 바로 "온톨로지를 사용하면 사용자에게 어떤 변화가 있나요?"였다. 난  대답했다. "글쎄요 ^^;; 어려운 추론이 섞인 질의나 단순한 전화번호를 묻는 질문이나 17인치 모니터안에서 보이는 것들은 동일할거예요." 어려운 추론이 섞인 질의나 단순한 질이든 사용자 입장에서는 뭐가 되었든 동일할것이고 동일해야 한다고 생각한다. 사실 사용자 가 얼마나 어려운 질의 를 하겠는가!? 별로 안좋아할껄. 차이는 그 다음부터라고 생각한다. 그 사람에게 맞는 서비스를 무엇을 어떻게 더 제공하느냐가 문제일뿐... 소리소문없이... 가끔 거대한 온톨로지를 만들어 이것만 구축되면 진정한 시맨틱웹이 구현될거라고 말하는 사람들을 본적이 있다. 웹이 온톨로지/시맨틱을 아는 사람들의 판은 아니기에 그런 관점이 아닌 보편적으로 웹을 바라보는 사람들의 관점에서 바라봐야한다. terrie 님의 블로그에서 RDFa Primer 1.0 소식을 접했다. HTML안에 RDF를 삽입하는 구조이다. 예전에 SHOE에서 했던 구조와 비슷하지만 태그를 기술하는 방식이 좀더 명시적이다. <html xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#"> <span property="c...
댓글 2개
자세한 내용 보기

SAC2007 후기

이미지
리츠칼튼 호텔에서 열린 SAC2007 에 다녀왔습니다. (좀 늦었네요) 리츠칼튼 호텔이라는 곳을 태어나서 처음 가봤습니다. 기억에 남는것만 몇자 적어볼께요. Semantic Web 2.0컨퍼런스 에 비하면 절반도 안되는 사람들이 온것 같더군요. (아마 동시에 Web2.0컨퍼런스가 다른곳에서 하고 있어서 그런것 같기도 합니다.) Web2.0보다는 사람들 보이는 연령대? 가 조금은 높은것 같다란 생각도 들고요. ^^; Deri Innsbruck 에서 오신 Dieter Fensel아저씨는 Service Web 3.0 ?이라는 기괴한 물건을 가지고 나오셨더군요. 지금도 앞으로도 수많은 서비스들이 출몰하게 되는데 그 감당못하는 서비스들에 대한 Discovery가 중요할 것이며, 올해안에 대기업들이 그런 인프라를 만드는데 뛰어들것이라고 자신의 월급을 걸고 확담을 했습니다. (Deri Innsbruck은 Semantic Web Services에 대한 연구가 많은 걸로 알고 있습니다. 해서 이의 확장팩이 아닌가 싶네요.) 대부분 회사, 제품소개, 프로젝트를 중심으로 발표가 진행되었어요. 그 기술에는 온톨로지가 한 몫을 단단히 할것이라는 얘기와 함께요. "시맨틱웹"이라기 보다는 "시맨틱한 뭔가"에 관심이 많은듯 했습니다. 개인적은 느낌엔 아직 큰 구름이 많은 것 같았어요. 그걸 해서 내세울만한 뭔가가 없어서인가요? 그림을 너무 크게 잡아서 인가요? 기업(Enterprise)를 중심으로 한 그림을 그리고 있지만 Ontology Evaluation, Methology에 대한 문제는 남아 있는것 같습니다. 예전에 ETRI에서 리죽스 기반 데스크탑검색에 대한 기사 를 봤는데, ETRI연구원님께서 발표하시는 내용에 부분 속해 있더군요. (윈도우랑 웹에서도 된다는군요. 웹에서 데스크탑검색?) 관심이 있었던 Annotaiton(그냥 태깅)을 하는 부분은 자동적, 반자동적으로 의미정보를 추출한다고 합니다. 자동부분에 있어서는 NER을 통한 기존 IR에서...
댓글 4개
자세한 내용 보기

확장가능하고 느슨한 온톨로지

분류된 온톨로지를 보고 ARQ를 이용해 속성과 그에 대한 속성값을 가지고 있 특정 인스턴스를 뽑는 작업을 하던중 몇가지 적어본다. 난 제주도를 "섬"이라는 카테고리에 넣었고, 검색하려사는 사람 "휴향지"라는 카테고리에서 찾으려 한다면 '제주도'에 대한 정보는 찾을 수 없다. 예제가 억지스러울수도 있고, 제주도를 둘다, '섬'에도 넣고 '휴향지'에도 넣으면 되고, 또, 제주도가 가지고 있는 특정 속성과 값으로 추출하면되지 않겠냐...는 말도 나올수 있겠다. 이런 저런 꽁수야 많겠지만, '분류화'를 이용하여 개념을 표현하고 실제값(Individual)을 넣고, 추출을 하려하다 보면 그 많은 에로사항?들이 나온다. 온톨로지를 구축하는 방법은 도메인 전문가의 머리속의 개념들을 Top-down으로 만드는 방법이 대표적인것 같다. 하지만, 이런 방법은 재사용되기 응근히~?어렵다. 온톨로지를 보면서 나왔던 많은 좋은 말들?중에 하나가 reusability이지만, 막상 다른 사람이나 단체가 만든 온톨로지를 다시 사용하려 하면 그닥! 쉽지 않다. 큰 온톨로지를 가져와서 부분적으로만 사용할지라도 내가 만들고 있는 Application에서는 적절하지 못하다. 또, 실제값들(individuals)을 넣기 더더욱 어렵다. "'제주도'를 어디에 넣어야 하냐고요~"라고 물어올지도 모른다. 그래서~ 개념들과 Application이 함께 feekbace을 주고 받으며 최대한 loose하고 확장가능한,  Individual에 초점을 맞춘 온톨로지가 어떨까 생각한다. 1. Application의 시나리오 question과 답을 유도할 대표Individual을 만든다. 2. Individual의 속성을 풍부하게 한다. (정확하게 말하면 유니크한 속성으로, 이유는 검색) 3. Classfication을 한다. (최소한 개념수와 레벨, 최대한 loose한 ...
댓글 쓰기
자세한 내용 보기

두번째 Tagging이야기

예전에 썼던 annotation에 대한 글 에 대한 두번째 이야기… 화두가 되고 있는 Web2.0이 되기 전의 웹사이트들은 웹컨텐츠 제공자(웹 디자이너, 웹 마스터 등)들이 웹 배포 어플리케이션(Dreamweaver, Namo등)을 이용하여 컨텐츠를 배포하였다. (물론 메모장에 최고의 도구일 시절이 있었겠지만…) 그 후, server page기술을 이용하여 웹컨테츠 요청자들도 함께 컨텐츠를 만들어 배포할 수 있게 되었다. 이때 부터 요청자와 제공자의 구분이 묘현해지기 시작한것 같다. 최근 wiki나 블로그와 같은 형태의 페이지를 만들어 자신들의 컨텐츠를 배포한다. 그래, 내가 알찬 컨텐츠를 만들었어, CD로 구워서 다락방에 올려놓길 원치 않는다면 최대한 가져갈 수 있도록 도와줘야 한다고 생각한다. 첫째, 이 텍스트들의 관계를 잘라가면서 indexing을 하는 멋진 클롤러가 존재하길 바라는 방법도 있겠고 두번째로, 좋은 컨텐츠를 제공하는 provider입장이 되어, 후진 크롤러라도 환상적인 내 컨텐츠를 긇어갈 수 있도록 도와주는 방법이 있을것 같다. 요새 난 그 두번째 방법으로 annotation, tagging에 관심 있다. (이 하나가 완벽하게 만들어주길 기대하지 말자, cowork!) Tagging방법 요약사이트에 속해 있는 각 페이지를 메타수준에서 tagging을 해준다. (이 기능을 지원하기 위해 웹 브라우저에 붙어 있는 툴바와 비슷한 모습이든 어플리케이션의 모습이든 별도의 Client가 필요할 것이다.) Tag뭉치를 담고 있는 플랫폼내지는 서버? Tag들과 Tag와 엮여져 있는 Resource들을 검색할 수 있는 Client (이것도 웹브라우져거 되든 application형태가 되든 할것이다.) 예를 들어, 내가 지금 보고 있는 페이지에 Tagging을 건다. 보고 있는 페이지의 상단이나 하단, 뭐 구석 어딘가에 Tagging을 걸어줄 부분을 마련한다. 물론 Tagging을 시도하는 나는 logon된 user일 것이다. logon된 u...
댓글 쓰기
자세한 내용 보기

Annotation

이미지
Annotation에 대해 몇가지 적어보자. 우선 Annotation는 사전에 찾아보면 “주석”정도로 해석될 수 있는데, 말 그대로 어떠한 리소스에 주석을 다는것이다. 위의 그림을 보면 문서내에 사람이 추가적인 설명을 적어놓는 방식으로 Annotation을 하고 있다. 이제부터 언급할 Annotation에서 사용되는 도메인은 웹을 통해 URI로 하여금 특정 리소스를 얻을 수 있는 범위를 말한다. 즉, 그 대상이 material한 책이나 문서가 아닌 웹을 통해 접근이 가능한 리소스를 의미한다. 이런 웹 리소스를 Annotation하기 위해서는 몇가지 방법이 있을 수 있겠다. (Annotation과 Tagging과의 관계가 포함관계인지, 포함관계라면 어느것이 어느것을 포함하고 있는것인지, 아니면 전혀 별개의것인지 아직 잘 모르겠다. ) 내부 Tagging방법 Provider(블로거, 사이트관리자 등)같은 정보를 제공하는 사람들이 해당 정보를 제공하면서 Tagging을하는 것이다. 이 방법은 Provider의 주관적인 관점이 많이 개입될 수 있다. 또한, 제공자의 부정확한 정보나 의도적인 잘못된 Tagging이 포함될 수 있다. 외부 Tagging방법 이미 Publish된 포스트 혹은 페이지에 대한 Annotation을 reader가 Tagging하는 방법이다. 외부Tagging방법은 Tagging정보를 담고 있을 별도의 Repository가 필요할 것이다. 내부Tagging방법보다는 주관적인 관점이 적게 개입될 수 있다. Requirement of Tagging (단계) Post(Extract) - Storage - retrieval Post(Extract)단계 - 포스트나 페이지가 생성될 때나 생성된 후에나 Tagging을 하는 작업은 필수이다. 이 작업은 Mannual 혹은 Automatic하게 이루어질 수 있다. 필요APP - Provider의 Tagging작업을 쉽게 도와주는 APP Storage 단계 - Tagging의 정보와 리소스...
댓글 쓰기
자세한 내용 보기

~의 타입이다, ~인스턴스이다.

분산된 정보(온톨로지)를 이용하고, 생성하는 것에 대해 고민해보자. 객체(individual)을 생성한다고 하면 해당 타입이 있게 된다.(optional 한건지 mandatory한건진 모르겠다. 내 생각인데 jena api를 이용해 보면 resource를 특정타입 없이 생성이 가능한걸로 봐서 optional이 아닌가 싶다.) 아무튼 어떤 객체에 대해 타입이 있기 마련인데 객체의 속성은 타입(클래스)의 속성을 상속받아(사실, 상속이란 단어도 좀 그런게 프레임 기반의 지식체계라면 ‘상속’이란게 맞지만, 그래프구조를 띄는 owl에서는 상속이란게 맞지 않는것 같다. Jena2 doc : Presenting RDF as frames 에 참고 내용이 좀 있다.) 여하튼, 앞에 신경쓰지말고 보면, 하나의 individual을 만들 때는 반드시 타입(클래스)가 가지고 있는 모든 속성을 표현해줘야 하나? 그렇다면 예를들어보자, ‘Person’이라는 타입이 있고 그의 속성으로 name, address, sex가 있다고 하고, ‘person_01′이라는 객체를 만들었다. 현재 ‘person_01′이란 객체는 name, address, sex가 null이다, 아니, 속성자체에 대한 ref가 없다. 이런 상황을 tool, 혹은 구현상에서 제대로된 ref를 갖도록 고쳐줘야하는 건가? 난 분산된 정보를 사용한다는 것은 각기의 정의된 타입( VCARD:FN 이나 VCARD:NICKNAME같은)들을 가져다가 사용한다는 것이라고 생각한다. 예를들어보자, 타입이 있기 전에 ‘person_01′이라는 객체가 만들어졌고, person_01에 VCARD:FN=’김광섭’, VCARD:NICKNAME=’좀만이’ 라고 트리플을 만들어준다. (전자의 individual만드는 것과 후자의 individual만드는 것은 방법의 차인가? 컨셉에서 객체를 만드는 것과 컨셉의 속성에서 객체를 만든 것…) 그리고, 몇가지 더 추가 내용이 있겠지만, person_01의 default NS는 person_01이 될터이고...
댓글 쓰기
자세한 내용 보기

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는 어느 컨셉의 인스턴스, ...
댓글 쓰기
자세한 내용 보기

온톨로지 - 개념의 표현(1)

이미지
An ontology is a specification of a conceptualization - Tom Gruber 아마도 많은 사람들이 저 문장으로 온톨로지를 이해하고 있는 내용인것 같다. 예전에 가끔 “온톨로지가 뭐냐?”는 질문에 머리속에서 온갖것들의 조합이 엉켜져 있어 어떻게 대답을 할까 고민했었다.(사실 지금도 그리 깔끔하게 풀려있지는 않은것 같다.:-)) 저걸 물어보는 사람이 이쪽을 얼마나 아는 사람이냐, 관심이 있는 사람이냐에 따라..등등, 아니면 어떻게 도망갈까? ^^;; 지식영역의 사물들을 표현하고 기술하는데 사용되는 용어들을 정의한다. 하늘의 금성이라는 개념을 예로 들어보자. 사람에 따라 “금성”, “제일 밝은 별” 또, 금성의 출현시기에 따라 저녁 무렵에 보이는 금성을 “태백성”, “장경성” 혹은 “개밥바라기”라 부르며, 일몰 전후 혹은 새벽 무렵에 보이는 금성을 “샛별”, “명성”이라 부른다. 그렇지만 우리가 금성이란 개념을 지칭하기에 앞어 그전에 금성은 금성이였다. 어떻게 언제 보아도 고유의 속성들을 지닌 금성이다. 온톨로지는 이런 개념, 속성들의 정의, 그들간의 관계를 표현한다. 사람이 온토로지를 구축할 때, 가장 많이 사용되는 방법이 Top-down일거다. 당연한 것이 난 “차”가 뭔지 알고 적어도 “오토바이”와의 차이점도 안다. 더불어, “차”, “오토바이”가 가지고 있는 속성도 안다. 그렇기 때문 컨셉의 정의를 만들고 속성들을 붙여나간다. 이렇게 개념을 정의한다. 반대로 속성들에 의해 컨셉이 정의 되는 Bottom-Up방식도 있다. “이동한다”, “바퀴가 2개다”, “뚜껑이 없다” 이 3개의 속성으로 오토바이임을 나는 안다. 하지만 “자전거”도 저 속성을 만족한다. Bottom-Up의 방식은 도메인이 한정되어 있는 분야에서 사용되야 할것이다. 결국 중요한건 온톨로지는 Top-down이건 Bottom-up이건 개념의 표현이란 것이다. origin source : http://chord.snu.ac.kr/~kskim/wp/...
댓글 쓰기
자세한 내용 보기