KR102156281B1

KR102156281B1 - 시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)의 정의

Info

Publication number: KR102156281B1
Application number: KR1020190000971A
Authority: KR
Inventors: 이창수; 강현국; 주성순
Original assignee: 고려대학교 세종산학협력단
Priority date: 2019-01-04
Filing date: 2019-01-04
Publication date: 2020-09-15
Also published as: KR20200084997A

Abstract

시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)의 정의가 개시된다. 일 실시예에 따른 기본대응규칙 정의 방법은, IoT 기기의 소셜 네트워크를 이용하여 다른 IoT 기기에 접근하기 위한 기본대응규칙을 정의하는 단계; 및 상기 정의된 기본대응규칙에 기초하여 IoT 기기간 질의 및 응답(Query&Answer)을 수행하는 단계를 포함할 수 있다.

Description

시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)의 정의{DEFINITION OF THE DEFAULT RESPONSE RULES FOR SPARAL OF IOT WHICH IS BASED ON SEMANTIC WEB}

아래의 설명은 웹 상에서 IoT 들이 협업을 위한 질의 및 응답(Query & Answer) 과정에서 SPARQL에 대한 기본대응규칙(DRRFS: Default Response Rules For SPARQL)을 정의하는 기술에 관한 것이다.

WebID은 W3C에서 제안한 표준에 따라 정의된 기술로, 에이전트 (개인, 조직, 그룹, 장치 등)를 참조하는 HTTP URI이다. WebID는 URI를 사용함으로써 전 세계적으로 고유한 식별자를 제공한다. WebID 프로파일은 WebID의 소유자를 설명하는 정보를 RDF 데이터 형식으로 작성한 문서이다. 이 문서의 데이터는 각각의 관계를 설명하는 온톨로지를 통해 정의된다. 온톨로지는 URI로 구성되어 있어 정의한 데이터에 전 세계적으로 고유한 식별자를 제공하고, 그 정의가 서비스를 대표할 수 있다.

SPARQL Protocol and RDF Query Language는 RDF 형식이나 RDF 형태의 구조화된 데이터를 처리하기 위한 질의 언어로 W3C에 의해 권고안으로 선정되었다. SPARQL의 주요 목적은 의미적(Semantic) 정보가 있는 질문을 표현하는 형식 언어(formal language)를 제공하는 것이다.

많은 IoT들이 생겨나면서, 다양한 IoT들을 쉽게 연결하고 공유할 수 있는 공통적인 이용환경이 필요하게 됨에 따라 특정 서비스를 위해 IoT들이 서로 통신하고 협력해서 공동의 작업을 하고, 협업했던 경험지식 데이터를 축척하고 활용할 수 있는 구조를 제공할 수 있다. 또한, 수많은 IoT들이 공통 사용 환경에서 서로 그룹을 이루어 협업을 하면서 생기는 많은 data는 네트워크에 심각한 트래픽을 일으킬 수 있다. 본 개발은 이러한 문제를 해결하기 위해서 시멘틱 웹 기반의 분산 social network을 구성하는 IoT의 구조를 설계하였다. 또한, social network을 통해 협업 가능한 상대방을 찾고, 협업 후 경험지식을 축척할 수 있는 IoT들의 자율협업서비스를 설계하고 구현하였다.

시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)을 통하여 IoT 들이 협업을 위한 질의 및 응답(Query & Answer)을 수행하는 방법 및 시스템을 제공할 수 있다.

기본신원정보를 갖춘 IoT은 독립적이고, 자율적 활동이 가능한 IoT Device이다. IoT는 RDF타입의 data를 저장하기 위해 Triple Database를 가지고 있으며, 자신의 정보를 Triple Database에서 직접 관리한다. 따라서 social network을 통해 웹상에서 협업 서비스를 구현하는 IoT들은 모두가 분산 social network을 갖는다. 분산 social network을 갖는 IoT들은 재귀적 질의를 통하여 협업파트너를 찾고 서비스를 제공한다.

기본대응규칙 정의 방법은, IoT 기기의 소셜 네트워크를 이용하여 다른 IoT 기기에 접근하기 위한 기본대응규칙을 정의하는 단계; 및 상기 정의된 기본대응규칙에 기초하여 IoT 기기간 질의 및 응답(Query&Answer)을 수행하는 단계를 포함할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 IoT 기기의 임시 저장장소 또는 경험지식 저장장소에 등록된 다른 IoT 기기들의 엔드포인트에 SPARQL에 기반한 질의를 통하여 협업을 위한 IoT 기기를 선정하는 기본대응규칙을 정의하는 단계를 포함할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 SPARQL에 기반한 질의문에 질문을 수신하는 IoT 기기의 엔드포인트 주소를 첨부하여 질의의 구조를 정의하는 단계를 포함할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 SPARQL에 기반한 질의에 대한 응답의 구조를 정의하는 단계를 포함하고, 상기 응답이 부정 응답일 경우, 'undefined'라고 대답하고, 상기 응답이 긍정 응답일 경우, IoT 기기의 웹 서버 주소로 대답할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 질의에 대한 결과 값이 부정 응답일 경우, 상기 부정 응답을 하기 전에, 경험지식 저장장소에 등록된 다른 IoT 기기들의 엔드포인트에 동일한 상기 SPARQL에 기반한 질의를 수행하고, 상기 다른 IoT 기기들로부터 질의에 대한 결과 값으로 부정 응답을 수신할 경우, 상기 부정 응답을 수행하도록 정의하는 단계를 포함할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 질의에 대한 결과 값이 긍정 응답일 경우, 상기 IoT 기기가 상기 IoT 기기의 웹 서버 주소로 응답하고, 상기 질의에 대한 결과 값이 부정 응답일 경우, 상기 부정 응답을 하기 전에, 상기 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기들에게 동일한 상기 SPARQL에 기반한 질의를 수행하도록 정의하는 단계를 포함할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 IoT 기기가 상기 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기부터 웹 서버 주소를 수신할 경우, 상기 다른 IoT 기기의 웹 서버 주소 뒤에 상기 IoT 기기의 웹 서버 주소를 첨부하여 응답하도록 정의하는 단계를 포함할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 IoT 기기가 상기 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기들부터 웹 서버 주소를 수신할 경우, 가장 먼저 응답한 IoT 기기의 웹 서버 주소만을 선택하도록 정의하는 단계를 포함할 수 있다.

