KR101094837B1 - 온톨로지 기반 상황 인지 시스템 및 이를 이용한 서비스 제공방법 - Google Patents

Abstract

본 발명의 상황 인지 시스템은, 상황을 구성하는 다수의 요소를 각각 정의하는 다수의 클래스를 구비하며, 상기 다수의 클래스 사이는 프로퍼티를 통해 연결되며, 각 클래스에는 상황을 구성하는 각 요소들을 세분화하기 위한 하위 클래스가 구비되는 상위 온톨로지; 상기 상위 온톨로지를 다수의 도메인의 환경에 각각 적합하게 정의하기 위한 다수의 클래스를 구비하며, 상기 다수의 클래스는 상기 상위 온톨로지의 다수의 클래스의 하위 클래스로 정의되는 도메인 온톨로지; 상기 다수의 도메인에 하나 이상 포함되는 존(zone)을 각각 담당하며, 해당 존에 존재하는 다수의 디바이스로부터의 상황 데이터들을 수집하여 인스턴스들을 생성하고, 상기 상위 및 도메인 온톨로지에 정의된 다수의 클래스와 프로퍼티를 통해 표현된 지식에 대해 클래스간 암시적 포함관계의 추론 및, 상기 인스턴스들이 상기 상위 및 도메인 온톨로지에 구비되는 다수의 컨텍스트 클래스 중 어느 클래스에 포함되는지를 추론하여 로우 레벨 컨텍스트를 도출하고, 도출된 하나 이상의 상기 로우 레벨 컨텍스트로부터 경험적 규칙을 SWRL로 작성한 규칙에 따라 하이 레벨 컨텍스트를 도출하고, 상기 하이 레벨 컨텍스트에 대응되는 맵핑된 서비스 제공을 요청하는 상황인식 협업 시스템; 상기 다수의 상황 인식 협업 시스템으로부터의 하이 레벨 컨텍스트들을 제공받아, 다수의 존을 이동하는 이용자에 대한 하이 레벨 컨텍스트들과 이용자에 대한 이용자 정보를 토대로 다음 서비스를 결정하고, 상기 결정된 서비스의 제공을 요청하는 상황정보 처리 시스템;을 구비한다.

U-CITY, OWL, SWRL, 상황인지

Description

온톨로지 기반 상황 인지 시스템 및 이를 이용한 서비스 제공방법{ONTOLOGY BASEDCONTEXT AWARENESS SYSTEM AND SERVICE PROVIDING METHOD THEREOF}

본 발명은 U-CITY를 위한 유비쿼터스 서비스 기술에 관한 것으로, 더욱 상세하게는 다양한 센서와 디바이스들로부터의 데이터들을 통해 상황을 인지하고 그에 따른 서비스를 제공하는 상황 인지 시스템 및 이를 이용한 서비스 제공방법에 관한 것이다.

최근 대두되고 있는 U-CITY는 도로, 교량, 학교, 병원 등 도시 기반 시설에 첨단 정보 통신 기술을 융합하여 유비쿼터스 기반 시설을 구축하여 교통, 환경, 복지 등 각종 유비쿼터스 서비스를 제공하는 도시이다.

상기 U-CITY를 위한 유비쿼터스 기반 시설은 공간 및 사물 및 사람들간의 연결 체계 속에서 사용자가 추구하는 기능을 실현하기 위한 다양한 매체로부터의 데이터들이 공간-사물-사람 사이에 실시간으로 송수신되게 한다.

상기한 유비 쿼터스 기반 시설은 이용자 중심의 서비스를 제공하기 위해 다양한 데이터들을 수집하여 상황을 인식하고, 인식된 상황에 적절한 유비쿼터스 서비스를 제공할 수 있는 기술의 개발이 절실하게 요망되었다.

본 발명은 이용자의 상황을 고려한 개인화된 서비스를 제공하기 위해 사용자를 둘러싼 위치, 시간, 디바이스, 개인 정보 및 선호도, 행위, 일정 등을 온톨로지를 이용하여 표현하고, 명시적으로 표현되지 않은 암묵적 상황을 추론을 통해 인식하며, 다양한 공간(존, zone)을 이동하는 이용자의 복합적인 상황을 관리함으로써 끊김없고(seamless) 능동적인 이용자 중심의 서비스를 제공하기 위한 상황 인지 시스템 및 이를 통한 이용자 중심의 서비스 제공방법을 제공하는 것을 목적으로 한다.

상기한 목적을 달성하기 위한 본 발명의 상황 인지 시스템은, 상황을 구성하는 다수의 요소를 각각 정의하는 다수의 클래스를 구비하며, 상기 다수의 클래스 사이는 프로퍼티를 통해 연결되며, 각 클래스에는 상황을 구성하는 각 요소들을 세분화하기 위한 하위 클래스가 구비되는 상위 온톨로지; 상기 상위 온톨로지를 다수의 도메인의 환경에 각각 적합하게 정의하기 위한 다수의 클래스를 구비하며, 상기 다수의 클래스는 상기 상위 온톨로지의 다수의 클래스의 하위 클래스로 정의되는 도메인 온톨로지; 상기 다수의 도메인에 하나 이상 포함되는 존(zone)을 각각 담당하며, 해당 존에 존재하는 다수의 디바이스로부터의 상황 데이터들을 수집하여 인스턴스들을 생성하고, 상기 상위 및 도메인 온톨로지에 정의된 다수의 클래스와 프로퍼티를 통해 표현된 지식에 대해 클래스간 암시적 포함관계의 추론 및, 상기 인 스턴스들이 상기 상위 및 도메인 온톨로지에 구비되는 다수의 컨텍스트 클래스 중 어느 클래스에 포함되는지를 추론하여 로우 레벨 컨텍스트를 도출하고, 도출된 하나 이상의 상기 로우 레벨 컨텍스트로부터 경험적 규칙을 SWRL로 작성한 규칙에 따라 하이 레벨 컨텍스트를 도출하고, 상기 하이 레벨 컨텍스트에 대응되는 맵핑된 서비스 제공을 요청하는 상황인식 협업 시스템; 상기 다수의 상황 인식 협업 시스템으로부터의 하이 레벨 컨텍스트들을 제공받아, 다수의 존을 이동하는 이용자에 대한 하이 레벨 컨텍스트들과 이용자에 대한 이용자 정보를 토대로 다음 서비스를 결정하고, 상기 결정된 서비스의 제공을 요청하는 상황정보 처리 시스템;을 구비한다.

본 발명은 이용자의 상황을 고려한 개인화된 서비스를 제공하기 위해 사용자를 둘러싼 위치, 시간, 디바이스, 개인 정보 및 선호도, 행위, 일정 등을 온톨로지를 이용하여 표현하고, 명시적으로 표현되지 않은 암묵적 상황을 추론을 통해 인식하여, 지능적이며 능동적인 이용자 중심의 서비스를 제공할 수 있다.

