KR20190059952A

KR20190059952A - 분산형 시맨틱 디스크립터들을 통한 시맨틱 질의

Info

Publication number: KR20190059952A
Application number: KR1020197012405A
Authority: KR
Inventors: 쉬 리; 충강 왕; 취앙 리; 데일 시드
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2016-09-29
Filing date: 2017-09-29
Publication date: 2019-05-31
Also published as: WO2018064442A1; EP3516547A1; CN109791561A; JP2019537775A; US20180089281A1; JP7065082B2

Abstract

현재, 분산형 시맨틱 디스크립터(예를 들어, oneM2M <semanticDescriptor> 자원들)를 통한 직접적 시맨틱 질의 처리를 위한 기존의 솔루션은 없다. 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 복수의 애플리케이션이 여기서 논의된다. 제1 예시적인 방법에서, 시맨틱 질의는, 정보가 단일 시맨틱 디스크립터에 저장될 때 고려된다. 제2 예시적인 방법에서, 시맨틱 질의는, 요청되거나 기타의 방식으로 필요한 정보가 시맨틱 디스크립터에 저장되지 않을 때 고려된다. 제3 예시적인 방법에서, 시맨틱 질의는, 정보가 상이하지만 관련된 시맨틱 디스크립터들에 분산될 때 고려된다. 제4 예시적인 방법에서, 시맨틱 질의는, 정보가 상이하고 관련되지 않거나 피어 시맨틱 디스크립터들에 분산될 때 고려된다. 제5 방법에서, 기존의 시맨틱 자원 발견 메커니즘을 활용함에 의한 타겟 자원으로부터의 정보의 간접 질의가 있을 수 있다.

Description

분산형 시맨틱 디스크립터들을 통한 시맨틱 질의

관련 출원의 상호참조

본 출원은, 참조로 그 내용을 본 명세서에 포함시키는, 발명의 명칭이 "Semantic Query Processing Over Distributed Semantic Descriptors"인, 2016년 9월 29일 출원된 미국 가출원번호 제62/401,640호의 우선권을 주장한다.

시맨틱 웹(Semantic Web)

시맨틱 웹은 월드 와이드 웹 컨소시엄(World Wide Web Consortium)(W3C)에 의한 표준을 통한 웹의 확장이다. 이 표준은, 웹 상의 공통 데이터 포맷 및 교환 프로토콜, 가장 근본적으로는 RDF(Resource Description Framework)를 촉진한다.

시맨틱 웹은, 데이터를 위해 특별히 설계된 언어들: 자원 기술 프레임워크(Resource Description Framework)(RDF), 웹 온톨로지 언어(Web Ontology Language)(OWL), 및 확장가능한 마크업 언어(Extensible Markup Language)(XML)로 게시하는 것을 포함한다. 이들 기술들은 결합되어 링크된 데이터의 웹을 통해 웹 문서의 콘텐츠를 보완하거나 대체하는 설명을 제공한다. 따라서, 콘텐츠는, 웹-액세스가능한 데이터베이스에 저장된 설명 데이터로서, 또는 문서 내의 마크업으로서, 특히, XML 내에 산재된 XHTML(Extensible HTML) 또는 더 빈번하게는, 레이아웃 또는 렌더링 단서들이 별도로 저장된 순수하게 XML로서 나타날 수 있다.

시맨틱 웹 스택(Semantic Web Stack)

시맨틱 웹 스택은, 도 1에 도시된 바와 같이, W3C에 의해 명시된, 시맨틱 웹의 아키텍처를 도시한다. 도 1에 도시된 컴포넌트들의 기능 및 관계가 아래에서 논의된다. XML은 문서 내의 콘텐츠 구조에 대한 기본적인 신택스(elemental syntax)를 제공하지만, 어떠한 시맨틱(semantic)도 내부에 포함된 콘텐츠의 의미와 연관시키지 않는다. Turtle 등의 대안적인 신택스(syntax)가 존재하기 때문에, 대부분의 경우 XML은 현재 시맨틱 웹 기술의 필수 컴포넌트가 아니다. Turtle은 사실상 표준이지만 공식적인 표준화 프로세스를 거치지 않았다. XML Schema는 XML 문서 내에 포함된 요소들의 구조 및 콘텐츠를 제공하고 제한하기 위한 언어이다. RDF는, 객체들("웹 자원들"), 및 주체-술어-객체, 예를 들어, S-P-O 트리플 또는 RDF 트리플의 형태로 된 그들의 관계를 참조하는 데이터 모델을 표현하기 위한 간단한 언어이다. RDF-기반 모델은, 다양한 신택스, 예를 들어, RDF/XML, N3, Turtle 및 RDFa로 표현될 수 있다. RDF는 Semantic Web의 기본 표준이다.

RDF 그래프는, 에지가 RDF 트리플의 "술어"를 나타내는 반면 그래프 노드는 RDF 트리플의 "주체" 및/또는 "객체"를 나타내는 방향성 그래프이다. 즉, RDF 트리플로서 기술된 링킹 구조는 방향성 RDF 그래프를 형성한다. RDF Schema(예를 들어, RDF Schema 1.1)는 RDF를 확장하고 RDF-기반 자원의 속성 및 클래스를, 이러한 속성 및 클래스의 일반화된-계층들에 대한 시맨틱과 함께 기술하기 위한 어휘이다. OWL은, 속성 및 클래스: 특히, 클래스들간의 관계(예를 들어, 분리(disjointness)), 카디널리티(예를 들어, "정확히 하나"), 동등성(equality), 더 풍부한 유형의 속성, 속성의 특성(예를 들어, 대칭성) 및 열거된 클래스들을 기술하기 위한 더 많은 어휘를 추가한다.

SPARQL(예를 들어, SPARQL 1.1)은, 웹이나 RDF 스토어(예를 들어, 시맨틱 그래프 스토어(Semantic Graph Store)) 상의 RDF 그래프 콘텐츠(예를 들어, RDF 트리플)를 질의하고 조작하기 위한, 시맨틱 웹 데이터 소스에 대한 프로토콜 및 질의어이다. SPARQL 1.1 Query(RDF 그래프용 질의어)는, 데이터가 태생적으로 RDF로서 저장되거나 미들웨어를 통해 RDF로서 뷰잉되는지와 관계없이, 다양한 데이터 소스들에 걸쳐 질의를 표현하는데 이용될 수 있다. SPARQL은 필수의 및 선택사항적 그래프 패턴들을 그들의 연결 및 분리와 함께 질의하기 위한 능력들을 포함한다. SPARQL은 또한, 집결, 서브질의, 부정, 표현식에 의한 값 생성, 확장가능한 값 테스팅, 소스 RDF 그래프에 의한 질의 제약 등을 지원한다. SPARQL 질의의 결과는 결과 세트 또는 RDF 그래프일 수 있다. SPARQL 1.1 Update는 RDF 그래프를 위한 업데이트 언어이다. 이것은 RDF용 SPARQL Query Language로부터 도출된 신택스를 이용한다. 업데이트 동작은 Semantic Graph Store 내의 그래프들의 모음에 관해 수행된다. Semantic Graph Store 내의 RDF 그래프를 업데이트, 생성, 및 제거하기 위한 동작들이 제공된다. RIF는 W3C 규칙 교환 포맷(Rule Interchange Format)이다. 이것은, 컴퓨터가 실행할 수 있는 웹 규칙을 표현하기 위한 XML 언어이다. RIF는, 방언이라고 불리는 복수의 버전을 제공한다. 이것은, RIF BLD(RIF Basic Logic Dialect) 및 RIF PRD(RIF Production Rules Dialect)를 포함한다.

시맨틱 검색 및 시맨틱 질의

관계형 데이터베이스는 데이터간의 관계를 묵시적 방식으로 포함한다. 예를 들어, (2개의 콘텐츠 테이블에 저장되고 추가적인 링크 테이블로 연결된) 고객과 제품 사이의 관계는, 개발자에 의해 작성된 질의문(예를 들어, SQL은 관계형 데이터베이스의 경우에 이용됨)에서만 존재한다. 질의를 작성하는 것은 데이터베이스 스키마에 대한 정확한 지식을 요구한다. 많은 관계형 데이터베이스는, 데이터가 트리형 구조로 조직화되는 계층적 데이터베이스에서와 같이 모델링된다. 데이터는 링크를 통해 서로 연결된 레코드로서 저장된다. 계층적 데이터베이스 모델에서의 레코드는, 관계형 데이터베이스 모델의 행(또는 튜플)에 대응하며 엔티티 유형은 표(또는 관계 - 부모 & 자식)에 대응한다. 레코드의 검색 또는 질의는, SQL 또는 비-SQL 검색 엔진에 의해 수행될 수 있다.

도 2에 도시된 바와 같이, 계층적 데이터베이스 모델은, 각각의 자식 레코드가 오직 하나의 부모만을 갖는 반면, 각각의 부모 레코드는 하나 이상의 자식 레코드를 가질 수 있는 것을 요구한다. 계층적 데이터베이스로부터 데이터를 회수하기 위해, 루트 노드로부터 시작하여 전체 트리가 탐색될 필요가 있다. 관계가 일-대-다 관계로 제한되어 있기 때문에, 이 구조는 간단하지만 융통성이 없다.

링크된-데이터는 데이터 사이의 모든 관계를 명시적인 방식으로 포함한다. 관계형 데이터베이스에 대해 설명된 위에서 언급된 예에서는, 어떠한 질의 코드도 작성될 필요가 없다. 각각의 고객에 대한 올바른 제품을 자동으로 가져올 수 있다. 이 간단한 예는 사소하지만, 링크된-데이터의 진정한 힘은 정보의 네트워크가 생성될 때 역할하게 된다(도시, 주 및 국가와 같은 지리공간 정보를 가진 고객들; 하위 카테고리 및 상위 카테고리 내에 해당 카테고리를 갖는 제품들). 이제 시스템은 특정한 위치의 제품 카테고리와의 연결을 찾는 더 복잡한 질의 및 분석에 자동으로 응답할 수 있다. 이 질의에 대한 개발 노력은 생략된다. 시맨틱 질의를 실행하는 것은, 정보의 네트워크를 걷고 정합되는 것을 발견하는 것(데이터 그래프 답파라고도 함)에 의해 수행된다.

시맨틱 검색(Semantic Search)은, 웹 상이든 닫힌 시스템 내이든, 검색가능한 데이터공간에 나타날 때 검색자의 의도 및 용어들의 정황적 의미를 이해함으로써 더 관련있는 결과를 생성하여 검색 정확도를 향상시키려고 한다. 시맨틱 검색 시스템은, 관련있는 검색 결과를 제공하기 위해, 검색의 정황, 위치, 의도, 및 단어의 변형, 동의어, 일반화된 및 전문화된 질의, 개념 정합, 및 자연어 질의를 포함한 다양한 포인트를 고려한다. Google 및 Bing 등의 주요 웹 검색 엔진은 시맨틱 검색의 일부 요소들을 포함한다. 시맨틱 검색은 관련성이 높은 검색 결과를 생성하기 위해 시맨틱을 이용한다. 대부분의 경우, 목표는, 느슨하게 관련된 키워드 결과들의 목록을 사용자가 정렬시키는 것이 아니라 사용자에 의해 질의된 정보를 전달하는 것이다. 예를 들어, 시맨틱은, 계층적 관계형 데이터베이스에서 레코드 검색 또는 질의를 강화하는데 이용될 수 있다.

시맨틱 질의는 연관적 및 정황적 성질의 질의 및 분석을 허용한다. 시맨틱 질의들은, 데이터에 포함된 구문적, 의미론적 및 구조적 정보에 기초하여 명시적으로 및 묵시적으로 도출된 정보의 회수를 가능케한다. 이들은, 패턴 정합 및 디지털 추론을 통해 정확한 결과(아마도 단일 정보의 개별적 선택)를 전달하거나 더욱 퍼지적(fuzzy)이고 자유로운 질문에 대답하도록 설계된다.

시맨틱 질의는, 명명된 그래프, 링크된-데이터 또는 트리플에 작용한다. 이것은, 질의가 정보 사이의 실제 관계를 처리하고 데이터의 네트워크(network of data)로부터의 답변을 추론할 수 있게 한다. 이것은, 구조화되지 않은 텍스트에서 시맨틱을 이용하여 더 양호한 검색 결과를 생성하는(예를 들어, 자연어 처리) 시맨틱 검색과는 대조적이다.

기술적인 관점에서, 시맨틱 질의들은 데이터베이스 질의와 매우 유사한 정확한 관계형 동작이다. 그들은, 구조화된 데이터에 관해 작용하므로 연산자(예를 들어, >, < 및 =), 명칭공간, 패턴 정합, 하위-분류, 천이적 관계, 시맨틱 규칙 및 문맥적 전체 텍스트 검색과 같은 포괄적인 피처들을 활용할 가능성을 가진다. W3C의 시맨틱 웹 기술 스택은, SQL과 유사한 신택스로 시맨틱 질의를 공식화하는 SPARQL을 제공한다. 시맨틱 질의는, 트리플 스토어, 그래프 데이터베이스, 시맨틱 위키(semantic wikis), 자연어, 및 인공 지능 시스템에서 이용된다.

시맨틱 질의의 또 다른 양태는, 관계의 유형이 시스템 내에 지능을 통합하는데 이용될 수 있다는 것이다. 고객과 제품 사이의 관계는, 인근과 그 도시 사이의 관계와는 근본적으로 상이한 성질을 가지고 있다. 후자는, 시맨틱 질의 엔진이, Manhattan에 거주하는 고객이 New York City에도 거주하고 있는 반면 다른 관계들은 더 복잡한 패턴과 "정황적 분석"을 가질 수도 있다고 추론할 수 있게 한다. 이 프로세스를 추론 또는 추리라고 하며 주어진 사실에 기초하여 새로운 정보를 도출하는 소프트웨어의 능력이다.

oneM2M 기능적 아키텍처

개발중인 oneM2M 표준(oneM2M-TS-0001 oneM2M Functional Architecture -V2.9.0)은 공통 서비스 엔티티(CSE)라 불리는 서비스 계층을 정의한다. 서비스 계층의 목적은 상이한 "수직" M2M 시스템들 및 애플리케이션들에 의해 이용될 수 있는 "수평" 서비스를 제공하는 것이다. CSE는 도 3에 도시된 바와 같이 기준점들을 지원한다. Mca 기준점은 애플리케이션 엔티티(Application Entity)(AE)와 인터페이스한다. Mcc 기준점은 동일한 서비스 제공자 도메인 내의 또 다른 CSE와 인터페이스하며 Mcc' 기준점은 상이한 서비스 제공자 도메인 내의 또 다른 CSE와 인터페이스한다. Mcn 기준점은 기저 네트워크 서비스 엔티티(NSE)와 인터페이스한다. NSE는, 디바이스 관리, 위치 서비스 및 디바이스 트리거링 등의 기저 네트워크 서비스를 CSE에 제공한다.

CSE는, "발견(Discovery)" 및 "데이터 관리 및 저장소(Data Management & Repository)" 등의 "공통 서비스 기능(common service function)(CSF)"이라 불리는 복수의 논리적 기능을 포함한다. 도 4는 oneM2M에 의해 정의된 CSF들의 일부를 도시한다.

oneM2M 아키텍처는 도 3에 도시된 노드들의 유형들을 가능케한다. 애플리케이션 서비스 노드(applications service node)(ASN)는, 하나의 CSE를 포함하고 적어도 하나의 애플리케이션 엔티티(application entity)(AE)를 포함하는 노드이다. ASN은 M2M 엔드 디바이스에 상주할 수 있다. 애플리케이션 전용 노드(application dedicated node)(ADN)는, 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. oneM2M 시스템의 필드 도메인에는 0개 이상의 ADN이 있을 수 있다. 물리적 매핑의 예: 애플리케이션 전용 노드는 제약된 M2M 디바이스에 상주할 수 있다. 중간 노드(middle node)(MN)는 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. oneM2M 시스템의 필드 도메인에는 0개 이상의 MN이 있을 수 있다. MN은 M2M 게이트웨이에 상주할 수 있다. 인프라스트럭처 노드(infrastructure node)(IN)는, 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. oneM2M 서비스 제공자당 정확히 하나의 IN이 인프라스트럭처 도메인에 있다. IN의 CSE는 다른 노드 유형들에는 적용될 수 없는 CSE 기능을 포함할 수 있다. 물리적 매핑의 예: IN은 M2M 서비스 인프라스트럭처에 상주할 수 있다. 비-oneM2M 노드(non-oneM2M node; NoDN)는, oneM2M 엔티티를 포함하지 않는(AE도 CSE도 포함하지 않음) 노드이다. 이러한 노드는, 관리를 포함한 연동(interworking) 목적을 위해 oneM2M 시스템에 부착된 디바이스를 나타낸다.

oneM2M에서의 시맨틱 가능케하기

도 5에 도시된 <semanticDescriptor> 자원은, 자원 및 잠재적으로는 서브-자원에 관한 시맨틱 설명을 저장하는데 이용된다. 이러한 설명은 온톨로지(ontologies)에 따라 제공될 수 있다. 시맨틱 정보는, oneM2M 시스템의 시맨틱 기능에 의해 이용되고, 또한 애플리케이션 또는 CSE에 이용가능하다. <semanticDescriptor> 자원은 표 1에 명시된 속성들을 포함해야 한다.

표 1:

oneM2M에서 시맨틱 필터링 제안

일반 필터링은, 요청 동작(oneM2M-TS-0001 oneM2M Functional Architecture -V2.9.0 section 8.1.2)에 명시된 필터 기준을 가짐으로써 지원된다. 시맨틱 필터링을 제공하기 위하여, 요청 동작 필터 기준에 대한 추가적인 값은 oneM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.0 section 8.5.4에 제안되었으며, 그 정의가 아래 표에 도시되어 있다. 필터 기준을 평가하기 위한 일반적인 규칙에 따라 "OR" 시맨틱이 적용된다는 것을 의미하는 복수의 인스턴스가 이용될 수 있다, 예를 들어, 하나 이상의 시맨틱 필터가 시맨틱 설명과 정합한다면 시맨틱 필터 기준에 대한 전체 결과는 참이 된다. 아래 표의 시맨틱은, oneM2M TR-0007-Study_on_Abstraction_and_Semantics_Enablement-V2.11.0에 정의되어 있으며 oneM2M-TS-0001 oneM2M Functional Architecture -V2.9.0에서 요청 파라미터 semanticFilter에 대응한다는 점에 유의한다. semanticFilter 파라미터에 포함된 SPAQRL 질의가 부모 자원의 자식 자원 <semanticDescriptor> 중 하나에서 시맨틱 트리플과 정합할 때, 이것은 이 시맨틱 필터링이 성공적이고 대응하는 부모 자원이 반환될 것이라는 것을 의미한다.

표 2.

상기의 제안은 다음과 같은 가정을 이용한다: 시맨틱 설명은 RDF 트리플로서 명시된다(표현, 예를 들어, RDF/XML, Turtle, 설명 포맷이 아직 oneM2M에서 완전히 명시되지 않았다); 시맨틱 필터 기준은 시맨틱 설명에 관해 실행될 SPARQL 요청에 이용될 것이다.

이하는 oneM2M TR-0007에서 제공하는 시맨틱 필터링 예이다.

예 1: 온도를 측정하는 디바이스를 나타내는 AE 자원에 대한 필터.

디바이스 1 AE의 시맨틱 디스크립터

디바이스 2 AE의 시맨틱 디스크립터

SPARQL 요청 1

SPARQL 실행 결과

이것은 my: myDevice1에 의해 설명되는 AE 자원이 결과 세트에 포함되는 반면, my: myDevice2에 의해 설명되는 AE 자원은 포함되지 않음을 의미한다.

일부 경우에, 단일 검색에 대한 관련 시맨틱 정보는 상이한 <semanticDescriptor> 자원들 사이에 분산될 수 있다. 도 6에 제공된 예는 이 경우를 도시한다. 박스는 시맨틱 필터의 범위를 나타내며, 예를 들어, 이것은 평가를 위해 요구되는 정보이다. 주체-술어-객체 관계를 나타내는 시맨틱 그래프가 도시되어 있고, 여기서, 이 그래프의 상이한 부분들(타원들로 표시됨)은 상이한 <semanticDescriptor> 자원에 저장된다. 시맨틱 필터링은 완전한 시맨틱 그래프(의 부분들)에 적용될 필요가 있고, 이것은 시맨틱 동작의 실행을 위해 그래프의 수개의 상이한 부분들을 함께 두어야 한다는 문제를 야기한다.

이 문제는 시맨틱 웹의 영역에서 일반적으로 명백하지 않은데, 그 이유는, 클래스 인스턴스를 식별하는 URI가 직접적으로 참조해제되어 개념(예를 들어, 클래스, 관계) 정보가 그 URI에 기초하여 발견될 수 있기 때문이다. oneM2M의 경우, 액세스될 수 있는 자원과 시맨틱이 자원 콘텐츠로서 저장된다.

현재 SPARQL 1.1은 SERVICE 키워드를 이용하여 연합된 질의를 지원하며, 여기서, 원격 SPARQL 엔드포인트의 URL이 명시될 수 있다. 이 접근법의 경우, 요청자는 어떤 시맨틱 디스크립터가 검색에 요구되는 시맨틱 인스턴스를 포함하는지를 사전에 알 수 있어서, 시맨틱 디스크립터들이 자원 트리에 분산될 때 이 접근법이 일반적으로 적용될 수 없게 한다.

제시된 <semanticDescriptor> 자원에 걸쳐 저장된 시맨틱 설명에 대한 시맨틱 필터링을 가능케하기 위한 솔루션은 resourceDescriptorLink OWL 주석 속성 형태의 주석 링크를 도입한다. 이 주석 속성은 임의의 클래스 인스턴스에 대해 명시될 수 있고 그 값은 <semanticDescriptor> 자원의 URL이며, 여기서, 주어진 클래스 인스턴스에 대한 추가 RDF 트리플이 발견될 수 있다. 다음의 예는 도 8의 그래프를 생성하기 위하여 oneM2M Base Ontology(도 7)에 정의된 클래스 및 관계를 이용한다.

이 솔루션은 수신기의 SPARQL-기반 시맨틱 필터링 엔진을 위해 다음과 같은 기능적 흐름을 수반한다.

SPARQL 요청으로서 형성된 시맨틱 필터는, 후보 자원의 시맨틱 디스크립터 자원의 콘텐츠에 관해 실행된다.