상기 기본대응규칙을 정의하는 단계는, 상기 SPARQL에 기반한 질의를 종료하거나 SPARQL에 기반한 질의를 재시작하는 기본대응규칙을 정의하는 단계를 포함하고, 상기 SPARQL에 기반한 질의에 대한 응답으로 웹 서버 주소를 수신한 IoT 기기가 상기 웹 서버 주소를 수신한 IoT 기기의 경험지식 저장장소에 상기 수신된 웹 서버 주소와 동일한 웹 서버 주소가 존재하는지 확인하고, 상기 동일한 웹 서버 주소가 존재할 경우, 수신된 웹 서버 주소에 엔드포인트로 로그인하여 협업을 진행하고, 상기 동일한 웹 서버 주소가 존재하지 않을 경우, 신원확인절차를 수행하도록 정의할 수 있다.

상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는, 상기 IoT 기기간 신원확인절차를 수행함에 따라 등록된 IoT 기기들의 엔드포인트를 통하여 협업을 위한 IoT 기기를 선정하고, 상기 선정된 IoT 기기에 상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계를 포함할 수 있다.

상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는, IoT 기기가 별도의 IoT 기기로부터 질의된 질의문에 대한 부정 응답을 수행하기 전에, IoT 기기의 소셜 네트워크에 등록되어 있는 다른 IoT 기기들에게 SPARQL에 기반한 질의를 수행하고, 상기 다른 IoT 기기들로부터 상기 질의에 대한 결과값으로 긍정 응답 또는 부정 응답을 수신하는 단계를 포함할 수 있다.

상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는, 상기 다른 IoT 기기들로부터 상기 다른 IoT 기기들의 소셜 네트워크에 존재하는 또 다른 IoT 기기들에게 상기 SPARQL에 기반한 질의를 수행하고, 상기 또 다른 IoT 기기들 중 어느 하나의 IoT 기기로부터 상기 질의에 대한 결과 값으로 상기 어느 하나의 IoT 기기의 웹 서버 주소가 응답됨을 수신하는 단계를 포함할 수 있다.

상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는, 상기 수신된 어느 하나의 IoT 기기의 웹 서버 주소에 상기 다른 IoT 기기로부터 상기 질의에 대한 결과 값으로 상기 다른 IoT 기기의 웹 서버 주소가 부가되어 응답됨을 수신하는 단계를 포함할 수 있다.

상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는, 적어도 하나 이상의 IoT 기기에 대한 주소 정보가 부가된 결과 값 중에서 첫 번째 웹 서버 주소를 선택하고, 상기 선택된 첫 번째 웹 서버 주소와 상기 IoT 기기의 임시 저장장소 또는 경험지식 저장장소에 저장되어 있는 웹 서버 주소를 비교하여 일치하는 주소 정보가 존재하는지 확인하는 단계를 포함할 수 있다.

상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는, 상기 일치하는 주소 정보가 존재하지 않을 경우, 상기 선택된 첫 번째 웹 서버 주소에 로그인하여 신원확인절차를 수행한 후, 다시 SPARQL에 기반한 질의를 수행하는 단계를 포함할 수 있다.

기본대응규칙 정의를 위한 규칙 정의 시스템은, IoT 기기의 소셜 네트워크를 이용하여 다른 IoT 기기에 접근하기 위한 기본대응규칙을 정의하는 단계; 및 상기 정의된 기본대응규칙에 기초하여 IoT 기기간 질의 및 응답(Query&Answer)을 수행하는 단계를 포함할 수 있다.

시멘틱(Semantic) 기반의 IoT들이 질의하고 응답하는 기본 규칙을 최초로 정의하고 설계함으로써, 수많은 IoT가 Web 환경에서 목적을 위해 소통하고 답을 찾을 수 있다.

모든 IoT들이 질의 응답하는 기본 규칙을 따른다면, 인터넷은 수많은 IoT들이 소통할 수 있는 하나의 세상이 될 수 있다. 시멘틱 기술은 인터넷에 연결된 수많은 IoT 들의 새로운 Web application의 활용방법을 제시한다.

도 1은 일 실시예에 따른 IoT 기기의 구조를 설명하기 위한 도면이다.
도 2는 일 실시예에 따른 규칙 정의 시스템의 구성을 설명하기 위한 블록도이다.
도 3은 일 실시예에 따른 규칙 정의 시스템에서 시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)을 정의하는 방법을 설명하기 위한 흐름도이다.
도 4는 일 실시예에 따른 IoT 기기들의 신원확인 절차를 수행하는 동작을 설명하기로 한다.
도 5는 일 실시예에 있어서, 배송 드론과 게이트 1과의 협업 구성도를 나타낸 도면이다.
도 6은 일 실시예에 있어서, 기본대응규칙에 따른 답변을 수행하는 동작을 설명하기 위한 예이다.
도 7은 일 실시예에 있어서, 협업 이후 경험지식을 축적한 것을 설명하기 위한 예이다.

이하, 실시예를 첨부한 도면을 참조하여 상세히 설명한다.

도 1은 일 실시예에 따른 IoT 기기의 구조를 설명하기 위한 도면이다.

IoT 기기(100)는 PC(personal Computer), 스마트폰(smart phone), 태블릿(tablet), 웨어러블 컴퓨터(wearable Computer) 등과 같이 웹/모바일 사이트의 접속 또는 서비스 전용 어플리케이션의 설치 및 실행이 가능한 모든 전자 기기뿐만 아니라, IoT에 연결된 모든 사물들을 의미할 수 있다. IoT 기기(100)는 유형의 사물에만 국한되는 것이 아니라, 무형의 사물까지도 포함될 수 있다. 이러한 IoT 기기(100)에 시멘틱 웹 기반의 IoT의 기본신원정보를 정의하고, 정의된 기본신원정보에 기초하여 신원확인절차를 수행하여, IoT 기기들간 협업을 수행하기 위한 구조가 설계될 수 있다.