본 발명의 바람직한 실시예에 따른 상황 인지 시스템은 첨단 정보통신망을 기반으로 한 다양한 유비쿼터스 서비스를 주거, 경제, 교통, 시설 등 다양한 도시의 구성 요소에 적용하고, 이를 이용하는 이용자의 상황을 고려하여 개인화된 유비쿼터스 서비스를 제공한다.

상기한 본 발명의 상황 인지 시스템은 이용자의 상황을 고려한 개인화된 서 비스를 제공하기 위해 사용자를 둘러싼 위치, 시간, 디바이스, 개인 정보 및 선호도, 행위, 일정 등을 온톨로지를 이용하여 표현하고, 명시적으로 표현되지 않은 암묵적 상황을 추론을 통해 인식하여, 지능적이며 능동적인 이용자 중심의 서비스를 제공한다.

본 발명의 상황 인지 시스템의 구성을 도 1을 참조하여 설명한다.

상기 상황 인지 시스템은 다수의 존(zone)에 각각에 대해 상황을 인식하고 그 상황에 대응되는 서비스를 도출하는 다수의 상황 인식 협업 시스템(1021~102N)과 상기 다수의 상황 인식 협업 시스템(1021~102N)의 상위 시스템으로 이용자를 중심으로 상황을 인식하여 존(zone)과 존(zone) 사이의 연속된 이용자의 컨텍스트를 관리하며, 상황 모델에 저장되어 있는 지식 및 외부 인프라를 통한 정보의 확장을 통해 상황을 융합 및 확장하여 이용자에게 제공할 최적의 서비스를 도출하는 상황정보 처리 시스템(100)으로 구성된다.

즉, 상기 다수의 상황 인식 협업 시스템(1021~102N)에서 특정한 공간(zone)에 존재하는 다양한 센서와 디바이스로부터 수집된 정보를 온톨로지의 인스턴스로 가공 및 표현함으로써 로우 레벨(low-level)의 상황을 인식하고, 다시 로우 레벨(low-level)의 상황을 조합하여 하이 레벨(high-level)의 상황을 도출함으로써, 하이 레벨의 상황에 적합한 공간 기반의 디바이스 협업 서비스를 제공하는 역할을 이행한다.

그리고, 상기 상황 정보 처리 시스템(100)은 상기 다수의 상황 인식 협업 시스템(1021~102N)에서 도출된 상황을 확장하여 사용자를 중심으로 한 다양한 상황 정보 및 주변 정보의 융합을 통한 하이 레벨(high-level)의 상황을 도출함으로써 최적의 서비스를 제공한다.

본 발명의 다음과 같은 특징적인 구성을 구비한다.

<첫째. 다양한 도메인(DOMAIN)에 적용 가능한 상위(upper) 온톨로지의 구성>

본 발명은 상황을 표현하고 인식하기 위해 웹 온톨로지 언어인 OWL을 사용하여 컨텍스트 엔티티(ContextEntity) 클래스와 상황을 구성하는 요소로서 컨텍스트 엔티티(ContextEntity)의 하위 클래스로 사람(Person), 장소(Space), 일정(Schedule), 장치(Device), 상태(Status), 행위(Action)를 정의한다. 이로서 어떤 도메인(DOMAIN)에서 발생하는 모든 상황에 대해 표현이 가능하게 되며, 상기한 상위(upper) 온톨로지를 기반으로 한 다양한 존(ZONE)에 적용 및 확장을 가능하게 한다.

즉, 상위(upper) 온톨로지를 u-Home, u-Convention, u-Work, u-Shopping 등의 도메인(DOMAIN) 별로 적용 및 확장하면 도메인(DOMAIN)별 특성과 이에 관련된 도메인(DOMAIN) 지식을 도메인(DOMAIN) 온톨로지로 표현이 가능하다. 이는 더욱 구체적인 상황인식을 가능하게 하는 이유가 된다.

<둘째. OWL(Ontology Web Language)의 DL(Description Logic) 추론과 SWRL의 규칙 추론을 결합하여 상황을 도출하는 구성>

그리고 본 발명은 서술 논리(Description Logic) 기반의 OWL(Ontology Web Language)의 표현력을 이용하여 로우 레벨(low level)의 컨텍스트(context)를 도출하고 이를 기반으로 하여 결정 가능한 성질을 가지는 일차 술어 논리 기반의 SWRL 을 상위 레벨(high-level) 상황인식에 이용함으로써 효과적인 상황 인식과 최적 서비스를 도출한다.

<셋째. 이용자 중심의 상황 인지 구성>

또한 본 발명은 상황 인식의 중심이 되는 이용자의 암묵적 상황과 이에 따른 서비스 요구에 대처하기 위해 특정 존(zone)내의 상황 인식뿐만 아니라 존(zone)과 존(zone) 사이의 이동으로 발생하는 연속된 상황을 끊김없이(seamless) 인식하기 위하여 특정 존(zone) 내의 상황 인식 및 이에 대응하는 서비스 도출을 담당하는 상황 인식 협업 시스템(1021~102N)의 상위 시스템으로 상황 정보 처리 시스템(100)을 구비한다.

상기 상황 정보 처리 시스템(100)은 존(zone)과 존(zone) 사이의 연속된 이용자의 컨텍스트를 관리하여 이용자의 상황 변화에 따라 존(zone)과 존(zone)을 연계한 이용자 중심의 서비스를 제공한다.

이제 상황 인지 시스템의 각부에 대한 구성 및 동작을 상세히 설명한다.

<상황 인식 협업 시스템의 상세>

상기 다수의 상황 인식 협업 시스템(1021~102N)은 그 구성 및 동작이 동일하므로, 이하 어느 한 상황 인식 협업 시스템(1021)에 대해서만 구성 및 동작을 상세 설명한다.

도 2는 본 발명의 바람직한 실시예에 따른 상황 인식 협업 시스템(1021)의 구성을 도시한 것이다.

상기 상황 인식 협업 시스템(1021)은 컨텍스트 생성부(200), 컨텍스트 매니저(202), 컨텍스트 레파지토리(204), 지식 베이스(206), 컨텍스트 인식부(208), 서비스 인식부(210), 동기 매니저(212)로 구성된다.

상기 컨텍스트 생성부(200)는 존(ZONE)에 존재하는 다양한 센서와 디바이스로부터 수집된 데이터를 제공받아 이를 분석하여 상기 도메인 온톨로지에 따른 인스턴스로 생성한다. 상기 존(ZONE)에 존재하는 다양한 디바이스는 고정 설치된 온도 센서나 조도 센서 등의 센서(300)와 조명장치나 방재장치 등의 디바이스(302)와 시각정보를 제공하는 타이머(304)와 이용자의 휴대 단말기 등이 될 수 있다.

상기 컨텍스트 매니저(202)는, 컨텍스트 생성부를 통해 생성된 상황정보 인스턴스를 저장, 수정, 삭제 및 질의하는 기능을 수행한다. 상기 생성된 상황정보 인스턴스는 컨텍스트 매니저를 통해 컨텍스트 레파지토리(204)에 저장되며, 이후 수정, 삭제, 질의가 가능하다.