실행 동안에 하나 이상의 resourceDescriptorLink 주석을 갖는 클래스 인스턴스와 조우하면, 실행이 중지된다.

resourceDescriptorLink가 참조하는 <semanticDescriptor> 자원들 각각의 콘텐츠가 SPARQL 요청이 실행되고 있는 콘텐츠에 추가된다

확대된 콘텐츠에 관해 SPARQL 요청의 실행이 계속된다.

oneM2M 정황에서의 시맨틱 필터링/발견 및 시맨틱 질의

oneM2M은 시맨틱 필터를 통해 시맨틱 자원 발견을 지원한다. 일반적으로, 시맨틱 질의는 연관적 및 정황적 성질의 질의 및 분석을 허용한다. 시맨틱 질의들은, 데이터에 포함된 구문적, 의미론적, 또는 구조적 정보에 기초하여 명시적으로 및 묵시적으로 도출된 정보의 회수를 가능케한다.

아래에는 시맨틱 질의와 시맨틱 자원 발견 사이의 차이점에 대한 요약이 있다. 시맨틱 질의는 RDF 데이터 인프라스트럭처에 관한 유용한 지식을 추출하는 것이다. 시맨틱 자원 검색은, 자원을 발견하고 자원의 시맨틱 메타데이터 또는 시맨틱 필터에 기초하여 자원 URI를 반환하는 것을 타겟으로 한다(시맨틱 질의는 또한, 자원 URI를 반환할 수도 있다, 예를 들어, 시맨틱 질의는 시맨틱 자원 발견 이상을 수행할 수 있다는 점에 유의한다). 도 9는 다양한 시맨틱 질의의 질의 결과의 예를 도시한다. 도 9에 도시된 예로서, 질의 3은 홈페이지에 대해 질의하고 이 질의의 반환 결과는 자원 URI들(예를 들어, 홈페이지 주소들)의 세트이다. 시맨틱 질의는 트리플 스토어(Triple Store) 등의 시맨틱-중심적 인프라스트럭처와 더 연관되는 반면 시맨틱 자원 발견은 서비스 계층에서 정의된 oneM2M 자원 트리 등의 자원 트리 인프라스트럭처와 더 연관된다. 시맨틱 질의는, 자원의 URI가 아닌, "지식"이라는 측면에서 임의의 포맷의 질의 결과를 반환할 수 있다.

시맨틱 질의는, (예를 들어, RDF 트리플의 측면에서) 데이터에 포함된 구문적, 의미론적, 및 구조적 정보에 기초하여 명시적으로 및 묵시적으로 도출된 정보/지식의 회수를 가능케한다. 현재, oneM2M 정황에서, 시맨틱 관련 피처를 지원하기 위한 크게 2가지 아키텍처 선택이 있다, 예를 들어, 하나는 중앙집중형 접근법으로서, 이 경우, 시맨틱 처리, 예를 들어, 시맨틱 질의가 중앙집중형 트리플 스토어(Triple Store)에 관해 실행되도록 시스템에 중앙집중형 트리플 스토어가 있다. 다른 하나는, 트리플들이 자원 트리에 분산되고 상이한 <semanticDescriptor> 자원들에 저장된다는 의미에서 분산형 접근법이다.

현재, 분산형 시맨틱 디스크립터(예를 들어, oneM2M <semanticDescriptor> 자원들)을 통한 직접 시맨틱 질의 처리를 위한 기존의 솔루션은 없다. 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 복수의 애플리케이션이 여기서 논의된다. 제1 예시적인 방법에서, 시맨틱 질의는, 정보가 단일 시맨틱 디스크립터에 저장될 때 고려된다. 제2 예시적인 방법에서, 시맨틱 질의는, 요청되거나 기타의 방식으로 필요한 정보가 시맨틱 디스크립터에 저장되지 않을 때 고려된다. 제3 예시적인 방법에서, 시맨틱 질의는, 정보가 상이하지만 관련된 시맨틱 디스크립터들에 분산될 때 고려된다. 제4 예시적인 방법에서, 시맨틱 질의는, 정보가 상이하고 관련되지 않거나 피어 시맨틱 디스크립터들에 분산될 때 고려된다. 제5 방법에서, 기존의 시맨틱 자원 발견 메커니즘을 활용함에 의한 타겟 자원으로부터의 정보의 간접 질의일 수 있다.

본 요약은, 이하의 상세한 설명에서 더 설명되는 선발된 개념들을 간략화된 형태로 소개하기 위해 제공되는 것이다. 본 요약은, 청구 주제의 핵심 피처나 본질적 피처들을 식별하기 위함도 아니고, 청구 주제의 범위를 제한하기 위해 이용되는 것도 아니다. 또한, 청구 주제는 본 개시의 임의의 부분에서 언급된 임의의 또는 모든 단점을 해결하는 한도로 제한되지 않는다.

첨부된 도면과 연계하여, 예를 통해 주어지는 이하의 상세한 설명으로부터 더 상세한 이해를 얻을 수 있다. 이하에서:
도 1은 시맨틱 웹의 아키텍처를 도시한다;
도 2는 예시적인 계층적 데이터베이스를 도시한다;
도 3은 oneM2M 아키텍처를 도시한다;
도 4는 oneM2M 공통 서비스 기능을 도시한다;
도 5는 자원 트리 내의 <semanticDescriptor> 자원의 구조를 도시한다;
도 6은 상이한 자원들에 저장된 시맨틱 정보에 걸친 시맨틱 필터의 예시적인 범위를 도시한다;
도 7은 예시적인 oneM2M 베이스 온톨로지(Base Ontology)를 도시한다;
도 8은 예시적인 resourceDescriptionLink를 도시한다;
도 9는 월드 와이드 웹 컨소시엄에 의해 제공된 시맨틱 질의의 예시적인 질의 결과를 도시한다;
도 10은 시맨틱 계층(Semantic Layer)에 의해 제어되는 계층적으로 층을 이룬 구조에서의 액세스 제어를 도시한다;
도 11은 제1 시나리오에 대한 시맨틱 질의 처리를 위한 절차를 도시한다;
도 12는 <semanticDescriptor> 자원에 저장되지 않은 정보를 요구하는 시맨틱 질의를 도시한다;
도 13은 시나리오 2A에 대한 새로운 정보에 대한 RDF 트리플을 생성/저장하는 방법에 대한 옵션 1을 도시한다;
도 14는 시나리오 2A의 옵션 1에 대한 정보 클론 절차를 도시한다;
도 15는 시나리오 2A의 옵션 1에 대한 시맨틱 질의 처리 절차를 도시한다;
도 16은 온디맨드 정보 클로닝에 기초한 시나리오 2A의 옵션 1에 대한 대안적인 시맨틱 질의 처리 절차를 도시한다;
도 17은 시나리오 2A의 새로운 정보에 대한 RDF 트리플을 생성/저장하는 방법에 대한 옵션 2를 도시한다;
도 18은 시나리오 2A의 옵션 2에 대한 정보 클론 절차를 도시한다;
도 19는 시나리오 2B를 도시한다;
도 20은 시나리오 2B에 대한 정보 링킹 절차를 도시한다;
도 21은 시맨틱 질의 처리 절차 시나리오 2B를 도시한다;
도 22는, 상이하지만 관련된 <semanticDescriptor> 자원들에 분산된 정보를 요구하는 시맨틱 질의를 위한 예시적인 시나리오를 도시한다;
도 23은 제3 시나리오를 도시한다;
도 24는 제3 시나리오에 대한 시맨틱 질의 처리 절차를 도시한다;
도 25는 상이하고 관련없는 <semanticDescriptor> 자원들에 분산된 정보를 요구하는 시맨틱 질의를 도시한다;
도 26은 시나리오 4에 대한 시맨틱 질의 처리를 위한 수반된 자원을 도시한다;
도 27은 시나리오 4의 베이시스 솔루션에 대한 시맨틱 질의 처리 절차를 도시한다;
도 28은 상이한 질의 범위들을 도시한다;
도 29는 시나리오 4의 향상된 솔루션의 접근법 1에 대한 시맨틱 질의 처리 절차를 도시한다;
도 30은 시나리오 4에 대한 솔루션 B에서의 접근법 2의 동작 상세사항을 도시한다;
도 31은 시나리오 4의 향상된 솔루션의 접근법 2에 대한 시맨틱 질의 처리 절차를 도시한다;
도 32는 기존 시맨틱 자원 발견을 활용함으로써 타겟 자원으로부터의 간접적인 정보 질의를 도시한다;
도 33은 시나리오 5A에 대한 시맨틱 질의 처리 절차를 도시한다;
도 34는 시나리오 5B에 대한 시맨틱 질의 처리 절차를 도시한다;
도 35는 oneM2M 서비스 계층에 대한 DAS CSF를 도시한다;
도 36은 <QueryPortal> 자원을 도시한다;
도 37은 <queryPortal> 자원을 통한 시나리오 4에 대한 시맨틱 질의 처리를 위한 oneM2M-중심적 절차를 도시한다;
도 38은 시맨틱 질의 범위 체커에 대한 예시적인 사용자 인터페이스를 도시한다;
도 39는 시맨틱 질의 론처에 대한 예시적인 사용자 인터페이스를 도시한다;
도 40은 시맨틱 질의 결과 디스플레이를 위한 예시적인 사용자 인터페이스를 도시한다;
도 41a는 개시된 주제가 구현될 수 있는 예시적인 머신-대-머신(machine-to-machine; M2M) 또는 사물 인터넷(IoT) 통신 시스템을 도시한다.
도 41b는 도 41a에 도시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처를 도시한다;
도 41c는 도 41a에 도시된 통신 시스템 내에서 이용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스를 도시한다;
도 41d는 도 41a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템을 도시한다.

현재, oneM2M 정황에서, 시맨틱 관련 피처를 지원하기 위한 크게 2가지 아키텍처 선택이 있다, 예를 들어, 하나는 중앙집중형 접근법으로서, 이 경우, 시맨틱 처리, 예를 들어, 시맨틱 질의가 트리플 스토어(Triple Store)에 관해 실행되도록 시스템에 중앙집중형 트리플 스토어가 있다. 즉, 중앙집중형 트리플 스토어가 있고 RDF 트리플은 대부분의 시맨틱 처리를 지원하기 위해 이 트리플 스토어에 저장된다. 다른 하나는, 트리플들이 자원 트리에 분산되고 상이한 <semanticDescriptor> 자원들에 저장된다는 의미에서 분산형 접근법이다. 이들 <semanticDescriptor> 자원은 종종 보통의 oneM2M 자원의 자식 자원이고, 주로 시맨틱 주석 목적을 위해 이용되며, 또한 시맨틱 자원 발견을 가능케한다. 특히, 이 분산형 접근법에서, 각각의 CSE는 상이한 <semanticDescriptor> 자원들로부터 정보를 수집하고 로컬/임시 트리플 스토어를 형성하여 이에 관해 시맨틱 처리를 수행할 필요가 있다.

분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 개시된 방법들 및 시스템들에 컨텍스트를 제공할 수 있는 복수의 시나리오가 존재한다. 시나리오들의 일부는 다음을 포함한다: 1) 오직 단일의 <semanticDescriptor> 자원으로부터의 정보; 2) 시맨틱 질의는 <semanticDescriptor> 자원에 저장되지 않은 정보를 요구한다; 3) 시맨틱 질의는, 분산되어 있지만 상이한 <semanticDescriptor> 자원들에 저장될 수 있는 정보를 요구한다; 4) 상이하고 관련되지 않은 <semanticDescriptor> 자원에 분산된 정보를 요구하는 시맨틱 질의; 또는 5) 기존의 시맨틱 자원 발견을 활용함으로써 타겟 자원으로부터의 정보의 간접적 질의. 앞서 언급된 시나리오들에서와 같이, 분산형 시맨틱 질의에 이용될 수 있는, 방법, 시스템 및 장치들이 이하에서 논의된다. 시나리오들이 이하에서 더 상세히 논의될 것이다.

도 10 내지 도 37의 엔티티들 등의, 여기서 도시된 단계들을 수행하는 엔티티들은 논리적 엔티티일 수 있다는 것을 이해할 것이다. 이 단계들은, 도 41c 또는 도 41d에 도시된 것들 등의, 디바이스, 서버 또는 컴퓨터 시스템의 메모리에 저장되고 프로세서 상에서 실행될 수 있다. 한 예에서, M2M 디바이스들의 상호작용에 관한 이하의 더 상세한 설명과 함께, 도 37의 AE(295)는 도 41a의 M2M 단말 디바이스(18) 상에 상주할 수 있는 반면, 도 37의 CSE(296)는 도 41a의 M2M 게이트웨이 디바이스(14) 상에 상주할 수 있다.

표 3은 본 명세서에서 일반적으로 사용되는 용어에 대한 정의를 제공한다.

표 3:

제1 시나리오와 관련하여, 도 10은, <Device>(111)가, operation(114), operation(115), 및 RDF 트리플의 측면에서 관련된 시맨틱 설명을 포함하는 자식 <semanticDescriptor>(116) 자원을 갖는 온도 센서를 나타내는 부분적인 자원 트리 구조를 나타낸다. <semanticDescriptor>(116) 자원에 저장된 RDF 트리플은, 블록 110에서 논리적으로 그래프로서 간주될 수 있다. 질의 설명의 의도는 다음과 같을 수 있다: "디바이스 <Device>(111)에 의해 지원되는 동작의 수를 반환한다." SPARQL 표현은 다음과 같을 수 있다:

이 질의를 처리하는 방법에 관한 (예를 들어, oneM2M에서) 종래에 정의된 상세사항은 없다. 도 11은 제1 시나리오에 대한 시맨틱 질의 처리를 위한 예시적인 방법을 도시한다. 단계 130에서, SQI(121)는 RH-SLN(122)에 관한 일부 정보를 질의하기를 원한다. 따라서, SQI(121)는 상기의 것처럼 SPARQL 질의문을 공식화하여 그 질문을 기술한다. 서비스 계층 시맨틱-질의 개시자(SQI)(121)는 시맨틱 질의를 개시하는 논리적 엔티티일 수 있다. 자원 호스팅 서비스-계층 노드(RH-SLN)(122)는 RESTful 아키텍처로 구축되는 서비스 계층 노드일 수 있다. RH-SLN(122)의 서비스 계층은 동작 인터페이스로서 자원-트리를 노출시킬 수 있다.

단계 131에서, SQI(121)는 요청이 시맨틱 질의와 관련되어 있음을 나타내는 요청 메시지를 RH-SLN(122)에 전송한다. 메시지는, 이하에서 더 상세히 논의되는 다음과 같은 파라미터를 포함될 수 있다: 시맨틱 질의 표시자(semantic query indicator)(SQ), 단일 자원 평가 표시자(single resource evaluation indicator)(SE), 질의문(query statement)(QS), 또는 결과 포맷(result format)(RF) SQ는, SQI(121)로부터의 단계 131의 요청이 실행될 시맨틱 질의임을 나타낼 수 있는 정보를 포함한다. 즉, SQ는, 요청이 시맨틱 자원 발견을 위한 것이 아니라 RDF 트리플에 기초할 수 있는 도출된 정보 또는 지식을 시맨틱적으로 질의하거나 회수하기 위한 것임을 나타낸다. SE는, 이 질의가 단일 <semanticDescriptor> 자원에 적용될 것임을 나타낼 수 있다. 예를 들어, 이 요청 메시지의 "To" 파라미터가 <semanticDescriptor> 자원을 직접 타겟으로 하는 경우, 이 <semanticDescriptor> 자원은 시맨틱 질의가 실행될 자원일 것이다. 그러나, 이 요청 메시지의 "To" 파라미터가 일반 자원을 직접 타겟으로 하는 경우, 대응하는 즉석의 또는 가장 가까운 <semanticDescriptor> 자식 자원은 시맨틱 질의가 실행될 자원일 것이다. SQI(121)가 단일 <semanticDescriptor> 자원에 관해서만 시맨틱 질의를 수행하고자 할 때, 적절한 값을 가진 SE 파라미터가 요청 메시지에 포함되어야 한다는 요건이 있을 수 있다. 다시 말해, 특정한 값의 SE 파라미터가 요청 메시지에 포함되지 않은 경우, 디폴트 범위는 이 요청의 "To" 파라미터에 의해 표시된 URI의 모든 자식 자원일 수 있다(제4 시나리오에 관한 논의는 이 상황에 대해 다룬다). QS는, SPARQL 질의문일 수 있는, SQI(121)에 의해 명시된 질의문을 저장한다. 대안으로서, SQI(121)는 그 질의를 시맨틱 filterCriteria에서 운반할 수도 있다. RF는 질의 결과가 표현되어야 하는 방법을 나타내며, 일반 텍스트, JSON 또는 XML 형식일 수 있다. 앞의 예를 이용하면 SQ, SE, QS 및 RF에 대한 예시적 값들은 다음과 같다:

도 11을 계속 참조하면, 단계 132에서, RH-SLN(122)은 SQI(121)로부터 요청을 수신하고, SQI(121)에 의해 표시된 시작점으로부터 시맨틱 질의 처리를 수행한다. "To" 파라미터에 기초하여, 타겟 <semanticDescriptor> 자원이 질의된다. 일단 타겟 <semanticDescriptor> 자원이 식별되고 나면, 시맨틱 질의는 타겟 <semanticDescriptor> 자원 상에서 실행되어 질의 결과를 생성할 수 있다. 단계 132에서, RH-SLN(122)은 SQI(121)에 의해 표시된 포맷을 이용함으로써 질의 결과가 포함된 응답 메시지를 SQI(121)에 전송한다.

제2 시나리오와 관련하여, 도 12는, <Device>(111)가 온도 센서를 나타내고, 그 자식 <semanticDescriptor>(116) 자원은 RDF 트리플의 측면에서 관련된 시맨틱 설명을 포함하는 부분적인 자원 트리 구조를 나타낸다. <reading>(113)은 최신의 온도 판독치를 저장하는 <contentInstance> 자원이고, 이 <reading>(113) 자원의 Content 속성(117)에 값 "32"가 저장된다. <contentInstance> 자원은 <container> 자원 내의 데이터 인스턴스를 나타낼 수 있다. 시맨틱 질의는 <semanticDescriptor> 자원에 저장되지 않은 정보를 회수하는 것과 연관될 수 있다, 예를 들어, 일부 정보는 RDF 트리플로서 표현되지 않고 일반 자원에만 저장될 수 있다. 여기서, 일반 자원이란 기본적으로 <semanticDescriptor> 자원 이외의 자원을 지칭하며, 예를 들어 oneM2M 정황에서 <CSE>, <AE>, <container> 등의 자원일 수 있다. 질의 설명의 의도는 다음과 같을 수 있다: "현재의 온도가 20보다 큰 센서를 반환한다"

<Device>(111)의 <semanticDescriptor> 자원에 관해 직접 상기 질의를 적용하면, SPARQL의 "FILTER(? tempValue temp: hasValue >= 20)"이 충족될 수 없으므로, 종래에는 어떠한 결과도 반환되지 않을 수 있다. 그 이유는, 온도 값이 <semanticDescriptor> 자원에 RDF 트리플로서 현재 저장되어 있지 않기 때문이다. 이것은, RDF 포맷으로 저장된 정보는 그 대부분이 메타데이터 설명이므로 대부분 정적이라는 의미에서 기존의 시맨틱 인프라스트럭처의 전형적인 특성을 나타낸다. 대조적으로, 동적 데이터는 종종 자원 트리에 저장된다. 예를 들어, 도 12에 도시된 바와 같이, <Device>(111)의 시맨틱 설명의 경우, OutputX(118)가 온도 양태를 기술하지만, OutputX(118)의 현재 값(예를 들어, Device(111)의 현재 온도 값)은, 이 정보가 시간이 지남에 따라 변경되기 때문에 RDF 트리플로서 직접 기술되지 않고 이 <semanticDescriptor> 자원에 저장된다. 본 명세서에 개시된 바와 같이, "트리플"의 표시가 있는 경우, 단지 하나의 "트리플"이 있을 수 있다는 것도 생각해 볼 수 있다.

제2 시나리오를 참조하면, 그것을 다루기 위한 복수의 고려사항이 있다. 여기서, 제2 시나리오의 경우, 고려사항은 시나리오 2A 및 시나리오 2B에 의해 표시된다. 본 명세서에서는 복수의 예시적인 피처가 개시된다, 예를 들어 <contentInstance> 자원의 콘텐츠 속성에 저장된 데이터 콘텐츠도 역시 RDF 트리플로서 재표현되고 <semanticDescriptor> 자원에 저장될 수 있다. 또한, 새로운 속성은 데이터 콘텐츠가 RDF 트리플로서 재표현되는지를 나타낼 수 있다. "resourceDescriptorLink" 속성의 이용은, 2개의 <semanticDescriptor> 자원을 링크할 뿐만 아니라 <semanticDescriptor> 자원과 일반 oneM2M contentInstance 자원을 연결하도록 확장될 수 있다.

시나리오 2A의 경우, 고려사항은, 원래 <semanticDescriptor> 자원에서 원래 이용가능하지 않은 정보, 예를 들어, <reading>(113) 자원의 Content 속성(117)에만 저장되는 온도 값을 표현하기 위해 더 많은 RDF 트리플을 추가하는 것이다. 즉, 원래 일반 자원에 저장되는 정보는 RDF 트리플로서 표현되고 소정의 <semanticDescriptor> 자원에 저장될 수 있다. 시나리오 2A의 경우, 질의 처리 외에도, 일반 자원에 저장된 원래의 정보에 관한 임의의 변경(예를 들어, 원래의 정보가 생성, 수정, 삭제, 업데이트 등이 되는 경우)은 또한, 이 정보가 RDF 트리플로서 표현되고 소정의 <semanticDescriptor> 자원에 저장된 경우, 관련된 <semanticDescriptor> 자원에도 영향을 주어야 한다는 의미에서 RDF 트리플에 관한 유지보수 절차도 역시 있다. 이 유지보수 관련 처리를 지원하기 위해 일부 기존의 솔루션이 이용될 수 있다.