IoT 기기(100)는 Ubuntu 16.04 LTS와 JAVA(v1.8.0_181)를 기반으로 Node JS를 설치하고, 그 위에 상대방의 웹 ID를 수집하고 웹 ID를 통하여 상대방의 웹 서버에 로그인하기 위한 웹 서버(110)를 설치할 수 있다. 이때, 소스가 공개된 Socket IO 프로그램이 웹 서버로 이용될 수 있다. 그리고 수집된 웹 ID로부터 상대방의 프로파일(Profile)을 로드(Load)하고, 상대방의 엔드포인트(Endpoint)에 SPARQL하고, 경험지식데이터 등의 정보를 저장소인 TDB(Triple Database)에 저장하기 위해 Apache Jena Fuseki2(130)를 설치할 수 있다. 마지막으로 Python 2.7 기반에서 웹 ID, 프로파일 생성 및 관리를 위한 웹 ID 서버(예를 들면, Solid server)(120)를 설치할 수 있다.

Apache Jena Fuseki2(130)는 TDB(Triple Database)를 복수 개의 저장소 구조로 설계될 수 있다. 이때, 실시예에서는 3개의 저장소로 구성된 것을 설명하기로 한다. 표 1을 참고하면, TDB는 임시 저장장소(Temprary Knowledge), 업무관련지식 저장장소(TDB-Work knowledge), 경험지식 저장장소(Experience knowledge)로 구성될 수 있다. 임시 저장장소는 IoT 기기들로부터 획득된 데이터를 저장할 수 있고, 업무관련지식 저장장소는 업무와 관련된 데이터를 저장할 수 있고, 경험지식 저장장소는 임시 저장장소에 저장된 데이터 또는 업무관련지식 저장장소에 저장된 데이터가 축적되거나 협업하게 될 경우, 경험지식으로 변경되어 저장될 수 있다.

표 1:

IoT 기기(100)는 IoT를 식별하기 위한 기본신원정보(BII: Basic Identity Information)를 정의할 수 있다. 이때, 각각의 IoT 기기에 대한 웹 서버의 주소 정보, 웹 ID 정보 및 엔드포인트를 포함하는 기본신원정보를 정의할 수 있다. 이러한 기본신원정보를 정의하고, 정의된 기본신원정보에 기반하여 IoT 기기들 상호간 신원정보를 확인하는 신원확인절차가 수행됨에 따라 기본신원정보가 공유될 수 있다.

도 2는 일 실시예에 따른 규칙 정의 시스템의 구성을 설명하기 위한 블록도이고, 도 3은 일 실시예에 따른 규칙 정의 시스템에서 시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)을 정의하는 방법을 설명하기 위한 흐름도이다.

규칙 정의 시스템(200)의 프로세서는 정의부(210) 및 질의 응답부(220)를 포함할 수 있다. 일례로, 규칙 정의 시스템(200)는 IoT 기기 상에 어플리케이션 형태로 구현될 수 있으며, IoT 기기 대상에 서비스를 제공하는 플랫폼에 포함되는 형태로 구현될 수도 있다.

이러한 프로세서의 구성요소들은 규칙 정의 시스템에 저장된 프로그램 코드가 제공하는 제어 명령에 따라 프로세서에 의해 수행되는 서로 다른 기능들(different functions)의 표현들일 수 있다. 프로세서 및 프로세서의 구성요소들은 도 3의 시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)을 정의하는 방법이 포함하는 단계들(310 내지 320)을 수행하도록 규칙 정의 시스템을 제어할 수 있다. 이때, 프로세서 및 프로세서의 구성요소들은 메모리가 포함하는 운영체제의 코드와 적어도 하나의 프로그램의 코드에 따른 명령(instruction)을 실행하도록 구현될 수 있다.

프로세서는 시멘틱 웹 기반의 IoT의 SPARQL에 대한 기본대응규칙(DRRFS)을 정의하는 방법을 위한 프로그램의 파일에 저장된 프로그램 코드를 메모리에 로딩할 수 있다. 예를 들면, 규칙 정의 시스템에서 프로그램이 실행되면, 프로세서는 운영체제의 제어에 따라 프로그램의 파일로부터 프로그램 코드를 메모리에 로딩하도록 규칙 정의 시스템을 제어할 수 있다. 이때, 프로세서 및 프로세서가 포함하는 정의부(210) 및 질의 응답부(220) 각각은 메모리에 로딩된 프로그램 코드 중 대응하는 부분의 명령을 실행하여 이후 단계들(310 내지 320)을 실행하기 위한 프로세서의 서로 다른 기능적 표현들일 수 있다.

단계(310)에서 정의부(210)는 IoT 기기의 소셜 네트워크를 이용하여 다른 IoT 기기에 접근하기 위한 기본대응규칙을 정의할 수 있다. 정의부(210)는 IoT 기기의 임시 저장장소 또는 경험지식 저장장소에 등록된 다른 IoT 기기들의 엔드포인트에 SPARQL에 기반한 질의를 통하여 협업을 위한 IoT 기기를 선정하는 기본대응규칙을 정의할 수 있다. 정의부(210)는SPARQL에 기반한 질의문에 질문을 수신하는 IoT 기기의 엔드포인트 주소를 첨부하여 질의의 구조를 정의할 수 있다. 정의부(210)는 상기 SPARQL에 기반한 질의에 대한 응답의 구조를 정의할 수 있다. 이때, 응답이 부정 응답일 경우, 'undefined'라고 대답하고, 응답이 긍정 응답일 경우, IoT 기기의 웹 서버 주소로 대답될 수 있다. 정의부(210)는 질의에 대한 결과 값이 부정 응답일 경우, 부정 응답을 하기 전에, 경험지식 저장장소에 등록된 다른 IoT 기기들의 엔드포인트에 동일한 SPARQL에 기반한 질의를 수행하고, 다른 IoT 기기들로부터 질의에 대한 결과 값으로 부정 응답을 수신할 경우, 부정 응답을 수행하도록 정의할 수 있다. 정의부(210)는 질의에 대한 결과 값이 긍정 응답일 경우, IoT 기기가 IoT 기기의 웹 서버 주소로 응답하고, 질의에 대한 결과 값이 부정 응답일 경우, 부정 응답을 하기 전에, IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기들에게 동일한 SPARQL에 기반한 질의를 수행하도록 정의할 수 있다. 정의부(210)는 IoT 기기가 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기부터 웹 서버 주소를 수신할 경우, 다른 IoT 기기의 웹 서버 주소 뒤에 IoT 기기의 웹 서버 주소를 첨부하여 응답하도록 정의할 수 있다. 정의부(210)는 IoT 기기가 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기들부터 웹 서버 주소를 수신할 경우, 가장 먼저 응답한 IoT 기기의 웹 서버 주소만을 선택하도록 정의할 수 있다. 정의부(210)는 SPARQL에 기반한 질의를 종료하거나 SPARQL에 기반한 질의를 재시작하는 기본대응규칙을 정의할 수 있다. 정의부(210)는 SPARQL에 기반한 질의에 대한 응답으로 웹 서버 주소를 수신한 IoT 기기가 웹 서버 주소를 수신한 IoT 기기의 경험지식 저장장소에 상기 수신된 웹 서버 주소와 동일한 웹 서버 주소가 존재하는지 확인하고, 동일한 웹 서버 주소가 존재할 경우, 수신된 웹 서버 주소에 엔드포인트로 로그인하여 협업을 진행하고, 동일한 웹 서버 주소가 존재하지 않을 경우, 신원확인절차를 수행하도록 정의할 수 있다.