- Repository Handler : Domain Context Repository 에 트리플을 저장, 수정, 삭제 및 쿼링할 수 있는 모듈

- Knowledge Base : 상황 도출에 필요한 상황 모델 및 인스턴스 저장을 위한 모듈

- Query Generator : 상황 도출에 필요한 데이터가 DB에 있을 경우 필요한 정보를 가져오기 위한 질의를 생성하고, 반환되는 정보를 받는 모듈

상기 컨텍스트 레파지토리(204)는, 상기 생성된 상황정보 인스턴스를 트리 플(TRIPLE) 형태로 저장 및 관리하는 역할을 담당한다.

상기 지식 베이스(206)는, 상기 상위 온톨로지 및 도메인 온톨로지를 통해 표현된 도메인 지식의 저장소이다.

상기 컨텍스트 인식부(208)는, 컨텍스트 레파지토리에 저장된 상황 정보 인스턴스와 상기 상위 온톨로지 및 도메인 온톨로지로 표현된 지식베이스를 사용하여 추론을 통해 로우 레벨의 상황을 인식하고, 다시 로우 레벨의 상황을 조합하여 하이 레벨의 상황을 도출하는 역할을 담당한다. 이때 도출된 하이 레벨의 상황이 상황정보 처리 시스템(100)으로 전달되어 상황이 확장 또는 융합될 필요가 있다고 판단되는 경우 도출된 하이 레벨의 상황을 상황정보 처리 시스템(100)으로 전달한다.

상기 서비스 인식부(210)는, 도출된 하이 레벨의 상황을 전달 받아 이에 적합한 공간 기반의 디바이스 협업 서비스를 도출하고 서비스 실행을 요청하기 위한 각종 파라미터의 값을 결정한다.

상기 동기 매니저(212)는, 존(ZONE) 내의 서비스 저장소(312)로부터 이용자에게 제공 가능한 서비스 목록 및 각 서비스 마다 실행을 위해 필요한 파라메타 정보를 가져와서 서비스 온톨로지에 저장함으로써 서비스를 동기화하는 역할을 담당한다.

그리고 센서(300)는 존 내의 상황 감지를 위해 설치된 각종 센서, 예를 들어 RFID 센서, 화재감지센서, 조도센서, 온도센서 등을 가리킨다.

디바이스(302)는 이용자가 소지한 노트북, 휴대 단말기와 같은 이동형 디바이스와 존 내에 설치된 에어콘, TV, 가습기, 냉장고, 엑추에이터 등의 고정형 디바 이스를 가리킨다.

타이머(304)는 존 내의 상황인식 협업 시스템에 설정된 일정 정보의 상황, 즉 일정의 시작 전, 후, 또는 일정의 진행 중임을 감지하기 위해 제공되는 시스템 스케줄러이다.

추론기(316)는 컨텍스트 인식부(410)에서 컨텍스트 레파지토리(406)와 지식베이스(408)을 이용하여 컨텍스트를 도출하기 위해 사용한다.

유-서비스 저장소(312)는 존 내의 제공 가능한 유비쿼터스 서비스를 웹서비스 형태로 저장하는 역할을 담당한다.

유-서비스 제공 시스템(314)은 상황인식 협업 시스템(200)에서 도출된 서비스의 호출을 받아 서비스를 제공하기 위해 서비스 대상 디바이스를 찾아 서비스를 구동시키는 역할을 담당한다.

이하, 상기한 상황인식 협업 시스템의 동작을 좀더 상세히 설명한다.

<상위(Upper) 온톨로지의 구조>

먼저 상위 온톨로지는 직접적으로 상황을 구성하는 요소들을 정의한 컨텍스트 엔티티(ContextEntity) 클래스와 컨텍스트 엔티티(ContextEntity)를 표현하는 데 사용되는 부가적인 클래스들로 구성된다.

상기 컨텐스트 엔티티(ContextEntity)는 하위 클래스로 사람(Person), 공간(Space), 일정(Schedule), 디바이스(Device), 상태(Status), 동작(Action)를 가진다.

상기 사람(Person)은 "동작을 가진다(has Action)" 프로퍼티를 통해 동작(Action)을 가지게 되며, 상기 동작(Action)은 입장(Enter), 퇴장(Leave), 머뭄(Stay) 등의 사람(Person)의 현재 상태(또는 행위)를 표현하는 하위 클래스를 가진다.

또한 상기 사람(Person)에 대한 개인화된 서비스를 제공하기 위해 "선호를 가진다(hasPreference)" 프로퍼티로 연결되는 이용자 기술(UserDescription) 클래스는 선호도와 습관을 기술하는 "선호(Preference)" 클래스와 "습관(Habit)" 클래스로 구성되며, 이러한 클래스들은 다시 도메인 온톨로지에서 하위 클래스를 정의하여 확장될 수 있다.

상기 공간(Space)는 이용자(Person)가 현재 존재하는 장소를 기술하며, 여기에는 하나의 서비스 범위로 규정된 영역인 존(Zone)과 이에 대응되는 논리적인 장소인 논리적인 공간(LogicalSpace)로 구분되며, 상기 존(Zone)은 "이름(locationName)" 프로퍼티를 통해 논리적인 공간(LogicalSpace)으로 표현된다.

상기 일정(Schedule)은 시간과 장소를 포함하는 예정된 일정을 기술하는 클래스이다. 이러한 일정은, "위치를 가지다(hasLocation)" 프로퍼티의 값으로 "논리적 공간(LogicalSpace)"를 가지는 익명 클래스와 시각(time) 온톨로지의 인터벌(Interval) 클래스의 교집합으로, owl:equivalantClass 구성자를 이용하여 다음과 같이 정의된다.

:Schedule

a owl:Class ;

rdfs:subClassOf :ContextEntity ;

owl:equivalentClass

[ a owl:Class ;

owl:intersectionOf ([ a owl:Restriction ;

owl:onProperty :hasLocation ;

owl:someValuesFrom :LogicalSpace

] time:Interval)

] .

여기에서 일정(Schedule)에 사용되는 시간(Time)은 별도의 클래스를 정의하지 않고 W3C에서 정의한 시각 온톨로지(Time Ontology)를 이용하여 표현함으로써 온톨로지의 재사용성을 구현하였다.

그리고 상기 장치(Device)는 하나의 서비스 범위로 규정된 영역인 존(Zone)안에서 이용 가능한 모든 디바이스를 기술하기 위한 것으로 고정형 디바이스인 설비형 디바이스(FacilityDevice)와 센서(Sensor), 그리고 이용자가 소지하는 휴대 단말기(MobileDevice)로 구분되며, 상기 휴대 단말기(MobileDevice)는 상기 이용자(Person)와 "소유(owns)" 프로퍼티 관계로 연결된다.

그리고 상기 상태(Status)는 일정(Schedule) 및 디바이스(Device) 타입에 따라 상태를 기술하는 개별 클래스로 구성되며, 이것은 도메인에 따라 다양하게 달라질 수 있으므로 하위 클래스들은 도메인 온톨로지에서 정의된다.