시나리오 2A의 핵심 질문은 트리플을 저장할 장소이다. 대안적인 구현 옵션이 다음과 같이 논의된다. 시나리오 2A와 연관된 제1 옵션에서, 일반 자원으로부터 나오는 정보(예를 들어, 도 16에서와 같이 <reading>(113) 자원에 저장된 현재 온도 값(32))의 경우, <reading>(113) 자원이 현재 <semanticDescriptor> 자식 자원을 보유하고 있지 않으면, RH-SLN(122)은, 정보를 표현하는 새로운 RDF 트리플을 저장하는, <reading>(113) 자원에 대한 새로운 <semanticDescriptor> 자식 자원(예를 들어, <semanticDescriptor> 119)를 생성할 것이다. 한편, 이 새로운 <semanticDescriptor>(119) 자원은, 기존의 <semanticDescriptor> 자원의 "resourceDescriptorLink" 속성 또는 "relatedSemantics" 속성을 이용함으로써 다른 기존의 <semanticDescriptor> 자원(예를 들어, semanticDescriptor>(116) 자원)와 링크될 필요가 있다.

도 13은 시나리오 2A에 대해 제1 옵션이 어떻게 작용하는지를 설명하는 것을 돕는다. 블록 140을 참조한다. 볼 수 있는 바와 같이, 새로운 <semanticDescriptor> 자식 자원은, 이 <reading>(113) 자원의 생성과 함께, <reading>(113) 자원에 대해 생성된다. 한편, 이하에서 논의되는 바와 같이 "resourceDescriptorLink" 속성이 "TemperatureValue" 노드(141)를 통해 2개의 <semanticDescriptor> 자원을 함께 링크하는데 더 이용될 수 있도록, <Device>(121)의 <semanticDescriptor> 자식 자원에도 몇 가지 새로운 트리플이 생성된다.

옵션-1에서, 주요 노력은 원래 RDF 트리플로서 저장되지 않는 정보를 클론하는 것이라는 점에 유의한다. 클론의 의미는, 이전에는 일반 자원에만 저장되어 있는 정보를 복제하여 RDF 트리플로서 표현하는 것이다. 특히, RH-SLN(122)이 클로닝될 필요가 있는 새로운 정보를 수신하는 한, 클론 프로세스가 수행되어야 한다. 예시적인 정보 클론 프로세스는 도 14에 도시된 절차로서 설명되고, 상세한 설명은 도 13에 도시된 예를 이용하여 다음과 같다.

단계 150에서, Device(111)는 M2M 온도 디바이스이고 RH-SLN(122)에 이미 등록되어 있으며 그 판독치를 RH-SLN(122)에 전송할 수 있다. RH-SLN(122) 상의 <Device>(111) 자원은 그 시맨틱 설명을 포함하는 <semanticDescriptor>(116) 자식 자원을 갖는다. 단계 151에서, Device(111)는 새로운 판독치를 RH-SLN(122)에 전송한다.

단계 152에서, Device(111)로부터 새로운 판독치를 획득(예를 들어, 수신)할 때, 데이터는 도 13에 도시된 바와 같이 <contentInstance> 자원, 예를 들어 <reading>(113) 자원에 저장될 수 있다. 한편, <reading>(113) 자원의 생성과 함께, 완료되어야 할 복수의 동작이 있다. 단계 152와 관련한 제1 동작에서, 연관된 <semanticDescriptor> 자원이 또한 <reading>(113) 자원에 대해 생성된다. 예를 들어, 현재의 판독(예를 들어, 값 32)은 RDF 트리플로서 표현될 수 있고 이 새로이 생성된 <semanticDescriptor>(119) 자원에 저장될 수 있다. 도 13의 예에 도시된 바와 같이, 새로이 생성된 <semanticDescriptor>(119) 자원의 시맨틱 그래프의 경우, 이것은 2개의 링크를 갖는 "TemperatureValue" 노드(142)를 갖는다. 하나의 링크는 이 노드의 값이 "32"라는 것을 기술하기 위한 것이고 다른 링크는 온도 단위가 섭씨라는 것을 보여주기 위한 것이다. 이 단계에서, RH-SLN(122)는 적절한 RDF 트리플을 생성하기 위해 소정의 지능을 갖는다는 점에 유의한다. 예를 들어, Device(111)가 판독치를 전송할 때, 판독치는 또한, RH-SLN(122)의 인식을 위해 판독치가 섭씨라는 것을 나타내기 위해 일부 시맨틱 메타데이터를 포함할 수 있다. 대안으로서, 이러한 정보가 이미 <reading>(113)의 부모 <container> 자원(예를 들어, <OutPutX>(118) 자원)의 시맨틱 디스크립터에 저장되어 있다면, 이 정보는 또한, RH-SLN(122)에 의해 참조될 것이다. 또 다른 접근법은, RH-SLN(122)이 이 디바이스의 시맨틱 설명(예를 들어, Company-A에 의해 제조된 모든 디바이스가 디폴트로 섭씨를 이용하고 있음)에 기초하여 디바이스의 측정 단위를 결정하기 위해 시맨틱 추론을 이용할 수 있다는 것이다. 시맨틱 설명은, 이 디바이스의 semanticDescriptor 자식 자원에 저장된 정보(예를 들어, RDF 트리플)로서 고려될 수 있다.

도 14의 단계 152하에서의 제2 동작에서, resourceDescriptorLink를 이용하여 이 새로이 생성된 <semanticDescriptor>(119) 자원을 또 다른 <semanticDescriptor> 자원(예를 들어, <semanticDescriptor>(116) 자원)과 링크시키기 위하여, 2개의 <semanticDescriptor> 자원이 중첩되어야 한다(예를 들어, 중첩된 노드). 그러나, 도 13에 도시된 바와 같이, <Device>(111)의 <semanticDescriptor>(116) 자원은 새로이 생성된 <semanticDescriptor>(119) 자원과 중첩된 어떠한 노드도 갖지 않는다. 따라서, 다음 단계는, 일부 새로운 트리플을, <Device>(111)의 <semanticDescriptor> 자원(116)에 후크(hook)(예를 들어, 링크하는 방법)로서 추가하는 것이다. 도 13에서 알 수 있는 바와 같이, "hasCurrentValue" 속성을 통해 OutputX(118) 노드에 링크되는 "TemperatureValue" 노드(141)가 또한 추가된다. "TemperatureValue" 노드(141)는 트리플의 값이다. 예를 들어, TemperatureValue(주체 부분)는 Value(32)(객체 부분)를 갖는다(술어 부분). TemperatureValue는 주체 부분에 있다. 이전 시간 단위의 판독치를 참조하는, <Device>(111)의 <semanticDescriptor> 자원에 "TemperatureValue" 노드(141)가 이미 존재할 수 있다는 점에 유의해야 한다. 이 경우, 새로운 "TemperatureValue" 노드를 <Device>(111)의 <semanticDescriptor> 자원에 추가하는 것이 필요하지 않고, 대신에, "TemperatureValue" 노드(141)의 resourceDescriptorLink 속성에 관련된 트리플이, resourceDescriptorLink가 <reading>(113)의 새로이 생성된 <semanticDescriptor>(119) 자원을 참조하도록 변경될 수 있다.

제2 동작을 계속 참조하면, 각각의 RDF 트리플(S, P, O)에서 각각의 부분은 URI를 통해 참조된다는 것을 이해해야 한다. 각각의 oneM2M 자원이 고유 URI를 갖고 있는 것처럼, 주어진 트리플의 주체, 술어 또는 객체 부분에 나타나는 엔티티들도 역시 고유한 URI를 가진다. 2개의 <semanticDescriptor> 자원에서 "TemperatureValue" 노드(노드 141 및 노드 142)의 URI에 값을 할당하는 것과 관련하여 다음과 같은 옵션을 고려할 수 있다. 제1 옵션은 <reading>(113)의 현재 URI의 이용과 관련이 있다. 이 경우, 새로운 판독치가 수신될 때마다, <Device>(111)의 <semanticDescriptor> 자원에 나타나는 기존의 "TemperatureValue" 노드(141)의 URI는 새로이 수신된 판독치를 저장하는 자원의 URI를 갖도록 업데이트된다. 제2 옵션은 최신 판독치를 저장하는 "TemperatureValue" 노드(141)를 나타내기 위해 <Device>(111)에 의해 이용되는 시스템-전체에 걸친 특별 URI와 관련된다. 이 경우, <reading>(113)의 새로이 생성된 <semanticDescriptor>(119) 자원 내에서도, "TemperatureValue" 노드(142)는, <reading>(113)의 URI를 갖는 대신에, 이 시스템-전체에 걸친 특별 URI를 가질 수 있다. 비교로서, 후자의 옵션은 더 양호한 확장성과 더 용이한 유지보수를 가질 수 있다.

단계 152하에서의 제3 동작에서, resourceDescriptorLink는, 양쪽 <semanticDescriptor> 자원들(116 및 119) 모두에 나타나는 "TemperatureValue" 노드들에 이용되어, 이들 2개의 자원들이 함께 링크될 수 있게 한다.

단계 153에서, RH-SLN(122)은 Device(111)로부터 전송된 판독치의 수신에 대해 확인응답한다.

시맨틱 질의 처리 스테이지와 관련하여, 제2 시나리오에서 명시된 시맨틱 질의가 RH-SLN(122)에 의해 수신되고 <Device>(111)의 <semanticDescriptor>(116) 자식 자원들 상에서 실행될 때, 이 시점에서 누락된 정보가 없기 때문에 유효한 질의 결과가 나올 수 있다(예를 들어, 값 "32"가 이제는 RDF 트리플로서 이용가능하다). 이러한 시맨틱 질의 처리는, 도 15에 도시된 절차로서 정식으로 설명된다. 도 15의 시맨틱 질의 처리를 위한 일반적인 절차는 도 11에 도시된 것과 유사하고, 여기서, RH-SLN(122)이 시맨틱 질의를 어떻게 처리하는지에 관한 도 11의 단계 132와 도 15의 단계 155 사이에는 차이가 있다는 점에 유의한다. 따라서, 단계 155에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)에서의 질의 처리는 다음과 같은 동작들과 함께 수행된다. 제1 동작에서, SPARQL 질의는 <Device>(111)의 자식 <semanticDescriptor>(116) 자원 상에서 실행된다. 제2 동작에서, 실행 과정에서 하나 이상의 resourceDescriptorLink 주석을 갖는 클래스 인스턴스 또는 노드와 조우한다면, 실행이 중단된다. 도 13에 도시된 예에서, "TemperatureValue" 노드(141)는, 현재의 온도 값 "32"를 저장하는 새로이 생성된 <semanticDescriptor>(119) 자원을 참조하는 resourceDescriptorLink를 갖는다. 제3 동작에서, resourceDescriptorLink가 참조하는 <semanticDescriptor> 자원들 각각에 대해, SPARQL 질의가 실행되고 있는 원래의 콘텐츠에 콘텐츠가 추가된다. 예를 들어, Device(111)의 현재 온도 값이 32라는 사실을 설명하는 RDF 트리플이 추가될 것이다. 제4 동작에서, SPARQL 질의의 실행이 확장된 콘텐츠에 관해 계속되고 질의 결과를 낸다.

도 14는, 일단 새로운 정보가 이용가능하게 되면, 정보 클론 프로세스가 발생하는 경우를 도시한다는 점에 유의한다. 따라서, 도 15에 도시된 시맨틱 질의 처리는 정보 클론 프로세스와는 독립적이다. 대안으로서, 온디맨드 접근법은, 정보 클론 프로세스가 시맨틱 질의 처리에 의해 트리거된다는 의미에서 발생할 수 있다. 도 13에 도시된 예로서, <reading>(113)의 새로운 <semanticDescriptor> 자식 자원의 생성은, RH-SLN(122)에서 시맨틱 질의 수신 이벤트에 의해 트리거될 수 있다. 따라서, 이하에서 더 상세히 설명되는 바와 같이, 새로운 시맨틱 질의 처리 절차가 도 16에 개시된다.

도 16을 참조하면, 단계 160에서, Device(111)는 온도 디바이스이고 RH-SLN(122)에 이미 등록되어 있다. 한편, RH-SLN(122) 상의 <Device>(111) 자원은 또한, 시맨틱 설명을 포함하는 <semanticDescriptor>(116) 자식 자원을 갖는다. Device(111)는 그 판독치를 RH-SLN(122)에 주기적으로 전송하고, 이들 판독치는 <OutputX>(118) 자원 아래의 <contentInstance> 자식 자원에 저장된다. 필요에 기초하여, SQI(121) 측에서, 나중의 SQI(121)는 RH-SLN(122)에 관한 일부 정보를 질의할 필요가 있다. 따라서, SQI(121)는 그 질문을 기술하기 위해 SPARQL 질의문을 공식화한다. 예를 들어, SQI(121)가, 도 13에 도시된 예에서 논의된 바와 같이, Device(111)의 현재 판독치에 관련된 질의를 행하고자 한다고 가정한다. 단계 161에서, SQI(121)는 요청 메시지를 RH-SLN(122)에 전송하며, 여기서 이 메시지는 이 요청이 시맨틱 질의임을 나타낸다.

단계 162에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)은 수신된 시맨틱 질의를 조사한다. 질의가, RDF 형식으로는 현재 이용가능하지 않지만 다른 일반 자원에서 발견될 수 있는 어떤 정보를 찾고자 하는 경우, RH-SLN(122)은 정보를 추출하여 이를 RDF 트리플로서 표현한다. 이 단계 162의 경우, RH-SLN(122)은 소정의 지능을 가질 수 있다. 예를 들어, RH-SLN(122)은, <OutputX>(118) 또는 <Device>(111) 자원의 시맨틱 디스크립터에 저장된 어떤 유용한 정보를 이미 습득할 수 있다(예를 들어, <OutputX>(118)는 Device(111)의 모든 판독치를 저장하는 <container> 자원이고, 판독 단위는 섭씨이다). 이 정보를 알면, RH-SLN(122)은, 시맨틱 질의에 의해 요구될 때 <OutputX>(118) 자원하의 판독 정보를 위치파악할 수 있다. 또한, 더 진보된 접근법은, RH-SLN(122)이 시맨틱 추론을 이용하여 디바이스의 시맨틱 설명(예를 들어, Company-A에 의해 제조된 모든 디바이스는 디폴트로 섭씨를 이용한다)에 기초해 디바이스의 측정 단위를 결정할 수 있다는 것이다.

도 16의 단계 162를 계속 참조하면, 제2 시나리오에 도시된 예에서, <OutputX>(118) 자원의 시맨틱 설명에 기초하여, RH-SLN(122)은 이 자원이 <Device>(111)의 판독치를 저장한다는 것을 이해한다. 따라서, 질의가 <Device>(111)의 현재 판독치를 찾고 있을 때, RH-SLN(122)은 <reading>(113)이 최신 판독치를 저장한 자원임을 식별하고, 값 32를 추출하여 이를 RDF 트리플로서 표현한다. 그 후, 역시 최신 판독 정보를 RDF 포맷으로 저장하는 <reading>(113) 자원을 위해 연관된 <semanticDescriptor>(119) 자원이 생성된다. 추가로, 새로이 생성된 <semanticDescriptor>(119) 자원은 또한, resourceDescriptorLink 속성을 통해 다른 <semanticDescriptor> 자원(예를 들어, <Device>(111)의 <SemanticDescriptor>(116) 자원)와 링크될 수도 있다. 따라서, 이것은 미래의 시맨틱 질의를 지원할 수 있다.

후속해서, 단계 163에서, 대응하는 도 15(단계 155)와 유사한 질의 처리가 RH-SLN(122)에서 수행된다. 단계 164에서, RH-SLN(122)은, (단계 161에서 제공되는) SQI(121)에 표시된 포맷을 이용하여 질의 결과가 포함된 응답 메시지를 SQI(121)에 다시 전송한다.

도 17은 시나리오 2A에 대해 제2 옵션이 어떻게 작용하는지를 설명하는 것을 돕는다. (도 13 및 도 17을 참조하여) 요약하면, 일반 자원(예를 들어, <reading>(113) 자원)으로부터 나오는 정보의 경우, <reading>(113) 자원이 현재 <semanticDescriptor>(119) 자식 자원을 갖고 있지 않다면, RH-SLN(122)은, 정보를 나타내는 새로운 RDF 트리플을 <device>(111) 자원(부모 또는 조상)의 <semanticDescriptor>(116) 자원에 직접 추가할 것이다. <reading>(113) 자원이 현재 <semanticDescriptor>(119) 자식 자원을 이미 갖고 있다면, 새로운 RDF 트리플이 이 <semanticDescriptor>(119) 자원에 직접 추가될 것이다.

도 17을 계속 참조하면, 이때 <contentInstance> 자원에 대해 생성된 어떠한 <semanticDescriptor> 자원도 없고, 모든 새로운 트리플은 <Device>(111)의 <semanticDescriptor>(116) 자식 자원에 직접 추가된다. 도 14와 마찬가지로, 시나리오 2A의 제2 옵션에 대한 정보 클론 프로세스는 도 18에 도시된 절차로서 정식으로 설명된다(단계들은 단계 152를 제외하고 도 14의 단계들과 유사하다). 단계 170에서, 예를 들어, Device(111)는 M2M 온도 디바이스이고 RH-SLN(122)에 이미 등록되어 있다. Device(111)는 그 판독치를 RH-SLN(122)에 전송할 수 있다. 한편, RH-SLN(122) 상의 <Device>(111) 자원은, 그 시맨틱 설명을 포함하는 <semanticDescriptor>(116) 자식 자원을 갖는다. 단계 171에서, Device(111)는 새로운 판독치를 RH-SLN(122)에 전송한다.

도 17의 단계 172에서, Device(111)로부터 새로운 판독치를 수신할 때, 데이터는 도 17에 도시된 바와 같이 <contentInstance> 자원, 예를 들어 <reading>(113) 자원에 저장될 수 있다. 한편, <reading>(113) 자원의 생성과 함께, 다른 동작들도 완료된다. 제1 동작에서, 현재 판독치, 예를 들어, 값 32는 RDF 트리플로서 표현된다. 예를 들어, 이들 트리플들은 2개의 링크를 갖는 "TemperatureValue" 노드(141)를 갖는 그래프를 기술할 수 있다. 하나의 링크는 이 노드의 값이 "32"라는 것을 기술하기 위한 것이고 다른 링크는 온도 단위가 섭씨라는 것을 보여주기 위한 것이다. 제2 동작에서, 이들 새로이 생성된 RDF 트리플은 기존의 관련된 <semanticDescriptor>(116) 자원에 직접 추가될 수 있다. 이 예에서, <Device>(111)의 <semanticDescriptor>(116) 자원은, 이들 새로이 생성된 트리플을 저장할 장소일 수 있다. 도 17에 도시된 바와 같이, 새로운 트리플이 추가될 때, "TemperatureValue" 노드(141)는 또한, "hasCurrentValue" 속성을 통해 OutputX(118) 노드에 링크된다. 이전 시간 단위의 판독치를 참조하는, "TemperatureValue" 노드(예를 들어, <Device>(111)의 <semanticDescriptor> 자원 내의 "TemperatureValue" 노드(142))가 이미 존재할 수도 있다는 점에 유의한다. 그 경우, 어떠한 새로운 트리플도 생성할 필요가 없고, 대신에 기존의 RDF 트리플이 업데이트되어 실제의 또는 가장 최신의 판독치, 예를 들어 32를 반영하기 위해 Device(111)의 최신 판독치를 나타내는데 이용될 수 있다. 유사하게, 제2 동작의 또 다른 고려 사항은, "TemperatureValue" 노드의 URI가 <Device>(111)의 <semanticDescriptor> 자원에 나타나고 다음과 같은 옵션을 가질 수 있다는 것이다. 제1 옵션에서, <reading>(113)의 현재 URI를 이용한다. 이 경우, 매 회, 새로운 판독치가 수신되는 한, <Device>(111)의 <semanticDescriptor>(116) 자원에 나타난 기존의 "TemperatureValue" 노드(141)의 URI는 새로이 수신된 판독치를 저장하는 자원의 URI를 갖도록 업데이트될 필요가 있다. 제2 옵션에서, 시스템-전체에 걸친 특별 URI가 <Device>(111)에 의해 이용되어 그 최신 판독치를 저장하는 "TemperatureValue" 노드(141)를 나타낼 수 있다. 비교로서, 후자의 옵션은 확장성 또는 유지보수의 용이성을 보조할 수 있다.

단계 173에서, RH-SLN(122)은 Device(111)로부터 전송된 판독치의 수신에 대해 확인응답한다. 따라서, 이 제2 시나리오에서의 질의에 대한 질의 처리는, <Device>(111)의 이 단일 <semanticDescriptor>(116) 자식 자원에는 어떠한 누락된 정보도 없고, 질의를 처리할 때 단 하나의 <semanticDescriptor>(116) 자원만이 포함되므로, 더 간단할 수 있다.

시나리오 2B에서, 원래 일반 자원에 저장된 정보는 RDF 트리플로 표현되지 않거나 <semanicDescriptor> 자원에 저장되지 않을 수도 있다. 특히, 일반 자원-A(예를 들어, 도 19에서와 같은 <reading>(113) 자원)로부터 나오는 정보의 경우, <reading>(113) 자원 자체는 oneM2M에서 정의된 바와 같이 "resourceDescriptorLink" 속성 또는 <semanticDescriptor>(116) 자원의 "relatedSemantics" 속성에 의해 참조될 것이다. 다시 말해, 특정한 <semanticDescriptor>(116) 자원 내의 RDF 트리플이 <reading>(113) 자원에 저장된 정보와 관련이 있다면, 이 <semanticDescriptor>(116) 자원은 <reading>(113) 자원에 링크될 것이다(<reading>(113) 자원은 일반 oneM2M 자원이라는 점에 유의한다). 다시 말해, "resourceDescriptorLink" 속성의 이용은 이제, (oneM2M에 의해 정의된) 2개의 <semanticDescriptor> 자원을 링크할 뿐만 아니라 <semanticDescriptor> 자원과 일반 oneM2M 자원을 링크하도록 확장된다. 대안으로서, 기존 resourceDescriptorLink 속성을 오버로딩하는 것 대신에, 이 목적을 지원하기 위해 "informationLink"라 불리는 새로운 속성이 제안될 수 있다.

도 19를 참조하면, 알 수 있는 바와 같이, <Device>(111)의 <semanticDescriptor> 자식 자원의 "TemperatureValue" 노드(141)의 경우, 이제는 <contentInstance> 자원, 예를 들어, <reading>(113)을 참조하는, resourceDescriptorLink 속성을 갖는다는 것을 알 수 있다. 도 20은 시나리오 2B에 대한 정보 링킹 방법을 도시한다. 대부분의 단계들은, 정보 링킹 절차를 비교함으로써, 이 시점에서 정보 클론 프로세스가 채택되지 않는 단계 152를 제외하고는 도 14의 단계들과 유사하다는 점에 유의한다. 이하에서는 도 19를 참조하여 도 20의 방법 흐름을 설명한다.