단계(320)에서 질의 응답부(220)는 정의된 기본대응규칙에 기초하여 IoT 기기간 질의 및 응답(Query&Answer)을 수행할 수 있다. 질의 응답부(220)는 IoT 기기간 신원확인절차를 수행함에 따라 등록된 IoT 기기들의 엔드포인트를 통하여 협업을 위한 IoT 기기를 선정하고, 선정된 IoT 기기에 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행할 수 있다. 질의 응답부(220)는 IoT 기기가 별도의 IoT 기기로부터 질의된 질의문에 대한 부정 응답을 수행하기 전에, IoT 기기의 소셜 네트워크에 등록되어 있는 다른 IoT 기기들에게 SPARQL에 기반한 질의를 수행하고, 다른 IoT 기기들로부터 질의에 대한 결과값으로 긍정 응답 또는 부정 응답을 수신할 수 있다. 질의 응답부(220)는 다른 IoT 기기들로부터 다른 IoT 기기들의 소셜 네트워크에 존재하는 또 다른 IoT 기기들에게 SPARQL에 기반한 질의를 수행하고, 또 다른 IoT 기기들 중 어느 하나의 IoT 기기로부터 질의에 대한 결과 값으로 어느 하나의 IoT 기기의 웹 서버 주소가 응답됨을 수신할 수 있다. 질의 응답부(220)는 수신된 어느 하나의 IoT 기기의 웹 서버 주소에 다른 IoT 기기로부터 질의에 대한 결과 값으로 다른 IoT 기기의 웹 서버 주소가 부가되어 응답됨을 수신할 수 있다. 질의 응답부(220)는 적어도 하나 이상의 IoT 기기에 대한 주소 정보가 부가된 결과 값 중에서 첫 번째 웹 서버 주소를 선택하고, 선택된 첫 번째 웹 서버 주소와 IoT 기기의 임시 저장장소 또는 경험지식 저장장소에 저장되어 있는 웹 서버 주소를 비교하여 일치하는 주소 정보가 존재하는지 확인할 수 있다. 질의 응답부(220)는 일치하는 주소 정보가 존재하지 않을 경우, 선택된 첫 번째 웹 서버 주소에 로그인하여 신원확인절차를 수행한 후, 다시 SPARQL에 기반한 질의를 수행할 수 있다.

도 4는 일 실시예에 따른 IoT 기기들의 신원확인 절차를 수행하는 동작을 설명하기로 한다.

IoT 기기(Smart Thing)들이 작업(Task)를 위하여 그룹을 구성하여 협업하고, 협업을 수행한 경험을 축적 및 활용하기 위하여 IoT 기기들이 신원확인절차를 수행하고, 협업 가능한 파트너를 찾는 동작을 설명하기로 한다. 이때, 제1 IoT 기기(Smart Thing A)(401)와 제2 IoT 기기(Smart Thing B)(402) 사이의 동작을 설명하기로 한다.

제1 IoT 기기(Smart Thing A)(401)와 제2 IoT 기기(Smart Thing B)(402)는 웹 서버, 웹 ID 서버 및 Apache Jena Fuseki로 구성될 수 있으며, 자신의 웹ID로 상대방의 웹 서버에 로그인하면서 소통을 시작할 수 있다.

제1 IoT 기기(Smart Thing A)(401)는 제1 IoT 기기(401)의 웹 ID를 사용하여 제2 IoT 기기(402)의 웹 서버에 로그인할 수 있다(1). 제2 IoT 기기(402)의 웹 서버는 제1 IoT 기기(401)의 웹 ID를 제2 IoT 기기(402)의 Apache Jena Fuseki에 전달할 수 있다(2). 제2 IoT 기기(402)는 제1 IoT 기기(401)의 웹 ID와 관련된 프로파일에 SPARQL을 수행할 수 있다(3). 이때, 프로파일이란 웹 서버 주소, 웹ID, 엔드포인트를 포함하는 기본신원정보일 수 있다. 기본신원정보는 IoT 기기가 자신의 신원을 다른 IoT 기기에게 알리기 위하여 가져야 할 가장 기본적인 정보이다.

제2 IoT 기기(402)는 제1 IoT 기기(401)의 웹 ID와 관련된 프로파일에 SPARQL 기반의 질의를 수행함에 따라 질의에 대한 응답으로 제1 IoT 기기(401)에 로드된 프로파일 정보를 획득할 수 있다(4). 제2 IoT 기기(402)는 획득된 제1 IoT 기기(401)에 대한 프로파일 정보를 제2 IoT 기기(402)의 저장소에 저장할 수 있다(5). 이때, TDB 중 TDB-Temporary Knowledge인 임시 저장장소에 저장될 수 있다.

제2 IoT 기기(402)는 제1 IoT 기기(401)의 기본신원정보에서 확인한 제1 IoT 기기(401)의 웹 서버에 제2 IoT 기기(402)의 웹 ID로 로그인할 수 있다(6). 제1 IoT 기기(401)는 제2 IoT 기기(402)의 웹 ID를 제1 IoT 기기(401)의 Apache Jena Fuseki2로 전달할 수 있다(7). 제1 IoT 기기(401)는 제2 IoT 기기(402)의 웹 ID와 관련된 프로파일에 SPARQL을 수행할 수 있다(8). 제1 IoT 기기(401)는 제2 IoT 기기(402)의 웹 ID와 관련된 프로파일에 SPARQL 기반의 질의를 수행함에 따라 질의에 대한 응답으로 제2 IoT 기기(402)에 로드된 프로파일 정보를 획득할 수 있다(9). 제1 IoT 기기(401)는 획득된 제2 IoT 기기(402)에 대한 프로파일 정보를 제1 IoT 기기(401)의 저장소에 저장할 수 있다(10). 이때, TDB 중 TDB-Temporary Knowledge인 임시 저장장소에 저장될 수 있다.