그리고 상기 상황을 도출하기 위해 상황 데이터의 표현에 사용되는 컨텍스트 엔티티(ContextEntity)외에 이 컨텍스트 엔티티(ContextEntity)로부터 도출되는 상황을 정의하는 컨텍스트(Context) 클래스와 컨텍스트(Context)에 대응되는 서비스를 정의한 서비스(Service) 클래스가 있으며, 컨텍스트(Context)는 "서비스를 가지다(hasService)" 프로퍼티로 서비스(Service)를 갖는다.

상기한 본 발명의 바람직한 실시예에 따른 상위 온톨로지의 구조를 도시한 것이 도 4이다.

상기한 도 4를 참조하면, 상기 사람(Person), 공간(Space), 일정(Schedule), 디바이스(Device), 상태(Status), 동작(Action)에 대한 클래스와 각 클래스들에 대한 서브 클래스들을 나타낸다. 또한 각 클래스들에 대한 프로퍼티를 나타낸다.

<도메인 온톨로지>

상기 도메인(Domain) 온톨로지는 상위(upper) 온톨로지를 도메인의 환경에 맞게 상위(upper) 온톨로지를 임포트하여 확장 및 정의한다. 즉, 유-컨벤션(u-Convention)에서의 상황인지를 위해서 상위(upper) 온톨로지에 정의된 컨텍스트엔티티(ContextEntity)를 구성하는 이용자(Person), 디바이스(Device), 상황(Status), 일정(Schedule) 등의 클래스 및 콘텍스트(Context)와 이에 관련된 서비스(Service) 클래스의 하위 클래스를 정의한다.

예를들어, 유-컨벤션(u-Convention) 도메인에서 이용자(Person) 클래스는 컨벤션에 참가하는 역할에 따라 발표자(Presenter), 세션장(SessionChair), 참석자(Attendee), 전시자(Exhibiter) 등으로 하위 클래스를 생성할 수 있다.

이와 같은 역할의 규정은 이용자(Person)를 정의역으로, 일정(Schedule)을 공역으로 갖는 배열(arrange) 프로퍼티를 확장하여 하위 프로퍼티로 각각 "프리젠테이션을 제공하다(givePresentation)", "관리하다(manage)", "안내하다(conduct)"를 정의하고, 각 프로퍼티에 대해 특정 역할의 조건을 만족하는 제한 클래스로 발표자(Presenter), 세션장(SessionChair), 전시자(Exhibiter)를 정의하여 표현하며, 이를 도시한 것이 도 5이다. 상기 도 5는 유-컨벤션(u-Convention) 도메인에서 이용자(person)와 스케쥴을 정의한 것을 도시한다.

즉, 발표자(Presenter)는 이용자(Person)의 하위 클래스이며 동시에 "프레젠테이션을 제공하다(givePresentation)" 프로퍼티의 값으로 일정(Schedule) 클래스의 하위 클래스로 유-컨벤션(u-Convention) 도메인에서 확장 정의된 컨벤션(Convention) 클래스의 하위 클래스인 프레젠테이션(Presentation) 클래스의 인스턴스를 갖는 제한 클래스로 정의된다.

:Presenter

a owl:Class ;

rdfs:subClassOf upper:Person ;

owl:equivalentClass

[ a owl:Restriction ;

owl:onProperty :givePresentation ;

owl:someValuesFrom :Presentation

] .

따라서 이용자(Person) 클래스의 인스턴스로 생성된 P1이 일정(Schedule) 클래스의 프레젠테이션(Presentation) 클래스의 인스턴스와 프레젠테이션 제공(givePresentation) 프로퍼티를 통해 관계되어 있다면, 이 P1은 추론의 결과로 발표자(Presenter)의 인스턴스로 분류되어 발표자로 인지된다.

이와 유사하게 유-컨벤션(u-Convention) 도메인에서 컨벤션이 진행되는 발표장이라는 공간을 구성하는 디바이스(Device)의 하위 클래스로서 온도센서(TemperatureSensor)가 확장 정의되고, 이의 상태를 기술하는 상황(Status) 클래스의 하위클래스인 온도상태(TemperatureStatus)도 또한 정의된다. 상기 온도센서(TemperatureSensor)는 "상태를 가지다(hasStatus)" 프로퍼티에 대한 값으로 온도상태(TemperatureStatus)에서 정의된 인스턴스 값만을 갖도록 owl:Restriction 구성자를 이용하여 제한 클래스로 다음과 같이 정의된다.

:TemperatureSensor

a owl:Class ;

rdfs:subClassOf upper:Sensor ;

owl:equivalentClass

[ a owl:Restriction ;

owl:allValuesFrom :TemperatureStatus ;

owl:onProperty upper:hasStatus

].

<상황 데이터의 인스턴스 생성과정>

이제 본 발명에 따른 상황 데이터의 인스턴스 생성과정을 설명한다.

상황 인식 협업 시스템의 컨텍스트 생성부(200)는 해당 존(zone) 내에서 발생하는 상황 데이터를 처리하여 상황 인지 모델 기반의 인스턴스로 생성하는 역할을 담당한다.

상기 컨텍스트 생성부(200)는 인스턴스생성기(Instance Generator)를 구비하며, 상기 인스턴스 생성기는 센서(300)와 디바이스(302), 그리고 타이머(304)를 통해 생성되는 상황 데이터를 수집 및 분석하여 상황 인지 모델 기반의 인스턴스로 변환한다.

여기서, 상황을 표현하는 데이터는 이용자의 상태를 기술하는 동작(Action) 데이터와, 고정 디바이스나 센서로부터 수집되는 센스(Sensed) 데이터와, 그리고 특정 스케줄에 설정된 타이머를 통해 발생되는 이벤트(Event) 데이터를 포함한다. 상기한 상황 데이터는 상황 인지 모델의 컨텍스트 엔티티(ContextEntity) 클래스의 각 해당하는 하위 클래스에 인스턴스로 생성됨으로써 상황 데이터를 의미적으로 표현한다.

특히, 상기 액션(Action) 데이터는 이용자가 존(zone)으로 구분된 특정 영역으로 입장(Enter)하거나, 퇴장(Leave)하는 등의 이용자의 상태를 나타내며, 이는 도 6에 도시한 바와 같이 인스턴스로 변환되어 상황 인지 모델에 저장된다. 상기 도 6에 도시한 인스턴스 P1은 특정 시각(2009.1.1 10:00 am) 입장(Enter_1)이라는 액션을 가지며(hasAction), 이용자 식별정보(user_001)를 가지고, 휴대 단말기(MD_001)를가지고, 컨퍼런스 룸(ConfernceRoom_1)에 위치(hasLocation)하는 것을 기술한다.