단계 180에서, Device(111)는 M2M 온도 디바이스이고 RH-SLN(122)에 이미 등록되어 있으며 그 판독치를 RH-SLN(122)에 전송할 수 있다. 한편, RH-SLN(122) 상의 <Device>(111) 자원은, 그 시맨틱 설명을 포함하는 <semanticDescriptor> 자식 자원을 갖는다. 단계 181에서, Device(111)는 새로운 판독치를 RH-SLN(122)에 전송한다.

단계 183에서, Device(111)로부터 새로운 판독치를 수신할 때, 데이터는 <contentInstance> 자원(예를 들어, 도 19에 도시된 <reading>(113) 자원)에 저장될 수 있다. 시나리오 2B의 예에서, RH-SLN(122)이 모든 온도 디바이스들의 최신 판독치가 시맨틱 질의를 통해 회수될 수 있도록 관리자에 의해 구성된다고 가정하면, RH-SLN(122)은 이들 디바이스들에 대한 판독 제출물을 계속 알고 있을 것이다. 따라서, <reading>(113) 자원의 생성과 함께, 다음과 같은 동작들이 트리거될 수 있다. 제1 동작에서, RH-SLN(122)은 먼저, <reading>(113) 자원에 저장된 정보를 링킹하는데 이용될 수 있는 <Device>(111)의 가장 적절한 <semanticDescriptor> 자식 자원을 식별한다. 대개, 이것은, 이용가능하다면 직접적인 부모의 <semanticDescriptor>(116) 자식 자원일 수 있다. 그렇지 않다면, 이 예에서는, <Device>(111)의 <semanticDescriptor> 자식 자원이 선택될 것이다.

단계 183하에서의 제2 동작에서, "현재 온도 판독치", 예를 들어, 도 19에 도시된 "TemperatureValue" 노드(141)를 표현하기 위하여, <Device>(111)의 <semanticDescriptor>(116) 자식 자원에 몇 개의 새로운 트리플이 추가될 수 있다. 한편, "TemperatureValue" 노드(141)는 또한, "hasCurrentValue" 속성을 통해 OutputX(118) 노드에 링크된다. 이전 시간 단위의 판독치를 참조하는, <Device>(111)의 <semanticDescriptor>(116) 자원에 "TemperatureValue" 노드(141)가 존재할 수 있다는 점에 유의해야 한다. 그 경우, 새로운 트리플이 생성될 필요가 없고, 대신에, 기존의 RDF 트리플이 업데이트되어 "TemperatureValue" 노드(141)의 resourceDescriptorLink가, 최신 판독치, 예를 들어 <reading>(113) 자원을 참조할 수 있게 할 수 있다. 대안으로서, "TemperatureValue" 노드(141)의 resourceDescriptorLink는, 자원의 <container> 유형인 <OutputX>(118)의 <latest> 자식 자원을 참조하고 <reading>(113) 자원을 포함할 수 있다. 유사하게, <Device>(111)의 <semanticDescriptor>(116) 자원에 나타난 "TemperatureValue" 노드(141)의 URI와 관련하여, 이 경우, 최신 판독치를 저장하는 "TemperatureValue" 노드(141)를 항상 나타내기 위해 시스템-전체에 걸친 특별 URI가 <Device>(111)에 의해 이용될 수 있다는 것이 개시되어 있다. 따라서, "TemperatureValue" 노드(141)의 resourceDescriptorLink가 <reading>(113)을 참조하도록 다음과 같은 트리플이 추가될 수 있다:

" TemperatureValue " 노드(141)의 URI

oneM2M:resourceDescriptorLink

<reading>(113) 자원의 URI

단계 183에서, RH-SLN(122)은 Device(111)로부터 전송된 판독치의 수신에 대해 확인응답한다.

시나리오 2B에 대한 시맨틱 질의 처리 스테이지와 관련하여, 명시된 시맨틱 질의가 RH-SLN(122)에 의해 수신되고 <Device>(111)의 <semanticDescriptor>(116) 자식 자원들 상에서 실행될 때, 이 시점에서 어떠한 누락된 정보도 없기 때문에(예를 들어, "TemperatureValue" 노드(141)의 resourceDescriptorLink가 이제는 <reading>(113)을 참조하고 있기 때문에 값 "32"가 이제는 역시 이용가능하다) 유효한 질의 결과가 나올 수 있다. 이러한 시맨틱 질의 처리는, 도 21에 도시된 절차로서 정식으로 설명된다. 도 21의 시맨틱 질의 처리를 위한 일반적인 절차는 도 11에 도시된 것과 유사하고, 여기서, RH-SLN(122)이 시맨틱 질의를 어떻게 처리하는지에 관한 도 11의 단계 132와 도 21의 단계 182 사이에는 차이가 있다는 점에 유의한다.

단계 192에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)에서 질의 처리가 수행된다. SPARQL은 <Device>(111)의 자식 <semanticDescriptor>(116) 자원 상에서 실행될 수 있다. 실행 동안에, 하나 이상의 resourceDescriptorLink 주석을 갖는 클래스 인스턴스 또는 노드와 조우하면, 실행이 중지된다. 도 19에 도시된 본 예에서, "TemperatureValue" 노드(141)는 최신 온도 값 "32"를 저장하는 <contentInstance> 자원, 예를 들어 <reading>(113)을 참조하는 resourceDescriptorLink를 갖는다. resourceDescriptorLink가 참조하는 이러한 자원들 각각에 대해, SPARQL 질의가 실행되고 있는 원래의 콘텐츠에 콘텐츠가 추가된다. 예를 들어, Device(111)의 현재 온도 값이 32라는 사실을 나타내기 위하여 새로운 RDF 트리플이 생성되고 추가될 것이다. SPARQL 질의의 실행은 앞서 언급된 원래의 콘텐츠로의 추가에 기초하는 확장된 콘텐츠에 관해 계속 수행되며 질의 결과가 나온다.

대안으로서, 단순히 "32"를 <contentInstance> 자원에 저장하는 것 대신에, <contentInstance>가 RDF 트리플을 직접 저장할 수도 있다. 예를 들어, 트리플 ""TemperatureValue" 노드(141)의 URI가 값 32를 갖는다"는 <contentInstance> 자원에 직접 저장될 수 있다. 또한, 이 시나리오의 경우, 다음 텍스트들은 이전 절들에서 논의된 바와 같이 정보 클론 프로세스(즉, <contentInstance> 자원의 콘텐츠를 RDF 트리플에 전송하고 RDF 트리플을 <semanticDescriptor> 자원에 저장하는 것)를 수행할 수 있는 모든 가능한 경우를 설명한다. 다음 옵션들은 모든 대안적인 솔루션들이다. 1) 데이터 판독치가 RL-SLN에 의해 수신될 때, 원래의 판독치를 클론하고 RDF 트리플로서 표현하고 <semanticDescriptor> 자식 자원에 저장하며, 이것은 이전 섹션에서 논의된 주요 사례이다; 2) 또 다른 경우에, 발신기로서의 디바이스의 경우, 판독치를 RL-SLN에 전송할 때, 디바이스 자체가 시맨틱 능력을 가진다면, 그 판독치를 RDF 트리플로서 RL-SLN에 직접 전송할 수 있고, 원래의 판독치/콘텐츠를 저장하는 이전에 생성된 <contentInstance> 자원에 대한 <semanticDescriptor> 자식 자원을 생성한다; 3) 디바이스는 데이터 판독치를 RL-SLN에 전송하고 원래의 판독치를 저장하기 위해 <contentInstance>가 생성된다. 이 디바이스와 RL-SLN 양쪽 모두가 시맨틱 기능을 가지고 있지 않다면, 다른 엔티티들도 역시 도움이 될 수 있다. 예를 들어, 나중에, 시맨틱 능력을 가진 또 다른 엔티티(예를 들어, oneM2M 정황에서 또 다른 AE 또는 CSE)는 <contentInstance> 자원의 원래의 콘텐츠를 판독하고, 그 콘텐츠를 RDF 트리플로서 복제한 다음, RDF 트리플을 저장하기 위한 <semanticDescriptor> 자식 자원을 생성할 수 있다.

제3 시나리오를 참조하면, 시맨틱 질의는, 복수의 상이한 <semanticDescriptor> 자원들에 저장될 수 있는 정보를 요청할 수 있다. 특히, 이들 <semanticDescriptor> 자원들은, 이들 상이한 <semanticDescriptor> 자원들 사이에 일부 중첩된 노드들이 있을 수 있다는 의미에서 서로 관련될 수 있다. <semanticDescriptor> 자원 내의 시맨틱 설명은 개념적으로 그래프(예를 들어, 도 22의 블록 118 및 블록 144) 및 노드(예를 들어, 도 22의 디바이스 111)를 형성한다는 점에 유의한다.

이하에서는 제3 시나리오와 관련하여 더 논의된다. 도 22는, <Device>(111)가 온도 센서를 나타내고, 그 자식 자원 <semanticDescriptor>는 RDF 트리플의 측면에서 관련된 시맨틱 설명을 포함하는 부분적인 자원 트리 구조를 나타낸다. 한편, <Device>(111)는 그 동작(예를 들어, <Operation> 114)을 나타내는 자식 자원을 가지며, <Operation>(114)도 그 자신의 <semanticDescriptor>(143) 자원을 갖는다. <semanticDescriptor>(116) 자원과 <semanticDescriptor>(143) 자원은, 이들 양쪽 모두가 <Device>(111)의 일부 양태를 기술하고 있고 이들 양쪽 모두가 "Operation"(114)를 나타내는 동일한 노드를 가지므로 서로 관련되어 있다. 질의 설명의 의도는 다음과 같을 수 있다: "주어진 디바이스에 대한 서비스의 이용가능한 시간을 반환하고 이 서비스는 그 출력이 온도 양태를 기술하는 동작을 가진다." SPARQL 표현은 다음과 같을 수 있다:

이 예에서, 종래의 상황에서 <Device>(111)의 <semanticDescriptor>(116) 자식 자원에 관해 직접적으로 상기의 질의를 적용하면, <Operation>(114)에 관련된 시맨틱 정보 중 일부가 <Device>(111)의 <semanticDescriptor> 자식 자원으로부터 누락되어 있기 때문에, 어떠한 결과도 반환되지 않을 수 있다. 특히, 정보는 <Operation>(114)의 <semanticDescriptor> 자식 자원에 저장된다. 이러한 상황은 시맨틱 질의 처리 관점에서 이하에서 더 상세히 고려된다.

제3 시나리오의 고려사항은, 정의된 종래의 기존의 resourceDescriptorLink(예를 들어, oneM2M)가 이용되는 시나리오 2A(옵션-1)와 유사하다. 도 23에 도시된 바와 같이, 2개의 <semanticDescriptor> 자원이 Operation(114) 노드를 통해 함께 링크될 수 있도록 "resourceDescriptorLink" 속성이 이용된다.

시맨틱 질의 처리 스테이지와 관련하여, 이용 사례 3에서 명시된 시맨틱 질의가 RH-SLN(122)에 의해 수신될 때, 이 질의는 <Device>(111)의 자식 <semanticDescriptor> 자원 상에서 실행되고, <OperationA>의 <semanticDescriptor> 자식 자원에서 트리플을 발견하고 액세스하여 결국 유효한 질의 결과를 낸다. 도 11에 도시된 것과 유사한 도 24에 도시된 제3 시나리오의 시맨틱 질의 처리를 위한 일반 절차 및 가장 중요한 차이점은 RH-SLN(122)이 시맨틱 질의를 어떻게 처리하는지에 관한 도 24의 단계 202에 관한 것이라는 점에 유의한다. 단계 202에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)에서의 질의 처리는 다음과 같이 수행된다. SPARQL 질의는 <Device>(111)의 자식 <semanticDescriptor> 자원 상에서 실행된다. 실행 동안에, 하나 이상의 resourceDescriptorLink 주석을 갖는 클래스 인스턴스 또는 노드와 조우하면, 실행이 중지된다. 본 예에서, operation(114) 노드는 <Operation>(114) 자원의 자식 <semanticDescriptor> 자원을 참조하는 resourceDescriptorLink를 갖는다. resourceDescriptorLink가 참조하는 각각의 이러한 자원에 대해, SPARQL 질의가 실행되고 있는 원래의 콘텐츠에 콘텐츠가 추가된다. 예를 들어 <Operation>(114) 자원의 <semanticDescriptor> 자식 자원의 RDF 트리플들이 추가될 수 있다. SPARQL 질의의 실행은 (위에서 언급된 RDF 트리플의 추가에 기초하여) 확대된 콘텐츠에 관해 계속되고 질의 결과를 낸다.

제4 시나리오를 참조하면, 복수의 상이한 <semanticDescriptor> 자원들에 저장될 수 있는 정보를 요청할 수 있다. 특히, 이들 <semanticDescriptor> 자원은 심지어 서로 관련되지 않을 수도 있다(제3 시나리오와 상이함). "피어"는 기본적으로, 이들 <semanticDescriptor> 자원들이 서로 무관하고 각기 상이한 자원들(예를 들어, 한 지역 내의 다수의 <temperature-sensor> 자원)을 기술하지만, 이들 온도 센서들은 서로에 대해 피어이고 동일한 유형의 기능을 가진다는 것을 의미한다는 점에 유의한다. 예를 들어, 2개의 <semanticDescriptor> 자원은 각각 2개의 개별 온도 디바이스를 기술할 수 있고, 이들 2개의 온도 디바이스 또는 그들 각각의 <semanticDescriptor> 자원은, 예를 들어 이들이 동일한 유형이거나, 또는 동일한 지역에 있거나 등이기 때문에 피어로서 간주될 수 있다. 이것은, 2개의 <semanticDescriptor>가 동일한 디바이스를 기술하고 공통점을 가질 수 있는 상황을 다루는 시나리오 3과는 상이하다.

이하에서는 제3 시나리오와 관련하여 더 논의된다. 도 25는, <Device>(111), <Device>(146), 및 <Device>(147)가 3개의 디바이스를 나타내고, 이들 각각은 그들 각각의 시맨틱 설명을 저장하는 자식 자원 <semanticDescriptor>를 갖는 부분적인 자원 트리 구조를 도시한다. 따라서, 이들 3개의 <semanticDescriptor> 자원들은, 이들이 상이한 디바이스들을 설명하기 때문에 서로에 대한 피어이다. 또한, 이들 3개의 센서는 상이한 회사들에 속할 수 있다(예를 들어, <Device>(111)는 <CompanyA>의 자식 자원인 반면, <Device>(146) 및 <Device>(147)은 <CompanyB>의 자식 자원임). 질의 설명의 의도는 다음과 같을 수 있다: "CompanyA 및 CompanyB로부터의 모든 디바이스들의 동작의 작동 모드를 나에게 반환하라. "SPARQL 표현은 다음과 같을 수 있다:

이 예에서, CSE 노드의 루트 자원 <CSEBase>(210)에 관해 직접적으로 상기 질의를 적용할 때, 이들 각각이 상이한 디바이스를 나타내기 때문에 3개의 상이한 관련없는 <semanticDescriptor> 자원들을 평가할 필요가 있다. 그러나, 복수의 피어 또는 관련없는 <semanticDescriptor> 자원들로부터의 정보를 요구하는 경우 이러한 질의를 처리하는 방법에 관해 (예를 들어, oneM2M에서) 정의된 종래의 상세사항은 현재 없다.

기본 솔루션에서, 주어진 시맨틱 질의에 대해, 잠재적으로 관여된 <semanticDescriptor> 자원에 대한 질의 범위의 결정은 복수의 접근법을 활용할 수 있다. 제1 접근법에서, 시맨틱 질의를 운반하는 요청 메시지에 표시된 "To" 파라미터가 주어지면, "To" 파라미터에 의해 표시된 URI 아래의 모든 <semanticDescriptor> 자원이 관여될 것이다, 예를 들어, 범위는 "To" 파라미터에 의해 표시된 URI 아래의 자식 자원들을 포함한다. 추가로, oneM2M은 또한, 검색 범위를 제한하기 위해 "레벨(level)" 및 "오프셋(offset)" 파라미터를 정의한다. 따라서, 이들 2개 파라미터가 제 위치에 있다면, 그에 따라 질의 범위에도 영향을 줄 것이다. 제2 접근법에서, "peerSemantics"라 불리는 새로운 속성이 <semanticDescriptor> 자원에 대해 제안된다. 특히, 제1 접근법에서 식별된 <semanticDescriptor> 자원의 경우, 그들의 "peerSemantics" 속성도 체크될 수 있고, 이를 통해 더 많은 <semanticDescriptor> 자원이 관여된 자원으로서 식별될 수 있다(이것은, 질의 범위가, 공개된(disclosed) "peerSemantics" 속성에 의해 표시된 이들 <semanticDescriptor> 자원을 역시 포함할 것이라는 것을 의미한다). oneM2M에 의해 정의된 기존의 "relatedSemantics" 속성은 단일 SPARQL 처리를 위해 관련된 <semanticDescriptor> 자원들을 함께 링크하는 것이라는 점에 유의한다.

비교로서, 제안된 "peerSemantics는 피어 <semanticDescriptor> 자원을 링크하는 것이며, 시맨틱 질의는 이들 피어 <semanticDescriptor> 자원들 각각 상에서 개별적으로 실행될 수 있다. 이것은, 기존의 "relatedSemantics" 속성에 추가하여, 새로운 "peerSemantics" 속성이 왜 제안되는지에 대한 주요 이유이다(그렇지 않으면, 시스템이 2개의 <semanticDescriptor> 자원들 사이의 실제 관계를 말할 수 있는 방법을 갖지 못할 수도 있다). 예를 들어, 특정한 <semanticDescriptor-1> 자원에 관해 SPARQL Query-1이 적용된 상황을 고려해 보자: 또 다른 <semanticDescriptor-2> 자원에 링크하는 "relatedSemantics"가 있다면, <semanticDescriptor-2> 자원 내의 콘텐츠는 <semanticDescriptor-1> 자원 내의 콘텐츠와 통합된 다음, Query-1이 통합된 콘텐츠에 관해 실행될 것이다. 비교로서, 또 다른 <semanticDescriptor-2> 자원에 링크하는 "peerSemantics"가 있다면, Query-1이 <semanticDescriptor-1> 자원 및 <semanticDescriptor-2> 자원 양쪽 모두에 관해 개별적으로 적용되고, 각각의 실행은 부분적인 질의 결과를 반환할 수 있다는 의미에서 질의 처리가 상이할 것이다. 제1 접근법과 제2 접근법을 통해 식별된 이들 <semanticDescriptor> 자원들은 실행될 특정한 질의 처리를 위한 자원 세트일 수 있다.

이하, 제4 시나리오가 더 논의된다. 도 26은 "peerSemantics"가 질의 범위를 갖는 쟁점을 처리하는 것을 어떻게 도울 수 있는지를 도시한다. 여기서, SQI(121)는 RH-SLN(122)에서의 자원 구조에 대한 제한된 지식만을 갖고 있고, 이전의 자원 발견을 통해 <CompanyB>의 URI만을 알고 있다고 가정한다. SQI(121)는 이제 "모든 회사의 모든 디바이스들의 동작의 작동 모드를 나에게 반환하라"이라는 측면에서 새로운 질의를 갖는다. SQI(121)가 이 질의를 전송하는 한 방식은, <CSEBase>(210) 아래의 디바이스들이 발견될 수 있도록 <CSEBase>(210)을 직접 타겟으로 한다. 그러나, 이 동작에 대한 오버헤드는 상당할 수 있다. 제안된 "peerSemantics" 속성에 의해, SQI(121)이 여전히 <CompanyB>를 타겟으로 하는 질의를 전송하는 것을 가능케할 수 있다. 따라서, <CompanyB>(예를 들어, 이 예에 도시된 <Device> 147) 아래의 디바이스들 중 하나가 다른 회사들의 다른 디바이스들(예를 들어, 상이한 회사, <CompanyA>로부터의 디바이스 <Device> 111)에 링크하는 "relatedSemantics"를 갖고 있다면, 질의 처리는 "peerSemantics" 속성의 도움에 의해 모든 필요한 디바이스들을 찾을 수 있다.

도 26에서 알 수 있는 바와 같이, 기본적인 솔루션에서, 잠재적인 관여된 <semanticDescriptor> 자원을 찾는 것은, 동시에 이용될 수 있는 제안된 접근법 1 및 접근법 2를 통해 이루어질 수 있다. 한편, 질의 요청은 단일 RETRIEVE 메시지에 매핑될 수 있고, 질의 시작점은 "To" 파라미터에 의해 명시된 URI에 기초할 수 있다. 한편, 접근법 1은 "To" 파라미터에 의해 명시된 URI 아래의 관여된 <semanticDescriptor> 자원의 발견을 허용하는 반면, 접근법 2는 To" 파라미터에 의해 명시된 URI 아래에 존재하지 않을 수 있는, 예를 들어, (소정의 액세스 제어 정책을 준수할 필요가 있을지라도) 자원 트리 내의 임의의 곳에 있을 수 있는, 다른 관여된 <semanticDescriptor> 자원을 발견하도록 허용한다. 예를 들어, 제4 시나리오에서 명시된 시맨틱 질의가 RH-SLN(122)에 의해 수신되고 "To" 파라미터가 <CompanyB>의 URI를 향하는 경우, 어떠한 누락된 정보도 없기 때문에(예를 들어, <Device>(111)은 이 시점에서 놓치게 되지 않을 것이다) 정확한 질의 결과가 나올 것이다.