복수 개의 IoT 기기들이 서로 신원을 확인하는 신원확인절차를 위한 (1) 내지 (10)까지의 과정이 수행될 수 있다. 모든 IoT 기기들은 신원확인절차를 수행하여 서로의 신원을 확인할 수 있다. 신원확인절차를 완료한 후, 제1 IoT 기기(401)는 제2 IoT 기기(402)의 엔드포인트에 협업을 위한 SPARQL 기반의 질의를 수행할 수 있다(11). 이때, IoT 기기가 기본신원정보에 포함하고 있는 엔드포인트는 TDB-Work Knowledge를 의미할 수 있다.

이때, 제1 IoT 기기(401)와 제2 IoT 기기(402)는 질의 및 응답 과정에서 'SPARQL에 대한 기본대응규칙(DRRFS: Default Response Rules For SPARQL)'을 따른다. SPARQL에 대한 기본대응규칙을 설명하기로 한다.

표 1을 참고하면, 대상을 선정하는 기본대응규칙은 다음과 같이 나타낼 수 있다. 임시 저장장소 TDB(Temporary knowledge) 또는 경험지식 저장장소 TDB(Experience knowledge)에 등록된 IoT 기기들(모든 Smart thing들)의 엔드포인트에 SPARQL에 기반한 질의를 통하여 대상을 선정하는 기본대응규칙을 정의할 수 있다.

표 1:

표 2를 참고하면, 질문에 대한 기본대응규칙은 다음과 같이 나타낼 수 있다. 질문의 끝에 질문을 받는 모든 IoT 기기들의 엔드포인트 주소를 첨부할 수 있다.

표 2:

또한, SPARQL에 대한 긍정 응답 및 부정 응답에 대한 기본대응규칙을 정의할 수 있다. 다시 말해서, SPARQL에 답하는 기본대응규칙은 다음과 같이 나타낼 수 있다. 대답이 부정 응답('아니오')일 경우, IoT 기기들은 'undefined'라고 대답하고, 대답이 긍정 응답('예')일 경우, IoT 기기들은 자신의 IoT 기기의 웹 주소로 대답할 수 있다.

표 3을 참고하면, 대답이 '아니오'일 경우의 기본대응규칙에 관한 것이다. 답변 값이 아니오(No)인 IoT 기기들은 답변하기 전에 TDB <Experience knowledge>에 등록되어 있는 모든 소셜 네트워크(social network)의 엔드포인트에 똑같이 질문을 한다. 그 질문의 구조는 DRRFS 2와 같다.

표 3:

추가된 엔드포인트 주소 중에 중복되는 주소가 존재할 경우, 중복되는 주소에 대응하는 IoT 기기에는 질문을 하지 않는다. 모든 IoT 기기의 결과 값이 아니오('No')일 경우, 아니오('No')라고 답을 한다.

표 4를 참고하면, 대답이 '예'일 경우의 기본대응규칙에 관한 것이다.

표 4:

질의의 결과 값이 예('Yes')인 경우, IoT 기기는 자신의 웹 서버 주소로 답한다. 질의 받은 결과 값이 아니오('No')인 경우, IoT 기기는 결과를 답하기 전에 TDB-Experience knowledge에 등록된 모든 IoT 기기들에게 동일한 질의문을 SPARQL한다. 만약 제1 IoT 기기(Smart Thing A)가 TDB<Experience knowledge>에 등록된 제2 IoT 기기(Smart Thing B)로부터 제2 IoT 기기의 웹서버 주소를 받으면 제2 IoT 기기(Smart Thing B)의 웹서버 주소 뒤에 제1 IoT 기기(Smart Thing A)의 웹서버 주소를 첨부하여 답한다. 예를 들면, 'B's web server address + 'A's web server address와 같이 첨부할 수 있다. 만약 제1 IoT 기기(Smart Thing A)가 TDB<Experience knowledge>에 등록된 하나 이상의 다른 IoT 기기로부터 웹서버 주소를 받을 경우, 먼저 응답한 IoT 기기의 웹 서버 주소만을 선택한다.

표 5를 참고하면, 종료 또는 재시작에 대한 기본 대응 규칙을 나타낸 것이다. 질문 후 웹 서버 주소를 수신한 IoT 기기는 자신의 TDB에 동일한 웹 서버 주소가 있는지 확인한다. 만약 동일한 웹 서버 주소가 존재한다면, 동일한 웹 서버 주소에 엔드포인트로 로그인하고 협업을 진행한다. 만약 동일한 웹 서버 주소가 존재하지 않는다면, 신원확인절차를 거친후 다시 동일한 웹 서버 주소가 있는지 확인하고, 웹 서버 주소에 엔드포인트로 로그인하고 협업을 진행할 수 있다.

표 5:

이러한 신원확인절차가 완료됨에 따라 IoT 기기간 협업이 수행될 수 있다. 예를 들면, IoT 기기가 드론일 경우, 드론 간에 우편물 배송 협업을 수행할 수 있다. 드론 간에 우편물 배송 협업시스템(The mailing and delivery collaboration system among drones)에서 배송 드론의 TDB-Temporary knowledge는 http://ccl.korea.ac.kr:3030 /temp이며, 데이터를 임시로 저장하는 장소이다. TDB-Work knowledge는 http://ccl.korea.ac.kr:3030/ds이며, 업무 데이터를 저장하는 장소이다. 그리고 TDB-Experience knowledge는 http://ccl.korea.ac.kr:3030/ds이며, 협업 후 경험지식데이터를 저장하는 장소이다. 배송 드론은 협업을 위한 두 개의 질의문을 가지고 있을 수 있으며, 질의할 수 있다. 첫 번째는 '너는 0.8kg의 우편물을 운반할 수 있는가?'이고 두 번째는 '너는 AAA에게 우편물을 전달할 수 있는가?'이다. 다시 말해서, 배송 드론은 0.8kg의 우편물을 AAA에게 전달할 수 있는 사내 드론을 찾는 것이다.