그리고 상기 센스(Sensed) 데이터는 존(zone)으로 구분된 특정 영역에 설치된 고정형 디바이스(Facility Device) 또는 각종 센서, 예를 들어 온도 센서, 조도 센서 등을 통해 수집된 상황 데이터이며, 이용자가 위치하고 있는 공간에 대한 상황을 표현하기 위해 도 7에 도시한 바와 같이 상황인지 모델 기반의 인스턴스로 변환된다. 상기 도 7을 참조하면 인스턴스 TemperatureSensor_001은 특정 시각(2009.1.1 12:00 am)이 센싱되었을 때(hasSensedTime)에 더움(HOT)이라는 상태를 가지며(hasStatus), 컨퍼런스 룸(ConferenceRoom_1)에 위치(hasLocation)하는 것을 기술한다

그리고 이벤트(Event) 데이터는 존(zone) 내에 예정된 일정(Schedule)에 대한 상황 데이터를 나타낸다.

즉, 타이머(304)를 통해 지금이 특정 일정, 예를 들어 유-컨벤션(U-Convention) 도메인에서의 프리젠테이션 이전(Before)인지 이후(After)인지 등, 상황 인지 모델에서 일정에 대한 상황을 식별하기 위하여 도 8에 도시한 바와 같이 인스턴스로 변환된다. 상기 도 8을 참조하면 인스턴스 Presentation_1은 특정 시각(2009.10.23 08:52 am)이 센싱되었을 때(hasSensedTime)에 이전(before)이라는 상태를 가지며(hasStatus), 타입이 프레젠테이션(presentation)이며(rdf:type), 컨퍼런스 룸(ConferenceRoom_1)에 위치(hasLocation)하는 것을 기술한다.

<컨텍스트 도출과정>

이제 이용자 중심의 서비스 제공을 위한 컨텍스트 도출 과정을 설명한다.

먼저, DL 추론을 이용하여 로우 레벨(low-level) 컨텍스트를 도출하는 방법을 설명한다.

OWL(웹 온톨로지 언어)로 표현된 온톨로지는 서술 논리(Description Login)를 기반으로 하고 있으며, 상기 서술 논리는 지식을 표현할 때 지식의 용어적 부분(TBox)과 선언적 부분(ABox)로 나누어 표현한다.

상기 용어적 부분(TBox) 추론은 온톨로지 스키마에 정의된 클래스와 속성을 통해 표현된 지식에 대해 클래스 간에 형성된 암시적인 포함 관계(Subsumption)를 명시적으로 추론하고, 상기 선언적 부분(ABox) 추론은 인스턴스 관계를 추론하여, 인스턴스가 어떤 클래스에 포함되는지를 명시적으로 추론한다.

상기한 컨텍스트 도출 과정은 센서나 디바이스 등으로부터 수집된 상황 데이터를 명시적인 컨텍스트로 가공하는 과정으로, 먼저 서술 논리를 기반으로 정의된 컨텍스트 엔티티(ContextEntity)의 하위 클래스 및 속성들 간의 관계를 통해 도출되는 컨텍스트를 표현하고, 센서나 디바이스 등으로부터 수집된 상황 데이터의 인스턴스를 추론을 통해 컨텍스트화한다.

이러한 로우 레벨(low-level) 컨텍스트 도출 과정을 예를 들어 설명한다.

상기 로우 레벨(Low-level) 컨텍스트 선언은 컨텍스트 엔티티(ContextEntity)를 구성하는 하위 클래스들을 확장하여 정의한 도메인 온톨로지, 여기서는 유-컨벤션(u-Convention) 도메인 온톨로지로 상황을 표현하기 위한 지식을 서술 논리화하고, 용어적 부분(TBox) 추론을 통해 포함(Subsumption) 관계를 추론함으로써 클래스와 서브 클래스의 관계를 도출한다.

용어적 부분(TBox)에 저장된 컨텍스트를 서술 논리로 나타낸 예는 다음과 같다.

로우 레벨(Low-level) 컨텍스트 선언의 예 :

UserEnterConferenceRoom = Person

owns.MobileDevice

hasAction.Enter

hasLocation.ConferenceRoom

UserEnterRegistrationCounter = Person

owns.MobileDevice

hasAction.Enter

hasLocatioin.RegistrationCounter

BeforePresentation = Presentation

hasStatus.Before

PresenterInPlatform = Person

givePresentation.BeforePresentation

hasAction.Enter owns.MobileDevice

hasLocation.Platform

상기한 컨텍스트 선언을 이용한 상황 데이터의 인스턴스 선언(assertion)과 그에 따른 컨텍스트 추론(Abox) 결과는 다음과 같다.

먼저, userID가 user001인 사람이 MD_001이라는 ID를 가진 휴대 단말기(Mobile Device)를 가지고 회의실(ConferenceRoom_1)에 입장했다는 동작(Action) 데이터가 (userID, hasAction, owns, hasLocation, hasSensedTime)의 형태로 상황 인식 협업 시스템(1021)에 전달되면, 상기 상황 인식 협업 시스템(1021)은 다음과 같은 인스턴스를 생성한다.

Person(P1)

userID(P1, user001)

Action(Enter_1)

has Action(P1, Enter_1)

Mobile_Device(MD_001)

owns(P1, MD_001)

LogicalSpace(ConferenceRoom_1)

hasLocation(P1, ConferenceRoom_1)

hasSensedTime(P1, 2009.1.1 10:00 am)

위와 같이 표현된 인스턴스들은 선언적 부분(ABox) 추론을 통해 어느 컨텍스트(context) 클래스에 포함되는지 추론하며, 위의 예가 휴대 단말기(Mobile Device)를 가진 이용자(Person)가 회의실(Conference Room)에 입장(enter)이라는액 션을 가지는(hasAction) 상황을 UserEnterConferenceRoom 컨텍스트로 정의했으므로, 이용자(Person)의 인스턴스인 P1은 UserEnterConferenceRoom에 포함하는(subsume) 것으로 추론된다. 따라서, 추론의 결과는 다음과 같이 표현된다.

UserEnterConferenceRoom(P1)

이러한 상황 표현은 조합되어 더욱 복합적인 상황을 표현할 수 있다.

또한 위의 예에서 BeforePresentation은 일정(Schedule) 클래스의 하위 클래스인 프레젠테이션(Presentation)이 가진 상태(hasStatus)가 "스케줄 시작 전(Before)인 상황을 나타내는 컨텍스트이며, 이 컨텍스트는 다음의 "발표자가 발표단상에 입장(PresenterInPlatform)의 상황을 판단하는 하위 컨텍스트로 사용된다.

상기 "발표자가 발표단상에 입장(PresenterInPlatform)" 컨텍스트는 타입이 이용자(Person)인 어떤 사람이 "프레젠테이션을 주다(givePresentation)"의 값으로 어떤 "프레젠테이션(Presentation)"을 가지며, 휴대 단말기(Mobile Device)를 소유하고 있고, 지금 발표단상(Platform)에 입장(Enter)했음이 인지된 상황을 표현한다. 여기에서, 발표단상(Platform)에 입장(Enter)한 이 사람(Person)이 발표하기로 예정된 이 프리젠테이션은 "프레젠테이션 전(BeforePresentation)"으로 정의된 컨텍스트하에 있는 프리젠테이션임을 나타내며," 프레젠테이션 전(BeforePresentation)" 컨텍스트는 "발표자가 발표단상에 입장(PresenterInPlatform)" 컨텍스트를 더욱 구체적이고 정확하게 표현하기 위해 사용된다.