시맨틱 질의 처리 스테이지와 관련하여, 이것은 도 27에 도시된 절차로서 정식으로 설명된다. 도 27의 시맨틱 질의 처리를 위한 일반 절차는 도 11에 도시된 것과 유사하며, 유일한 차이점은, 이하에서 더 상세히 논의되는, RH-SLN(122)이 시맨틱 질의를 어떻게 처리하는지에 관한 단계 222이라는 점에 유의한다. 단계 222에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)에서의 질의 처리는 다음과 같은 동작들로 수행된다. 제1 동작에서, SQI(예를 들어, SQI(121))로부터 요청을 수신하면, 수신기(예를 들어, RH-SLN(122))는 요청 메시지 내의 "To" 파라미터에 의해 표시된 시작점으로부터 시맨틱 질의 처리를 수행하기 시작할 수 있다. 특히, RH-SLN(122)은 먼저, 앞서 정의된 접근법 1 및 접근법 2를 이용함으로써 잠재적인 모든 관여된 자원을 식별할 수 있다. 이 예에서, <Device>(111), <Device>(146), 및 <Device>(147)은 도 26에 도시된 바와 같이 식별될 수 있다. 도 26을 참조한 제2 동작에서, 각각의 잠재적으로 관여된 <semanticDescriptor> 자원에 대해, RH-SLN(122)은 소정의 액세스 제어 정책에 기초하여 시맨틱 질의가 그 자원 상에서 실행될 수 있는지를 더 평가한다. 만일 그렇다면, 이러한 자원은 정식 관여된 자원이 될 수 있다.

단계 222의 제3 동작에서, 각각의 정식 관여된 <semanticDescriptor> 자원에 대해, 시맨틱 질의가 그 자원 상에서 실행된다. 유효한 질의 결과가 있다면, 이 질의 결과가 최종 결과 세트에 추가될 수 있다. 한편, 이들 정식 관여된 자원에 관한 질의 처리는 서로 독립적으로 수행될 수 있다. 제4 동작에서, 공식 관여된 자원이 질의와 함께 평가된 후, 최종 결과 세트가 최종 질의 결과를 포함할 것이고, SQI(121)에 반환될 것이다.

앞서 논의된 기본 솔루션에서, "To" 파라미터에 의해 표시된 자원 URI는 주로 질의 처리가 시작되는 곳을 결정한다고 가정한다, 예를 들어, "To"(또는 유사) 파라미터가 디폴트 질의 범위를 결정하는데 이용된다. 사실상, 질의 범위는, 특히 주어진 시맨틱 질의가 복수의 <semanticDescriptor> 자원을 수반할 때 시맨틱 질의 처리에 영향을 줄 수 있는 주요 문제가 될 수 있다. 이하에서 논의되는 향상은 질의 범위 관련 문제를 해결하기 위한 것이다.

질의 범위와 연관된 중요한 문제는, 질의 범위가 기존의 oneM2M 명세를 준수하는 경우, 예를 들어, 특정한 시맨틱 질의에 성공적으로 및 올바르게 응답하기 위해 필요한 질의 범위와 같지 않을 수 있다는 것이다. 예를 들어, 도 28에서 알 수 있는 바와 같이, SQI가 <CSEBase>(210)을 루트로 하는 자원 트리를 호스팅하는 RH-SLN(122)에 시맨틱 질의 요청을 전송한다고 가정하자, 여기서, "To" 파라미터는 <CompanyB>(212)의 URI를 타겟으로 하고 요약된 시맨틱 질의는 "CompanyA(211) 및 CompanyB(212)로부터의 모든 디바이스들의 동작의 작동 모드를 나에게 반환하라"를 나타낸다. 이러한 경우에, 기존의 oneM2M 명세에 기초하여, <Device>(146) 및 <Device>(147)의 <semanticDescriptor> 자식 자원들이 관여될 수 있다. 그러나, 이 질의에 올바르게 응답하기 위해, <Device>(111)의 <semanticDescriptor>(116) 자식 자원도 역시 관여되어야 한다(액세스 제어가 여기서는 문제가 되지 않는다고 가정). 따라서, <Device>(146), <Device>(147) 및 그들의 <semanticDescriptor> 자식 자원에만 기초하는 최종 질의 결과는, 시맨틱 질의가 "모든 디바이스에 관해" 결과를 묻고 있기 때문에(<Device>(111)이 빠져 있으므로) 정확하지 않을 수 있다.

아래에서 논의되는 향상은 질의 범위 문제를 해결할 수 있는 복수의 접근법을 포함할 수 있다. 제1 향상된 접근법에서, SQI(121)는 원하는 임의의 특정한 시맨틱 질의를 여전히 명시할 수 있고, RH-SLN(122) 상에서, 관여된 <semanticDescriptor> 자식 자원을 식별하기 위해 질의 범위를 결정하는 (다음에 개시되는) 소정의 동작 정책을 따를 수 있다. 첫째, SQI(121)와 RH-SLN(122) 양쪽 모두는, 다음과 같은 3가지 경우를 포함하는, 질의 범위를 결정하는 방법에 관해 다음과 같은 협의를 갖는다. 즉, SQI(121)는, 질의가 협의된 질의 범위에서만 실행될 수 있다는 것을 미리 이해할 수 있다.

제1 향상된 접근법의 경우 1에서, SQI(121)는, <CSEBase>(210) 자원 아래에 있는 모든 <semanticDescriptor> 자식 자원이 체크될 수 있도록 <CSEBase>(210) 자원을 타겟으로 하는 그 시맨틱 질의 요청을 직접 전송할 수 있다, 예를 들어, 질의 범위는 이 경우 현재의 RH-SLN(122)의 전체 자원 트리이다. 더 일반적으로, 이전 절들에서 제안된 솔루션들이 역시 이용될 수 있는데, 예를 들어, <CSEBase>(210) 아래의 <semanticDescriptor> 자식 자원들은, 또 다른 CSE 상의 다른 <semanticDescriptor> 자원들에 링크될 수 있는 "peerSemantics" 속성을 가질 수 있다.

제1 향상된 접근법의 경우 2에서, <CSEBase>(210)를 타겟으로 하는 시맨틱 질의 요청을 전송하는 것 대신, <queryPortal>이라 불리는 새로운 자원이 공개된다. 따라서, SQI(121)는 이 <queryPortal> 자원을 타겟으로 하는 그 시맨틱 질의 요청을 직접 전송할 수 있다. 특히, 이 <queryPortal>은 그 자신의 질의 범위를 나타내는 "queryScope"라 불리는 속성을 가질 수 있다(이 새로운 자원에 대한 자세한 설명은 여기서 논의된다). 따라서, 이 <queryPortal> 자원에 전송된 모든 시맨틱 질의는, URI일 수 있고 대응하는 질의 범위는 이 URI 아래의 모든 자식 자원일 수 있는, 이 <queryPortal> 자원의 그 "queryScope" 속성에 의해 표시된 질의 범위에서 실행될 것이다. 또한, 주어진 RH-SLN(122)은 복수의 <queryPortal> 자원을 포함할 수 있고, 이들 각각은 그들 자신의 질의 범위를 가질 수 있다. 예를 들어 일반 자원 발견을 통해 이들 <queryPortal> 자원을 발견하고 질의가 실행되기를 원하는 것을 선택하는 것은 SQI에 달려있다.

제1 향상된 접근법의 경우 3에서, SQI(121)는 ("To" 파라미터에 의해 명시된) 임의의 자원 URI를 타겟으로 하는 그 시맨틱 질의 요청을 직접 전송할 수 있고, 이것은, 질의 범위가 이 URI 아래의 모든 <semanticDescriptor> 자식 자원일 수 있다는 것을 의미한다. 유사하게, 이전 절들에서 제안된 솔루션들이 역시 이용될 수 있다, 예를 들어, "To" 파라미터에 의해 명시된 URI 아래의 <semanticDescriptor> 자식 자원들은 또한, 이 CSE의 자원 트리의 임의의 장소에 있을 수 있는 다른 <semanticDescriptor> 자원에 링크하는 "peerSemantics" 속성을 가질 수 있다. 이 사례는 기본 솔루션과 함께 연구되었지만, 이 절은 개선을 이룰 수 있는 추가적인 변경을 제공한다는 점에 유의해야 한다. 예를 들어, 이 경우에 SQI(122)는 원하는 임의의 질의를 제공할 수 있기 때문에, RH-SLN(122)에 의해 이용되는 질의 범위가 정확한 질의 결과를 제공하기에 완벽하지 않은 경우 소정의 부정확성이 존재할 수 있다. 따라서, RH-SLN(122)은 질의 결과를 SQI에 그 인식을 위해 반환할 때 질의 결과/품질 요약을 나타낼 수 있는 것이 요구된다.

시맨틱 질의 처리 스테이지와 관련하여, 이것은 도 29에 도시된 절차로서 정식으로 설명된다(상세한 설명은 도 28에 도시된 예를 이용하여 예시된다). 단계 230에서, 전제 조건이 있다. 필요성에 기초하여, SQI(121)는 RH-SLN(122)에 관한 일부 정보를 질의할 수 있다. 따라서, SQI(121)는 그 질문을 기술하기 위해 SPARQL 질의문을 공식화한다. 예를 들어, SQI(121)가 시나리오 4에 예시된 바와 같이 질의를 수행하고자 한다고 가정하자.

도 29를 참조하면, 단계 231에서, SQI(121)는 RH-SLN(122)에 요청 메시지를 전송하고, 여기서, 이 메시지는 이 요청이 처리될 시맨틱 질의와 관련되어 있음을 나타낸다. 도 11의 단계 291에 개시된 파라미터에 추가하여, 메시지는 새로운 파라미터 Need_query_summary(nqs)를 포함할 수 있다: 이 정보는, RH-SLN(122)이 SQI(121)에 질의 결과를 반환할 때, SQI(121)가 관련된 질의 결과 또는 품질 요약 정보를 원하는지를 나타낸다.

단계 232에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)에서의 질의 처리는 다음과 같이 수행된다. 제1 동작에서, "To" 파라미터가 <CSEBase> 자원을 타겟으로 하는 경우, 이것은 잠재적인 관여된 <semanticDescriptor> 자원을 식별하기 위해 경우 1에서 소개된 상세사항에 따라 이 질의 처리를 취급할 수 있다. 또는, "To" 파라미터가 <queryPortal> 자원을 타겟으로 하는 경우, 이것은 잠재적인 관여된 <semanticDescriptor> 자원을 식별하기 위해 경우 2에서 소개된 상세사항에 따라 이 질의 처리를 취급할 수 있다. 또는, "To" 파라미터가 RH-SLN(122)의 자원 트리 내의 임의의 자원을 타겟으로 하는 경우, 이것은, 잠재적인 관여된 <semanticDescriptor> 자원을 식별하기 위해 경우 3에 소개된 상세사항에 따라 이 질의 처리를 취급할 수 있다. 단계 232에 대한 제2 동작에서, 잠재적인 관여된 <semanticDescriptor> 자원의 각각에 대해, RH-SLN(122)은 소정의 액세스 제어 정책에 기초하여 시맨틱 질의가 그 자원 상에서 실행될 수 있는지를 더 평가한다. 만일 그렇다면, 이러한 자원은 정식 관여된 자원이 될 것이다. 단계 232의 제3 동작에서, 각각의 정식 관여된 <semanticDescriptor> 자원에 대해, 시맨틱 질의가 그 자원 상에서 실행된다. 유효한 질의 결과가 있다면, 이 질의 결과가 최종 결과 세트에 추가될 수 있다. 한편, 이들 정식 관여된 자원에 관한 질의 처리는 서로 독립적으로 수행될 수 있다. 공식 관여된 자원이 질의와 함께 평가된 후, 최종 결과 세트가 최종 질의 결과를 포함할 수 있고, SQI(121)에 반환될 수 있다.

단계 233에서, RH-SLN(122)은 SQI(121)에 의해 표시된 포맷을 이용함으로써 질의 결과가 포함된 응답 메시지를 다시 SQI(121)에 전송할 수 있다. 도 11의 단계 231에서 제안된 파라미터에 추가하여, 메시지는 다음과 같은 새로운 파라미터 query_summary(qs)를 포함할 수 있다. query_summary 파라미터는, 질의 결과 품질 또는 요약 정보를 포함할 수 있다. 예를 들어, 이것은 질의가 실행된 <semanticDescriptor> 자원을 나타낼 수 있다. 이 정보를 이용함으로써, SQI(121)는 반환된 질의 결과가 바람직하고 충분히 정확한지 여부를 평가할 수 있다. 기타의 정보는 질의 처리 시간 비용 등을 포함할 수 있다.

제2 향상된 접근법에서, RH-SLN(122) 측에서는, 기존의 <group> 및 <semanticGroup> 자원을 이용함으로써 일부 관련된 자원을 함께 선제적으로 집결할 수 있다. <group> 및 <semanticGroup> 자원들의 일부 피처는 기존의 TS-0001 및 TR-0007에 정의된 바와 같다. 요약하면, 시맨틱 질의 프로세스는 시맨틱 디스크립터 수집과 분리될 수 있다. 예를 들어, 임의의 시맨틱 질의를 처리하지 않고, 수신시 측에서는, 기존의 <group> 또는 <semanticGroup> 자원을 이용함으로써 일부 관련된 <semanticDescriptor> 자원들을 선제적으로 집결할 수 있다. 따라서, SQI(121)는 먼저 이들 자원을 발견하고, 그 다음, 처리를 위해 이들 자원들에 시맨틱 질의를 전송할 수 있다. 특히, 이러한 접근법에서, SQI(121)에 의해 제기된 시맨틱 질의는, 질의 범위가 이들 <group> 또는 <semanticGroup> 자원의 멤버 자원에 의해 이미 결정되었으므로, 질의 범위 관련 진술문을 운반할 필요가 없다.

제2 향상된 접근법을 계속 참조하여, 예를 들어, <semanticGroup> 자원(또는 <group> 자원)은 <Device>(111), <Device>(146), 및 <Device>(147)의 모든 <semanticDescriptor> 자식 자원들을 포함할 수 있는 RH-SLN(122)에서 생성될 수 있다(예를 들어, 기존의 <semanticGroup> 자원의 "semanticGroupLinks" 속성 또는 <group> 자원의 "memberIDs" 속성을 이용함으로써). 도 30은 이들 2개의 경우에 대한 2개의 예를 제공한다. 따라서, <semanticGroup> 자원 내에서, 이 그룹이 무엇인지(일반 설명으로서, 예를 들어, "모든 디바이스") 나타낼 수 있고 또한 디바이스들의 모든 참조를 포함할 수도 있다. 따라서, SQI(121)가 "모든 디바이스들의 동작 명칭을 질의하는 것"과 같은 질의를 전송할 필요가 있는 접근법 1과는 달리, 접근법 2에서, SQI(121)는 먼저, CompanyA 및 CompanyB의 모든 디바이스들을 그 멤버로서 포함하는 특정한 <semanticGroup> 자원을 발견할 수 있다. 이 <semanticGroup> 자원의 일반 설명을 습득함으로써, SQI(121)는 이 <semanticGroup> 자원이 모든 디바이스의 참조를 갖는다는 것을 이해할 수 있다. 그 다음, SQI(121)는 질의 범위(예를 들어, "모든 디바이스들")를 나타내지 않고 "동작 명칭을 질의하는" 질의 요청을 전송할 수 있고, 이러한 질의는 이 <semanticGroup>의 모든 멤버 자원에 자동으로 적용될 것이며, <Device>(111), <Device>(146) 및 <Device>(147)의 모든 관여된 <semanticDescriptor> 자식 자원들이 체크될 수 있다. 제2의 개선된 접근법에서 알 수 있는 바와 같이, 질의 범위는 RH-SLN(122) 측에서 선제적으로 결정되고, SQI(121)는 시맨틱 질의를 전송하기 전에 질의 범위 또는 관여된 <semanticDescriptor> 자식 자원을 안다. 따라서, 질의 결과는, SQI(121)와 RH-SLN(122) 양쪽 모두가 질의 범위에 대해 동일한 이해를 가지므로, 제2 향상된 접근법에서 정확하다.

이하는, 제2 향상된 접근법에서 시맨틱 질의가 어떻게 처리될 수 있는지에 관한 더 많은 상세사항이다. 단계 251에서, SQI(121)는 <semanticGroup>(240) 또는 <group>(242) 자원을 발견한다. 단계 252에서, SQI(121)는 질의 요청을 포함할 수 있는 시맨틱 질의를 이 자원에 전송할 수 있다. 특히, 시맨틱 질의 요청은, 이 <group> 또는 <semanticGroup> 자원의 <semanticFanOutPoint> 자식 자원을 타겟으로 하는 RETRIVE 동작에 매핑될 수 있다. <semanticFanOutPoint> 자원은 표현을 갖지 않기 때문에 가상 자원이다. 이것은, <semanticDescriptor> 유형의 멤버들을 갖는 <group> 자원의 자식 자원이다. 시맨틱 질의 요청이 <semanticFanOutPoint> 자원에 전송될 때마다, 호스트(예를 들어, 이 경우 RH-SLN(122))는 부모 <group> 자원 또는 <semanticGroup> 자원의 memberIDs 속성을 이용하여 모든 관련된 시맨틱 디스크립터에 액세스한다. 다른 RH-SLN에 저장된 시맨틱 디스크립터가 존재하는 경우, 외부 시맨틱 디스크립터를 회수하기 위해 개개의 RETRIEVE 요청이 RH-SLN(122)으로부터 다른 RH-SLN들 각각에 전송된다. 시맨틱 디스크립터는 각각의 액세스 제어 정책에 기초하여 액세스된다.

특히, 이들 자원에 관한 기존의 시맨틱 발견 처리와는 달리, 시맨틱 질의 처리에서, 일단 관여된 <semanticDescriptor> 자원이 <group> 또는 <sematicGroup> 자원을 통해 식별되고 나면, 질의는, 이들 관여된 <semanticDescriptor> 자원들 각각 상에서 직접적으로 및 개별적으로 실행될 수 있다. 한편, 관여된 <semanticDescriptor> 자원이 시맨틱 질의 처리 능력을 갖지 않는 또 다른 RH-SLN 상에 있다면, 이 관여된 <semanticDescriptor> 자원의 콘텐츠는, 시맨틱 질의 요청을 수신하고 질의가 실행될 수 있는(그러나 여전히 개별적으로) <group> 또는 <sematicGroup> 자원을 호스팅하는 원래의 RH-SLN에 의해 여전히 회수될 수 있다. 마지막으로, 최종 질의 결과는, 관여된 <semanticDescriptor> 자원들 각각에 관한 모든 개개의 질의 결과를 결합함으로써 생성될 수 있다(단계 253).

도 30은 상기 동작 상세사항을 도시하는 예를 제공한다. 예를 들어, RH-SLN(122) 측에서, 그 semanticGroupLink가 모든 디바이스들에 대한 참조를 포함하는 <SemanticGroup-1>(240) 자원, 예를 들어, <Device>(111), <Device>(146) 및 <Device>(147)(또는 <Device>(111), <Device>(146) 또는 <Device>(147) 자원일 수도 있다)의 <semanticDescriptor>(116, 148, 49) 자식 자원들이 생성될 수 있다. 이 그룹이 모든 회사들로부터의 모든 디바이스들을 포함한다는 것을 기술하기 위해 이 <SemanticGroup> 자원에 대해 새로운 "설명" 속성이 정의될 수 있다. 파라미터는 또한, 다른 유익한 정보를 포함할 수 있다. 예를 들어, 이것은, 이 <SemanticGroup> 자원이 어떤 종류의 질의를 지원할 수 있는지를 기술/표시할 수 있다. 이 방식은, SQI(121)가 나중에 시맨틱 질의를 전송하기 위한 적절한 <SemanticGroup> 자원을 발견하는 것을 용이화하고 도울 수 있다.

대안으로서, 이 그룹은 <group>(242) 자원에 의해 표현될 수도 있다. 특히 <Group-1>(242)의 <semanticDescriptor> 자원은, 이 자원 그룹이 무엇인지에 대해 기술하는데 이용될 수 있다. 절차와 관련하여, SQI(121)는 먼저, 이들 <semanticGroup>(240) 또는 <group>(242) 자원을 발견할 수 있다(단계 251). 일단 적절한 것이 선택되고 나면, SQI(121)는 이 선택된 <semanticGroup>(240) 또는 <group>(242) 자원에 그 시맨틱 질의를 전송할 수 있고(단계 252), 질의는, 이 선택된 <semanticGroup>(240) 또는 <group>(242) 자원에 의해 표시된 멤버 자원들 상에서 질의가 실행될 것이다(단계 253). 단계 254에서, 질의 결과는 SQI(121)에 반환될 것이다.

시맨틱 질의 처리 스테이지와 관련하여, 도 31에 도시된 바와 같이 설명된다. 단계 261에서, SQI(121)는 자원 발견 요청 메시지를 RH-SLN(122)에 전송하며, 여기서, 이 메시지는, 이 요청이 나중에 시맨틱 질의가 실행될 잠재적인 <semanticDescriptor> 자원을 발견하는 것임을 나타낸다. 이 요청에서, 새로운 파라미터 resource_discovery_purpose(rdp)는 이 자원 발견 요청의 목적을 나타낼 수 있다. resource_discovery_purpose(rdp) 정보는, SQI(121)가 시맨틱 질의를 수행하기 위한 <semanticDescriptor> 자원을 찾고 있다는 것을 나타낸다. 단계 262에서, rdp 파라미터를 통해, RH-SLN(122)은 이 자원 발견이 소정의 <group>(242) 또는 <semanticGroup>(240) 자원으로만 제한된다는 것을 알게 된다. 따라서, RH-SLN(122)은 일반 자원 발견 프로세스를 수행하고, 시맨틱 질의를 지원하는데 이용될 수 있는 <group>(242) 또는 <semanticGroup>(240) 자원들의 목록을 반환한다. 단계 263에서, RH-SLN(122)은 <group>(242) 또는 <semanticGroup>(240) 자원들의 목록이 포함된 응답 메시지를, 이들 자원들에 관한 설명 정보와 함께, SQI(121)에 다시 전송한다.

단계 264에서, SQI(121)는 반환된 <group>(242) 또는 <semanticGroup>(240) 자원들 각각을 평가하여 원하는 자원을 결정한다. 이 프로세스 동안, SQI(121)는 또한, 더 많은 정보를 획득하기 위해 이들 자원에 액세스할 수 있다. 단계 265에서, 특정한 <group>(242) 또는 <semanticGroup>(240) 자원을 결정한 후, SQI(121)는, 예를 들어 선택된 <semanticGroup>(240) 자원의 <semanticFanOutPoint> 자식 자원을 타겟으로 하는 새로운 시맨틱 질의 요청을 전송한다. 새로운 파라미터 질의문(QS), 결과 포맷(RF), 또는 필요 질의 요약(NQS)이 이용될 수 있다. 질의문(qs)은, SPARQL 질의문일 수 있는, SQI(121)에 의해 명시된 질의문의 저장을 명령하는 정보를 제공한다. 대안적으로, SQI(121)는 그 질의를 시맨틱 filterCriteria에서 운반할 수도 있다. 결과 포맷(rf)은, 일반 텍스트, JSON 또는 XML 포맷일 수 있는, 질의 결과가 어떻게 표현되어야 하는지의 저장을 명령하는 정보를 제공한다. Need_query_summary(nqs)는, RH-SLN(122)이 질의 결과를 SQI(121)에 반환하는 때, SQI(121)가 관련된 질의 결과 또는 품질 요약 정보를 역시 원하는지를 나타내는 정보를 제공한다.