제1 IoT 기기(401)는 TDB-Work knowledge에 우편물 정보가 있으며, 제2 IoT 기기(402)의 TDB-Work knowledge에는 제2 IoT 기기(402)가 운반할 수 있는 한계 무게(limit weight) 정보가 들어있다고 하자. 제1 IoT 기기(401) 및 제2 IoT 기기(402)는 배송 드론에서 질의하는 두 개의 질의문에 대한 답을 확인할 수 있다(12). 만약, 답이 '예'일 경우, 제1 IoT 기기(401)는 제1 IoT 기기의 엔드포인트를 제2 IoT 기기(402)의 웹 서버에 입력할 수 있다(13). 이때, 만약, 답이 '아니요'일 경우, 제1 IoT 기기(401)는 다시 다른 상대방을 탐색하여 (1)번 과정부터 다시 시작할 수 있다.

제2 IoT 기기(402)의 웹 서버는 제1 IoT 기기(401)의 엔드포인트를 SPARQL에 기반하여 질의를 수행할 수 있다(14). 제2 IoT 기기(402)는 제1 IoT 기기(401)의 엔드포인트를 통하여 로드된 우편물 정보를 획득할 수 있다(15, 16). 제2 IoT 기기(402)는 획득된 제1 IoT 기기(401)의 우편물 정보를 TDB-Temporary knowledge에 저장할 수 있다(17). 제1 IoT 기기(401)는 TDB-Temporary knowledge에 저장했던 제2 IoT 기기(402)의 프로파일을 TDB-Experience knowledge로 이동 저장할 수 있다. 마찬가지로, 제2 IoT 기기(402)도 TDB-Temporary knowledge에 저장했던 제1 IoT 기기(401)의 프로파일을 제2 IoT 기기(402)의 TDB-Experience knowledge로 이동 저장할 수 있다(18). 이때, IoT의 TDB-Experience knowledge는 협업을 했었던 자신의 경험지식이며 또한 소셜 네트워크(social network) 정보이기도 하다. 협업을 완료한 이후에, 제1 IoT 기기(401)가 동일한 작업을 다시 하게 될 경우, 경험지식이 축적된 제2 IoT 기기(402)의 엔드포인트에 곧바로 SPARQL 함으로써 보다 빠르게 협업을 수행 및 완료할 수 있다.

도 5는 일 실시예에 있어서, 배송 드론과 게이트 1과의 협업 구성도를 나타낸 도면이다.