이제 규칙(rule)을 이용한 하이-레벨(high-level) 컨텍스트를 도출하는 과정을 설명한다.

OWL(웹 온톨로지 언어)의 서술 논리는로우 레벨(low-level) 센서나 디바이스로부터 수집된 상황 데이터를 가공하여 암묵적으로 내재된 상황을 컨텍스트로 명시화하는 데 유용하다.

그러나 상기 OWL은 규칙 표현을 배제하는 단점으로 인해 복합적인 상황의 표현과 이에 따른 서비스 도출에 제약이 있다. 따라서 본 발명은 복합적인 상황, 즉 상황의 확장을 통한 다양한 상황의 융복합을 정의하고 표현하기 위한 하이-레벨(high-level) 컨텍스트를 정의하는 데 SWRL(Semantic Web Rule Language) 추론을 사용하였다.

상기 SWRL 추론은 경험적 규칙을 SWRL로 작성하여 지식의 용어적 부분(TBox)과 선언적 부분(ABox)의 관계를 추론하는 것을 의미하며, 규칙의 조건부에 정의한 용어적 부분(TBox)과 선언적 부분(ABox)의 관계가 성립하는 경우에 규칙의 결론을 유도하여 새로운 지식을 추론하는 것이다.

예를 들어, 로우 레벨(low-level) 컨텍스트로 정의된 "발표자가 발표단상에 입장(PresenterInPlatform)" 이라는 상황은 발표자가 단상에 들어옴이 인지되면 발표자가 미리 설정한 발표시의 조도(illuminance)에 대한 선호도 값으로 발표장의 조도를 맞추는 서비스를 제공하는 것이 될 수 있다. 이를 위해 "발표자가 발표단상에 입장(PresenterInPlatform)" 컨텍스트로 분류된(subsume) 발표자(P1)의 조도에 대한 선호도 값과 센서를 통해 수집된 발표장의 조도 상태 값을 비교함으로써 두 값이 같지 않다면 발표자에 대한 조도 맞춤 서비스가 필요하다는 컨텍스트를 도출하는 것이다.

이러한 내용을 SWRL 문법으로 표현하면 다음과 같다.

convention:LightingSensor(?lightSensor)

(?lightSensor upper:hasStatus ?lightStatus)

(?lightSensor upper:locatedIn ?loc_A)

PresenterInPlatform(?user)

(?user upper:hasLocation ?platform)

(?platform upper:isPartOf ?loc_B)

Equal(?loc_A, ?loc_B)

(?user convention:lightingPreference ?userlightPref)

notEqual(?lightStatus, ?userlightPref)

-> RequestLightingAdjustment(?user)

즉, "플랫폼에 발표자 입장(PresenterInPlatform)"이라는 컨텍스트를 기반으로 "플랫폼에 발표자 입장(PresenterInPlatform)" 컨텍스트가 발생한 장소(Space)에 존재하는 조도 센서(LightingSensor)의 상태 정보와 이용자(Presenter)의 조도에 대한 선호도 정보가 융합되어 조도 조절 요청(RequestLightingAdjustment)라는 하이-레벨(high-level) 컨텍스트가 도출된다.

이제 상기한 바와 같이 도출된 컨텍스트를 서비스와 매핑하는 과정을 설명한다.

컨텍스트(Context)와 서비스(Service)의 관계는 "서비스를 가지다(hasService)" 프로퍼티를 통해 연결된다. 상기 컨텍스트(Context) 클래스에 정의된 하이-레벨(high-level) 컨텍스트는 하위 클래스(subClassOf)로 선언된다.

상기 서비스(Service) 클래스는 실제 서비스 호출을 위한 서비스 네임(service name), 서비스 식별정보(service ID) 뿐만 아니라 파라메터(parameter) 들을 가진다. 상기 서비스(Service) 클래스는 "파라메터를 가지다(hasParameter)" 프로퍼티를 통해 파라메터(Parameter) 클래스를 가지게 되며 파라메터(Parameter) 클래스는 다시 파라미터 넘버(paramNo), 파라미터 타입(paramType), 파라미터 명(paramName), 파라미터 값(paramValue) 과 같은 속성, 즉 프로퍼티를 갖는다. 도 9는 상기한 본 발명에 따른 서비스 온톨로지를 도시한 것이다.

상기 도메인 온톨로지에서 서비스(Service) 클래스는 도메인, 예를 들어유-컨벤션(u-Convention) 환경에서 제공될 수 있는 각종 서비스(Service)로 구체화된다.

즉, "발표 전 상황(BeforePresentation)"이며, "발표단상에 발표자 입장( PresenterInPlatform )"인 상황에서 발표자가 선호하는 조도로 발표장의 조도를 셋팅하는 서비스는 서비스(Service) 클래스의 인스턴스로서 조도조정(LightingAdjustment) 라는 서비스로 선언된다.

상기의 예에서 "조도조정요청(RequestLightingAdjustment)" 컨텍스트로 분류된 인스턴스는 사실상 프리젠테이션이 예정된 이용자로 ?user라는 변수(variable)에 바인딩된 이용자(Person)의 인스턴스이다. "조도조정요 청(RequestLightingAdjustment)"이라는 상황(컨텍스트)하에 놓인 이 이용자는 "서비스를 가지다(hasService)" 프로퍼티를 통해 "조도조정(LightingAdjustment)"를 서비스로 갖게 된다.

상기 "조도조정(LightingAdjustment)" 서비스는 유-컨벤션(u-Convention) 도메인에서 실행 가능한 서비스로 서비스저장소에 저장되어 있으며, 상황인지시스템에서는 이를 호출하기 위해 서비스(Service) 온톨로지 내에 서비스 구동에 필요한 서비스 ID, 서비스 명, 파라메터(parameter) 타입, 파라메터(parameter) 순서 등이 프로파일(profile)로 정의된다.

따라서 컨텍스트에 적합한 서비스 인스턴스를 "서비스를 가지다(hasService)" 프로퍼티를 통해 매핑하게 되면 이 서비스를 호출하기 위해 필요한 파라미터 값들, 조도조정(LightingAdjustment)의 예에서는 이용자의 조도 선호도 값을 해당 컨텍스트 하에 분류된 인스턴스를 통해 읽어옴으로써 파라미터를 셋팅한다.

<상황정보 처리 시스템의 상세>

도 3은 본 발명의 바람직한 실시예에 따른 상황정보 처리 시스템(100)의 구성을 도시한 것이다.

상기 상황정보 처리 시스템(100)은 컨텍스트 확장부(400), 애드온 정보 요청부(402), 컨텍스트 매니저(404), 컨텍스트 레파지토리(406), 지식 베이스(408), 컨텍스트 인식부(410), 서비스 인식부(412), 동기 매니저(414)로 구성된다.