단계 266에서, RH-SLN(122)이 이 시맨틱 질의 요청을 수신한 후, RH-SLN(122)은 부모 <group> 자원 또는 <semanticGroup>(240) 자원의 memberID 속성을 이용하여 관련된 시맨틱 디스크립터에 액세스한다. 다시 말해, <semanticGroup>(240) 자원에 포함된 멤버들의 <semanticDescriptor> 자식 자원은 잠재적인 관여된 <semanticGroup> 자원일 수 있다. 특히, 질의 처리는 다음과 같이 동작한다. 제1 동작에서, 잠재적인 관여된 <semanticDescriptor> 자원의 각각에 대해, RH-SLN(122)은 소정의 액세스 제어 정책에 기초하여 시맨틱 질의가 그 자원 상에서 실행될 수 있는지를 더 평가한다. 만일 그렇다면, 이러한 자원은 정식 관여된 자원이 될 수 있다. 제2 동작에서, 특정한 정식 관여된 <semanticDescriptor> 자원의 경우, 복수의 경우가 있을 수 있다. 경우 1에서, 이것이 RH-SLN(122)에 의해 호스팅된다면, 시맨틱 질의가 그 자원 상에서 직접 실행된다. 경우 2에서, 이것이 시맨틱 질의 처리 능력을 역시 갖는 또 다른 RH-SLN-2(미도시) 상에서 호스팅된다면, RH-SLN(122)은 시맨틱 질의를 다른 RH-SLN-2에 전송하여 그 다른 RH-SLN-2에서 시맨틱 질의를 직접 실행할 수 있다. 경우 3에서, 이것이 시맨틱 질의 처리 능력을 갖지 않는 또 다른 RH-SLN-3(미도시)에서 호스트되는 경우, RH-SLN(122)은 이 관여된 <semanticDescriptor> 자원에 포함된 모든 콘텐츠를 RH-SLN-3으로부터 회수한 다음, RH-SLN(122) 상에서 국지적으로 시맨틱 질의를 실행한다. 공식 관여된 자원이 질의와 함께 평가된 후, 최종 결과 세트가 최종 질의 결과를 포함할 수 있고, SQI(121)에 반환될 수 있다. 대안으로서, RH-SLN은 또한, 모든 관여된 <semanticDescriptor> 자원들을 회수하고, 이 자원들은 통합된 RDF 데이터 기반을 형성할 수 있다. 그 다음, 시맨틱 질의문이 이 통합된 RDF 데이터 기반에서 실행될 것이고 시맨틱 질의 결과가 생성될 수 있다. 단계 267에서, RH-SLN(122)은 SQI(121)에 의해 표시된 포맷을 이용함으로써 질의 결과가 포함된 응답 메시지를 SQI(121)에 다시 전송한다. 필요하다면 품질 요약 정보도 역시 반환될 수 있다.

제5 시나리오를 참조하면, <semanticDescriptor> 자원에 저장되지 않은 시맨틱 질의 요청 정보, 예를 들어 어떤 요구되는 정보는, RDF 트리플로 표현되지 않고 단지 일반 자원에 저장될 수 있다. 그러나, 앞서 논의된 제2 시나리오에서, 시맨틱 질의를 실행하기 위해 어떤 <semanticDescriptor> 자원이 포함되어야 하는지는, 예를 들어 시맨틱 질의 요청 메시지에 포함된 "To" 파라미터에 기초하여 이미 알려져 있다고 가정한다. 시나리오 5는, 사용자가 어떤 "타겟 자원"(이들 타겟 자원은 소정의 제약을 충족할 필요가 있다)으로부터의 정보를 필요로 하지만, 이들 타겟 자원을 식별하는 것이 미리 이루어지지 못하는 상황을 논의한다. 제5 시나리오는 앞서 논의된 제2 시나리오와 제4 시나리오의 조합과 유사할 수 있다. 이 제5 시나리오에서 시맨틱 질의는 임의의 관여된 <semanticDescriptor> 상에서 실행될 수 있다는 점이 중요하다. 제1 시나리오의 제1 단계는, "타겟 자원"을 식별한 다음, 이들 타겟 자원으로부터 필요한 정보를 추출하는 것이다. 따라서, 사용자가 여전히 정보를 질의하고 있지만, 이것은 시맨틱 질의 처리에 직접 의존하는 것이 아니라, 기존의 시맨틱 자원 발견 처리를 간접적으로 거칠 수 있다는 것을 알 수 있다.

이하에서는 제5 시나리오와 관련하여 더 논의된다. 도 32는, <Device>(111), <Device>(146), 및 <Device>(147)가 3개의 온도 디바이스를 나타내고, 이들 각각은 그들 각각의 시맨틱 설명을 저장하는 자식 자원 <semanticDescriptor>를 갖는 부분적인 자원 트리 구조를 도시한다. 한편, 이들 3개의 디바이스 각각은 "OperationA"를 가지며, 이 동작은 "현재의 동작 상태"라 불리는 속성을 갖는다. 질의 설명의 의도는 다음과 같을 수 있다: "CompanyA 및 CompanyB로부터의 모든 온도 디바이스들의 현재 동작 상태를 나에게 반환하라" 현재, 시맨틱 질의를 더 처리하기 위해 기존의 시맨틱 자원 발견 메커니즘을 활용하는 방법을 예시하는 본 명세서에서 논의된 것과 같은 솔루션은 없다.

시맨틱 질의 요청을 처리하기 위해 기존의 시맨틱 자원 발견 프로세스를 활용하는 복수의 방식이 있다. 여기에, 시나리오 5A 및 시나리오 5B 등의, 기존의 시맨틱 자원 발견 프로세스를 활용하는 몇 가지 예가 있다.

시나리오 5A를 참조하면, SQI(121)는 그 질의를 명시하기 위해 여전히 기존의 시맨틱 필터 인터페이스를 이용한다. 한편, 시맨틱 필터는 타겟 자원을 식별하는 방법을 명시할 수 있다. SQI(121)는 또한, 일단 타겟 자원이 식별되고 나면, 어떤 정보가 추출되고 반환될 필요가 있는지를 나타낸다. 유사하게, 일단 RH-SLN(122)이 SQI(121)로부터 요청을 수신하고 나면, 먼저, 시맨틱 필터에 포함된 제약을 이용하여 타겟 자원을 먼저 식별하고, 이것은 기존의 시맨틱 자원 발견에 의해 지원될 수 있다. 일단 자원이 타겟 자원으로서 식별되고 나면, RH-SLN(122)은 이 타겟 자원으로부터 정보를 더 추출할 수 있다.

도 33은 도 32를 참조한 예시적인 방법을 도시한다. 단계 270에서, 전제 조건이 있을 수 있다. 전제 조건 필요성에 기초하여, SQI는 RL-SLN에 관한 일부 정보를 질의할 필요가 있다. 예를 들어, SQI가 시나리오 5에 예시된 바와 같이 질의를 수행하고 한다고 가정하자. 단계 271에서, SQI(121)는 요청 메시지를 RH-SLN(122)에 전송하고, 여기서, 이 메시지는 요청이 처리될 시맨틱 질의와 관련되어 있음을 나타낸다. 단계 271의 시맨틱 질의는, 시맨틱 필터, 필요한 정보(NI), 또는 결과 포맷(RF)을 포함할 수 있다. 기존의 시맨틱 필터는, 시맨틱 자원 발견을 통해 잠재적인 타겟 자원을 식별하는 방법을 명시하는데 이용될 수 있다. 제5 시나리오에 도시된 예의 경우, 시맨틱 필터는 다음과 같이 기술될 수 있다(이것은 모든 동작 A 자원을 찾는 것이다):

필요한 정보(NI)는, 일단 타겟 자원이 식별되고 나면 추출되어야 하는 정보이다. 결과 포맷(RF)은, 일반 텍스트, JSON 또는 XML 포맷일 수 있는, 질의 결과를 저장하는 방법을 명령하는 정보이다.

대안으로서, SQI(121)는 기존의 시맨틱 필터를 이용하지 않고 완전한 시맨틱 질의를 직접 전송할 수 있다. 이 경우, 완전한 시맨틱 질의는, 제1 시나리오에서 제안된 바와 같이 이전에-제안된 질의문(QS) 파라미터에 포함될 수 있다. 도 32와 연관된 제5 시나리오에 도시된 예의 경우, 완전한 시맨틱 질의는 다음과 같이 기재될 수 있다:

완전한 시맨틱 질의가 RH-SLN(122)에 제출될 수 있지만, RH-SLN(122)은 여전히 이 질의를 처리하기 위해 기존의 시맨틱 자원 발견을 이용할 수 있다는 점에 유의한다.

단계 272에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)은 시맨틱 필터에 저장된 정보에 기초하여 타겟 자원을 식별하기 위해 기존의 시맨틱 자원 발견을 수행한다. 특히, SQI(121)가 완전한 시맨틱 질의를 전송했더라도, RH-SLN(122)은 여전히, 관련된 자원을 먼저 식별할 수 있다. 예를 들어, 제5 시나리오에서, 3개의 <OperationA> 자원이 타겟 자원으로서 식별될 수 있다. 단계 273에서, 각각의 타겟 자원에 대해, RH-SLN(122)은 이 자원으로부터 필요한 정보를 더 추출하여 최종 결과 세트에 추가한다. 일단 정보가 타겟 자원으로부터 추출되고 나면, SQI(121)에 반환될 것이다. 예를 들어, 제5 시나리오에서, 3개의 <OperationA> 자원의 동작 상태가 시맨틱 질의 결과로서 추출될 것이다. 단계 274에서, RH-SLN(122)은 SQI(121)에 의해 표시된 포맷을 이용함으로써 질의 결과가 포함된 응답 메시지를 SQI(121)에 다시 전송한다. 대안으로서, 질의 결과가 단일 응답 메시지에서 운반되기에는 너무 클 수 있으므로, RH-SLN(122)은, 예를 들어 <request> 자원을 이용하여 질의 결과를 저장할 새로운 자원을 생성할 수 있다. 그 다음, RH-SLN(122)은 질의 결과를 직접 SQI(121)에 반환하지 않고, 질의 결과를 저장하는 새로이 생성된 자원의 URI에 반환할 것이다. 따라서, SQI(121)는 나중 시간에 자체적으로 질의 결과를 회수하기로 선택할 수 있다.

시나리오 5B를 참조하면, SQI(121)는 그 질의를 명시하기 위해 여전히 기존의 시맨틱 필터 인터페이스를 이용할 수 있다. 한편, 시맨틱 필터는 타겟 자원을 식별하는 방법을 명시할 수 있다. 시나리오 5A와는 달리, SQI(121)는 어떤 정보가 타겟 자원으로부터 추출될 필요가 있는지를 나타내지 않는다. 즉, SQI(121)는 타겟 자원 발견을 위해 RH-SLN(122)에만 의존한다. 일단 타겟 자원이 식별되어 SQI(121)로 반환되고 나면, SQI(121)는 자체적으로 이들 타겟 자원으로부터 정보를 더 추출할 수 있다.

도 43은 예시적인 단계들을 도시한다. 단계 280에서 전제 조건이 있을 수 있다. 필요성에 기초하여, SQI는 RH-SLN에 관한 일부 정보를 질의할 필요가 있다. 예를 들어, SQI가 시나리오 5에 예시된 바와 같이 질의를 수행하고 한다고 가정하자. 도 34를 참조하면, 단계 281에서, SQI(121)는 요청 메시지를 RH-SLN(122)에 전송하고, 여기서 이것은 시맨틱 자원 발견만을 요구한다. 시맨틱 필터는 요청 메시지에 포함될 수 있다. 시맨틱 필터는 시맨틱 자원 발견을 통해 잠재적인 타겟 자원을 식별하는 방법을 명시할 수 있다. 제5 시나리오와 관련하여 도시된 예의 경우, 시맨틱 필터는 다음과 같이 기술될 수 있다(이것은 모든 OperationA 자원을 찾는 것이다):

도 34를 계속 참조하면, 시맨틱 질의 표시자(sq)는 SQI(121)가 실행될 시맨틱 질의를 전송하고 있음을 나타내며, 이것은, 이 요청이 시맨틱 자원 발견을 위한 것이 아니라, 일부 RDF 트리플에 기초한 일부 도출된 정보 또는 지식을 질의하거나 회수하기 위한 것임을 의미한다. oneM2M 실시예에서, 이러한 sq 파라미터는 새로운 요청 파라미터일 수 있다. 대안으로서, filterCriteria의 기존 filterUsage는 또한, sq의 효과를 실현하는데 이용될 수 있다. 예를 들어, 새로운 값이 나타나는 한, 이것이 시맨틱 질의 동작을 트리거하는 것을 의미하도록, filterUsage에 대해 새로운 값이 정의될 수 있다.

단계 282에서, SQI(121)로부터 시맨틱 질의를 수신하면, RH-SLN(122)은 시맨틱 필터에 저장된 정보에 기초하여 타겟 자원을 식별하기 위해 기존의 시맨틱 자원 발견을 수행한다. 단계 283에서, 식별된 타겟 자원에 대하여, RH-SLN(122)은 이들 타겟 자원을 포함하는 <group>(242) 자원을 생성할 수 있다. 단계 284에서, RH-SLN(122)은 <group> 자원의 URI가 반환되는 응답 메시지를 SQI(121)에 다시 전송한다. 단계 285에서, SQI(121)는 이 <group>(242) 자원의 fanoutPoint에 RETRIEVE를 전송하여 발견된 또는 타겟된 자원으로부터 필요한 값을 회수할 수 있다.

시맨틱 질의 CSF 및 논리적 엔티티 예가 이하에서 논의된다. oneM2M은 현재 oneM2M 서비스 계층에 의해 지원되는 능력을 정의하는 과정 중에 있다. 이들 능력들을 능력 서비스 기능(capability service function)(CSF)이라고 한다. oneM2M 서비스 계층은 능력 서비스 엔티티(capability service entity)(CSE)(287)라고 지칭된다. 따라서, 분산된 <semanticDescriptor> 자원에 관한 공개된 시맨틱 질의는, 도 35에 도시된 바와 같이, 서비스 계층의 새로운 CSF(288)로서 간주될 수 있다. 대안으로서, 이것은 또한, oneM2M TS-0001에 정의된 기존의 시맨틱-관련 CSF의 일부일 수도 있다. 본 명세서에 개시된 절차뿐만 아니라 새로운 파라미터는, 주로, 도 35에 도시된 바와 같이 mca 및 mcc/mcc'기준점에서 발생한다. 상이한 유형들의 M2M 노드들은, M2M 게이트웨이, M2M 서버, M2M 디바이스 등의 시맨틱 질의 서비스를 구현할 수 있다. 특히, 이들 노드들에 대한 상이한 하드웨어 또는 소프트웨어 용량에 따라, 이들 노드들에 의해 구현된 시맨틱 질의 서비스의 기능 또는 용량도 역시 달라질 수 있다. 또한, oneM2M의 정황에서, 논리적 엔티티 RH-SLN(122)은 물리적 CSE로서 구현될 수 있다. 논리적 엔티티 SQI(121)는 AE 또는 CSE로서 구현될 수 있다.

이하, 일반 oneM2M 자원의 속성이 논의된다. 시나리오 2에서, 우리의 접근법들 중 하나는 원래 RDF 포맷으로 이용가능하지 않고 <semanticDescriptor> 자원에 저장되는 정보를 표현하기 위해 더 많은 RDF 트리플을 추가하는 것이었다. 예를 들어, 일반 Resource-A(예를 들어, <reading>(113) 자원에 저장된 현재의 온도 값(32))로부터 나오는 정보 Info-X의 경우, 일단 정보 Info-X를 나타내는 새로운 RDF 트리플이 생성되고 나면, Resource-A의 어떤 정보가 RDF 형식으로 표현되었는지를 나타내는 것이 역시 유익할 수 있다. 이렇게 하기 위해, 새로운 속성 "duplicatedAsRDF"가 Resource-A에 대해 정의되고 "duplicatedAsRDF"에 대한 상세한 설명이 표 4에 나와 있다. Resource-A는, <AE>, <CSE>, <container>, <contentInstance> 등의, 임의의 기존의 또는 미래의 자원 유형일 수 있다는 점에 유의한다.

표 4.

도 42는 제2 시나리오 및 제4 시나리오와 연관된 예시적인 방법을 도시한다. 단계 4201에서, RH-SLN(122)은 센서와 연관된 정보(예를 들어, <reading>(113))를 획득할 수 있다. 예시적인 센서는, 가속도계, 바이오메트릭 센서, 또는 온도 센서를 포함할 수 있다. 단계 4202에서, RH-SLN(122)은 센서와 연관된 정보를 <contentInstance> 등의 일반 자원 내에 통합할 수 있다. 단계 4203에서, RH-SLN(122)은 정보에 대한 semanticDescriptor 자원을 생성할 수 있고, 여기서, semanticDescriptor 자원은 정보를 트리플로서 표현한다. 단계 4204에서, RH-SLN(122)은 일반 자원 정보가 트리플로 복제되었음을 플래깅할 수 있다.

새로운 요청 파라미터가 아래에 설명된다. oneM2M에서, SQI(121)는 AE-1로서 구현될 수 있고 RH-SLN(122)은 CSE-1로서 구현될 수 있다. 제1 단계에서, AE-1은 시맨틱 질의가 포함된 CSE-1에 요청을 전송한다. 제2 단계에서, 요청을 수신하면, CSE-1은 시맨틱 질의 처리를 수행하고 질의 결과를 생성한다. 이 단계는 본 개시내용에서 가장 주안점이고 혁신적인 단계이며, 이 단계에서 수행되는 질의 처리는 경우에 따라 상이하다는 점에 유의한다. 제3 단계에서, CSE-1은 질의 결과를 다시 AE-1에 반환한다. oneM2M의 경우, AE-1이 CSE-1에 요청을 전송할 때, 그 요청은 oneM2M RETRIEVE 요청일 수 있다. 본 명세서에 제시된 시나리오들에서 시맨틱 질의 처리에 대한 소정의 차이점들이 존재하기 때문에, 예를 들어, 새로운 파라미터가 RETRIEVE 요청 및 응답 메시지에서 운반될 수 있다.

이하는, oneM2M 요청 또는 응답 메시지에 포함될 수 있는 이들 파라미터들의 요약이다. 시나리오 1에서, RETRIEVE 메시지는 다음과 같은 새로운 파라미터를 포함할 수 있다: 특히, SQ, SE, QS 또는 RF. 시나리오 2와 시나리오 3의 경우, RETRIEVE 메시지는 다음을 포함할 수 있다: 특히, SQ, QS, 또는 RF. 시나리오 4와 연관된 기본 솔루션 및 향상된 솔루션의 제1 접근법의 경우, RETRIEVE 메시지는 특히 SQ, QS, NQS 또는 RF를 포함할 수 있는 반면, 응답 메시지는 QS를 포함할 수 있다. 시나리오 4와 연관된 향상된 솔루션의 제2 접근법의 경우, RETRIEVE 메시지는 RDP를 포함할 수 있고, 또 다른 RETRIEVE 메시지는 특히 SQ, QS, NQS 또는 RF를 포함할 수 있는 반면, 응답 메시지는 QS를 포함할 수 있다. 시나리오 5A의 경우, RETRIEVE 메시지는, 특히, NI 또는 SQ를 포함할 수 있다.

새로운 시맨틱 질의 포털 자원 <queryPortal>. 시나리오 4에 대한 향상된 솔루션의 접근법 1의 경우, <queryPortal>(290)이라 불리는 새로운 자원이 개시된다(도 36 참조). <queryPortal>(290)은, 그 자신의 질의 범위를 나타내는 "queryScope"(291)라 불리는 속성을 가질 수 있다. 따라서, <queryPortal>(290) 자원에 전송되는 모든 시맨틱 질의는 이 자원의 "queryScope"(291) 속성에 의해 표시된 질의 범위에서 실행될 수 있다. 또한, 주어진 CSE가 복수의 <queryPortal>(290) 자원을 포함할 수 있고 이들 각각은 그들 자신의 질의 범위(291)를 가진다. 일반 자원 발견 등에 의해, 이들 <queryPortal>(290) 자원을 발견하고 질의가 실행될 원하는 자원을 선택하는 것은 SQI(예를 들어, AE 또는 CSE)에 달려 있다. <queryPortal>(290) 자원은 용이한 자원 발견을 위해 <CSEBase>(210) 아래에 있을 수 있다. <queryPortal>(290) 자원은 일반 CRUD 동작을 통해 구성될 수 있다. 예를 들어, 호스팅 CSE는 그 지식에 기초하여 <queryPortal>(290) 자원을 관리하기 위한 그 자신의 태스크를 셋업하고 일반 자원 상에서 동작들을 실행할 수 있다. 그 결과, 일단 시맨틱 질의가 특정한 <queryPortal> 자원에 전송되고 나면, queryScope(291) 속성에 포함된 관여된 <semanticDescriptor> 자원이 회수될 수 있다. 그 다음, <semanticDescriptor> 자원들 각각 상에서 질의를 실행되고 질의 결과가 반환할 수 있다. <queryPortal>(290) 자원은 표 5에 명시된 속성을 포함할 수 있다.

표 5.

<queryPortal> 자원에 관한 생성/회수/업데이트/삭제 동작이 이하에서 논의된다. <queryPortal> 생성 절차는 표 6에서 설명된 <queryPortal> 자원을 생성하는데 이용될 수 있다.

표 6.

이 <queryPortal> 회수 절차는 표 7에 설명된 <queryPortal> 자원의 속성을 회수하는데 이용될 수 있다.

표 7.

표 8에서 설명된 <queryPortal> 업데이트 절차는 기존 <queryPortal>을 업데이트하는데 이용될 수 있다, 예를 들어, 그 queryScope에 대한 업데이트. 일반 업데이트 절차는 [9]의 조항 10.1.3에 설명되어 있다.