도 5 및 도 6에서는 드론 간에 우편물 배송 협업을 수행하는 것을 예를 들어 설명하기로 한다. 여기서, IoT 기기는 드론일 수 있으며, 배송 드론(501) 및 복수 개의 사내 드론(502, 503, 504)이 존재한다고 가정하자. 수령인이 근무하는 회사에 우편물을 가져온 배송 드론(Delivery drone)(501)이 우편물을 수령인에게 정확히 전달할 수 있는 사내 드론(In-house drone#3)(504)을 찾고, 가지고 온 우편물을 전달해주는 것이다. 사내 드론(502, 503, 504)은 회사 내의 우편물 배송을 담당할 수 있다. 모든 IoT기기들에서 물리적인 이동과 우편물이 GPS와 기계적 장치를 이용하는 별도의 어플리케이션으로 대체된다고 가정하기로 한다.

기본신원정보를 갖춘 배송 드론(501)은 우편물을 수령인에게 전달할 수 있는 사내 드론 #3(504)을 찾기 위해 DRRFS에 따라서 사내 드론(502, 503, 504)에게 SPARQL할 수 있다. 배송을 완료한 배송 드론(501)과 사내 드론#3(504)은 상대방의 기본신원정보(BII)를 경험지식 저장장소(TDB-Experience knowledge)에 저장할 수 있다. 이것은 협업 경험지식 데이터가 된다. 협업 이후, 배송 드론(501)은 동일한 업무를 수행 시 추가된 경험지식 데이터를 이용하여 더욱 빠르고 정확하게 협업 파트너를 탐색할 수 있다.

표 5는 드론 간에 우편물 배송 협업에 등장하는 IoT들의 세부 데이터이다. 각 IoT 기기의 기본신원정보 및 TDB 정보를 설명하고 있다.

표 5:

수령인이 회사로 우편물을 가지고 온 배송 드론(501)이 게이트 1(Gate 1)(510)에 로그인했을 때, 게이트 1(510)이 자신의 소셜 네트워크를 이용하여 배송 드론(501)에게 적합한 사내 드론을 연결해주는 협업 시나리오의 구현 동작을 설명하기로 한다. 이것은 게이트 1(510)이 게이트 1의 소셜 네트워크에서 해답을 찾는 방법이기도 하다. 이때, 소셜 네트워크는 각각의 IoT 기기가 다른 IoT 기기와 관계를 맺고 있는 관계 정보를 의미할 수 있다. 도 5를 참고하면, 게이트 1(510)과 사내 드론 #1(502), 사내 드론 #2(503)가 소셜 네트워크 그룹을 구성하고 있고, 사내 드론 #2(503)와 사내 드론 #3(504)이 소셜 네트워크를 구성하고 있다.

도 6예서는 기본대응규칙에 따른 답변을 수행하는 동작을 설명하기로 한다. 회사에 도착한 배송 드론(501)은 게이트 1(510)의 웹 서버에 배송 드론(501)의 웹 ID로 로그인할 수 있다.

배송 드론(501)과 게이트 1(510)은 신원확인 절차를 수행할 수 있다. 배송 드론(501)은 복수 개(예를 들면, 2개)의 질의문인 '너는 0.8kg의 우편물을 운반할 수 있는가?', '너는 AAA에게 우편물을 전달할 수 있는가?'를 게이트 1(510)의 엔드포인트를 통하여 SPARQL에 기반한 질의를 수행할 수 있다(1).

SPARQL에 대한 응답은 표 1 내지 4의 기본대응규칙을 따르며, 기본대응규칙에 따른 진행은 도 5와 같이 동작할 수 있다.

게이트 1(510)은 'NO'라고 답하기 전에, <DRRFS-3>의 SPARQL에 답하기('Yes'인 경우)에 따라서 게이트 1(510)의 소셜 네트워크에 등록되어 있는 사내 드론 #1(502), 사내 드론 #2(503)에게 동일하게 SPARQL에 기반한 질의를 수행할 수 있다(2). 사내 드론 #1(502)는 <DRRFS-2>의 SPARQL에 답하기('NO'인 경우)에 따라서 질의에 대한 결과 값으로 'No'를 응답할 수 있다(3).

사내 드론 #2(503)은 'NO'라고 답하기 전에, <DRRFS-3>의 SPARQL에 답하기('Yes'인 경우)에 따라서 사내 드론 #3(504)에게 동일하게 SPARQL에 기반한 질의를 수행할 수 있다(4). 사내 드론 #3(504)은 <DRRFS-3>의 SPARQL에 답하기('Yes'인 경우)에 따라서 질의에 대한 결과 값으로 사내 드론 #2(503)에게 사내 드론 #3(504)의 웹 서버 주소 'http://dd3.korea.ac.kr:3000'로 응답할 수 있다(5).

<DRRFS-3>에 따라서, 사내 드론 #2(503)는 게이트 1(510)에게 결과 값으로 사내 드론 #3(504)의 웹 서버 주소에 사내 드론 #2(503)의 웹 서버 주소를 부가하여 응답할 수 있다. 예를 들면, 사내 드론 #2(503)는 'http://dd3.korea.ac.kr + http://dd2.korea.ac.kr'를 응답할 수 있다(6). 이때, 사내 드론 #2(503)은 사내 드론 #3(504)의 웹 서버 주소 앞에 사내 드론 #2(503)의 웹 서버 주소를 부가하는 형식을 취할 수 있다.

게이트 1(510)은 배달 드론(501)에게 결과 값으로 사내 드론 #3(504)의 웹 서버 주소 및 사내 드론 #2(503)의 웹 서버 주소에 게이트 1(510)의 웹 서버 주소를 부가하여 응답할 수 있다. 예를 들면, 게이트 1(510)은 'http://dd3.korea.ac.kr + http://dd2.korea.ac.kr + http://ccl.korea.ac.kr'를 응답할 수 있다(7). 이때, 게이트 1(510)은 사내 드론 #3(504)의 웹 서버 주소 및 사내 드론 #2(503)의 웹 서버 주소 앞에 게이트 1(510)의 웹 서버 주소를 부가하는 형식을 취할 수 있다.

배송 드론(501)은 <DRRFS-4>에 따라서 게이트 1(510)의 결과 값으로 'http://dd3.korea.ac.kr + http://dd2.korea.ac.kr + http://ccl.korea.ac.kr' 중에 첫 번째 주소(맨 앞의 주소)인 'http://dd3.korea.ac.kr' 만을 선택할 수 있다. 다시 말해서, 결과 값 중 맨 앞의 웹 서버 주소가 협업을 위하여 탐색된 IoT 기기들의 웹 주소 정보 중 협업 파트너인 IoT 기기의 웹 주소 정보를 의미할 수 있고, 맨 앞의 웹 서버 주소 이외의 주소 정보들은 협업 파트너인 IoT 기기의 웹 주소 정보를 획득하기 위한 경로 정보일 수 있다.

배송 드론(501)은 배송 드론(501)의 경험지식 저장장소와 임시 저장장소에 저장되어 있는 웹 서버 주소 중에 http://dd3.korea.ac.kr와 동일한 주소가 있는지 확인할 수 있다. 배송 드론의 경험지식 저장장소 및 임시저장장소에 http://dd3.korea.ac.kr와 동일한 주소가 없으면, http://dd3.korea.ac.kr에 로그인하고 신원확인절차를 거친 후 다시 SPARQL에 기반한 질의를 수행할 수 있다(8).

배송 드론(501)은 사내 드론 #3(504)의 엔드포인트를 통하여 SPARQL에 기반한 질의를 수행하고, 질의에 대한 응답으로 결과 값 http://dd3.korea.ac.kr을 확인할 수 있다.

배송 드론(501)은 임시 저장장소에 사내 드론 #3(504)과 동일한 웹 서버 주소가 존재하므로, 배송 드론(501)의 엔드포인트, 'http://ccl.korea.ac.kr:3030/ds/query'로 사내 드론 #3(504)의 웹 서버에 로그인할 수 있다.

사내 드론 #3(504)은 배송 드론(501)에 로드된 우편물 정보를 획득하여 임시 저장장소에 저장할 수 있다. 실시예에서는 각 IoT들의 물리적인 이동과 우편물 전달은 GPS와 기계적 장치를 이용한 별도의 어플리케이션으로 대체된다고 가정하였으므로, 사내 드론 #3(504)이 배송 드론(501)의 우편물 정보를 가져오는 것으로 대체할 수 있다.

배송 드론(501)과 사내 드론 #3(504)은 임시 저장장소에 저장되어 있던 상대방, 예를 들면, 배송 드론(501)은 사내 드론 #3(504), 사내 드론 #3(504)은 배송 드론(501)의 기본신원정보를 경험지식 저장장소에 이동 저장할 수 있다.

향후에, 배송 드론(501)이 동일한 업무를 수행하게 될 경우, 추가된 사내 드론 #3(504)의 엔드포인트에 곧바로 SPARQL을 할 수 있다.

도 7은 일 실시예에 있어서, 협업 이후 경험지식을 축적한 것을 설명하기 위한 예이다. 도 7을 참고하면, 배송 드론(501)과 사내 드론 #3(504)의 협업 이후 축적된 경험지식을 나타낸 것이다. 협업이 완료된 후 배송 드론(501)은 사내 드론 #3(504)의 기본신원정보를 경험지식데이터에 추가로 저장할 수 있으며, 사내 드론 #3(504)은 배송 드론(501)의 기본신원정보를 경험지식데이터에 추가로 저장할 수 있다.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims

기본대응규칙 정의 방법에 있어서,
IoT 기기의 소셜 네트워크를 이용하여 다른 IoT 기기에 접근하기 위한 기본대응규칙을 정의하는 단계; 및
상기 정의된 기본대응규칙에 기초하여 IoT 기기간 질의 및 응답(Query&Answer)을 수행하는 단계
를 포함하는 기본대응규칙 정의 방법.
제1항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 IoT 기기의 임시 저장장소 또는 경험지식 저장장소에 등록된 다른 IoT 기기들의 엔드포인트에 SPARQL에 기반한 질의를 통하여 협업을 위한 IoT 기기를 선정하는 기본대응규칙을 정의하는 단계
를 포함하는 기본대응규칙 정의 방법.
제2항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 SPARQL에 기반한 질의문에 질문을 수신하는 IoT 기기의 엔드포인트 주소를 첨부하여 질의의 구조를 정의하는 단계
를 포함하는 기본대응규칙 정의 방법.
제2항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 SPARQL에 기반한 질의에 대한 응답의 구조를 정의하는 단계
를 포함하고,
상기 응답이 부정 응답일 경우, 'undefined'라고 대답하고, 상기 응답이 긍정 응답일 경우, IoT 기기의 웹 서버 주소로 대답하는
기본대응규칙 정의 방법.
제4항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 질의에 대한 결과 값이 부정 응답일 경우, 상기 부정 응답을 하기 전에, 경험지식 저장장소에 등록된 다른 IoT 기기들의 엔드포인트에 동일한 상기 SPARQL에 기반한 질의를 수행하고, 상기 다른 IoT 기기들로부터 질의에 대한 결과 값으로 부정 응답을 수신할 경우, 상기 부정 응답을 수행하도록 정의하는 단계
를 포함하는 기본대응규칙 정의 방법.
제4항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 질의에 대한 결과 값이 긍정 응답일 경우, 상기 IoT 기기가 상기 IoT 기기의 웹 서버 주소로 응답하고, 상기 질의에 대한 결과 값이 부정 응답일 경우, 상기 부정 응답을 하기 전에, 상기 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기들에게 동일한 상기 SPARQL에 기반한 질의를 수행하도록 정의하는 단계
를 포함하는 기본대응규칙 정의 방법.
제6항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 IoT 기기가 상기 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기부터 웹 서버 주소를 수신할 경우, 상기 다른 IoT 기기의 웹 서버 주소 뒤에 상기 IoT 기기의 웹 서버 주소를 첨부하여 응답하도록 정의하는 단계
를 포함하는 기본대응규칙 정의 방법.
제6항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 IoT 기기가 상기 IoT 기기의 경험지식 저장장소에 등록된 다른 IoT 기기들부터 웹 서버 주소를 수신할 경우, 가장 먼저 응답한 IoT 기기의 웹 서버 주소만을 선택하도록 정의하는 단계
를 포함하는 기본대응규칙 정의 방법.
제2항에 있어서,
상기 기본대응규칙을 정의하는 단계는,
상기 SPARQL에 기반한 질의를 종료하거나 SPARQL에 기반한 질의를 재시작하는 기본대응규칙을 정의하는 단계
를 포함하고,
상기 SPARQL에 기반한 질의에 대한 응답으로 웹 서버 주소를 수신한 IoT 기기가 상기 웹 서버 주소를 수신한 IoT 기기의 경험지식 저장장소에 상기 수신된 웹 서버 주소와 동일한 웹 서버 주소가 존재하는지 확인하고, 상기 동일한 웹 서버 주소가 존재할 경우, 수신된 웹 서버 주소에 엔드포인트로 로그인하여 협업을 진행하고, 상기 동일한 웹 서버 주소가 존재하지 않을 경우, 신원확인절차를 수행하도록 정의하는, 기본대응규칙 정의 방법.
제1항에 있어서,
상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는,
상기 IoT 기기간 신원확인절차를 수행함에 따라 등록된 IoT 기기들의 엔드포인트를 통하여 협업을 위한 IoT 기기를 선정하고, 상기 선정된 IoT 기기에 상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계
를 포함하는 기본대응규칙 정의 방법.
제1항에 있어서,
상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는,
IoT 기기가 별도의 IoT 기기로부터 질의된 질의문에 대한 부정 응답을 수행하기 전에, IoT 기기의 소셜 네트워크에 등록되어 있는 다른 IoT 기기들에게 SPARQL에 기반한 질의를 수행하고, 상기 다른 IoT 기기들로부터 상기 질의에 대한 결과값으로 긍정 응답 또는 부정 응답을 수신하는 단계
를 포함하는 기본대응규칙 정의 방법.
제11항에 있어서,
상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는,
상기 다른 IoT 기기들로부터 상기 다른 IoT 기기들의 소셜 네트워크에 존재하는 또 다른 IoT 기기들에게 상기 SPARQL에 기반한 질의를 수행하고, 상기 또 다른 IoT 기기들 중 어느 하나의 IoT 기기로부터 상기 질의에 대한 결과 값으로 상기 어느 하나의 IoT 기기의 웹 서버 주소가 응답됨을 수신하는 단계
를 포함하는 기본대응규칙 정의 방법.
제11항에 있어서,
상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는,
상기 수신된 어느 하나의 IoT 기기의 웹 서버 주소에 상기 다른 IoT 기기로부터 상기 질의에 대한 결과 값으로 상기 다른 IoT 기기의 웹 서버 주소가 부가되어 응답됨을 수신하는 단계
를 포함하는 기본대응규칙 정의 방법.
제13항에 있어서,
상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는,
적어도 하나 이상의 IoT 기기에 대한 주소 정보가 부가된 결과 값 중에서 첫 번째 웹 서버 주소를 선택하고, 상기 선택된 첫 번째 웹 서버 주소와 상기 IoT 기기의 임시 저장장소 또는 경험지식 저장장소에 저장되어 있는 웹 서버 주소를 비교하여 일치하는 주소 정보가 존재하는지 확인하는 단계
를 포함하는 기본대응규칙 정의 방법.
제14항에 있어서,
상기 정의된 기본대응규칙에 기초하여 질의 및 응답(Query&Answer)을 수행하는 단계는,
상기 일치하는 주소 정보가 존재하지 않을 경우, 상기 선택된 첫 번째 웹 서버 주소에 로그인하여 신원확인절차를 수행한 후, 다시 SPARQL에 기반한 질의를 수행하는 단계
를 포함하는 기본대응규칙 정의 방법.
기본대응규칙 정의를 위한 규칙 정의 시스템에 있어서,
IoT 기기의 소셜 네트워크를 이용하여 다른 IoT 기기에 접근하기 위한 기본대응규칙을 정의하는 정의부; 및
상기 정의된 기본대응규칙에 기초하여 IoT 기기간 질의 및 응답(Query&Answer)을 수행하는 질의 응답부
를 포함하는 기본대응규칙 정의를 위한 규칙 정의 시스템.