상기 컨텍스트 확장부(400)는, 상기 상황인식 협업 시스템(200)으로부터 전 달받은 하이 레벨 컨텍스트를 분석한 후 컨텍스트의 확장에 외부 정보가 필요하다고 판단되는 경우 애드온 정보 요청부(402)에 관련 정보를 요청한다.

상기 애드온 정보 요청부(402)는, 상기 컨텍스트 확장부(400)의 요청을 받아 외부 정보 데이터베이스(318) 또는 내부 정보 데이터베이스(310)을 접속하여 관련 정보를 요청하고 이를 컨텍스트 도출에 필요한 인스턴스로 변환하기 위해 트리플 컨버터(308)를 이용하여 변환한다.

상기 컨텍스트 매니저(404)는, 컨텍스트 확장부(400)를 통해 전달된 컨텍스트 정보 및 트리플 컨버터(308)를 통해 변환된 내부 정보, 또는 외부 정보를 컨텍스트 레파지토리에 저장, 수정, 삭제 및 질의하는 역할을 담당한다.

상기 컨텍스트 레파지토리(406)는, 상기 컨텍스트 정보 및 내부 정보 또는 외부 정보를 트리플 형태로 저장 및 관리하는 역할을 담당한다.

상기 지식 베이스(408)는, 상위 온톨로지 및 도메인 온톨로지로 표현된 도메인 지식을 가리킨다.

상기 컨텍스트 인식부(410)는, 수집되어 컨텍스트 레파지토리(406)에 저장된 컨텍스트 정보와 지식 베이스(408)를 이용하여 추론을 통해 컨텍스트를 도출한다.

상기 서비스 인식부(412)는, 컨텍스트 인식부(410)을 통해 도출된 하이 레벨 상황에 적합한 서비스를 도출하고 서비스 실행을 요청하기 위한 각종 파라미터의 값을 결정하는데, 이 때의 서비스는 공간 기반의 서비스가 아니라 이용자 중심의 서비스로, 복수 개의 디바이스 협업 서비스가 조합된 융복합 서비스 형태를 띠거나 위치에 상관없이 이용자의 휴대 단말기를 통해 제공되는 서비스이다.

그리고 외부 정보 데이터베이스(318)는 컨텍스트를 확장하기 위해 필요한 외부 정보를 얻기 위해 유-씨티의 기간 통신망을 이용하여 접근 가능한 외부 데이터베이스로서, 도시 교통 정보, 지역 정보, 날씨 정보 등을 예로 들 수 있다.

이제 상황정보 처리 시스템(100)의 동작을 상세히 설명한다.

주거, 경제, 교통, 시설 등 다양한 도시의 구성요소에 유비쿼터스 서비스를 적용한 유-씨티(u-City) 환경은 이용자의 도시 생활과 관련된 행위(activity)를 네트워크화된 각종 기기를 이용하여 편리하게 지원하기 위한 것이다.

따라서 본 발명은 특정 공간인 존(zone) 내에서의 상황 인식뿐만 아니라 존(zone)과 존(zone) 사이의 이동으로 발생하는 연속된 상황 간의 끊김없는(seamless) 복합적 상황을 인식한다.

이를 위해 본 발명은 존(zone) 내의 상황 인식 및 이에 대응하는 서비스 도출을 담당하는 상황 인식 협업 시스템(1021~102N)과, 다수의 존(zone)을 담당하는 각 상황 인식 협업 시스템(1021~102N)의 상위 시스템으로서의 상황 정보 처리 시스템(100)을 구비한다.

상기 상황정보 처리 시스템(100)은 이용자를 중심으로 상황을 인식하고 존(zone)과 존(zone) 사이의 연속된 이용자의 컨텍스트를 관리하며, 또한 상황 모델에 저장되어 있는 지식 및 외부 인프라 시스템을 통한 정보의 확장을 통해 상황을 융합하고 확장함으로써 이용자에게 최적의 서비스를 도출한다.

예를 들어 설명하면, 유-컨벤션(u-Convention) 도메인에서 발표장(conference room)은 하나의 존(zone)으로 구성되며, 발표장이라는 존(zone)을 담당하는 상황 인식 협업 시스템은 발표장이라는 특정 공간 내에서 발생하는 상황의 인식과 이에 따른 서비스들을 담당한다.

또한 유-컨벤션(u-Convention) 도메인에는 발표장 외에도 전시장(Exhibition Room)이라는 공간이 존재할 수 있다. 이 경우 본 발명의 상황 인지 시스템은 발표장에서 전시장으로 이동하는 이용자에게 이 두 존(zone)을 연계한 복합적 상황을 인식하고 그에 따른 서비스를 제공한다.

이를 도 10에 도시한 예를 참조하여 설명하면, "발표장(ConferenceRoom_1)에서 발표를 마친 이용자가 발표장을 떠난다(UserLeaveConferenceRoom)" 컨텍스트가 도출되면, 상기 발표장을 담당하는 상황 인식 협업 시스템(1021)은 "이용자가 발표장을 떠난다(UserLeaveConferenceRoom)" 컨텍스트를 도출하지만 이용자는 이미 발표장을 떠났으므로 이에 대한 서비스는 발생하지 않는다.

따라서 상황 인식 협업 시스템(1021)은 이 컨텍스트를 상황 정보 처리 시스템(100)에 전달한다.

상기 상황 정보 처리 시스템(100)은 "이용자가 발표장을 떠난다(UserLeaveConferenceRoom)" 컨텍스트를 받아 컨텍스트 분석을 통해 이 이용자가 발표를 끝냈으며(UserFinishedSchedule), 그 이후의 일정이 아직 없다는 것을 인식한다(UserHasNoNextSchedule). 이에 대해 상황 정보 처리 시스템(100)은 상황 모델에 저장되어 있는 이용자의 관심 분야, 즉 이용자(Person) 클래스에 관심(interest) 프로퍼티 값으로 연결되어 있는 관심 분야를 분석하고, 이에 매칭되는 이후 스케줄, 예를 들어 전시회의 관심 분야에 해당되는 부스들을 이용자에게 추천하는 서비스를 제공한다(RecommendNextSchedule).

상기 상황 정보 처리 시스템(100)은 이 서비스는 발표장을 나와 로비(Lobby) 존(zone)에 있는 이용자에게 제공된다.

이러한 상황 분석 및 확장, 그리고 서비스 도출은 존(zone)과 존(zone) 사이의 연계를 담당하는 상황 정보 처리 시스템에서 이루어지며, 이러한 이용자의 위치 센싱 및 존(zone) 내에서의 상황 인식과 이에 따른 하위 컨텍스트의 생성은 상황 인식 협업 시스템이 담당한다.

도 1은 본 발명의 바람직한 실시예에 따른 상황 인지 시스템의 구성도.

도 2는 본 발명의 바람직한 실시예에 따른 상황인식 협업 시스템의 구성도.

도 3은 본 발명의 바람직한 실시예에 따른 상황정보 처리 시스템의 구성도.