표 8.

표 9에 설명된 <queryPortal> 삭제 절차는 기존의 <queryPortal>을 삭제하는데 이용되어야 한다. 일반 삭제 절차는 [9]의 조항 10.1.4.1에 설명되어 있다.

표 9.

<queryPortal> 자원을 통한 시맨틱 질의 처리 절차. 이 절은, <queryPortal> 자원을 통한 시맨틱 질의 처리 절차에 대한 oneM2M 예를 제공한다. 도 37은 <queryPortal> 자원을 통한 시나리오 4에 대한 시맨틱 질의 처리를 위한 oneM2M-중심적 절차를 도시한다. 단계 300에서, <queryPortal-1> 자원은 질의 포털을 생성하기 위해 CSE(296) 자체에 의해 생성되었다. 단계 301에서, AE(295)는 일반 자원 발견을 통해 CSE(296)에 의해 호스팅되는 <queryPortal-1> 자원을 발견한다. 단계 302a 및 단계 302b에서, AE(295)는 질의 범위를 나타내는 "queryScope" 속성에 액세스한다. 예를 들어, <queryPortal-1> 자원의 "queryScope"는 2개의 URI를 포함할 수 있다: <CSE>/<CompanyA> 및 <CSE>/<CompanyB>. 단계 303에서, AE(295)는 회사 A 및 회사 B로부터의 디바이스들에 관련된 정보를 질의하고자 하고, 바람직한 질의 포털로서 <queryPortal-1> 자원을 선택한다. AE(295)의 질의는 다음과 같을 수 있다: "회사 A와 회사 B로부터의 모든 디바이스들의 동작의 작동 모드를 나에게 반환하라".

단계 304에서, AE(295)는 ("To" 파라미터에 표시된) CSE(296) 상의 <queryPortal-1> 자원을 타겟으로 하는 RETRIEVE 메시지를 전송하고, 요청 메시지는 다음과 같은 새로운 파라미터를 포함할 수 있다: 특히, SQ, QS, RF, 또는 NQS. 단계 305에서, AE(295)로부터 시맨틱 질의를 수신하면, CSE(296)에서의 질의 처리가 수행된다. <queryPortal-1> 자원의 "queryScope"는 2개의 URI: <CSE-1>/<CompanyA> 및 <CSE-1>/<CompanyB>를 포함하기 때문에, 이들 2개의 URI 아래의 <semanticDescriptor> 자원을 식별하기 시작할 수 있다. 특히, 모든 회사의 <Device>(111), <Device>(146), <Device>(147)의 <semanticDescriptor> 자식 자원은, 관여된 <semanticDescriptor> 자원으로서 식별될 것이다. 도 26을 참조한다. 단계 306에서, 잠재적인 관여된 <semanticDescriptor> 자원의 각각에 대해, CSE(296)는 소정의 액세스 제어 정책에 기초하여 시맨틱 질의가 그 자원 상에서 실행될 수 있는지를 더 평가한다. 만일 그렇다면, 이러한 자원은 정식 관여된 자원이 될 수 있다. 단계 307에서, 각각의 정식 관여된 <semanticDescriptor> 자원에 대해, 시맨틱 질의가 그 자원 상에서 실행된다. 유효한 질의 결과가 있다면, 이 질의 결과가 최종 결과 세트에 추가될 수 있다. 한편, 이들 정식 관여된 자원에 관한 질의 처리는 서로 독립적으로 수행될 수 있다.

단계 308에서, 공식 관여된 자원이 질의와 함께 평가된 후, 최종 결과 세트가 최종 질의 결과를 포함할 수 있고, AE(295)에 반환될 수 있다. 시나리오 4의 예에서, <Device>(111), <Device>(146), <Device>(147)의 동작들의 작동 모드가 최종 질의 결과일 수 있다. 단계에서, 30CSE-1은 응답 메시지를 AE(295)에 다시 전송하고, (단계 4에서와 같이) 이 메시지에는 AE(295)에 표시된 포맷을 이용함으로써 질의 결과가 포함된다. 또한, 메시지에는 파라미터 QS를 포함할 수 있다. 파라미터 QS는, 질의 결과 품질 또는 요약 정보를 포함한다. 예를 들어, 이것은 질의가 실행된 <semanticDescriptor> 자원을 나타낼 수 있다. 이 정보를 이용함으로써, AE(295)는 반환된 질의 결과가 바람직하고 충분히 정확한지 여부를 평가할 수 있다. 기타의 정보는 질의 처리 시간 비용 등을 포함할 수 있다.

이하에서는, 분산형 시맨틱 디스크립터들에 관한 시맨틱 질의를 위한 예시적인 사용자 인터페이스들이 논의된다. 도 38은 시맨틱 질의 범위 체크에 대한 예시적인 사용자 인터페이스를 도시한다. 그래픽 사용자 인터페이스(GUI)(310)는, 특정한 <semanticGroup> 자원의 질의 범위를 체크하는데 이용될 수 있다. 블록 311에서 체크될 <semanticGroup> 자원의 URI를 입력함으로써, 그 멤버 자원들, 예를 들어, 관여된 <semanticDescriptor> 자원들이 보여질 수 있다. 특히, 멤버 자원들 중 일부는, 그에 따라, 수신된 URI와 동일한 노드에 있지 않을 수도 있다. URI 입력이 타겟으로 하는 노드의 멤버 자원을 체크하는 옵션(312)이 있다.

도 39는 시맨틱 질의 론처에 대한 예시적인 사용자 인터페이스를 도시한다. GUI 인터페이스(320)는 시맨틱 질의를 론칭하는데 이용될 수 있다. 알 수 있는 바와 같이, 파라미터의 값은 본 명세서에 개시된 바와 같이 수신될 수 있다. 블록 316은 <semanticQuery> 자원에 이용될 수 있고, 블록 317은 질의문 입력에 이용될 수 있고, 블록 318은 질의 결과의 포맷에 이용될 수 있고, 질의 요약이 필요한지를 나타내는 블록 319가 있을 수 있다. 따라서, 입력에 기초하여, 시맨틱 질의 메시지가 생성되어 처리를 위해 전송될 수 있다. 도 40은 시맨틱 질의 결과 디스플레이를 위한 예시적인 사용자 인터페이스를 도시한다. 시맨틱 질의 결과가 반환된 후에, 이것은 블록 321에서 시맨틱 질의 결과 GUI(320) 상에 보여질 수 있다. 블록 322는 질의 요약을 디스플레이한다. 한 예에서, 도 40에 도시된 결과는 (사용자에 의해 요구될 때) 회사 A 및 회사 B로부터의 모든 디바이스들의 동작 A의 동작 상태이다. 또한, 질의 요약 정보도 반환되며, 여기서, 이 정보는 질의 처리 관련 정보를 보여준다.

본 명세서에서 나타나는 청구항들의 범위, 해석 또는 적용을 어떤 식으로든 과도하게 제한하지 않으면서, 본 명세서에 개시된 예들 중 하나 이상의 기술적 효과는 시맨틱 질의에 대한 조정을 제공하는 것이다. 현재, 분산형 시맨틱 디스크립터들(예를 들어, oneM2M <semanticDescriptor> 자원들)에 관한 직접적 시맨틱 질의 처리를 위한 기존의 솔루션은 없다. 본 명세서에서 논의된 방법 및 시스템은 여기서 논의된 시맨틱 질의를 가능케한다. 개시된 주제는, 단일 자원(예를 들어, 단일 <semanticDescriptor>로부터의 정보만을 이용하는 것)에 관해 직접 질의 처리를 직접 수행하는 것을 허용한다. 개시된 주제는 시맨틱 디스크립터에 저장되지 않은 정보를 이용한 시맨틱 질의를 허용한다. 개시된 주제는 상이한 관련없는 시맨틱 디스크립터들에 분산된 시맨틱 질의를 허용한다. 이것은 시맨틱 질의에 대한 "질의 범위"를 결정하는 것을 포함할 수 있다. 개시된 주제는 상이하지만 관련된 시맨틱 디스크립터들에 분산된 시맨틱 질의를 허용한다. 이것은, 시맨틱 질의에 필요한 충분한 정보를 제공하기 위해 관련된 <semanticDescriptor> 자원들이 함께 링크될 수 있도록 기존의 "resourceDescriptorLink" 속성을 이용하는 것을 포함한다. 개시된 주제는, 기존의 시맨틱 자원 발견을 활용함으로써 타겟 자원으로부터의 정보를 간접적으로 질의하는 것을 허용한다. 이것은, 시맨틱 자원 발견 메커니즘을 활용하여 시맨틱 질의 사용자에 의해 질의되고 요구되는 자원 트리에 저장된 정보를 더 회수하는 절차를 포함할 수 있다.

도 41a는 분산형 시맨틱 디스크립터를 통한 시맨틱 질의와 연관된 하나 이상의 개시된 개념이 구현될 수 있는(예를 들어, 도 10 내지 도 39 및 동반되는 논의) 예시적인 머신-대-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술은 IoT/WoT를 위한 구축 블록을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 IoT/WoT의 한 컴포넌트 뿐만 아니라 IoT/WoT 서비스 계층 등일 수도 있다.

도 41a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는, 고정된 네트워크(예를 들어, Ethernet, Fiber, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는, 음성, 데이터, 비디오, 메시징, 브로드캐스트 등의 콘텐츠를 복수의 사용자에게 제공하는 복수의 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는, CDMA(code division multiple access) TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), 단일 캐리어 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 채용할 수 있다. 또한, 통신 네트워크(12)는, 예를 들어, 코어 네트워크, 인터넷, 센서 네트워크, 산업용 제어 네트워크, 개인 영역 네트워크, 융합된 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크 등의 다른 네트워크들을 포함할 수 있다.

도 41a에 도시된 바와 같이, M2M/ IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭처 도메인이란 단-대-단 M2M 배치의 네트워크측을 말하고, 필드 도메인이란, 대개는 M2M 게이트웨이 뒤쪽의, 영역 네트워크(area network)를 말한다. 필드 도메인은 M2M 게이트웨이(14)와 단말 디바이스(18)를 포함한다. 원한다면 임의 개수의 M2M 게이트웨이 디바이스(14)와 M2M 단말 디바이스(18)가 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 것을 이해할 것이다. M2M 게이트웨이 디바이스(14)와 M2M 단말 디바이스(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호를 전송 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스(예를 들어, 셀룰러 및 비-셀룰러) 뿐만 아니라 고정된 네트워크 M2M 디바이스(예를 들어, PLC)가 통신 네트워크(12) 또는 직접 무선 링크 등의 운영자 네트워크를 통해 통신하는 것을 허용한다. 예를 들어, M2M 디바이스(18)는 데이터를 수집하고, 이 데이터를, 통신 네트워크(12) 또는 직접 무선 링크를 통해, M2M 애플리케이션(20) 또는 M2M 디바이스(18)에 전송할 수 있다. M2M 디바이스(18)는 또한, M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수도 있다. 또한, 데이터와 신호는, 후술되는 바와 같이, M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 전송되거나 이로부터 수신될 수 있다. M2M 디바이스(18)와 게이트웨이(14)는, 예를 들어, 셀룰러, WLAN, WPAN(예를 들어, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 와이어라인 등을 포함한 다양한 네트워크를 통해 통신할 수 있다.

도 41b를 참조하여, 필드 도메인 내의 예시된 M2M 서비스 계층(22)(예를 들어, 본 명세서에서 설명된 RH-SLN(122) 또는 CSE(296))은, M2M 애플리케이션(20)(예를 들어, AE(295) 또는 SQI(121)), M2M 게이트웨이 디바이스(14), M2M 단말 디바이스(18), 및 통신 네트워크(12)에 서비스들을 제공한다. M2M 서비스 계층(22)은, 원한다면, 임의 개수의 M2M 애플리케이션, M2M 게이트웨이 디바이스(14), M2M 단말 디바이스(18), 및 통신 네트워크(12)와 통신할 수 있다는 것을 이해할 것이다. M2M 서비스 계층(22)은 하나 이상의 서버, 컴퓨터 등에 의해 구현될 수 있다. M2M 서비스 계층(22)은, M2M 단말 디바이스(18), M2M 게이트웨이 디바이스(14), 및 M2M 애플리케이션(20)에 적용되는 서비스 능력을 제공한다. M2M 서비스 계층(22)의 기능은, 다양한 방식으로, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드 등에서 구현될 수 있다.

예시된 M2M 서비스 계층(22)과 유사하게, 인프라스트럭처 도메인에는 M2M 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 인프라스트럭처 도메인의 M2M 애플리케이션(20') 및 기저 통신 네트워크(12')에 서비스를 제공한다. M2M 서비스 계층(22')은 또한, 필드 도메인의 M2M 게이트웨이 디바이스(14)와 M2M 단말 디바이스(18)에 서비스를 제공한다. M2M 서비스 계층(22')은, 임의 개수의 M2M 애플리케이션, M2M 게이트웨이 디바이스, 및 M2M 단말 디바이스와 통신할 수 있다는 것을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의한 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은 하나 이상의 서버, 컴퓨터, 가상 머신(예를 들어, 클라우드/계산/스토리지 팜(farm) 등) 등에 의해 구현될 수 있다.

또한 도 41b를 참조하면, M2M 서비스 계층들(22 및 22')은 다양한 애플리케이션 및 버티컬(vertical)이 활용할 수 있는 핵심 세트의 서비스 전달 능력을 제공한다. 이들 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용하고, 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 요금청구, 서비스/디바이스 발견 등의 기능을 수행할 수 있게 한다. 본질적으로, 이들 서비스 능력은 애플리케이션으로부터 이들 기능들을 구현하는 부담을 제거하므로, 애플리케이션 개발을 간소화하고 출시를 위한 비용과 시간을 감소시킨다. 서비스 계층들(22 및 22')은 또한, M2M 애플리케이션들(20 및 20')이, 서비스 계층들(22 및 22')이 제공하는 서비스와 관련하여 다양한 네트워크들(12 및 12')을 통해 통신하게 할 수 있다.

일부 예에서, M2M 애플리케이션들(20 및 20')은, 본 명세서에서 논의된 바와 같이, 분산형 시맨틱 디스크립터를 통한 시맨틱 질의와 연관된 메시지들을 이용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 제한없이, 수송, 건강 및 웰빙, 접속된 홈, 에너지 관리, 자산 추적, 및 보안 및 감시 등의, 다양한 산업에서의 애플리케이션을 포함할 수 있다. 앞서 언급된 바와 같이, M2M 서비스 계층, 디바이스들에 걸친 실행, 게이트웨이, 및 시스템의 기타의 서버들은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 요금청구, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합 등의 기능을 지원하고, 이들 기능을 서비스로서 M2M 애플리케이션(20 및 20')에 제공한다.

본 출원의 분산형 시맨틱 디스크립터를 통한 시맨틱 질의는 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층은, 한 세트의 애플리케이션 프로그래밍 인터페이스(API)와 기저 네트워킹 인터페이스를 통해 가치-부가된 서비스 능력을 지원하는 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어 상에 구현되는 디바이스, 게이트웨이 또는 서비스/플랫폼 등의 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M과 oneM2M 양쪽 모두는, 본 출원의 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 포함할 수 있는 서비스 계층을 이용한다. oneM2M 서비스 계층은 한 세트의 공통 서비스 기능(CSF)(즉, 서비스 능력)을 지원한다. 한 세트의 하나 이상의 특정한 타입의 CSF의 구체화는 상이한 타입의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션-특유의 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)라고 언급된다. 또한, 본 출원의 분산형 시맨틱 디스크립터를 통한 시맨틱 질의는, 서비스 중심 아키텍처(Service Oriented Architecture)(SOA) 및/또는 자원 중심 아키텍처(resource-oriented architecture)(ROA)를 이용하여 본 출원의 분산형 시맨틱 디스크립터를 통한 시맨틱 질의 등의 서비스에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.

본 명세서에 논의된 바와 같이, 서비스 계층은 네트워크 서비스 아키텍처 내의 기능 계층일 수 있다. 서비스 계층은, 통상적으로 HTTP, CoAP 또는 MQTT 등의 애플리케이션 프로토콜 계층 위에 있으며, 클라이언트 애플리케이션에 부가 가치 서비스를 제공한다. 서비스 계층은 또한, 예를 들어 제어 계층 및 트랜스포트/액세스 계층 등의 하위 자원 계층에서 코어 네트워크에 대한 인터페이스를 제공한다. 서비스 계층은, 서비스 정의, 서비스 런타임 가능화, 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함한 복수의 범주의 (서비스) 능력 또는 기능을 지원한다. 최근에는, 수 개의 업계 표준 기관, 예를 들어, oneM2M은, M2M 유형의 디바이스들 및 애플리케이션들의 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크 등의 배치로의 통합과 연관된 문제를 해결하기 위해 M2M 서비스 계층을 개발해 왔다. M2M 서비스 계층은, CSE 또는 SCL이라고 지칭될 수 있는, 서비스 계층에 의해 지원되는, 위에서 언급된 능력들 또는 기능들의 모음 또는 세트에 대한 액세스를 애플리케이션들 및 다양한 디바이스에 제공할 수 있다. 몇 가지 예는, 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 다양한 애플리케이션에 의해 흔하게 이용될 수 있는 접속 관리를 포함하지만, 이것으로 제한되는 것은 아니다. 이러한 능력 또는 기능은 M2M 서비스 계층에 의해 정의된 메시지 포맷, 자원 구조 및 자원 표현을 이용하는 API를 통해 이러한 다양한 애플리케이션에 이용가능하게 된다. CSE 또는 SCL은, 하드웨어 또는 소프트웨어로 구현될 수 있고 다양한 기능을 이용하기 위해 다양한 애플리케이션 또는 디바이스들에 노출된 (서비스) 능력 또는 기능(즉, 이러한 기능 엔티티들 사이의 기능 인터페이스)을 제공하여 다양한 애플리케이션 또는 디바이스들이 이러한 능력 또는 기능을 이용할 수 있게 하는 기능 엔티티이다.

도 41c는, 예를 들어, (AE(295) 또는 SQI(121)를 포함할 수 있는) M2M 단말 디바이스(18) 또는 (도 30 또는 도 20의 하나 이상의 컴포넌트를 포함할 수 있는) M2M 게이트웨이 디바이스(14) 등의, 예시적인 M2M 디바이스(30)의 시스템도를 도시한다. 도 41c에 도시된 바와 같이, M2M 디바이스(30)는, 프로세서(32), 트랜시버(34), 전송/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 기타의 주변기기(52)를 포함할 수 있다. M2M 디바이스(30)는 개시된 주제와 일관성을 유지하면서 전술된 요소들의 임의의 하위-조합을 포함할 수 있다는 것을 이해할 것이다. M2M 디바이스(30)(예를 들어, AE(295), SQI(121), RH-SLN(122), CSE(296) 등)는 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 개시된 시스템 및 방법을 수행하는 예시적인 구현일 수 있다.

프로세서(32)는, 범용 프로세서, 특별 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(digital signal processor)(DSP), 복수의 마이크로프로세서, DSP 코어와 연계한 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, 주문형 집적 회로(Application Specific Integrated Circuit)(ASIC), 필드 프로그래머블 게이트 어레이(Field Programmable Gate Array)(FPGA) 회로, 기타 임의 유형의 집적 회로(IC), 상태 머신 등일 수 있다. 프로세서(32)는, 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 기타 임의의 기능을 수행할 수 있다. 프로세서(32)는, 전송/수신 요소(36)에 결합될 수 있는 트랜시버(34)에 결합될 수 있다. 도 41c는 프로세서(32)와 트랜시버(34)를 별개의 컴포넌트로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 팩키지 또는 칩 내에 함께 통합될 수도 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션-계층 프로그램(예를 들어, 브라우저) 또는 무선 액세스-계층(RAN) 프로그램 또는 통신을 수행할 수 있다. 프로세서(32)는, 인증, 보안 키 협의, 또는 예를 들어, 액세스-계층 또는 애플리케이션 계층에서 등의 암호 동작과 같은 보안 동작을 수행할 수 있다.

전송/수신 요소(36)는, M2M 서비스 플랫폼(22)에 신호를 전송하거나 이로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 전송/수신 요소(36)는 RF 신호를 전송 또는 수신하도록 구성된 안테나일 수 있다. 전송/수신 요소(36)는, WLAN, WPAN, 셀룰러 등의, 다양한 네트워크 및 에어 인터페이스를 지원할 수 있다. 한 예에서, 전송/수신 요소(36)는, 예를 들어, IR, UV, 또는 가시광 신호를 전송 또는 수신하도록 구성된 방출기/검출기일 수도 있다. 역시 또 다른 예에서, 전송/수신 요소(36)는 RF 및 광 신호 양쪽 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 임의 조합의 무선 또는 유선 신호를 전송 또는 수신하도록 구성될 수 있다는 것을 이해할 것이다.

또한, 전송/수신 요소(36)가 도 41c에서는 단일 요소로서 도시되어 있지만, M2M 디바이스(30)는 임의 개수의 전송/수신 요소(36)를 포함할 수 있다. 더 구체적으로는, M2M 디바이스(30)는 MIMO 기술을 채용할 수도 있다. 따라서, 한 예에서, M2M 디바이스(30)는, 무선 신호를 전송 및 수신하기 위한 2개 이상의 전송/수신 요소(36)(예를 들어, 복수의 안테나)를 포함할 수도 있다.

트랜시버(34)는, 전송/수신 요소(36)에 의해 전송되는 신호를 변조하고 전송/수신 요소(36)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 앞서 언급한 바와 같이, M2M 디바이스(30)는 멀티-모드 능력을 가질 수도 있다. 따라서, 트랜시버(34)는, M2M 디바이스(30)가, 예를 들어, UTRA 및 IEEE 802.11 등의 복수의 RAT를 통해 통신할 수 있게 하기 위한 복수의 트랜시버를 포함할 수 있다.

프로세서(32)는, 비이동식 메모리(44) 또는 이동식 메모리(46) 등의, 임의의 유형의 적절한 메모리로부터 정보를 액세스하거나, 여기에 데이터를 저장할 수도 있다. 비이동식 메모리(44)는, 랜덤 액세스 메모리(RAM), 판독-전용 메모리(ROM), 하드 디스크, 또는 기타 임의 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는, 가입자 신원 모듈(subscriber identity module)(SIM) 카드, 메모리 스틱, 보안 디지털(secure digital)(SD) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는, 서버 또는 가정용 컴퓨터 등의, M2M 디바이스(30)에 물리적으로 위치해 있지 않은 메모리로부터 정보를 액세스하거나, 여기서 데이터를 저장할 수도 있다. 프로세서(32)는 본 명세서에서 설명된 예들 중 일부에서 분산형 시맨틱 디스크립터를 통한 시맨틱 질의의 성공 여부에 응답하여 디스플레이 또는 표시자(42) 상의 점등 패턴, 이미지 또는 색상을 제어하거나 분산형 시맨틱 디스크립터 및 연관된 컴포넌트들을 통한 시맨틱 질의의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시기(42) 상의 제어 점등 패턴, 이미지 또는 색상은, 본 명세서에서 예시되거나 논의된 도면들(예를 들어, 도 10 내지 도 37 등의) 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영할 수 있다. 분산형 시맨틱 디스크립터를 통한 시맨틱 질의의 메시지들 및 절차들이 여기서 개시된다. 메시지들 및 절차들은, 사용자가, 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40), 또는 디스플레이/터치 패드(42))를 이용하여 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 요청하고 디스플레이(42) 상에 디스플레이될 수 있는 특히 자원들의 분산형 시맨틱 정보를 요청, 구성, 또는 질의하기 위한 인터페이스 API를 제공하도록 확장될 수 있다.

프로세서(32)는, 전원(48)으로부터 전력을 수신할 수 있고, M2M 디바이스(30) 내의 다른 컴포넌트들에 전력을 분배 및/또는 전력을 제어하도록 구성될 수 있다. 전원(48)은 M2M 디바이스(30)에 전력을 공급하기 위한 임의의 적절한 디바이스일 수 있다. 예를 들어, 전원(48)은, 하나 이상의 건식 셀 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양 전지, 연료 전지 등을 포함할 수 있다.

프로세서(32)는 또한, M2M 디바이스(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된 GPS 칩셋(50)에 결합될 수 있다. M2M 디바이스(30)는 본 명세서에서 개시된 정보와 여전히 일치되면서 임의의 적절한 위치-결정 방법을 통해 위치 정보를 취득할 수 있다는 점을 이해할 것이다.

프로세서(32)는 또한, 추가적인 피처, 기능 또는 유선이나 무선 접속을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수도 있는 다른 주변기기(52)에도 결합될 수도 있다. 예를 들어, 주변기기(52)는, 가속도계, 생체인식(예를 들어, 지문) 센서 등의 다양한 센서, e-나침반, 위성 트랜시버, (사진 또는 비디오용) 디지털 카메라, USB 포트 또는 기타의 상호접속 인터페이스, 진동 디바이스, 텔레비전 트랜시버, 핸즈프리 헤드셋, Bluetooth® 모듈, 주파수 변조(FM) 무선 유닛, 디지털 음악 재생기, 미디어 재생기, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

전송/수신 요소(36)는, 센서, 가전 제품, 스마트 시계 또는 스마트 의류 등의 착용형 디바이스, 의료 또는 e헬스(ehealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차 또는 비행기 등의 운송 수단 등의 다른 장치나 디바이스에서 구현될 수 있다. 전송/수신 요소(36)는, 주변기기(52) 중 하나를 포함할 수 있는 상호접속 인터페이스 등의, 하나 이상의 상호접속 인터페이스를 통해 이러한 장치나 디바이스의 다른 컴포넌트들, 모듈들, 또는 시스템들에 접속될 수 있다.

도 41d는, 예를 들어, 도 41a 및 도 41b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독 가능한 명령어에 의해, 또는 이러한 명령어들이 저장되거나 액세스되는 어떠한 수단에 의해 제어될 수 있다. 이러한 컴퓨터 판독 가능한 명령어는 중앙 처리 장치(CPU)(91) 내에서 실행되어 컴퓨팅 시스템(90)이 작업을 할 수 있게 한다. 많은 공지된 워크스테이션, 서버 및 개인용 컴퓨터에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서를 포함할 수도 있다. 코프로세서(81)는, 추가적인 기능을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개의, 선택사항적 프로세서이다. CPU(91) 또는 코프로세서(81)는, queryScope, QS, NI, NQS, RF 등의, 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 개시된 시스템 및 방법에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

동작시, CPU(91)는, 명령어를 인출하고, 디코딩하고, 실행하며, 컴퓨터의 메인 데이터-전송 경로, 즉, 시스템 버스(80)를 통해, 정보를 다른 자원들에 전송하거나 이로부터 정보를 가져온다. 이러한 시스템 버스는 컴퓨팅 시스템(90) 내의 컴포넌트들을 상호접속하고 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는, 전형적으로, 데이터를 전송하기 위한 데이터 라인, 주소를 전송하기 위한 주소 라인, 및 인터럽트를 전송하고 시스템 버스를 동작시키기 위한 제어 라인을 포함한다. 이러한 시스템 버스(80)의 한 예는 PCI(Peripheral Component Interconnect) 버스이다.

시스템 버스(80)에 결합된 메모리 디바이스는 랜덤 액세스 메모리(RAM)(82)와 판독 전용 메모리(ROM)(93)를 포함한다. 이러한 메모리는 정보가 저장 및 회수되는 것을 허용하는 회로를 포함한다. ROM(93)은 일반적으로, 용이하게 수정될 수 없는 저장된 데이터를 포함한다. RAM(82)에 저장된 데이터는 CPU(91) 또는 기타의 하드웨어 디바이스에 의해 판독되거나 변경될 수 있다. RAM(82) 또는 ROM(93)으로의 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어가 실행될 때 가상 주소를 물리적 주소로 변환하는 주소 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 또한, 시스템 내의 프로세스들을 분리하고, 시스템 프로세스를 사용자 프로세스로부터 분리하는 메모리 보호 기능을 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 프로세스 가상 주소 공간에 의해 매핑되는 메모리만을 액세스할 수 있다; 이것은 프로세스들간의 메모리 공유가 셋업되지 않는 한 또 다른 프로세스의 가상 주소 공간 내의 메모리에 액세스할 수 없다.

또한, 컴퓨팅 시스템(90)은, CPU(91)로부터, 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85) 등의 주변기기에 명령어를 전달하는 책임을 지는 주변기기 제어기(83)를 포함할 수 있다.

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성된 시각적 출력을 디스플레이하는데 이용된다. 이러한 시각적 출력은, 텍스트, 그래픽, 애니메이트된 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는, CRT-기반의 비디오 디스플레이, LCD-기반의 평판 디스플레이, 개스 플라즈마-기반의 평판 디스플레이 또는 터치-패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 컴포넌트를 포함한다.

또한, 컴퓨팅 시스템(90)은, 도 41a 및 도 41b의 네트워크(12) 등의, 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하는데 이용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

여기서 설명된 시스템들, 방법들, 및 프로세스들 중 임의의 것 또는 전부는 컴퓨터 판독 가능한 저장 매체에 저장된 컴퓨터 실행 가능한 명령어(즉, 프로그램 코드)의 형태로 임베딩될 수 있고, 명령어는, 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등의 머신에 의해 실행될 때, 여기서 설명된 시스템, 방법, 및 프로세스를 수행 및/또는 구현한다는 것을 이해할 것이다. 구체적으로는, 전술된 단계들, 동작들 또는 기능들 중 임의의 것은 이러한 컴퓨터 실행 가능한 명령어의 형태로 구현될 수 있다. 컴퓨터 판독 가능한 저장 매체는, 정보 저장을 위한 임의의 방법이나 기술로 구현된 휘발성 및 비휘발성의, 이동식 또는 비이동식 매체 양쪽 모두를 포함하지만, 이러한 컴퓨터 판독 가능한 저장 매체는 신호 그 자체를 포함하지 않는다. 본 명세서의 설명으로부터 명백한 바와 같이, 저장 매체는 법적 대상인 것으로 해석되어야 한다. 컴퓨터 판독 가능한 저장 매체는, RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타의 메모리 기술, CD-ROM, DVD, 또는 기타의 광학 디스크 스토리지, 자기 카셋트, 자기 테이프, 자기 디스크 저장 또는 기타의 자기 저장 디바이스, 또는 컴퓨터에 의해 액세스될 수 있고 원하는 정보를 저장하는데 이용될 수 있는 기타 임의의 물리적 매체를 포함한다.

본 개시내용의 주제 - 분산형 시맨틱 디스크립터를 통한 시맨틱 질의 - 의 선호되는 방법, 시스템, 또는 장치를 설명하는데 있어서, 도면들에 예시된 바와 같이, 명료성을 위해 특정한 전문용어가 채용된다. 그러나, 청구 주제는 이와 같이 선택된 특정한 전문용어로 제한되고자 함은 아니고, 각각의 특정한 요소는 유사한 목적을 달성하는 유사한 방식으로 동작하는 모든 기술적 균등물을 포함한다는 것을 이해해야 한다.

본 명세서에서 설명된 다양한 기술들은, 하드웨어, 펌웨어, 소프트웨어, 또는 적절한 경우, 이들의 조합과 관련하여 구현될 수 있다. 이러한 하드웨어, 펌웨어 및 소프트웨어는, 통신 네트워크의 다양한 노드들에 위치한 장치들에 상주할 수 있다. 이 장치들은 본 명세서에서 설명된 방법을 수행하기 위해 단독으로 또는 서로 조합하여 작동할 수 있다. 본 명세서에서 사용될 때, 용어 "장치", "네트워크 장치", "노드", "디바이스", "네트워크 노드" 등은 서로 바꾸어 사용될 수 있다.

상기의 설명은, 최상의 모드를 포함한 본 발명을 개시하기 위해, 및 본 기술분야의 임의의 통상의 기술자가, 임의의 디바이스 또는 시스템을 제작하고 이용하며 임의의 포함된 방법을 수행하는 것을 포함한 본 발명을 실시할 수 있게 하기 위해, 예들을 이용하고 있다. 본 발명의 특허가능한 범위는, 청구항들에 의해 정의되며, 본 기술분야의 통상의 기술자에게 가능한 다른 예(예를 들어, 단계를 건너 뛰거나, 단계들을 결합하거나, 본 명세서에 개시된 예시적인 방법들 사이에 단계들을 추가하는 것)를 포함할 수 있다. 이러한 다른 예들은, 청구항의 자구(literal language)와 상이하지 않은 구조적 요소를 포함하거나, 청구항의 자구와 사소한 차이를 갖는 균등한 구조적 요소를 포함한다면, 청구항의 범위 내에 드는 것이다.

특히, 본 명세서에 설명된 방법, 시스템, 및 장치는, 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 수단을 제공할 수 있다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 시맨틱 디스크립터 자원이 자원 디스크립터 링크 주석을 갖는 클래스 인스턴스를 포함한다고 결정하고; 시맨틱 디스크립터 자원이 제1 자원에 대한 자원 디스크립터 링크 주석을 갖는 클래스 인스턴스를 포함한다고 결정하는 것에 응답하여, 자원 디스크립터 링크 주석에 의해 링크된 제1 자원의 콘텐츠를 시맨틱 디스크립터 자원에 추가하기 위한 수단을 가진다. 시맨틱 디스크립터 자원이 자원 디스크립터 링크 주석을 갖는 클래스 인스턴스를 포함한다고 결정하는 것은, 시맨틱 디스크립터 자원의 시맨틱 질의에 응답할 수 있다. 제1 자원의 콘텐츠는, 트리플 또는 자원 설명 프레임워크 트리플을 포함한다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 제1 자원의 콘텐츠를 추가한 후에, 시맨틱 디스크립터 자원 상에서 시맨틱 질의를 실행하기 위한 수단을 갖는다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 실행된 시맨틱 질의의 결과를 제공하기 위한 수단을 가지며, 여기서, 결과는 시맨틱 질의에 대한 요청에서 수신된 포맷팅 명령에 기초할 수 있다. 시맨틱 질의에 대한 요청은, 시맨틱 디스크립터 자원이 자원 디스크립터 링크 주석을 갖는 클래스 인스턴스를 포함한다는 결정에 선행한다. 시맨틱 디스크립터 자원은 자식 자원일 수 있다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 실행된 질의와 연관된 결과를 디스플레이에 제공하기 위한 수단을 가지며, 여기서, 결과는 질의 요약을 포함한다. 디스플레이는 모바일 디바이스와 접속될 수 있다. 일부 구현에서, 시맨틱 디스크립터 자원은 대신에 또 다른 자원일 수 있다. (단계들의 제거 또는 추가를 포함한) 이 단락의 모든 조합은, 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

특히 본 명세서에 설명된 방법, 시스템, 및 장치는, 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 수단을 제공할 수 있다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 센서로부터 또는 센서와 연관된 정보(예를 들어, 센서로부터의 판독치)를 획득하고; 센서와 연관된 정보를 일반 자원에 제공하며; 정보에 대한 제1 semanticDescriptor 자원을 생성 - 제1 semanticDescriptor 자원은 정보를 트리플로서 표현함 - 하고; 제1 semanticDescriptor 자원을 생성하는 것에 기초하여 정보가 트리플로 복제된다는 것을 일반 자원의 속성에서 표시하기 위한 수단을 가진다. 센서가 개시되었지만, 다른 디바이스들(특히, M2M 디바이스)이 이용될 수 있는 것으로 고려된다. (단계들의 제거 또는 추가를 포함한) 이 단락의 모든 조합은, 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

본 명세서에 설명된, 특히, 방법, 시스템, 및 장치는, 분산형 시맨틱 디스크립터를 통한 시맨틱 질의를 위한 수단을 제공할 수 있다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 시맨틱 질의를 포함하는 요청 메시지를 수신하고; 요청 메시지 수신에 응답하여, 시맨틱 디스크립터 자원 상에서 시맨틱 질의를 실행하며; 시맨틱 디스크립터 자원이 자원 디스크립터 링크 주석을 갖는 노드를 포함한다고 결정하는 것에 기초하여 시맨틱 질의의 실행을 중지하기 위한 수단을 가진다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 단일 자원을 통해 직접 질의 처리를 수행하기 위한 수단을 갖는다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 시맨틱 질의에 의해 필요한 충분한 정보를 제공하기 위해 관련된 시맨틱 디스크립터 자원들이 함께 링크되도록 "resourceDescriptorLink" 속성을 이용하기 위한 수단을 갖는다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 어느 시맨틱 디스크립터를 이용할지를 결정하기 위해 시맨틱 질의에 대한 "질의 범위"를 이용하기 위한 수단을 갖는다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 시맨틱 질의에 응답하여, 자원 트리에 저장된 정보를 회수하기 위해 시맨틱 자원 발견을 이용하기 위한 수단을 갖는다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 센서에 대한 데이터 판독치를 획득하고; 데이터 판독치를 일반 자원(예를 들어, constentInstance)에 제공하며; 데이터 판독치를 일반 자원에 제공하는 것에 기초하여, 일반 자원에 대한 제1 semanticDescriptor 자원을 생성하기 위한 수단을 가지며, 여기서, 제1 semanticDescriptor 자원은 데이터 판독치를 트리플(예를 들어, RDF 트리플)로서 표현한다. 제1 semanticDescriptor 자원은, 센서에 대한 업데이트된 데이터 판독치를 획득하기 위한 또 다른 장치의 제2 semanticDescriptor 자원과 링크될 수 있다. 제1 semanticDescriptor 자원은, 균일한 자원 식별자를 통해 제2 semanticDescriptor 자원과 링크될 수 있다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 데이터 판독의 측정 단위를 획득하기 위해 시맨틱 추론을 이용하기 위한 수단을 가진다. 속성의 저장된 정보가 이미 RDF 형식으로 표현되었음을 나타내는 플래그가 있을 수 있다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 센서와 연관된 정보를 획득하고; 센서와 연관된 정보를 일반 자원에 제공하며; 정보에 대한 제1 semanticDescriptor 자원을 생성하기 위한 수단을 가진다. 제1 semanticDescriptor 자원은 정보를 트리플로서 나타낼 수 있다. 이 정보는 제1 semanticDescriptor 자원의 생성에 기초하여 트리플로서 복제된 것으로 표시될 수 있다. 이 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 시맨틱 질의를 포함하는 요청 메시지를 획득하고; 제1 시맨틱 디스크립터 자원이 자원 디스크립터 링크 주석을 갖는 복수의 노드 중 제1 노드를 포함한다는 결정에 기초하여 시맨틱 질의의 실행을 정지시키기 위한 수단을 가진다. (단계들의 제거 또는 추가를 포함한) 이 단락의 모든 조합들은, 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

Claims

분산형 시맨틱 디스크립터(distributed semantic descriptor)들을 통한 시맨틱 질의(semantic query)를 위한 장치로서,
프로세서; 및
상기 프로세서에 결합된 메모리
를 포함하고, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 수행하게 하는 실행 가능한 명령어들을 포함하며,
상기 동작들은:
센서와 연관된 정보를 획득하는 단계;
상기 센서와 연관된 정보를 일반 자원에 제공하는 단계;
상기 정보에 대한 제1 semanticDescriptor 자원을 생성하는 단계 - 상기 제1 semanticDescriptor 자원은 상기 정보를 트리플(triple)로서 표현함 -; 및
상기 제1 semanticDescriptor 자원을 생성하는 것에 기초하여 상기 정보가 트리플로서 복제된다는 것을 상기 일반 자원의 속성에서 표시하는 단계
를 포함하는 장치.
제1항에 있어서, 상기 일반 자원은 contentInstance 자원인 장치.
제1항에 있어서, 상기 제1 semanticDescriptor 자원은 상기 센서로부터 업데이트된 정보를 획득하기 위한 또 다른 장치의 제2 semanticDescriptor 자원과 링크되고, 상기 정보는 상기 센서로부터의 측정치들(measurements)인 장치.
제1항에 있어서, 상기 제1 semanticDescriptor 자원은 상기 센서로부터 업데이트된 정보를 획득하기 위한 또 다른 장치의 제2 semanticDescriptor 자원과 링크되고, 상기 제1 semanticDescriptor 자원은 균일 자원 식별자(uniform resource identifier)를 통해 상기 제2 semanticDescriptor 자원과 링크되는 장치.
제1항에 있어서, 상기 동작들은 상기 정보의 측정 단위를 나타내는 시맨틱 메타데이터를 획득하는 단계를 더 포함하는 장치.
제1항에 있어서, 상기 동작들은 상기 정보의 측정 단위를 획득하기 위해 시맨틱 추론(semantic reasoning)을 이용하는 단계를 더 포함하는 장치.
제1항에 있어서, 상기 제1 시맨틱 디스크립터는 상기 일반 자원의 자식 자원인 장치.
방법으로서,
센서와 연관된 정보를 획득하는 단계;
상기 센서와 연관된 정보를 일반 자원에 제공하는 단계;
상기 정보에 대한 제1 semanticDescriptor 자원을 생성하는 단계 - 상기 제1 semanticDescriptor 자원은 상기 정보를 트리플로서 표현함 -; 및
상기 제1 semanticDescriptor 자원을 생성하는 것에 기초하여 상기 정보가 트리플로서 복제된다는 것을 상기 일반 자원의 속성에서 표시하는 단계
를 포함하는 방법.
제8항에 있어서, 상기 일반 자원은 contentInstance 자원인 방법.
제8항에 있어서, 상기 제1 semanticDescriptor 자원은 상기 센서로부터 업데이트된 정보를 획득하기 위한 또 다른 장치의 제2 semanticDescriptor 자원과 링크되고, 상기 정보는 상기 센서로부터의 측정치들인 방법.
제8항에 있어서, 상기 제1 semanticDescriptor 자원은 상기 센서로부터 업데이트된 정보를 획득하기 위한 또 다른 장치의 제2 semanticDescriptor 자원과 링크되고, 상기 제1 semanticDescriptor 자원은 균일 자원 식별자를 통해 상기 제2 semanticDescriptor 자원과 링크되는 방법.
제8항에 있어서, 상기 정보의 측정 단위를 나타내는 시맨틱 메타데이터를 획득하는 단계를 더 포함하는 방법.
제8항에 있어서, 상기 정보의 측정 단위를 획득하기 위해 시맨틱 추론을 이용하는 단계를 더 포함하는 방법.
제8항에 있어서, 상기 제1 시맨틱 디스크립터는 상기 일반 자원의 자식 자원인 방법.
컴퓨팅 디바이스에 의해 실행될 때 상기 컴퓨팅 디바이스로 하여금 동작들을 수행하게 하는 컴퓨터 실행 가능한 명령어들을 저장한 컴퓨터 판독 가능한 저장 매체로서, 상기 동작들은:
센서와 연관된 정보를 획득하는 단계;
상기 센서와 연관된 정보를 일반 자원에 제공하는 단계;
상기 정보에 대한 제1 semanticDescriptor 자원을 생성하는 단계 - 상기 제1 semanticDescriptor 자원은 상기 정보를 트리플로서 표현함 -; 및
상기 제1 semanticDescriptor 자원을 생성하는 것에 기초하여 상기 정보가 트리플로서 복제된다는 것을 상기 일반 자원의 속성에서 표시하는 단계
를 포함하는 컴퓨터 판독 가능한 저장 매체.
제15항에 있어서, 상기 일반 자원은 contentInstance 자원인 컴퓨터 판독 가능한 저장 매체.
제15항에 있어서, 상기 제1 semanticDescriptor 자원은 상기 센서로부터 업데이트된 정보를 획득하기 위한 또 다른 장치의 제2 semanticDescriptor 자원과 링크되고, 상기 제1 semanticDescriptor 자원은 균일 자원 식별자를 통해 상기 제2 semanticDescriptor 자원과 링크되는 컴퓨터 판독 가능한 저장 매체.
제15항에 있어서, 상기 동작들은 상기 정보의 측정 단위를 나타내는 시맨틱 메타데이터를 획득하는 단계를 더 포함하는 컴퓨터 판독 가능한 저장 매체.
제15항에 있어서, 상기 동작들은 상기 정보의 측정 단위를 획득하기 위해 시맨틱 추론을 이용하는 단계를 더 포함하는 컴퓨터 판독 가능한 저장 매체.
제15항에 있어서, 상기 제1 semanticDescriptor 자원은 상기 센서로부터 업데이트된 정보를 획득하기 위한 또 다른 장치의 제2 semanticDescriptor 자원과 링크되며, 상기 정보는 상기 센서로부터의 측정치들인 컴퓨터 판독 가능한 저장 매체.