도 4 내지 도 9는 본 발명의 바람직한 실시예에 따라 온톨로지 구조 및 상황인지과정을 예시한 도면.

도 10은 본 발명의 바람직한 실시예에 따른 상황정보 처리 시스템의 처리 과정을 예시한 도면.

Claims (8)

1. 상황 인지 시스템에 있어서,

   상황을 구성하는 다수의 요소를 각각 정의하는 다수의 클래스를 구비하며, 상기 다수의 클래스 사이는 프로퍼티를 통해 연결되며, 각 클래스에는 상태를 표현하기 위한 하위 클래스가 구비되는 상위 온톨로지;

   상기 상위 온톨로지를 다수의 도메인의 환경 각각을 정의하기 위한 다수의 클래스를 구비하며, 상기 다수의 클래스는 상기 상위 온톨로지의 다수의 클래스의 하위 클래스로 정의되는 도메인 온톨로지;

   상기 다수의 도메인에 하나 이상 포함되는 존(zone)을 각각 담당하며,

   해당 존에 존재하는 다수의 디바이스로부터의 상황 데이터들을 수집하여 인스턴스들을 생성하고,

   상기 상위 및 도메인 온톨로지에 정의된 다수의 클래스와 프로퍼티를 통해 표현된 지식에 대해 클래스간 포함관계 및, 상기 인스턴스들이 상기 상위 및 도메인 온톨로지에 구비되는 다수의 클래스를 정의하는 다수의 하위 클래스 중 어느 클래스에 포함되는지를 추론하여 로우 레벨 컨텍스트를 도출하고,

   상기 로우 레벨 컨텍스트로부터 경험적 규칙을 SWRL로 작성한 규칙에 따라 하이 레벨 컨텍스트를 도출하고,

   상기 하이 레벨 컨텍스트에 대응되게 맵핑된 서비스 제공을 요청하는 상황인식 협업 시스템;

   상기 다수의 상황 인식 협업 시스템으로부터의 하이 레벨 컨텍스트들을 제공받아, 다수의 존을 이동하는 이용자에 대한 하이 레벨 컨텍스트들과 이용자에 대한 이용자 정보를 토대로 다음 서비스를 결정하고, 상기 결정된 서비스의 제공을 요청하는 상황정보 처리 시스템;을 구비하며,

   상기 상황 인식 협업 시스템은,

   상기 하이 레벨 컨텍스트에 매핑된 서비스가 존재하지 않으면, 상기 하이 레벨 컨텍스트를 상기 상황정보 처리 시스템으로 제공함을 특징으로 하는 상황 인지 시스템.
2. 제1항에 있어서,

   상기 상위 온톨로지는,

   웹 온톨로지 언어를 사용하여 컨텍스트 엔티티 클래스를 정의하고,

   이의 하위 클래스로서 사람, 장소, 시간, 일정, 장치, 상태, 행위를 정의하며,

   컨텍스트 엔티티 클래스의 하위 클래스들을 이용하여 표현되는 상황을 명시적으로 컨텍스트 클래스로 정의하고, 컨텍스트에 매핑되는 서비스를 서비스 클래스로 정의하며,

   상기 도메인 온톨로지는,

   상기 상위 온톨로지를 도메인별로 적용하여 도메인별 특성과 도메인 지식을 반영하고, 이를 이용하여 도메인별 상황들을 명시적으로 표현하는 컨텍스트들과 이에 매핑되는 서비스들을 정의함을 특징으로 하는 상황 인지 시스템.
3. 삭제
4. 제1항에 있어서,

   상기 로우 레벨 컨텍스트 및 상기 하이 레벨 컨텍스트는 조합되어 복합적인 상황을 표현함을 특징으로 하는 상황 인지 시스템.
5. 상황 인지 시스템을 통한 서비스 제공방법에 있어서,

   상황을 구성하는 다수의 요소를 각각 정의하는 다수의 클래스를 구비하며, 상기 다수의 클래스 사이는 프로퍼티를 통해 연결되며, 각 클래스에는 상태를 표현하기 위한 하위 클래스가 구비되는 상위 온톨로지;

   상기 상위 온톨로지를 다수의 도메인의 환경 각각을 정의하기 위한 다수의 클래스를 구비하며, 상기 다수의 클래스는 상기 상위 온톨로지의 다수의 클래스의 하위 클래스로 정의되는 도메인 온톨로지;를 구성하는 단계;

   상황 인식 협업 시스템이,

   상기 다수의 도메인에 하나 이상 포함되는 존(zone)을 각각 담당하며,

   해당 존에 존재하는 다수의 디바이스로부터의 상황 데이터들을 수집하여 인스턴스들을 생성하고,

   상기 상위 및 도메인 온톨로지에 정의된 다수의 클래스와 프로퍼티를 통해 표현된 지식에 대해 클래스간 포함관계 및

   상기 인스턴스들이 상기 상위 및 도메인 온톨로지에 구비된 클래스를 정의하는 다수의 하위 클래스 중 어느 클래스에 포함되는지를 추론하여 로우 레벨 컨텍스트를 도출하고,

   상기 로우 레벨 컨텍스트로부터 경험적 규칙을 SWRL로 작성한 규칙에 따라 하이 레벨 컨텍스트를 도출하고,

   상기 하이 레벨 컨텍스트에 대응되게 맵핑된 서비스 제공을 요청하는 단계;

   상황 정보 처리 시스템이,

   상기 다수의 상황 인식 협업 시스템으로부터의 하이 레벨 컨텍스트들을 제공받아, 다수의 존을 이동하는 이용자에 대한 하이 레벨 컨텍스트들과 이용자에 대한 이용자 정보를 토대로 다음 서비스를 결정하고, 상기 결정된 서비스의 제공을 요청하는 단계;를 구비하며,

   상기 상황 인식 협업 시스템은,

   상기 하이 레벨 컨텍스트에 매핑된 서비스가 존재하지 않으면, 상기 하이 레벨 컨텍스트를 상기 상황정보 처리 시스템으로 제공함을 특징으로 하는 상황 인지 시스템을 통한 서비스 제공방법.
6. 제5항에 있어서,

   상기 상위 온톨로지는,

   웹 온톨로지 언어를 사용하여 컨텍스트 엔티티 클래스를 정의하고,

   이의 하위 클래스로서 사람, 장소, 시간, 일정, 장치, 상태, 행위를 정의하며,

   상기 도메인 온톨로지는,

   상기 상위 온톨로지를 도메인별로 적용하여 도메인별 특성과 도메인 지식을 반영하며, 이를 이용하여 도메인별 상황들을 명시적으로 표현하는 컨텍스트들과 이에 매핑되는 서비스들을 정의함을 특징으로 하는 상황 인지 시스템을 통한 서비스 제공방법.
7. 삭제
8. 제5항에 있어서,

   상기 로우 레벨 컨텍스트 및 상기 하이 레벨 컨텍스트는 조합되어 복합적인 상황을 표현함을 특징으로 하는 상황 인지 시스템을 통한 서비스 제공방법.

Images