KR20200124267A - 분산형 시맨틱 데이터를 통한 시맨틱 동작들 및 추론 지원 - Google Patents

Abstract

방법들, 시스템들, 및 장치들은 시맨틱 추론 동작들에 관한 문제들을 해결한다. 상이한 맞춤화된 또는 사용자-정의된 규칙들은 애플리케이션 요구들에 기반하여 정의될 수 있고, 이는 동일한 초기 팩트들에 기반하더라도 상이한 추론된 팩트들을 초래할 수 있다.

Description

분산형 시맨틱 데이터를 통한 시맨틱 동작들 및 추론 지원

관련 출원들에 대한 상호 참조

본 출원은 "Semantic Operations and Reasoning Support Over Distributed Semantic Data"라는 명칭으로, 2018년 2월 27일자로 출원된 미국 가특허 출원 제62/635,827호의 이익을 주장하며, 그 내용들은 본 명세서에 참조로 포함된다.

시맨틱 웹은 W3C(World Wide Web Consortium)의 표준들을 통한 웹의 확장이다. 이 표준들은 웹 상의 공통 데이터 포맷들 및 교환 프로토콜들, 가장 기본적으로는 리소스 설명 프레임워크(Resource Description Framework: RDF)를 촉진한다. 시맨틱 웹은 데이터를 위해 특별히 설계된 언어들, 즉, RDF, OWL(Web Ontology Language), 및 XML(Extensible Markup Language)로 게시하는 것을 포함한다. 이러한 기술들은 링크된 데이터의 웹을 통해 웹 문서들의 콘텐츠를 보완하거나 대체하는 설명들을 제공하도록 결합된다. 따라서, 콘텐츠는 웹 액세스가능한 데이터베이스들에 저장된 설명형 데이터로서, 또는 별도로 저장된 레이아웃 또는 렌더링 큐들을 이용하여, 특히, XML이 산재된 XHTML(Extensible HTML) 또는 보다 빈번하게는 순수하게 XML에서 문서들 내의 마크업으로서, 자신을 표명할 수 있다.

시맨틱 웹 스택은 도 1에 도시된 바와 같이 W3C에 의해 지정된 시맨틱 웹의 아키텍처를 예시한다. 구성요소들의 기능들 및 관계들은 다음과 같이 요약될 수 있다. XML은 문서들 내의 콘텐츠 구조에 대한 요소적 신택스를 제공하지만, 어떠한 시맨틱도 그 안에 포함된 콘텐츠의 의미와 연관시키지 않는다. 터틀과 같은 대안적인 신택스들이 존재하기 때문에, 현재 대부분의 경우들에서 XML은 시맨틱 웹 기술들의 필요한 구성요소가 아니다. 터틀은 사실상 표준이지만, 공식적인 표준화 프로세스를 거치지는 않았다.

XML 스키마는 XML 문서들 내에 포함된 요소들의 구조와 콘텐츠를 제공하고 제한하기 위한 언어이다.

RDF는 객체들("웹 리소스들") 및 그들의 관계들을 주어-술어-목적어(subject-predicate-object), 예를 들어, S-P-O 트리플 또는 RDF 트리플의 형태로 나타내는 데이터 모델들을 표현하기 위한 간단한 언어이다. RDF 기반 모델은 다양한 신택스들, 예를 들어, RDF/XML, N3, 터틀 및 RDFa로 표현될 수 있다. RDF는 시맨틱 웹의 기본 표준이다.

RDF 그래프는 에지들이 RDF 트리플들의 "술어"를 표현하는 반면 그래프 노드들이 RDF 트리플들의 "주어" 또는 "목적어"를 표현하는 방향성 그래프이다. 즉, RDF 트리플들에 설명된 바와 같은 링킹 구조는 이러한 방향성 RDF 그래프를 형성한다.

RDF 스키마(RDFS)는 RDF를 확장하고, 그 특성들 및 클래스들의 일반화된 계층구조들에 대한 시맨틱으로 RDF 기반 리소스들의 특성들 및 클래스들을 설명하기 위한 어휘이다.

OWL은 특성들과 클래스들을 설명하기 위한 보다 많은 어휘, 특히, 클래스들 간의 관계들(예를 들어, 분리), 카디널리티(cardinality)(예를 들어, "정확히 하나"), 동등성, 보다 풍부한 유형의 특성들, 특성들의 특징들(예를 들어, 대칭) 및 열거형(enumerated) 클래스들을 추가한다.

SPARQL은 웹 또는 RDF 저장소(예를 들어, 시맨틱 그래프 저장소)에서 RDF 그래프 콘텐츠(예를 들어, RDF 트리플들)를 질의하고 조작하기 위한 시맨틱 웹 데이터 소스들에 대한 프로토콜 및 질의 언어이다.

· SPARQL 1.1 질의는 RDF 그래프에 대한 질의 언어이고, 데이터가 선천적으로 RDF로서 저장되거나 미들웨어를 통해 RDF로서 보이든 간에 다양한 데이터 소스들에 걸쳐 질의들을 표현하는데 이용될 수 있다. SPARQL은 논리곱(conjunction)들 및 논리합(disjunction)들과 함께 필수적 및 임의적 그래프 패턴들을 질의하기 위한 하나 이상의 능력을 포함한다. SPARQL은 또한 집계, 하위 질의들, 부정(negation), 표현식(expression)들에 의한 값 생성, 확장성 값 테스팅, 및 소스 RDF 그래프에 의한 질의 제약을 지원한다. SPARQL 질의들의 결과들은 결과 세트들 또는 RDF 그래프들일 수 있다.

· SPARQL 1.1 업데이트는 RDF 그래프들에 대한 업데이트 언어이다. 이것은 RDF에 대한 SPARQL 질의 언어로부터 파생된 신택스를 이용한다. 업데이트 동작들은 시맨틱 그래프 저장소의 그래프들의 모음에 대해 수행된다. 동작들은 시맨틱 그래프 저장소에서의 RDF 그래프들을 업데이트, 생성 및 제거하도록 제공된다.

규칙은 컴퓨터 과학에서의 개념이다: 이것은 IF - THEN 구조이다. 일부 데이터세트에서 체크가능한 일부 조건(IF 부분)이 유지되는 경우, 결론(THEN 부분)이 처리된다. 온톨로지가 도메인 지식을 설명할 수 있지만, 규칙은 때때로 어렵거나 또는 OWL에서 이용되는 설명 로직을 이용하여 직접 설명될 수 없는 특정 지식 또는 관계들을 설명하는 다른 접근법이다. 규칙은 또한 시맨틱 추론/추론에 이용될 수 있고, 예를 들어 사용자들은 그들 자신의 추론 규칙들을 정의할 수 있다.

RIF는 규칙 교환 포맷이다. 컴퓨터 과학 및 로직 프로그래밍 커뮤니티들에서, 규칙들을 이해하기 위해 2개의 상이하지만 밀접하게 관련된 방식들이 있다. 하나는 컴퓨터 프로그램에서 명령어의 아이디어에 밀접하게 관련된다: 특정한 조건이 유지되는 경우, 일부 액션이 수행된다. 이러한 규칙들은 종종 생성 규칙들로 지칭된다. 생성 규칙의 예는 "고객이 100,000 마일보다 많이 비행한 경우, 그를 골드 멤버 상태로 업그레이드한다"이다.

대안적으로, 세계에 관한 팩트를 진술하는 규칙을 생각할 수 있다. 종종 선언적 규칙들로서 지칭되는 이러한 규칙들은 "P이면, Q이다"인 형태의 문장들인 것으로 이해된다. 선언적 규칙의 예는 "사람이 현재 미국의 대통령이면, 그 또는 그녀의 현재 거주지는 백악관이다"라는 것이다.

SILK, OntoBroker, Eye, VampirePrime, N3-Logic 및 SWRL(선언적 규칙 언어들); 및 Jess, Drools, IBM ILog 및 Oracle Business Rules(생성 규칙 언어들)를 포함하는 많은 규칙 언어들이 있다. 많은 언어들은 선언적 및 생성 규칙 언어 둘 다의 특징들을 포함한다. 상이한 언어들에서의 규칙 세트들의 풍부함은 규칙 세트들을 통합하거나, 하나의 규칙 세트로부터 다른 규칙 세트로 정보를 가져오길 원하는 경우 어려움들을 생성할 수 있다. 규칙 엔진이 어떻게 상이한 언어들의 규칙 세트들과 함께 동작할 수 있는지가 본 명세서에서 고려된다.

W3C 규칙 교환 포맷(RIF)은 규칙 세트 통합 및 합성을 용이하게 하도록 개발된 표준이다. 이것은 다양한 특징들을 갖는 규칙 언어들을 나타내는 RIF 코어, RIF BLD(Basic Logic Dialect), RIF PRD(Production Rule Dialect) 등과 같은 상호연결된 방언들의 세트를 포함한다. 예를 들어, 이하에서 논의되는 예들은 (가장 기본적인 것인) RIF 코어에 기반한다. RIF 방언 BLD는 논리적으로 정의된 기능들을 허용함으로써 RIF-코어를 확장한다. RIF 방언 PRD는 지식 베이스 수정의 규칙들, 부정, 및 명시적 문(statement)의 우선순위화를 허용함으로써 RIF-코어를 확장한다.

아래는 RIF의 예이다. 이 예는 시맨틱 웹을 통한 영화 및 연극에 관한 데이터 통합에 관한 것이다. 예를 들어, IMDb(Internet Movie Data Base(http://imdb.com)로부터의 영화에 관한 데이터를 DBpedia(http://dbpedia.org)와 조합하기를 원하는 것으로 가정한다. 양쪽 리소스들은 영화에 출연하는 배우들에 관한 팩트들을 포함하지만, DBpedia는 이러한 팩트들을 이진 관계(일명 술어 또는 RDF 특성)로 표현한다.

예를 들어, DBpedia에서, 배우가 영화에 출연한다는 팩트를 표현할 수 있다:

'?' 접두사 변수들을 플레이스홀더들로서 이용한다. 이 예에서 이용된 변수들의 이름들은 인간 독자들에게는 의미가 있지만 기계에게는 의미가 없다. 이들 변수 이름들은 DBpedia 주연 관계의 첫 번째 주장이 영화이고, 두 번째가 영화에서의 주연 배우라는 것을 독자들에게 전달하기 위한 것이다.

그러나, IMDb에서는 유사한 관계가 없다. 오히려, 역할들을 하는 배우들에 대해 다음과 같은 형식의 팩트들을 진술할 수 있다:

영화에 등장하는 역할들(캐릭터들)에 대해 다음과 같은 형식의 팩트들을 진술할 수 있다:

따라서, 예를 들어, DBpedia에서 비비안 리(Vivien Leigh)가 A Streetcar Named Desire의 출연진에 있었다는 정보를 팩트로 나타낸다:

그러나, IMDb에서는, 다음과 같은 두 가지 단편의 정보를 나타낸다:

비비안 리가 Blanche DuBois의 역할을 하였고,

Blanche DuBois가 A Streetcar Named Desire에서의 캐릭터였다.

이 데이터를 조합하는데 있어서 다음과 같은 과제가 있다: 2개의 데이터 소스(IMDb 및 DBpedia)가 상이한 어휘(관계 이름들 starring, playsRole, roleInFilm)를 이용할 뿐만 아니라 구조가 상이하다. 이 데이터를 조합하기 위해, 우리는 본질적으로 다음과 같은 규칙 등의 무언가를 말하기를 원한다: IMDb 데이터베이스에, 배우가 역할/캐릭터를 연기하고, 그 캐릭터가 영화에 있다고 말하는 두 가지 팩트가 있는 경우, 그 배우가 그 영화에 출연한다고 말하는 단일 팩트가 DBpedia 데이터베이스에 있다. 이 전술한 규칙은 다음과 같이 RIF 규칙으로 작성될 수 있다(굵은 단어들은 RIF에 의해 정의되는 키워드들이고, RIF 사양에 관한 더 많은 상세들은 RIF 프라이머, https://www.w3.org/2005/rules/wiki/Primer에서 발견될 수 있다):

시맨틱 추론. 일반적으로, 시맨틱 추론 또는 추론은 지식 베이스에서 명시적으로 표현되지 않는 팩트들을 도출하는 것을 의미한다. 즉, 이것은 기존 지식 베이스로부터 새로운 암시적 지식을 도출하는 메커니즘이다. 예: (초기 팩트들/지식으로서) 고려될 데이터 세트는 관계를 포함할 수 있다(플리퍼는 돌고래-인스턴스에 관한 팩트이다). 유의할 점은, 팩트들 및 지식이 본 명세서에서 상호교환 가능하게 이용될 수 있다는 것이다. 온톨로지는 "모든 돌고래가 또한 포유류-개념에 관한 팩트임"을 선언할 수 있다. 추론 규칙이 "A가 클래스 B의 인스턴스이고, B가 클래스 C의 하위 클래스이면, A는 또한 클래스 C의 인스턴스임"을 진술하고 있는 경우, 추론 프로세스의 관점에서 초기 팩트들에 걸쳐 이 규칙을 적용함으로써, 새로운 문이 추론될 수 있다: 플리퍼가 포유류이고, 이는 초기 팩트들, [W3C Semantic Inference,www.w3.org/standards/semanticweb/inference]의 일부가 아니더라도, 추론에 기반하여 도출되는 암시적 지식/팩트이다.

위의 예로부터, 시맨틱 추론을 수반하는 몇몇 주요 개념들이 있다는 것을 알 수 있다:

1. 지식/팩트 베이스(팩트 및 지식은 이 작업에서 상호교환 가능하게 이용될 것임)

2. 시맨틱 추론 규칙들, 및

3. 추론된 팩트들.

이하의 섹션들은 지식 베이스 및 시맨틱 규칙들에 대한 더 많은 상세들을 제공한다. 위의 예에 대한 시맨틱 추론 프로세스를 구현하기 위해, 시맨틱 추론기(시맨틱 추론기, https://en.wikipedia.org/wiki/Semantic_reasoner)가 이용될 수 있다. 통상적으로, 시맨틱 추론기(추론 엔진, 규칙 엔진, 또는 간단히 추론기)는 추론 규칙들의 세트를 이용하여 어써팅된 팩트들의 세트로부터 논리적 결과들을 추론할 수 있는 소프트웨어의 부분이다. 일부 개방-소스 시맨틱 추론기들이 존재하고, 나중 섹션은 Apache Jena에 의해 제공되는 예시적인 추론기(https://jena.apache.org/documentation/inference/)에 관한 더 많은 상세들을 제공할 것이다. 또한, 시맨틱 추론 또는 추론은 통상적으로 추가 정보를 도출하는 추상 프로세스를 지칭하는 반면, 시맨틱 추론기는 추론 작업들을 수행하는 특정 코드 객체를 지칭한다.

지식 베이스(KB)는 컴퓨터 시스템[https://en.wikipedia.org/wiki/Abox][TBox, https://en.wikipedia.org/wiki/Tbox]에 의해 이용되는 복잡한 구조화된 및 비구조화된 정보를 저장하는데 이용되는 기술이다. KB의 구성은 다음의 형태를 갖는다:

지식 베이스 = ABox + TBox

ABox 및 TBox라는 용어들은 2개의 상이한 유형의 문들/팩트들을 기술하는데 이용된다. TBox 문들은 제어된 어휘들, 예를 들어, 클래스들 및 특성들의 세트(예컨대, 스킴 또는 온톨로지 정의)의 관점에서 시스템을 기술한다. ABox는 그 어휘에 관한 TBox-준수 문들이다.

예를 들어, ABox 문들은 전형적으로 다음과 같은 형태를 갖는다:

A는 B의 인스턴스이거나 존은 사람이다.

비교하면, TBox 문들은 전형적으로 다음과 같은 형태를 갖는다:

모든 학생들은 사람들이거나 또는

두 가지 유형의 사람들, 즉 학생들 및 교사들이 있다(예를 들어, 학생들 및 교사들은 사람들의 하위 클래스이다).

요약하면, TBox 문들은 객체 지향 클래스들(예컨대, 스킴 또는 온톨로지 정의)과 연관되고, ABox 문들은 이러한 클래스들의 인스턴스들과 연관된다. 이전의 예에서, 팩트 문 "플리퍼가 돌고래이다"는 Abox 문인 반면, "모든 돌고래가 또한 포유류이다"는 TBox 문이다.

함의는 특정 조건들 하에서 하나의 문의 진실이 두 번째 문의 진실을 보장한다는 원리이다. W3C에 의해 정의되는 바와 같은 상이한 표준 함의 체제들, 예를 들어 RDF 함의, RDF 스키마 함의, OWL 2 RDF 기반 시맨틱 함의 등이 있다. 특히, 각각의 함의 체제는 함의 규칙들의 세트[https://www.w3.org/TR/sparql11-entailment/]를 정의하고, 이하는 RDFS 함의 체제[https://www.w3.org/TR/rdf-mt/#rules]에 의해 정의되는 추론 규칙들 중 2개(규칙 7 및 규칙 11)이다:

규칙 7: aaa rdfs:subPropertyof bbb && uuu aaa yyy이면, uuu bbb yyy이다.

이것은, aaa가 bbb의 하위 특성이고, uuu가 그 aaa 특성에 대한 yyy의 값을 가지면, uuu는 또한 그 bbb 특성에 대한 yyy의 값을 갖는다는 것을 의미한다(여기서, "aaa", "uuu", "bbb"는 단지 변수 이름들이다).

규칙 11: uuu rdfs:subClassOf vvv 및 vvv rdfs:subClassOf x이면, uuu rdfs:subClassOf x이다.

이것은, uuu가 vvv의 하위 클래스이고, vvv가 x의 하위 클래스이면, uuu는 또한 x의 하위 클래스라는 것을 의미한다.

시맨틱 추론 도구에서 시맨틱 추론기를 개시할 때, 종종 어느 함의 체제가 실현될 것인지를 지정하는 것이 요구된다. 예를 들어, 시맨틱 추론기 인스턴스 A는 RDFS 함의 체제에 의해 정의되는 추론 규칙들을 지원할 "RDFS 추론기"일 수 있다. 예로서, (RDF 트리플들에 설명된) 다음의 초기 팩트들을 갖는다고 가정한다:

이들 팩트들을 시맨틱 추론기 인스턴스 A에 입력함으로써, 다음과 같은 추론된 팩트가 위에 소개된 바와 같이 RDFS 규칙 11을 이용하여 도출될 수 있다:

시맨틱 추론 도구 예: Jena 추론 지원. Jena 추론은 추론 엔진들 또는 추론기들의 범위가 Jena에 플러깅되는 것을 허용하도록 설계된다. 이러한 엔진들은 임의의 선택적인 온톨로지 정보 및 추론기와 연관된 규칙들과 함께 일부 기존/베이스 팩트들로부터 함의되는 추가적인 RDF 어써션들/팩트들을 도출하는데 이용된다.

Jena 분포는 "사용자-정의된" 규칙들을 지원하는 일반 규칙 기반 추론기인 일반 규칙 추론기뿐만 아니라, RDFS 추론기 또는 OWL 추론기(이전 섹션에서 제각기 소개된 바와 같이 대응하는 함의 체제들에 의해 정의되는 추론 규칙들의 세트를 구현함)와 같은, 다수의 미리 정의된 추론기들을 지원한다.

이하의 코드 예는 시맨틱 추론 작업을 위해 Jena API를 어떻게 이용할지를 예시한다: 특성 "p"가 (라인 6에 정의된 바와 같이) 다른 특성 "q"의 하위 특성이라는 문들을 포함하는, (실제로 이 예에서 "초기 팩트들"인, 라인 3에서 rdfsExample라 불리는) Jena 모델을 먼저 생성하고, (라인 7에 정의된 바와 같이) "p"에 대한 값 "foo"를 갖는 리소스 "a"를 갖는다:

1. 스트링 NS = "urn:x-hp-jena:eg/";

2. // 사소한 예시적인 데이터 세트의 구축

3. 모델 rdfsExample = ModelFactory.createDefaultModel();

4. 특성 p = rdfsExample.createProperty(NS, "p");

5. 특성 q = rdfsExample.createProperty(NS, "q");

6. rdfsExample.add(p, RDFS.subPropertyOf, q);

7. rdfsExample.createResource(NS+"a").addProperty(p, "foo");

이제 모든 초기 팩트들이 변수 rdfsExample에 저장된다. 그 후, 다음과 같은 코드로 초기 팩트들에 걸쳐 RDFS 추론을 수행하는 추론 모델을 생성할 수 있다:

8. InfModel inf = ModelFactory.createRDFSModel(rdfsExample);

라인 8에 도시된 바와 같이, RDFS 추론기는 createRDFSModel() API를 이용하여 생성되고, 입력은 변수 rdfsExample에 저장된 초기 팩트들이다. 따라서, 시맨틱 추론 프로세스는 (부분적인) RDFS 규칙 세트를 rdfsExample에 저장된 팩트들에 적용함으로써 실행될 것이고, 추론된 팩트들은 변수 inf에 저장된다.

이제 변수 inf에 저장된 추론된 팩트들을 체크할 수 있다. 예를 들어, 리소스 a의 특성 q의 값을 알기를 원하며, 이는 다음과 같은 코드로 구현될 수 있다:

9. 리소스 a = inf.getResource(NS+"a");

10. System.out.println("Statement: " + a.getProperty(q));

출력은 다음과 같을 것이다:

11. 문: [urn:x-hp-jena:eg/a, urn:x-hp-jena:eg/q, Literal<foo>]

라인 11에 도시된 바와 같이, 리소스 a의 특성 q의 값은 "foo"이고, 이는 RDFS 추론 규칙 중 하나에 기반한 추론된 팩트이다: aaa rdfs:subPropertytyof bbb && uuu aaa yyy이면, uuu bbb yyy(RDFS 함의 규칙들 중 규칙 7)이다. 추론 프로세스는 다음과 같다: 리소스 a에 대해, 그 특성 p의 값은 "foo"이고, p는 q의 하위 특성이므로, 리소스 a의 특성 q의 값은 "foo"이다.

oneM2M. 개발하에 있는 oneM2M 표준은 "CSE(Common Service Entity)"라고 지칭되는 서비스 계층을 정의한다. 서비스 계층의 목적은 상이한 "수직(vertical)" M2M 시스템들 및 애플리케이션들에 의해 이용될 수 있는 "수평(horizontal)" 서비스들을 제공하는 것이다. CSE는 도 2에 도시된 바와 같이 4개의 참조 포인트를 지원한다. Mca 참조 포인트는 애플리케이션 엔티티(AE)와 인터페이싱한다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인 내의 다른 CSE와 인터페이싱하고, Mcc' 참조 포인트는 상이한 서비스 제공자 도메인에서의 다른 CSE와 인터페이싱한다. Mcn 참조 포인트는 기반 네트워크 서비스 엔티티(NSE))와 인터페이싱한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 기반 네트워크 서비스들을 CSE들에게 제공한다.

CSE는, "발견" 및 "데이터 관리 및 저장소"와 같은, "공통 서비스 기능들(CSF들)"이라고 불리는 복수의 논리적 기능들 중 하나 이상을 포함할 수 있다. 도 3은 oneM2M에 의해 정의되는 CSF들 중 일부를 예시한다.

oneM2M 아키텍처는 이하의 유형들의 노드들을 가능하게 한다:

애플리케이션 서비스 노드(ASN): ASN은 하나의 CSE를 포함하고 적어도 하나의 애플리케이션 엔티티(AE)를 포함하는 노드이다. 물리적 매핑의 예: ASN은 M2M 디바이스에 존재할 수 있다.

애플리케이션 전용 노드(ADN): ADN은 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. oneM2M 시스템의 필드 도메인에 0개 이상의 ADN이 있을 수 있다. 물리적 매핑의 예: 애플리케이션 전용 노드는 제약된 M2M 디바이스에 존재할 수 있다.

중간 노드(MN): MN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. oneM2M 시스템의 필드 도메인에 0개 이상의 MN이 있을 수 있다. 물리적 매핑의 예: MN은 M2M 게이트웨이에 존재할 수 있다.

인프라스트럭처 노드(IN): IN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. 인프라스트럭처 도메인에 oneM2M 서비스 제공자당 정확히 하나의 IN이 있다. IN의 CSE는 다른 노드 유형들에 적용가능하지 않은 CSE 기능들을 포함할 수 있다. 물리적 매핑의 예: IN은 M2M 서비스 인프라스트럭처에 존재할 수 있다.

비-oneM2M 노드(NoDN): 비-oneM2M 노드는 oneM2M 엔티티들을 포함하지 않는(AE들도 CSE들도 포함하지 않는) 노드이다. 이러한 노드들은, 관리를 포함한, 상호연동 목적들을 위해 oneM2M 시스템에 부속된 디바이스들을 나타낸다.

시맨틱 주석부기. oneM2M에서, <semanticDescriptor> 리소스는 리소스에 관한 시맨틱 설명을 저장하는데 이용된다. 이러한 설명은 온톨로지들에 따라 제공된다. 시맨틱 정보는 oneM2M 시스템의 시맨틱 기능들에 의해 이용되며, 애플리케이션들 또는 CSE들에도 또한 이용가능하다. 일반적으로, <semanticDescriptor> 리소스(도 4에 도시된 바와 같음)는 <AE>, <container>, <CSE>, <group> 리소스들 등과 같은 그 부모 리소스의 시맨틱 주석부기이다.

시맨틱 필터링 및 리소스 발견. 일단 시맨틱 주석부기가 인에이블되면(예컨대, <semanticDescriptor> 리소스에서의 콘텐츠가 그 부모 리소스의 시맨틱 주석부기이면), 시맨틱 리소스 발견 또는 시맨틱 필터링이 지원될 수 있다. 시맨틱 리소스 발견은 <semanticDescriptor> 리소스들의 디스크립터 속성에 포함된 시맨틱 설명들에 기반하여 CSE에서 리소스들을 찾는데 이용된다. 그렇게 하기 위해, 요청 동작 필터 기준들에 대한 추가 값(예컨대, "semanticsFilter" 필터)이 개시되었고, 그 정의가 이하의 표 1에 도시된다. 시맨틱 필터는 관련된 시맨틱 설명들을 통해 실행될, (요구들에 기반한 발견 기준들/제약들을 정의하는) SPARQL 문을 저장한다. "요구들"(예컨대, 요청들 또는 요건들)은 종종 애플리케이션 주도이다. 예를 들어, 지리적 영역에서 제조 A에 의해 생성된 모든 디바이스들을 찾기 위한 요청이 있을 수 있고, 대응하는 SPARQL 문이 이러한 요구를 위해 기입될 수 있다. 시맨틱 리소스 발견의 작업 메커니즘은 다음과 같다: 시맨틱 리소스 발견은 semanticsFilter 파라미터를 갖는 검색 요청을 전송함으로써 개시된다. 전체 시맨틱 설명(그래프를 형성함)이 <semanticDescriptor> 리소스들의 세트에 걸쳐 분포될 수 있기 때문에, 모든 관련된 시맨틱 설명들이 먼저 검색되어야 한다. 그 다음, 시맨틱 필터에 포함된 바와 같은 SPARQL 질의문은 그 관련된 시맨틱 설명들에 대해 실행될 것이다. SPARQL 처리 동안 특정 리소스 URI들이 식별될 수 있다면, 이러한 리소스 URI들은 발견 결과로서 회신될 것이다. 표 1은 [oneM2M-TS-0001 oneM2M 기능적 아키텍처 -V3.8.0]에 언급된 바와 같다.

<표 1>

시맨틱 질의. 일반적으로, 시맨틱 질의들은 (RDF 데이터와 같은) 데이터에 포함된 구문, 시맨틱 및 구조적 정보에 기반하여 명시적으로 그리고 암시적으로 도출된 정보 양쪽 모두의 검색을 가능하게 한다. 시맨틱 질의의 결과는 그 질의에 응답/일치하기 위한 시맨틱 정보/지식이다. 이에 비해, 시맨틱 리소스 발견의 결과는 식별된 리소스 URI들의 리스트이다. 예로서, 시맨틱 리소스 발견은 "빌딩 A 내의 온도 센서들을 나타내는 모든 리소스 URI들"을 찾는 것(예컨대, 발견 결과는 <센서-1> 및 <센서-2>의 URI들을 포함할 수 있음)인 반면, 시맨틱 질의는 "얼마나 많은 온도 센서들이 빌딩 A 내에 있는가?"라는 질문을 하는 것이다(예컨대, 질의 결과는, 빌딩 A 내에 2개의 센서, 예를 들어 <센서-1> 및 <센서-2>가 있으므로, "2"일 것이다).

주어진 시맨틱 질의에 대해, 이것은 (<semanticDescriptor> 리소스들과 같은) 상이한 시맨틱 리소스들에서 분포될 수 있는 RDF 트리플들의 세트("RDF 데이터 베이시스"라고 함)에 대해 실행될 수 있다. 시맨틱 질의와 연관된 "질의 범위"는 어느 시맨틱 리소스들이 이 질의의 RDF 데이터 베이시스에 포함되어야 하는지를 결정하는 것이다.

시맨틱 리소스 발견 및 시맨틱 질의 둘 다는 SPARQL 질의 언어에서 지정되는 질의문을 지정하기 위해 동일한 시맨틱 필터를 이용한다. CSE가 시맨틱 필터를 포함하는 검색 요청을 수신할 때, 시맨틱 질의 표시자 파라미터가 그 요청에 또한 존재하는 경우, 그 요청은 시맨틱 질의로서 처리될 것이고; 그렇지 않으면, 그 요청은 시맨틱 리소스 발견으로서 처리될 것이다. 시맨틱 질의 프로세스에서, 수신된 시맨틱 질의 요청 및 그 질의 범위가 주어지면, SPARQL 질의문은 질의 범위 내의 시맨틱 리소스(들)로부터 수집된 집성된 시맨틱 정보를 통해 실행될 것이고, 생성된 출력은 이 시맨틱 질의의 결과일 것이다.

종래의 시맨틱 추론은 팩트 관점(일반적으로 팩트들은 시맨틱 트리플들로서 표현됨) 및 추론 규칙 관점으로부터의 새로운 문제들로 인해 SL 기반 플랫폼의 컨텍스트에서 직접 이용되지 않을 수 있다. 팩트 관점에서, 데이터 또는 팩트들은 종종 상이한 장소들(예를 들어, 기존의 oneM2M <semanticDescriptor> 리소스들에서의 RDF 트리플들)에 단편화되거나 분포된다. 본 명세서에는 추론 프로세스를 위한 입력들(예컨대, 팩트 세트들)을 준비하기 위해 관련된 "팩트 사일로들"을 조직화하거나 통합할 수 있는 방법들, 시스템들 및 장치들이 개시된다. 추론 규칙 관점에서, 서비스 계층(SL) 기반 플랫폼은 종종 상이한 섹션들에 걸쳐 애플리케이션들을 가능하게 하는 수평 플랫폼인 것으로 가정된다. 따라서, 상이한 맞춤화된 또는 사용자-정의된 규칙들은 애플리케이션 요구들에 기반하여 정의될 수 있으며, 이는 (동일한 초기 팩트들에 기반하더라도) 상이한 추론된 팩트들을 초래할 수 있다.

더 상세한 이해는 첨부의 도면들과 관련하여 예를 들어 주어진 다음의 설명으로부터 얻어질 수 있다.
도 1은 시맨틱 웹의 예시적인 아키텍처를 도시한다.
도 2는 예시적인 oneM2M 아키텍처를 도시한다.
도 3은 예시적인 oneM2M 공통 서비스 기능들을 도시한다.
도 4는 <semanticDescriptor> 리소스의 예시적인 구조를 도시한다.
도 5는 예시적인 지능형 시설 관리 이용 사례를 도시한다.
도 6은 예시적인 시맨틱 추론 구성요소들 및 다른 시맨틱 동작들과의 최적화를 도시한다.
도 7은 FS 공개를 위한 예시적인 생성 동작을 도시한다.
도 8은 FS 검색을 위한 예시적인 검색 동작을 도시한다.
도 9는 FS 업데이트/삭제를 위한 예시적인 업데이트/삭제 동작을 도시한다.
도 10은 RS 공개를 위한 예시적인 생성 동작을 도시한다.
도 11은 RS 검색을 위한 예시적인 검색 동작을 도시한다.
도 12는 RS 업데이트/삭제를 위한 예시적인 업데이트/삭제 동작을 도시한다.
도 13은 RI에 의해 트리거링되는 예시적인 1회 추론을 도시한다.
도 14는 RI에 의해 트리거링되는 예시적인 연속적 추론을 도시한다.
도 15는 추론에 의해 지원되는 예시적인 증강 IDB를 도시한다.
도 16은 oneM2M 서비스 계층에 대한 예시적인 새로운 시맨틱 추론 서비스 CSF를 도시한다.
도 17은 FS 인에이블먼트에 대해 정의된 엔티티들에 대한 예시적인 oneM2M 예를 도시한다.
도 18은 RS 인에이블먼트에 대해 정의된 엔티티들에 대한 예시적인 oneM2M 예를 도시한다.
도 19는 개별 시맨틱 추론 동작에 수반되는 엔티티들에 대한 예시적인 oneM2M 예를 도시한다.
도 20은 개개의 시맨틱 추론 동작에 수반되는 엔티티들에 대한 예시적인 대안 예를 도시한다.
도 21은 추론 지원을 갖는 시맨틱 동작들을 최적화하도록 정의된 엔티티들에 대한 예시적인 oneM2M 예를 도시한다.
도 22는 추론 지원을 갖는 시맨틱 동작들을 최적화하도록 정의된 엔티티들에 대한 예시적인 대안 예를 도시한다.
도 23은 ETSI CIM과 oneM2M 사이의 추론 지원을 갖는 시맨틱 질의에 대한 예시적인 대안 예를 도시한다.
도 24는 <facts> 리소스의 예시적인 구조를 도시한다.
도 25는 <factRepository> 리소스의 예시적인 구조를 도시한다.
도 26은 <reasoningRules> 리소스의 예시적인 구조를 도시한다.
도 27은 <ruleRepository> 리소스의 예시적인 구조를 도시한다.
도 28은 <semanticReasoner> 리소스의 예시적인 구조를 도시한다.
도 29는 <reasoningRules> 리소스의 예시적인 구조를 도시한다.
도 30은 <reasoningResult> 리소스의 예시적인 구조를 도시한다.
도 31은 도 13에 개시된 RI에 의해 트리거링되는 1회 추론의 예시적인 OneM2M 예를 도시한다.
도 32는 도 14에서 RI에 의해 트리거링되는 연속적인 추론의 예시적인 OneM2M 예를 도시한다.
도 33a는 도 15에서의 추론에 의해 지원되는 증강 IDB의 예시적인 OneM2M 예를 도시한다.
도 33b는 도 15에서의 추론에 의해 지원되는 증강 IDB의 예시적인 OneM2M 예를 도시한다.
도 34는 예시적인 사용자 인터페이스를 도시한다.
도 35는 시맨틱 추론 기능(SRF)의 예시적인 특징들을 도시한다.
도 36은 시맨틱 추론 기능의 예시적인 특징들을 도시한다.
도 37a는 개시된 주제가 구현될 수 있는 예시적인 M2M 또는 IoT 통신 시스템을 도시한다.
도 37b는 도 37a에 도시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처를 도시한다.
도 37c는 도 37a에 도시된 통신 시스템 내에서 이용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스를 도시한다.
도 37d는 도 37a의 통신 시스템의 양태들의 예시적인 컴퓨팅 시스템을 도시한다.

도 5에 도시된 바와 같은 스마트 도시 시나리오에서의 지능형 시설 관리 이용 사례를 고려한다. 대형 병원은 수년에 걸쳐 많은 빌딩들을 세웠다. 감시 및 시설 관리 목적을 시행하기 위해, 병원은 또한 그 빌딩들의 방들에 모니터링 카메라들을 설치하였다. 특히, 병원은 SL 기반 플랫폼(예컨대, oneM2M)을 채택하였다. 예를 들어, 각각의 빌딩(예컨대, 빌딩 1, 빌딩 2, 및 빌딩 3)은 MN-CSE(예컨대, MN-CSE(105), MN-CSE(106) 및 MN-CSE(107))를 호스팅하고, 빌딩 방들에 배치된 카메라들 각각은 빌딩의 대응하는 MN-CSE에 등록하고 SL 리소스 표현을 갖는다. 예를 들어, 빌딩-1의 방-109에 배치된 카메라-111은 예를 들어 oneM2M에서 정의된 바와 같은 리소스들의 <AE> 유형일 수 있는, 빌딩-1의 MN-CSE(105)에 <카메라-111> 리소스 표현을 가질 것이다. 시맨틱을 지원하기 위해, <카메라-111> 리소스는 시맨틱 주석부기들로서 일부 메타데이터를 이용하여 주석부기될 수 있다. 예를 들어, 일부 팩트들은 그 디바이스 유형 및 그 위치 정보를 설명하는데 이용될 수 있으며, 이는 예로서 다음의 2개의 RDF 트리플로서 작성된다:

· 팩트-1: 카메라-111은 카메라이다("카메라"는 온톨로지에 의해 정의되는 개념/클래스이다).

· 팩트-2: 카메라-111은 빌딩-1의 방-109에 위치된다.

도메인 내의 각각의 개념의 경우, 이것은 그 도메인 온톨로지에서의 클래스에 대응한다. 예를 들어, 대학 맥락에서, 교사는 개념이고, 이어서 "교사"는 대학 온톨로지에서의 클래스로서 정의된다. 각각의 카메라는 시맨틱 자식 리소스(예컨대, oneM2M <semanticDescriptor> 리소스)에 저장되는 시맨틱 주석부기를 가질 수 있다. 따라서, 상이한 oneM2M 리소스들이 그들 자신의 시맨틱 주석부기들을 가질 수 있기 때문에, 데이터의 시맨틱 유형은 MN-CSE들의 리소스 트리에 분포될 수 있다.

병원은 외부 사용자들(예를 들어, 소방서, 도시 건강 부서 등)이 또한 병원의 시설들 또는 디바이스들을 관리하고, 질의하고, 운영하고, 모니터링할 수 있도록 (예를 들어, 스마트 도시를 실현하기 위한 계획으로서) 그 시설들을 도시 인프라스트럭처에 통합한다.

각각의 병원 빌딩에서, 방들은 상이한 목적들을 위해 이용된다. 예를 들어, 일부 방들(예컨대, 방-109)은 혈액 시험 샘플들을 저장하기 위한 것인 반면 일부 다른 방들은 의료용 산소 실린더들을 저장하기 위한 것이다. 방들의 상이한 이용들로 인해, 병원은 몇 개의 "관리 구역들(MZ)"을 정의하였고, 각각의 구역은 다수의 방들을 포함한다. MZ들의 분할은 반드시 지리적 위치들에 기반하는 것은 아니지만, 특히, 이용 목적에 기반할 수 있다는 점에 유의한다. 예를 들어, MZ-1은 혈액 시험 샘플들을 저장하는 방들을 포함한다. 따라서, 이들 방들은 도시 건강 부서에 의해 더 관심을 받을 것이다. 즉, 도시 건강 부서는 MZ-1에 속하는 방들에 배치된 카메라들에 액세스하도록 요청할 수 있다. 유사하게, MZ-2는 의료용 산소 실린더들을 저장하는 방들을 포함한다. 따라서, 도시 소방서는 그 방들에 관심이 있을 수 있다. 따라서, 도시 소방서는 MZ-2에 속하는 방들에 배치된 카메라들에 액세스할 수 있다. 각각의 MZ 내의 방들은 병원 시설 팀에 의한 방 재배열 또는 재배정으로 인해 시간의 경과에 따라 변경될 수 있다. 예를 들어, 방-109는, 예를 들어 혈액 시험 샘플들을 더 이상 저장하지 않고, 의료용 산소 실린더들을 저장하는데 이용되기 시작할 때 MZ-2에 속할 수 있다.

잠재적 사용자가 MZ-1에 속하는 방들로부터 실시간 이미지들을 검색하기를 원하는 시나리오를 고려한다. 그렇게 하기 위해, 사용자는 먼저 다음의 SPARQL 문-1을 이용하여 이들 카메라들을 식별하기 위해 시맨틱 리소스 발견을 수행한다:

위의 내용을 염두에 두고, 본 개시내용에 의해 해결되는 잠재적인 문제들이 있다. 통상적으로, 리소스 발견 프로세스 동안, <카메라-111> 리소스는 발견 결과에는 포함되어야 하지만, 원하는 리소스로서 식별되지 않을 것이다. 그 이유는, 카메라-111이 MZ-1에 속하는 방에 실제로 배치되더라도, (<카메라-111>의 시맨틱 주석부기인) 팩트 "Device-1 is-located-in Room-109-of-Building-1"이 SPARQL 문-1 "?device monitors-room-in MZ-1"에서의 패턴과 일치할 수 없기 때문이다. 문제는 디바이스들의 종래의 시맨틱 주석부기가 물리적 위치들과 같은 하위 레벨 메타데이터를 종종 포함하고, MZ에 대한 상위 레벨 메타데이터를 포함하지 않는다는 팩트로부터 유래한다. 그러나, 사용자는 특정한 MZ(예컨대, MZ-1) 내의 방들에만 관심이 있을 수 있고 이들 방들의 물리적 위치들에 관심이 없을 수 있다. 위의 예를 참조하면, 사용자는 MZ-1에 속하는 방들에 배치된 카메라들로부터의 이미지들에만 관심이 있고, 사용자는 물리적 방 또는 빌딩 번호들에 관심이 꼭 있지는 않다. 실제로, 사용자는 방 배정 정보도 알지 못할 수 있다(예를 들어, 어느 방이 어느 목적을 위한 것인지, 이것은 단지 병원 시설 팀에 의해 관리되는 내부 정보일 수 있기 때문이다). 이와 같이, 추론 또는 추론 메커니즘들이 이러한 문제들을 해결하는데 이용될 수 있다. 예를 들어, 다음의 추론 규칙에 대한 지식을 이용한다:

· 규칙-1: A가 B 내에 위치되고, B가 C 하에서 관리되면, A는 C 내의 방을 모니터링한다.

팩트-1, 팩트-2 및 규칙-1을 이용함으로써, 새로운 팩트를 추론할 수 있다:

· 카메라-111은 MZ-1 내의 방을 모니터링한다.

이러한 새로운 팩트는 위의 SPARQL 문-1에 도시된 질의에 응답하는데 유용할 수 있다.

상위 레벨 질의는 하위 레벨 메타데이터와 직접 일치하지 않을 수 있고, 이러한 현상은 상위 계층 사용자로부터의 질의가 상위 레벨 개념(예컨대, 용어 또는 척도)에 기반하는 반면 하위 계층 물리적 리소스들이 하위 레벨 메타데이터로 주석부기된다는 점에서 많은 컴퓨터 과학 영역들에서 "추상화"의 이용으로 인해 매우 일반적이라는 점에 유의한다. 예로서, 사용자가 랩톱 상의 C: 디스크 내의 파일을 질의할 때, 운영 체제는 사용자에게 완전히 투명한, 하드 드라이브 상의 이 파일의 물리적 블록들을 찾아야 한다.

이용가능한 일부 기존의 시맨틱 추론 도구들이 존재하지만, 이들은 팩트 관점 및 추론 규칙 관점으로부터의 새로운 문제들로 인해 SL 기반 플랫폼의 컨텍스트에서 직접 이용될 수 없다. 팩트 관점에서, 데이터 또는 팩트들은 종종 상이한 장소들(예를 들어, 기존의 oneM2M <semanticDescriptor> 리소스들에서의 RDF 트리플들)에 단편화되거나 분포된다. 따라서, 추론 프로세스를 위한 입력들(예컨대, 팩트 세트들)을 준비하기 위해 관련된 "팩트 사일로들"을 조직화하거나 통합하기 위한 효율적인 방식이 본 명세서에 개시된다. 추론 규칙 관점에서, 서비스 계층(SL) 기반 플랫폼은 종종 상이한 섹션들에 걸쳐 애플리케이션들을 가능하게 하는 수평 플랫폼인 것으로 가정된다. 따라서, 상이한 맞춤화된 또는 사용자-정의된 규칙들은 애플리케이션 요건들 또는 요청들에 기반하여 정의될 수 있으며, 이는 (동일한 초기 팩트들에 기반하더라도) 상이한 추론된 팩트들을 초래할 수 있다.

이하는 문제들의 추가 설명이다. 팩트 관점에서 첫 번째 문제는 많은 경우들에서, 초기 입력 팩트들이 충분하지 않을 수 있고, 추가적인 팩트들이 추론 동작이 실행될 수 있기 전에 입력들로서 추가로 식별될 수 있다는 것이다. 팩트에서의 이러한 문제는 서비스 계층의 컨텍스트에서 악화되는데, 그 이유는 팩트들이 상이한 장소들에 "분포"될 수 있고 수집하기 어려울 수 있기 때문이다. 추론 규칙 관점에서 두 번째 문제는 통상적으로 SL 엔티티들이 다양한 애플리케이션들에 대한 추론을 지원하기 위해 사용자-정의된 추론 규칙들을 정의, 공개(예를 들어, 규칙 또는 팩트가 다른 것들에 의해 공유되도록 공개될 수 있음)하기 위한 어떠한 방법들도 없다는 것이다.

세 번째 문제는, 통상적으로, SL 엔티티들이 입력들로서 팩트들 및 규칙들을 지정함으로써 "개별" 추론 프로세스를 트리거링하기 위한 어떠한 방법들도 없다는 것이다. 그러나, 많은 애플리케이션들이 암시적 팩트들을 식별하기 위해 시맨틱 추론을 요구할 수 있기 때문에 추론이 요구되거나 요청될 수 있다. 예를 들어, 시맨틱 추론 프로세스는 공원 및 실외 활동 어드바이저 관련된 추론 규칙의 현재 실외 온도, 습도 또는 바람을 2개의 입력으로서 취할 수 있다. 추론 프로세스를 실행한 후에, "상위 레벨의 추론된 팩트"는 현재 실외 스포츠를 하기에 좋은 시간인지에 대해 산출될 수 있다. 이러한 상위 레벨의 추론된 팩트는 사용자들이 하위 레벨의 입력 팩트들(예컨대, 온도, 습도, 또는 바람 수치들)의 상세들을 알 필요가 없다는 점에서 사용자들에게 직접적으로 이익이 될 수 있다. 다른 이용 시나리오에서, 추론된 팩트들은 또한 원래의 팩트들을 증강시키는데도 이용될 수 있다. 예를 들어, 카메라-111의 시맨틱 주석부기는 초기에 카메라-111이 A:digitalCamera라는 것을 말하는 하나의 트리플(예컨대, 팩트)을 포함하고, 여기서 A:digitalCamera는 온톨로지 A에 의해 정의되는 클래스 또는 개념이다. 추론 프로세스를 통해, 추론된 팩트는 카메라-111이 B:highResolutionCamera라는 것과 같이, 카메라-111의 시맨틱 주석부기에 또한 추가될 수 있고, 여기서 B:highResolutionCamera는 다른 온톨로지 B에 의해 정의되는 클래스/개념이다. 이러한 증강에 의해, 카메라-111의 시맨틱 주석부기는 이제 더 풍부한 정보를 갖는다.

네 번째 문제는, 통상적으로, (시맨틱 질의, 시맨틱 리소스 발견 등과 같은) 다른 시맨틱 동작들을 최적화하기 위한 "배경 지원"으로서 시맨틱 추론을 활용하기 위한 제한된 지원이 있다는 것이다. 이 경우, 사용자들은 단지 그들이 특정 시맨틱 동작(예를 들어, 시맨틱 질의 또는 시맨틱 리소스 발견 등)을 개시하고 있다는 것을 알 수 있다. 그러나, 이 동작의 처리 동안, 시맨틱 추론은 사용자들에게 투명한 배경에서 트리거링될 수 있다. 예를 들어, 사용자는 현재 공원에서의 실외 스포츠 추천들에 대한 시맨틱 질의를 개시할 수 있다. 처리 엔진이 공원의 현재 실외 온도, 습도, 또는 바람 데이터와 같은 원시 팩트들을 단지 갖는 경우, 질의는 응답되지 않을 수 있는데, 그 이유는 SPARQL 질의 처리가 패턴 일치에 기반하기 때문이다(예컨대, 그 일치는 대개 정확해야만 한다). 대조적으로, 이러한 원시 팩트들이 추론을 통해 상위 레벨의 팩트(예컨대, 현재 스포츠를 하기에 좋은 시간인지 여부)를 추론하는데 이용될 수 있는 경우, 이러한 추론된 팩트는 사용자의 질의에 직접 응답할 수 있다.

기존의 서비스 계층은 시맨틱 추론을 가능하게 하는 능력을 갖지 않으며, 이것 없이는 다양한 시맨틱 기반 동작들이 효과적으로 동작될 수 없다. 시맨틱 추론이 효율적이고 효과적으로 지원되기 위해 본 명세서에 개시된 시맨틱 추론 연관 방법들 및 시스템들 중 하나 이상이 구현되어야 한다. 요약하면, 도 6을 참조하면, 이러한 방법들 및 시스템들은 다음의 3개의 부분을 수반할 수 있다: 1) 블록(115) - 시맨틱 추론 데이터의 관리를 가능하게 하는 것(예컨대, 팩트들 및 규칙들을 참조함); 2) 블록(120) - 개별 시맨틱 추론 프로세스를 가능하게 하는 것; 및 3) 블록(125) - 배경 추론 지원으로 다른 시맨틱 동작들을 최적화하는 것. 블록(115)(부분 1)은 팩트 세트 및 규칙 세트가 서비스 계층에서 이용가능하도록 시맨틱 추론 데이터를 어떻게 가능하게 하는지에 초점을 맞춘다. 팩트 세트(FS) 및 규칙 세트(RS)가 가능하게 되고, 시맨틱 추론기(SR)가 가능하게 될 때, 블록(120)(부분 2)에서 개별 시맨틱 추론 프로세스가 개시될 수 있고, 여기서 미래의 추론 동작들에서의 입력에 대해 추론된 결과가 다시 이용될 수 있다. 마지막으로, 블록(125)(부분 3)에서, 개시된 시맨틱 추론은 시맨틱 동작들(예컨대, 시맨틱 질의, 시맨틱 리소스 발견, 시맨틱 매시업 등)을 더 효율적이고 효과적으로 실행하는데 이용될 수 있다. 전술한 방법들 및 시스템들 각각은 본 명세서에서 더 상세히 개시된다.

도 7 내지 도 15와 같은, 본 명세서에 예시되는 단계들을 수행하는 엔티티들이 논리적 엔티티들일 수 있다는 것이 이해된다. 이 단계들은 도 37c 또는 도 37d에 예시된 것들과 같은 디바이스, 서버, 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행될 수 있다. 예로서, M2M 디바이스들의 상호작용과 관련된 아래의 추가 상세에 있어서, 도 33a의 AE(331)는 도 37a의 M2M 단말 디바이스(18) 상에 존재할 수 있고, 도 33a의 CSE(332) 및 CSE(333)는 도 37a의 M2M 게이트웨이 디바이스(14) 상에 존재할 수 있다. 본 명세서에 개시된 예시적인 방법들(예컨대, 도 7 내지 도 15) 사이에 단계들을 스킵하는 것, 단계들을 조합하는 것, 또는 단계들을 추가하는 것이 고려된다.

SL에서 팩트들 및 추론 규칙들을 공개, 업데이트 및 공유하는 방법이 아래에 개시된다(블록(115) - 부분 1). 다음의 데이터 엔티티들이 정의되었다: 팩트 세트(FS) 및 규칙 세트(RS). 팩트 세트(FS)는 팩트들의 세트이다. FS가 시맨틱 추론에 관여하는 경우, FS는 InputFS 또는 InferredFS에 의해 추가로 분류될 수 있다. 특히, InputFS(블록(116))는 특정한 추론 동작에 대한 입력들로서 이용되는 FS이고, InferredFS(블록(122))는 시맨틱 추론 결과이다(예컨대, InferredFS는 추론된 팩트들을 포함한다). 추론 동작 A에 의해 생성된 InferredFS(블록(122))는 (도 6에 도시된 바와 같이) 추후/장래 추론 동작들을 위한 InputFS로서 이용될 수 있다. InputFS는 또한 Initial_InputFS 및 Addi_InputFS에 의해 분류될 수 있다(예컨대, 도 13 참조). Initial_InputFS는 시맨틱 추론 동작을 트리거링하기 위해 시맨틱 추론기(SR)에 요청을 전송할 때 추론 개시자(RI)에 의해 제공될 수 있다. Addi_InputFS는 추가적인 팩트들이 시맨틱 추론 동작에서 이용되어야 하는 경우 SR에 의해 추가로 제공되거나 결정된다. 이하의 설명들에서, 일반 용어 FS는 복수의 유형들의 팩트 세트들을 커버하는데 이용될 수 있다. 규칙 세트(RS - 예컨대, RS(117))는 추론 규칙들의 세트이다. RS는 또한 Initial_RS 및 Addi_RS에 의해 분류될 수 있다. 예를 들어, Initial_RS는 시맨틱 추론 동작을 트리거링하기 위해 SR에 요청을 전송할 때 RI에 의해 제공된다. Addi_RS는 추가적인 규칙들이 시맨틱 추론 동작에서 이용되어야 하는 경우 SR에 의해 추가로 제공되거나 결정된다. Initial_InputFS는 추론 개시자(RI)에 의해 제공되는 FS를 지칭한다. 예를 들어, RI가 SR에 추론 요청을 전송할 때, RI는 어떤 팩트들이 추론 입력으로서 일 것인지를 나타낼 수 있고, 이러한 팩트들은 Initial_InputFS로서 고려될 것이다. 다음으로, SR은 Initial_InputFS가 충분하지 않다는 것을 발견할 수 있고, 입력들로서 더 많은 팩트들을 포함할 수 있고, 이는 Addi_InputFS로서 고려될 것이다.

FS 관점으로부터, 서비스 계층에서, 데이터는 리소스들 및 팩트들이 상이한 장소들에서 단편화되거나 분포됨에 따라 정상적으로 노출된다. 팩트들은 정상 SL 리소스들의 시맨틱 주석부기들(예컨대, 상이한 <semanticDescriptor> 리소스들에서의 RDF 트리플들)에 제한되지 않고, 팩트들은 또한 (예를 들어, 공개된) 서비스 계층에서 이용가능하게 될 수 있고 다른 것들에 의해 저장되거나 액세스될 수 있는 임의의 정보 또는 지식을 지칭할 수 있다. 예를 들어, FS의 특별한 경우는 oneM2M에 정의된 <ontology> 리소스에 저장될 수 있는 온톨로지일 수 있다.

RS 관점으로부터, SL 기반 플랫폼은 종종 상이한 도메인들에 걸쳐 애플리케이션들을 가능하게 하는 수평 플랫폼인 것으로 가정된다. 따라서, 상이한 RS들은 상이한 애플리케이션들을 지원하기 위해 (예를 들어, 공개된) 서비스 계층에서 이용가능하게 될 수 있고 다른 것들에 의해 저장되거나 액세스될 수 있다. 예를 들어, 공원에서의 현재 실외 온도, 습도, 또는 바람을 설명하는 InputFS의 경우, 실외 활동 어드바이저 관련 추론 규칙은 (바로 소화될 수 있는) 지금 실외 스포츠를 하기에 좋은 시간인지의 상위 레벨의 팩트를 추론하는데 이용될 수 있다. 이와 비교하여, 스마트 잔디 물주기 관련 규칙은 현재의 물주기 스케줄이 바람직한지의 팩트를 추론하는데 이용될 수 있다. 전체적으로, 블록(115 - 부분 1)은 서비스 계층에서 이용가능한 FS 또는 RS 및 그들의 관련된 CRUD(생성, 판독, 업데이트, 및 삭제) 동작들을 어떻게 하는지에 관하여 시맨틱 추론 데이터를 가능하게 하는 방법과 연관된다.

이 섹션은 FS 인에이블먼트에 대한 CRUD 동작들을 도입하여, 주어진 FS(InputFS 및 InferredFS 경우들 모두를 커버함)가 공개, 액세스, 업데이트, 또는 삭제될 수 있도록 한다.

다음의 절차들에서, 일부 "논리적 엔티티들"이 관여되고, 그들 각각은 대응하는 역할을 갖는다. 이들은 다음과 같이 열거된다:

· 팩트 제공자(FP): 이것은 주어진 FS를 생성하고 SL에서 이용가능하게 하는 엔티티(예를 들어, oneM2M AE 또는 CSE)이다.

· 팩트 호스트(FH): 이것은 주어진 FS를 호스팅할 수 있는 엔티티(예를 들어, oneM2M CSE)이다.

· 팩트 수정자(FM): 이것은 기존 FS 상에서 수정 또는 업데이트들을 행하는 엔티티(예를 들어, oneM2M AE 또는 CSE)이다.

· 팩트 소비자(FC): 이것은 SL에서 이용가능한 주어진 FS를 검색하는 엔티티(예를 들어, oneM2M AE 또는 CSE)이다.

따라서, 상이한 물리적 엔티티들은 위에서 정의된 바와 같이 상이한 논리적 역할들을 취할 수 있다. 예를 들어, AE는 FP일 수 있고, CSE는 FH일 수 있다. oneM2M CSE와 같은 하나의 물리적 엔티티는 위에서 정의된 바와 같은 복수의 역할을 취할 수 있다. 예를 들어, CSE는 FP뿐만 아니라 FH일 수 있다. AE는 FP일 수 있고 나중에 또한 FM일 수 있다.

도 7은 FS 공개에 대한 생성 동작을 위한 예시적인 방법을 도시한다. 도 7에 도시된 바와 같이, FS-1을 공개하는 것과 관련되는 FP(131) 및 FH(132)가 있을 수 있다. 단계(140)는 공개 방법에 대한 전제 조건일 수 있다. 단계(140)에서, FP(131)는 FS-1로 표시되는 팩트들의 세트를 갖는다. FP(131)는 FS-1이 시스템에서 이용가능하게 하도록 의도한다(예를 들어, 트리거에 기반하여 결정한다). 예를 들어, 가능한 트리거는 FS-1이 외부 엔티티들에 이용가능하게 될 수 있다면, 이것은 FS-1을 서비스 계층에 공개하도록 FP(131)를 트리거링할 수 있다는 것이다. 단계(141)에서, FP(131)는 공개를 위해 FS-1을 FH(132)에 전송한다. FS는 일반적으로 몇몇 형태들을 가질 수 있다는 점에 유의한다. 예를 들어, FS-1은 주어진 이용 사례(예컨대, 병원, 도시 소방서, 빌딩, 방들 등과 같이, 본 명세서에 개시된 바와 같은 스마트 도시 이용 사례, 여기서 많은 도메인 개념들 및 그 관계가 정의됨)에 대한 도메인 지식을 설명하는 온톨로지를 지칭할 수 있다. 다른 예로서, FS-1은 특정 인스턴스들과 관련된 팩트들을 지칭할 수 있다. 여전히 도 5의 이전 예를 이용하여, FS는 그 빌딩, 방 배열, 배정 정보와 같은 병원의 현재의 관리 구역 정의들을 설명할 수 있다(예컨대, 관리 구역 MZ-1은 빌딩-1에서의 방-109, 빌딩-3에서의 방-117 등과 같은 혈액 시험 샘플들을 저장하는데 이용되는 방들을 포함한다). 이러한 유형의 팩트들의 경우, 이것은 시스템에 개별적으로 존재할 수 있다(예컨대, 다른 리소스들에 대한 시맨틱 주석부기들일 필요가 없다). 더욱이, FS는 또한 시스템에서 리소스, 엔티티, 또는 다른 것에 관한 시맨틱 주석부기들을 지칭할 수 있다. 도 5를 계속 참조하면, FS는 빌딩-1의 방-109에 배치되는 카메라-111의 시맨틱 주석부기들일 수 있다.

도 7을 계속 참조하면, 단계(142)에서, FH(132)는 FS-1이 그것에 저장될 수 있는지를 결정한다. 예를 들어, FH(132)는 FP(131)가 그렇게 할 적절한 액세스 권한을 갖는지를 체크할 수 있다. FS-1이 그것에 저장될 수 있는 경우, FH(132)는 FS-1을 저장할 것이고, 이는 시스템 내의 다른 엔티티들에 이용가능하게 될 수 있다. 예를 들어, 나중의 시맨틱 추론 프로세스는 FS-1을 입력으로서 이용할 수 있고, 그 경우, FS-1이 검색되고 처리를 위해 SR에 입력될 것이다. 주어진 FS에 관하여, 일부 유용한 정보(이 정보는 단계(141)에서 FP(131)에 의해 또는 다른 것들에 의해 제공될 수 있음)를 표시하기 위해 특정 정보가 또한 이 FS와 연관되거나 저장될 수 있다. 예를 들어, 이 정보는 관련된 온톨로지들 또는 관련된 규칙들을 포함할 수 있다.

관련된 온톨로지들을 참조하여, FS-1에 저장된 팩트들은 특정 온톨로지들에 의해 정의되는 개념들 또는 용어들을 이용할 수 있고, 따라서 어느 온톨로지들이 (그 RDF 트리플들에서의 주어/술어/목적어의 의미가 정확하게 해석될 수 있도록) 이들 팩트들에 관여되는지를 표시하는 것이 유용하다. 예를 들어, FS-1에 저장된 다음의 팩트들을 고려한다:

· 팩트-1: 카메라-111은 빌딩-1의 방-109에 위치한다.

· 팩트-2: 빌딩-1의 방-109는 MZ-1 하에 관리된다.

FS-1에서의 팩트들은, 특정 온톨로지에 의해 정의되는 어휘들 또는 특성들일 수 있는, "~에 위치한다" 또는 "~에 의해 관리된다"와 같은 일부 용어들을 이용한다는 것이 관찰될 수 있다.

관련 규칙들을 참조하여, FS-1에 저장된 팩트들이 잠재적으로 특정 추론 규칙들을 갖는 추론에 이용될 수 있는 것이 또한 가능하며, 따라서 어느 잠재적인 RS들이 추론을 위해 이 FS-1에 대해 적용될 수 있는지를 표시하는 것이 또한 유용하다. 이러한 규칙들은 그것이 의미가 있는 한 이 FS-1에 다른 규칙들도 적용될 수 있다는 점에서 제안들일 뿐이라는 점에 유의한다. RS-1에 저장된 다음의 추론 규칙을 고려한다:

· 규칙-1: A가 B에 위치하고, B가 C 하에 관리되면, A는 C 내의 방을 모니터링한다.

RS-1에서의 규칙(규칙-1)은 FS-1에 저장된 팩트들(팩트-1 및 팩트-2)에 걸쳐 적용될 수 있다. 단계(143)에서, FH(132)는 FS-1이 이제 FH(132)에 저장되어 있다는 것을 확인응답한다.

도 8은 FS 검색에 대한 검색 동작을 위한 예시적인 방법을 도시한다. 도 8에 도시된 바와 같이, FH(132)에 저장된 FS-1을 검색할 수 있는 FC(133)가 존재할 수 있다. 단계(150)에서, 검색 방법에 대한 전제 조건이 있을 수 있다. 단계(150)에서, FC(133)는 FH(132) 상에서 리소스 발견 동작을 수행하였고 관심있는 FS(예컨대, FS-1)를 식별하였다. 도 5의 이전 예를 여전히 이용하면, FS-1이 그 방 배정 정보와 같은 병원의 현재 관리 구역 정의들을 기술하면, 이것은 추론 프로세스 동안에 SR에 의해 이용될 수 있다. 예를 들어, FS-1은 관리 구역 관련 정보가 아니라 물리적 위치 정보(예컨대, 방 및 빌딩 번호들)로만 주석부기되는 관심있는 카메라들을 식별하는데 유용할 수 있다. 사용자가 MZ-1에 속하는 방들에 배치된 카메라들을 찾고 있는 경우, 이러한 FS-1은 추론 프로세스를 통해 관련 카메라들을 식별하는데 유용할 것이다. 단계(151)에서, FC(133)는 FS-1을 검색하기 위한 요청을 FH(132)에 전송한다. 단계(152)에서, FH(132)는 FC(133)가 FS-1을 검색하는 것이 허용되는지를 결정한다. 이러한 경우, FH(132)는 FS-1의 콘텐츠를 FC(133)에 회신할 것이다. 단계(153)에서, FS-1의 콘텐츠가 FC(133)에 회신된다.

업데이트 또는 삭제 동작에 관하여, FM(134)은 도 9에 도시된 다음의 절차를 이용하여 FH(132) 상에 저장된 FS-1을 업데이트 또는 삭제할 수 있다. 단계(160)에서, 이전에 팩트들(FS-1)의 세트는 FH(132)에 의해 공개되거나 국부적으로 생성되었다. 이제, FM(134)은 FS-1에서 콘텐츠를 업데이트하고자 의도하거나(예를 들어, 트리거에 기반하여 결정하거나) 또는 FS-1을 삭제하고자 의도한다. 예를 들어, FM은 FS-1이 유효 기간이 지났다는 통지를 수신하였다면, 업데이트 또는 삭제가 트리거링된다. 도 5의 이전 예를 여전히 이용하면, FS-1이 그 방 배정 정보와 같은 병원의 관리 구역 정의들을 기술하는 것으로 가정하면, 병원이 방 배정을 재구성했다면 FS-1이 업데이트되도록 요구되거나 요청될 수 있다(예컨대, 이제 빌딩-1에서의 방 109는 혈액 샘플들을 저장하는데 이용되지 않고 다른 목적을 위해 이용되기 때문에 MZ-1에 더 이상 속하지 않는다). 단계(161)에서, FM(134)은 FS-1에 저장된 콘텐츠들을 수정하기 위한 업데이트 요청을 FH(132)에 전송하거나 FS-1을 삭제하기 위한 삭제 요청을 전송한다. 단계(162)에서, FH(132)는 이 업데이트 또는 삭제 요청이 (예를 들어, 특정 액세스 권한들에 기반하여) 허용될 수 있는지를 결정한다. 그렇다면, FS-1은 FM(134)으로부터 전송된 요청에 기반하여 업데이트 또는 삭제될 것이다. 단계(163)에서, FH(132)는 FS-1이 이미 업데이트되었거나 삭제되었다는 것을 확인응답한다. 대안적인 접근법으로서, FS에 저장된 팩트들이 RDF 트리플들의 형태인 경우, FS는 SPARQL 질의문을 이용하여 업데이트될 수 있다. 그렇게 하기 위해, 단계(161)에서, 업데이트 요청은 FS가 어떻게 업데이트되어야 하는지를 기술하는 SPARQL 질의문을 포함할 수 있다. 특히, 이 접근법에서, FS는 완전히 업데이트되거나 부분적으로 업데이트될 수 있는데, 이는 SPARQL 질의문이 어떻게 작성되는지에 의존한다. 대안적인 접근법의 예는, FM이 완전히 시맨틱 가능한 사용자이고 SPARQL 질의 언어를 알고 있을 때, FM이 그 업데이트 요건들 또는 요청들을 SPARQL 질의문의 형태로 직접 작성할 수 있는 것을 포함할 수 있다.

이 섹션은 주어진 RS가 공개되고, 액세스되고, 업데이트되고, 삭제될 수 있도록, RS 인에이블먼트를 위한 CRUD 동작들을 도입한다. RS 인에이블먼트는 일반적으로 맞춤화된 또는 사용자-정의된 규칙들을 지칭한다. 다음의 절차들에서, 일부 "논리적 엔티티들"이 관여되고, 그들 각각은 대응하는 역할을 갖는다. 이들은 다음과 같이 열거된다:

· 규칙 제공자(RP): 이것은 주어진 RS를 생성하고 SL에서 이용가능하게 하는 엔티티(예를 들어, oneM2M AE 또는 CSE)이다.

· 규칙 호스트(RH): 이것은 주어진 RS를 호스팅할 수 있는 엔티티(예를 들어, oneM2M CSE)이다.

· 규칙 수정자(RM): 이것은 기존의 RS에서 수정(예컨대, 업데이트)을 하는 엔티티(예를 들어, oneM2M AE 또는 CSE)이다.

· 규칙 소비자(RC): 이것은 SL에서 이용가능한 주어진 RS를 검색하는 엔티티(예를 들어, oneM2M AE 또는 CSE)이다.

따라서, 상이한 물리적 엔티티들은 위에서 정의된 바와 같이 상이한 논리적 역할들을 취할 수 있다. 예를 들어, AE는 RP일 수 있고, CSE는 RH일 수 있다. oneM2M CSE와 같은 하나의 물리적 엔티티는 위에서 정의된 바와 같은 복수의 역할을 취할 수 있다. 예를 들어, CSE는 RP뿐만 아니라 RH일 수 있다. AE는 RP일 수 있고, 나중에 또한 RM일 수 있다.

생성 동작에 관하여, RP(135)는 RS-1을 공개하고 그것을 도 10에 도시된 다음의 절차를 이용하여 RH(136) 상에 저장할 수 있다. 전제 조건으로서, 단계(170)에서, RP(135)는 RS-1로 표시되는 규칙들의 세트를 갖는다. RP(135)는 RS-1이 시스템에서 이용가능하게 하려고 의도한다. 가능한 트리거는, RS-1이 외부 엔티티들에 이용가능하게 될 수 있다면, FS-1을 서비스 계층에 공개하도록 RP(135)를 트리거링할 수 있다는 것이다. 단계(171)에서, RP(135)는 공개를 위해 RS-1을 RH(136)에 전송한다. 도 5의 이전 예를 여전히 이용하면, RS-1은 "A(예컨대, 카메라-111)가 B(예컨대, 빌딩-1의 방-109)에 위치하고, B가 C(예컨대, MZ-1) 하에 관리되면, A는 C 내의 방을 모니터링한다"라는 규칙을 포함할 수 있다. 이러한 규칙은 카메라를 특정한 MZ와 연관시킬 수 있는 새로운 팩트를 추론하는데 유용할 수 있다. 단계(172)에서, RH(136)는 RS-1이 특정 액세스 권한에 기반하여 그것에 저장될 수 있는지를 결정한다. RS-1이 그것에 저장될 수 있는 경우, RH(136)는 시스템 내의 다른 엔티티들에 이용가능한 RS-1을 저장할 수 있다. 예를 들어, 나중의 시맨틱 추론 프로세스는 RS-1을 입력으로서 이용할 수 있고, 그 경우, RS-1은 검색될 수 있고 처리를 위해 SR에 입력될 수 있다. 특정 정보는 또한 일부 유용한 정보를 표시하기 위해 이 RS와 연관되거나 저장될 수 있다. 이 정보는 단계(171)에서 RP(135)에 의해 또는 다른 것들에 의해 제공될 수 있다. 예를 들어, 이 정보는 관련된 온톨로지들 또는 관련된 팩트들을 포함할 수 있다. 관련된 온톨로지들에 관하여, RS에 저장된 규칙들이 특정 온톨로지들에 의해 정의되는 개념들 또는 용어들을 이용할 수 있는 것이 가능하며, 따라서, 어느 온톨로지들이 그 규칙들에 관여되는지를 표시하는 것이 유용하다. 예를 들어, RS-1에 저장된 다음의 사용자-정의된 추론 규칙을 고려한다:

· 규칙-1: A가 B에 위치하고, B가 C 하에 관리되면, A는 C 내의 방을 모니터링한다.

규칙-1은 "~에 위치한다" 또는 "~에 의해 관리된다"와 같은 일부 용어들을 사용하며, 이는 특정 온톨로지에 의해 정의되는 어휘들/특성들일 수 있다.

관련된 팩트와 관련하여, RS에 저장된 규칙들이 특정 유형의 팩트들에 대해 적용될 수 있는 것이 또한 가능하며, 따라서, 이 RS가 추론을 위해 어느 잠재적인 FS들에 적용될 수 있는지를 표시하는 것이 또한 유용하다. 유의할 점은, 이러한 팩트들이 이 RS가 FS에서 사용되는 용어들 및 RS에서 사용되는 용어들이 중첩하는 경우에 다른 팩트들에도 적용될 수 있다는 점에서 단지 제안들일 뿐이라는 점이다. 예를 들어, 다음의 2개의 팩트가 RDF 트리플들로서 설명되는 FS-1에 저장된다고 고려한다:

· 팩트-1: 카메라-111은 빌딩-1의 방-109에 위치한다.

· 팩트-2: 빌딩-1의 방-109는 MZ-1 하에 관리된다.

RS-1에서의 규칙(규칙-1)은 FS-1에 저장된 팩트들(팩트-1 및 팩트-2)에 대해 적용될 수 있는데, 그 이유는 예를 들어 "~에 위치한다" 또는 "~에 의해 관리된다" 등의 이러한 용어들과 같이, 팩트들에서 이용되는 온톨로지들과 규칙들에서 이용되는 온톨로지들 사이에 중첩이 있기 때문이다. 단계(173)에서, RH(136)는 RS-1이 이제 RH(136) 상에 URI와 함께 저장되는 것을 확인응답한다.

이 섹션에는 추론 규칙들이 어떻게 생성될 수 있는지가 도시되어 있다. 먼저, 다양한 애플리케이션 시나리오들 또는 요건들에 기반하여, 이전에 논의된 지능형 시설 관리 이용 사례에서 정의된 이러한 규칙들과 같은 다양한 애플리케이션-주도 추론 규칙들이 정의될 수 있다:

· 규칙-1: A가 B에 위치하고, B가 백업 전력을 구비하면, A는 백업 전력을 구비한다.

둘째, 추론 규칙들이 생성될 수 있는 다른 경우는 온톨로지 정렬 또는 매핑을 행할 때이다. 온톨로지 정렬 또는 온톨로지 일치는 온톨로지들 내의 개념들 사이의 대응관계들을 결정하는 프로세스이다. 예로서, 주어진 온톨로지 A 및 온톨로지 B에 대해, 온톨로지 매핑은 수행되지 않을 수 있고, 식별된 매핑들 중 하나는 온톨로지 A에서의 개념 또는 클래스 "레코드"가 온톨로지 B에서의 개념/클래스 "로그 레코드"와 동일하거나 같다는 것일 수 있다. 개념은 통상적으로 온톨로지에서 정의된 클래스에 대응한다. 따라서, 일반적으로, 개념 및 클래스는 동일한 것을 지칭한다. 여기서, "레코드"라고 불리는 클래스는 온톨로지 A에서 정의되고, "로그 레코드"라고 불리는 클래스는 온톨로지 B에서 정의된다. 따라서, 이 매핑은 (OWL에서 정의된 "sameAs" 술어를 이용하여) 이하의 트리플과 같은 RDF 트리플로서 설명될 수 있다:

· RDF 트리플-A: ontologyA:Record 　owl:sameAs ontologyB:LogRecord

아래에 제공되는 바와 같이, 이 RDF 트리플-A를 어떻게 더 이용하는지에 관한 복수의 방식들이 있다. 즉, RDF-A 트리플은 이미 2개의 온톨로지 사이의 매핑 결과이다. 이하에서는, 이 매핑 결과가 추가로 이용될 수 있는 예시적인 방식들의 논의이다. 제1 방식에서, RDF 트리플-A는 레코드(예컨대, 레코드-X)의 시맨틱 주석부기들에 추가될 수 있다. 예를 들어, 주어진 레코드-X에 대해, 초기에 그 시맨틱 주석부기는 다음과 같은 RDF 트리플(이는 레코드-X가 온톨로지 B에서의 LogRecord 개념/클래스의 인스턴스임을 보여줌)을 단지 포함한다:

· RDF 트리플-B: 레코드-X가 ontologyB:LogRecord이다.

따라서, 사용자가 다음의 SPARQL 질의문을 이용하여 시맨틱 발견을 수행하기를 원한다면:

· SELECT ?rec WHERE { ?rec is-a ontologyA:Record }

사용자는 발견 결과에서 레코드-X를 얻을 수 없는데, 그 이유는 위의 SPARQL 질의문이 (레코드-X가 ontologyB:LogRecord의 유형이고, 사용자가 레코드를 찾고 있는 동안, 이는 ontologyA:Record의 유형이기 때문에) 레코드-X의 시맨틱 주석부기와 일치할 수 없기 때문이다. 이 문제를 해결하기 위해, RDF 트리플-A를 레코드-X의 시맨틱 주석부기에 추가할 수 있다. 이후, 시맨틱 발견 동작 동안 위의 SPARQL 문을 처리할 때, 예를 들어, 레코드-X의 시맨틱 주석부기들에 대해 특정 추론 규칙들을 적용함으로써 추론이 트리거링될 수 있다:

· 규칙-2: uuu owl:sameAs vvv이고, Y가 uuu이면, Y는 vvv이다(여기서, "uuu", "vvv", "Y"는 모두 교체될 와일드카드들이다).

그 결과, 추론 결과는 다음과 같은 트리플이다:

· RDF 트리플-C: 레코드-X는 ontologyA:Record이다.

그 다음, 이러한 RDF 트리플-C는 원래 SPARQL 문(예컨대, 패턴 WHERE { ?rec is-a ontologyA:Record })과 일치할 수 있고, 마지막으로 레코드-X가 이 시맨틱 발견 동작 동안 식별될 수 있다.

두 번째 방식은 RDF 트리플-A를 추가 이용을 위해 추론 규칙으로 변환한다. 예를 들어, RDF 트리플-A는 다음과 같은 추론 규칙으로 표현될 수 있다:

· 규칙-3: Y가 ontologyB:LogRecord이면, Y는 ontologyA:Record이다.

그 후, 이러한 추론 규칙은 (예를 들어, 호스트 상에서 RS를 생성하기 위한 생성 동작을 이용하여) 본 개시내용에 정의된 바와 같은 RS 인에이블먼트 절차를 이용함으로써 서비스 계층에 저장될 수 있다. oneM2M에서, 이것은 규칙-3을 저장하기 위해 <reasoningRule> 리소스를 생성하기 위한 생성 동작을 이용할 수 있다는 것을 의미할 수 있다.

이전의 예(이전에 논의된 레코드-X 및 SPARQL 문)를 여전히 이용한다. 이 접근법에서는, RDF 트리플-A를 레코드-X의 시맨틱 주석부기에 추가하지 않는다. 대신에, 시맨틱 발견 동작 동안 위의 SPARQL 문을 처리할 때, 시맨틱 추론은 규칙-3을 이용하여 트리거링될 수 있다. 그 결과, 추론 결과는 RDF 트리플-C와 동일할 수 있다. 마지막으로, 레코드-X는 또한 이 시맨틱 발견 동작 동안 식별될 수 있다.

검색 동작에 관하여, RC(137)는 도 11에 도시된 다음의 절차를 이용하여 RH(136) 상에 저장된 RS-1을 검색할 수 있다. 전제 조건으로서, 단계(180)에서, RC(137)는 RH(136) 상에서 리소스 발견 동작을 수행하였고 관심있는 RS-1을 식별하였다. 예를 들어, RC(137)는 SR이고 RS-1을 이용하여 추론 동작을 행하려고 의도한다(예를 들어, 이 경우, SR은 RC의 논리적 역할을 취한다). 단계(181)에서, RC(137)는 RS-1을 검색하기 위한 요청을 RH(136)에 전송한다. 단계(182)에서, RH(136)는 RC(137)가 RS-1을 검색하도록 허용되는지를 결정한다. 만약 그렇다면, RH(136)는 RS-1의 콘텐츠를 RC(137)에 회신할 것이다. 단계(183)에서, RS-1의 콘텐츠가 FC(133)에 회신된다.

업데이트/삭제 동작에 관하여, RM(138)은 도 12에 도시된 다음의 절차를 이용하여 RH(136)에 저장된 RS-1을 업데이트 또는 삭제할 수 있다. 전제 조건으로서, 단계(190)에서, 이전에 규칙들의 세트(RS-1)가 RH(136)에 공개되었다. 이제, RM(138)은 RS-1에서 콘텐츠를 업데이트하고자 의도하거나(예컨대, 트리거에 기반하여 결정하거나) RS-1을 삭제하고자 의도한다. 예를 들어, 트리거는 RM(138)이 RS-1이 유효 기간이 지났다는 통지를 수신하였고, 이후 업데이트 또는 삭제될 필요가 있다는 것일 수 있다. 여전히 도 5의 이전 예를 이용하면, RS-1은 원래 단지 하나의 추론 규칙을 포함했다. 그러나, 디바이스 액세스 권한들에 관한 더 많은 팩트들을 추론하기 위해 새로운 추론 규칙이 추가될 수 있다. 예를 들어, 새로운 규칙은 "A(예컨대, 카메라-111)가 B(예컨대, 혈액 시험 샘플들을 저장하는 방들의 MZ-1) 하에 관리되고, B가 C(예컨대, 도시 건강 부서가 MZ-1을 인식함)에 노출되면, C는 A에 액세스하도록 허용된다(예를 들어, 카메라-111은 도시 건강 부서에 의해 액세스될 수 있다)"일 수 있다. 추론을 위해 이러한 새로운 규칙을 이용하여, 추론된 팩트는 디바이스들이 도시 건강 부서에 의해 액세스될 수 있는 것과 같은 질의에 응답하는데 이용될 수 있다. 단계(191)에서, RM(138)은 RS-1에 저장된 콘텐츠들을 수정하기 위한 업데이트 요청을 RH(136)에 전송하거나 RS-1을 삭제하기 위한 삭제 요청을 전송한다. 단계(192)에서, RH(136)는 특정 액세스 권한에 기반하여 이 업데이트/삭제 요청이 허용될 수 있는지를 결정한다. 만약 그렇다면, RS-1은 RM(138)으로부터 전송된 요청에 기반하여 업데이트/삭제될 것이다. 단계(193)에서, RH(136)는 RS-1이 이미 업데이트/삭제되었음을 확인응답한다.

이 부분은 개별 시맨틱 추론 프로세스를 가능하게 하기 위한 여러 방법들 및 시스템들을 도입한다. 제1 예시적인 방법은 1회 추론 동작과 연관될 수 있다. 이러한 동작을 위해, 추론 개시자(RI)는 일부 관심있는 InputFS 및 RS를 식별하였고, 일부 새로운 팩트들(예컨대, 지식)을 식별하기 위해 SR에서 추론 동작을 개시하기를 원한다. 제2 예시적인 방법은 연속적 추론 동작과 연관될 수 있다. 이 시스템에서, RI는 관련된 InputFS 및 RS에 대한 연속적 추론 동작을 개시하기 위해 요구되거나 요청할 수 있다. 그 이유는 InputFS 및 RS가 시간의 경과에 따라 변경(예컨대, 업데이트)될 수 있고, 따라서 이전에 추론된 팩트들이 더 이상 유효하지 않을 수 있다는 것이다. 따라서, 새로운 추론 동작이 최신 InputFS 및 RS를 통해 실행되고 더 신규한 추론된 팩트들을 낳아야 한다.

이전의 예를 이용하여, 시맨틱 추론 프로세스는 (InputFS로서의) 공원의 현재의 실외 온도/습도/바람 및 (RS로서의) 실외 활동 어드바이저 관련 추론 규칙을 2개의 입력으로서 취할 수 있다. 추론 프로세스를 실행한 후에, (InferredFS로서의) 상위 레벨 팩트는, 예를 들어, 지금이 실외 스포츠를 하기에 좋은 시간인지에 대해 추론될 수 있다. 여기서 "개별"이라는 단어는 시맨틱 추론 프로세스가 반드시 (시맨틱 리소스 발견, 시맨틱 질의 등과 같은) 다른 시맨틱 동작들과 연관되는 것은 아니라는 것을 의미한다. 시맨틱 추론 프로세스를 가능하게 하기 위해, 이것은 다음과 같은 다수의 문제들을 수반한다:

1. 이용할 InputFS가 무엇이며 어디서 이를 수집하는가?

2. 이용할 RS가 무엇이며 어디서 이를 수집하는가?

3. 누가 InputFS 및 RS 수집을 담당할 것인가? 예를 들어, 이것은 시맨틱 프로세스를 개시하는 애플리케이션 엔티티일 수 있거나, SR이 이를 처리할 수 있다.

4. RS에 의해 InferredFS가 생성되면, 이를 어디에 전달하거나 저장하는가?

이하의 개시된 방법들 및 시스템들은 전술한 문제들을 다룬다. FH 및 RH와 같은 일부 이전에 정의된 "논리적 엔티티들"이 여전히 수반된다. 또한, SR이 시스템에서 이용가능하고, 추론 개시자(RI)라고 불리는 새로운 논리적 엔티티는 추론 동작을 트리거링하기 위해 SR에 요청을 전송할 수 있는 것이다.

1회 추론과 관련된 이러한 시나리오에서, RI는 일부 관심있는 InputFS 및 RS를 식별하였고 일부 새로운 지식/팩트들을 발견하기 위해 SR에서 추론 동작을 개시하기를 원한다. 서비스 계층에서 1회 추론 동작을 트리거링하는 방식들을 제공하는 시스템들, 방법들 또는 장치들이 본 명세서에 개시된다. 도 13은 1회 추론 동작을 위한 예시적인 방법을 도시하고, 상세한 설명들은 다음과 같다. 단계(200)에서, 전제 조건으로서, RI(231)는 SR(232)의 존재를 알고 있다. RI(231)는 AE 또는 CSE일 수 있다. 발견을 통해, RI(231)는 FH(132) 상의 관심있는 팩트들의 세트(이 팩트 세트는 Initial_InputFS로 표시됨) 및 RH(136) 상의 일부 추론 규칙들(이 규칙 세트는 Initial_RS로 표시됨)을 식별하였다. RI(231)가 Initial_InputFS 부분을 먼저 식별할 수 있고, Initial_InputFS에 관한 더 많은 정보가 또한 이용가능한 경우(예를 들어, "관련 규칙" 정보가 또한 이용가능한 경우)(이는 추론을 위해 Initial_InputFS에 대해 어느 잠재적인 RS들이 적용될 수 있는지를 표시함), RI(231)는 이들 제안들로부터 일부 관심있는 규칙들을 직접 선택할 수 있는 것이 또한 가능하다. 본 개시내용 전반에 걸쳐 논의된 식별된 "관심있는" 팩트들 및 규칙들에 관하여, 추론 개시자(RI)는 팩트들 또는 추론 규칙들을 저장하는 oneM2M 리소스들을 식별하기 위해 기존의 시맨틱 리소스 발견을 이용할 수 있다. 일반적으로, 시맨틱 발견 요청에서, 시맨틱 필터 및 이 필터는 SPARQL 문을 운반할 수 있다. 이러한 SPARQL 문은 RI가 어떤 유형의 팩트들 또는 규칙들에 관심이 있는지를 나타낼 수 있다(즉, 요청 메시지는 특정 데이터에 관한 더 많은 정보에 대한 요청을 포함한다). 예를 들어, RI는 "도심의 가로등들에 관한 모든 팩트들(예컨대, 그 생산 연도, 그 브랜드, 그 위치 등)을 찾아주세요"라고 말할 수 있으며, 이것은 RI의 관심있는 팩트이다. RI는 또한, "가로등 유지 계획을 나타내는 추론 규칙들을 찾아주세요. 예를 들어, 규칙은 다음과 같이 작성될 수 있다: 가로등이 브랜드 X이거나 특정 도로에 있는 경우, 이 가로등은 지금 업그레이드될 필요가 있다"라고 말할 수 있으며, 이것은 RI의 관심있는 규칙이다. 그 후, RI(예를 들어, 도시 가로등 유지 애플리케이션)가 어느 가로등들이 업그레이드되어야 하는지를 알기를 원하는 경우(이것은 RI가 "~하려고 의도할" 때에 대한 예일 수 있음), 이 RI는 도 13에 도시된 바와 같은 추론 동작을 트리거링하기 위해 식별된 팩트들 및 규칙들을 이용할 수 있고, 추론 결과들은 업그레이드될 필요가 있는 가로등들의 리스트이다. 따라서, 요컨대, RI가 어떤 유형의 팩트들 또는 규칙들에 관심이 있는지는 애플리케이션 비즈니스 요구들에 의존할 수 있다.

예로서, RI(231)는 2개의 카메라(예컨대, 카메라-111, 카메라-112)에 관심이 있고, Initial_InputFS는 다음과 같은 2개의 카메라에 관한 여러 팩트들을 갖는다:

· 팩트-1: 카메라-111은 브랜드 이름 "XYZ"를 갖는다.

· 팩트-2: 카메라-112는 빌딩-1에 위치한다.

RI(231)는 또한 다음과 같은 규칙을 (Initial_RS로서) 식별하였고 이들 관심있는 카메라들에 관한 보다 암시적인 지식/팩트들을 발견하기 위해 추론을 위해 이를 이용하려고 의도한다:

· 규칙-1: A가 브랜드 이름 "XYZ"를 가지면, A는 백업 전력을 구비한다.

이들 Initial_InputFS 및 Initial_RS에 의해, 정전이 발생하더라도 7*24 모니터링 목적을 지원할 수 있도록 이들 카메라들이 백업 전력을 갖는지에 관한 일부 새로운 지식을 추론하는 것이 가능하다. 단계(201)에서, RI(231)는 일부 새로운 지식을 발견하기 위해 SR(232)에서 추론 동작/작업을 트리거링하도록 입력들로서 Initial_InputFS 및 Initial_RS를 이용하려고 의도한다(예를 들어, 트리거에 기반하여 결정한다). RI(231)가 추론 요청을 전송하기 위한 트리거는 RI(231)가 이전 발견 동작 동안 "비어있지 않은" 팩트들 및 규칙들의 세트를 수신하는 것일 수 있으며, 이것은 RI가 추론 요청을 전송하도록 트리거링할 수 있다. 즉, Initial_RS 및 Initial_FS가 비어 있지 않은 경우, 이것은 추론 요청을 전송하도록 RI(231)를 트리거링할 수 있다. 단계(202)에서, RI(231)는 Initial_InputFS 및 Initial_RS에 관한 정보(예컨대, 이들의 URI들)와 함께 추론 요청을 SR(232)에 전송한다. 예를 들어, 정보는 Initial_InputFS를 저장하기 위한 대응하는 FH(132)의 URI, Initial_RS를 저장하기 위한 대응하는 RH(136)의 URI를 포함한다. 단계(203)에서, RI(231)로부터 전송된 정보에 기반하여, SR(232)은 FH(132)로부터 Initial_InputFS-1을 그리고 RH(136)로부터 Initial_RS를 검색한다.

단계(204)에서, RI(231)에 의해 제공되는 입력들에 더하여, SR(232)은 또한 추가적인 FS 또는 RS가 이 시맨틱 추론 동작에서 이용될 수 있는지를 결정할 수 있다. SR(232)은 대안적인 FH 및 RH를 인식하는 경우, 추가적인 FS 또는 RS를 획득하기 위해 이들을 질의할 수 있다.

예를 들어, RI(231)가 단지 부분적인 팩트들 및 규칙들을 식별한 것이 가능하며(예컨대, RI(231)가 FH(234) 및 RS-2에 대해 발견을 수행하지 않았지만, RI(231)가 관심이 있는 FH(234) 및 RS-2에 대한 유용한 FS 및 RS가 또한 존재하며), 이는 SR이 새로운 지식을 추론하는 능력을 제한할 수 있다. 예를 들어, 단지 Initial_InputFS 및 Initial_RS에 의해, SR(232)은 단지 새로운 팩트의 하나의 단편을 낳을 수 있다:

· 추론된 팩트-1: 카메라-111이 백업 전력을 구비한다.

일반적으로, 이 단계(204)에서, SR(232)이 추가적인 팩트들 또는 추가적인 규칙들을 이용할지 여부는 상이한 구현 선택들을 가질 수 있다. 예를 들어, 제1 접근법에서, RI(231)는 단계(202)에서 SR(232)이 추가적인 팩트들 또는 규칙들을 추가할 수 있는지를 표시할 수 있다. 제2 접근법에서, RI(231)는 SR(232)이 추가적인 팩트들 또는 규칙들을 추가할 수 있는지를 단계(202)에서 표시하지 않을 수 있다. 대신에, SR(232)의 로컬 정책이 이러한 결정을 할 수 있다.

계속해서 단계(204)를 참조하면, 일반적으로, SR(232)이 어느 추가적인 FS 및 RS가 이용될 수 있는지를 결정하기 위한 다음과 같은 잠재적인 방식들이 존재할 수 있다. 이것은 SR(232) 상에 일부 로컬 정책들 또는 구성들을 설정함으로써 달성될 수 있다. 예를 들어:

· Initial_InputFS에 포함된 주어진 FS(예컨대, FS-1)에 대해, SR(232)은 FS-1과 연관된(예컨대, 저장된) 유용한 정보가 있는지 여부를 추가로 체크할 수 있다. 예를 들어, 정보는 어느 잠재적인 RS들이 추론을 위해 FS-1에 대해 적용될 수 있는지를 나타내는 "관련 규칙들"을 포함할 수 있다. 그 관련 규칙들의 임의의 부분이 Initial_RS에 포함되지 않았다면, RI(231)는 그 관련 규칙들 중 일부를 추가 규칙들로서 추가할지를 추가로 결정할 수 있다.

· Initial_RS에 포함된 주어진 RS(예컨대, RS-1)에 대해, SR(232)은 RS-1과 연관/저장된 유용한 정보가 있는지 여부를 추가로 체크할 수 있다. 예를 들어, 정보 중 하나는 어느 잠재적인 FS들에 RS-1이 적용될 수 있는지를 나타내는 "관련 팩트들"일 수 있다. 이들 관련 팩트들의 임의의 부분이 Initial_InputFS에 포함되지 않았다면, RI(231)는 그 팩트들 중 일부를 추가적인 팩트들로서 추가할지를 추가로 결정할 수 있다.

· SR(232)이 위에서 논의된 바와 같이 Initial_InputFS 및 Initial_RS로부터 유용한 정보를 얻을 수 없을 때, SR(232)은 또한 그 로컬 구성들 또는 정책들에 기반하여 액션들을 취할 수 있다. 예를 들어, SR(232)은 Initial_InputFS 또는 Initial_RS에서 사용되는 관심있는 용어들/개념들/술어들 또는 특정 온톨로지들을 보는 한, 더 많은 팩트들 또는 규칙들을 추가로 검색할 수 있도록 구성될 수 있다. 다시 말해서, SR(232)은 그 관심있는 키워드들을 기록하기 위해 로컬 구성 표를 유지할 수 있고, 각각의 키워드는 다수의 관련된 FS들 및 RS들과 연관될 수 있다. 따라서, 임의의 키워드(용어, 개념, 또는 술어)가 Initial_InputFS 및 Initial_RS에 나타난 경우, SR(232)은 이 키워드의 연관된 FS들 및 RS들을 찾기 위해 그 구성 표를 체크할 수 있다. 이러한 연관된 FS들 및 RS들은 잠재적으로 이들이 Initial_InputFS 및 Initial_RS에 포함되지 않았다면 이용될 수 있는 추가적인 FS들 및 RS들일 수 있다. 예를 들어, SR(232)이 팩트-2를 수신하고 팩트-2에 용어 "빌딩-1"이 나타난 것을 찾았을 때(예컨대, "빌딩-1"은 그 구성 표에서의 관심있는 용어 또는 키워드임), SR(232)은, 아래에 도시된 팩트-3과 같이, (예를 들어, 그 구성 표에서의 정보에 기반하여) 빌딩-1에 관한 추가적인 팩트들을 추가하기로 선택할 수 있다. 유사하게, SR(232)은 관심있는 술어 "~에 위치한다"가 팩트-2에서 나타나고, 관심있는 술어 "~를 구비한다"가 팩트-3에서 나타난다는 것을 찾기 때문에, 아래에 도시된 규칙-2와 같이 추가적인/더 많은 규칙들을 추가할 것이다:

· 팩트-3: 빌딩-1이 백업 전력을 구비한다.

· 규칙-2: A가 B에 위치하고, B가 백업 전력을 구비하면, A는 백업 전력을 구비한다.

· SR(232)은 또한 추가적인 FS 및 RS가 이용되어야 하는 RI(231)의 유형이 주어지도록 구성될 수 있다(예를 들어, RI의 유형에 의존하고; 예를 들어, RI가 VIP 사용자이면, 더 많은 FS는 고품질 추론 결과가 생성될 수 있도록 추론 프로세스에 포함될 수 있다).

여기서 단계(204)에서의 접근법들은 또한 도 14의 단계(214) 및 도 15의 단계(225)와 같은 후속 섹션들에서의 방법들에서 이용될 수 있다.

단계(205)에서, SR(232)은 FH(234)로부터 추가 FS(Addi_InputFS로 표시됨) 및 RH(235)로부터 추가 RS(Addi_RS로 표시됨)를 검색한다. 예를 들어, Addi_InputFS는 빌딩-1에 대해 위에 도시된 바와 같이 팩트-3을 갖고, Addi_RS는 위에 도시된 바와 같이 규칙-2를 갖는다. 추가적인 FS 및 RS와 팩트-2에 의해, SR(232)은 추론된 팩트-2를 낳을 수 있다:

· 추론된 팩트-2: 카메라-112가 백업 전력을 구비한다.

단계(206)에서, 모든 InputFS(예컨대, Initial_InputFS 및 Addi_InputFS) 및 RS(예컨대, Initial_RS 및 Addi_RS)에 의해, SR(232)은 추론 프로세스를 실행하고 InferredFS를 낳을 것이다. 앞서 언급된 바와 같이, 2개의 추론된 팩트(추론된 팩트-1 및 추론된 팩트-2)가 InferredFS에 포함될 것이다. 단계(207)에서, SR(232)은 InferredFS를 RI(231)에 다시 전송한다.

리프레셔로서, 개념은 교사, 학생, 과목과 같은 온톨로지에서의 클래스와 같고, 이들은 모두 대학 온톨로지에서의 개념들이다. 술어는 클래스 사이의 "관계"를 설명하며, 예를 들어 교사가 과목을 "가르친다". "풀-타임"과 같은 용어는 종종 모두에게 이해되는 도메인 내의 키워드들이다. 다음의 RDF 트리플들을 (주어-술어-목적어의 면에서) 고려한다:

RDF 트리플 1: 잭은 교사이다(여기서, 교사는 클래스이고, 잭은 클래스 교사의 인스턴스이다).

RDF 트리플 2: 잭은 과목-232를 가르친다(여기서, 이 RDF 트리플에서의 가르친다가 술어이다).

RDF 트리플 3: 잭은 "풀 타임"의 직장 상태를 갖는다(여기서, "풀-타임"은 모두에게 알려진 용어이다).

도 13에 도시된 절차의 몇몇 대안들이 또한 다음과 같이 정의된다(대안들은 별개로 고려될 수 있다). 단계(201)에 대한 대안-1에서, RI(231)는 Initial_InputFS 및 Initial_RS를 식별하기 위해 발견을 할 필요가 없다. 대신에, RI(231) 자체는 그 자체로 Initial_InputFS 및 Initial_RS를 생성하고 이들을 SR(232)에 전송할 수 있다(이 경우, 단계(203)는 요구되지 않는다).

단계(201)에 대한 대안-2에서, RI(231)는 사용자-정의된 추론 규칙 세트를 이용할 필요가 없다. 대신에, RI(231)는 또한 기존의 표준 추론 규칙들을 이용할 수 있다. 예를 들어, SR(232)은 RDFS 함의, OWL 함의 등과 같은 특정 W3C 함의 체제들에 의해 정의되는 바와 같은 추론 규칙들의 전부 또는 일부에 기반하여 추론을 지원할 수 있는 것이 가능하다(예를 들어, 이 경우에 Initial_RS는 이들 표준 추론 규칙들을 지칭할 수 있다). 그렇게 하기 위해, RI(231)는 RI(231)가 처음으로 SR(232)을 발견할 때, 어떤 표준 추론 규칙들 또는 함의 체제들을 지원할 수 있는지를 SR(232)에 문의할 수 있다.

대안-3, 단계(202)에 대한 대안에서, RI(231)는 Initial_InputFS 및 Initial_RS에 대한 위치 정보만을 전송할 수 있다. 그 후, SR(232)은 RI(231)를 대신하여 Initial_InputFS 및 Initial_RS를 검색할 수 있다.

대안-4는 시맨틱 추론 동작이 소정 시간을 취할 수 있다는 팩트를 고려하여 시맨틱 동작을 트리거링하기 위한 비-블록 기반 접근법이 또한 지원될 수 있다는 것이다. 예를 들어, 단계(203) 이전에, SR(232)은 RI(231)로부터 전송된 요청에 대한 수락에 대한 신속한 확인응답을 먼저 다시 전송할 수 있다. 그리고, SR(232)은 추론 결과(예컨대, InferredFS)를 산출한 후에, 단계(207)에 도시된 바와 같이 InferredFS를 RI(231)에 다시 전송할 것이다. 블록-기반 접근법에서, RI가 SR에 요청을 전송할 때, SR이 추론 결과를 산출하기 전에, SR은 RI에 임의의 응답을 다시 전송하지 않을 것이라는 점에 유의한다. 이에 비해, 비-블록 접근법에서, SR이 추론 요청을 수신할 때, SR은 RI에 신속한 확인응답을 다시 전송할 수 있다. 이어서, 나중에, SR은 추론 결과를 산출할 때, 추론 결과를 RI에 추가로 전송할 수 있다.

대안-5, 단계(207)에 대한 다른 대안에서는, InferredFS가 RI(231)에 회신될 필요가 없다. 대신에, 이것은 요건들 또는 계획된 이용에 기반하여 특정 FH들에 저장될 수 있다. 예를 들어:

1. SR(232)은 Initial_InputFS가 이전보다 "증강"될 것이도록 Initial_InputFS와 InferredFS를 통합할 수 있다. 이것은 Initial_InputFS가 디바이스의 시맨틱 주석부기인 경우에 유용하다. InferredFS에 의해, 시맨틱 주석부기는 더 풍부한 정보를 가질 수 있다. 예를 들어, 처음에, Initial_InputFS는 "카메라-111이 OntologyA: VideoCamera이다"라는 팩트를 단지 설명할 수 있다. 추론을 수행한 후에, 추론된 팩트가 생성(카메라-111이 OntologyB:DigitalCamera임)되고, 이는 또한 카메라-111의 시맨틱 주석부기로서 추가될 수 있다. 이러한 방식으로, 카메라-111은 (추론 지원 없이도) 나중의 발견 동작들에서 성공적으로 식별될 더 나은 기회를 가지며, 이는 온톨로지 A에서 정의된 개념 "VideoCamera" 또는 온톨로지 B에서 정의된 개념 "DigitalCamera"를 이용한다.

2. SR(232)은 FH(132) 상에 또는 로컬로 SR(232) 상에 InferredFS를 저장하기 위한 새로운 리소스를 생성할 수 있고, SR(232)은 FH(132) 상에 InferredFS의 리소스 URI 또는 위치를 단지 회신할 수 있다. 이것은, Initial_InputFS가 디바이스의 일부 하위 레벨 시맨틱 정보를 설명하는 반면, InferredFS는 일부 상위 레벨 시맨틱 정보를 설명하는 경우에 유용하다. 예를 들어, Initial_InputFS는 "카메라-113이 방 147에 위치한다"라는 팩트를 단지 설명할 수 있고, InferredFS는 "카메라-113이 환자-메리를 모니터링한다"라는 팩트를 설명할 수 있다. 이러한 상위 레벨 지식은 카메라-113의 하위 레벨 시맨틱 주석부기들과 통합되지 않아야 한다.

대안-6의 경우, 개시된 방법들에서, 특정 규칙 세트 또는 팩트 세트(예컨대, Initial_InputFS, Addi_InputFS, Initial_RS, Addi_RS)가 하나의 FH(132) 또는 하나의 RH(136)로부터 검색되는 경우를 고려하는데, 이는 단지 더 쉬운 제시를 위한 것이라는 점에 유의한다. 일반적으로, Initial_InputFS(그리고 이와 유사하게 Addi_InputFS)는 복수의 FH들 상에 호스팅되는 복수의 FS들에 의해 구성될 수 있다. Initial_RS(그리고 이와 유사하게 Addi_RS)는 복수의 RH들 상에 호스팅되는 복수의 RS들에 의해 구성될 수 있다. 위의 대안들 모두가 본 명세서에 개시된 바와 같은 다른 유사한 방법들(예컨대, 도 14의 방법)에도 적용될 수 있다는 점에 유의한다.

연속적인 추론 동작: 이 시나리오에서, RI(231)는 관련된 FS 및 RS를 통해 연속적인 추론 동작을 개시할 수 있다. 그 이유는 때때로 InputFS 및 RS가 시간의 경과에 따라 변경/업데이트될 수 있고, 따라서 이전 추론된 팩트들이 더 이상 유효하지 않을 수 있기 때문이다. 따라서, 새로운 추론 동작은 최신 InputFS 및 RS를 통해 실행될 수 있고, 더 신규한 추론된 팩트들을 낳을 수 있다. 도 14는 연속적인 추론 동작을 위한 예시적인 방법들을 도시하고, 상세한 설명들은 다음과 같다. 단계(210)에서, 전제 조건으로서, RI(231)는 SR(232)의 존재를 알고 있다. 발견을 통해, RI(231)는 FH(132) 상의 관심있는 팩트들의 세트(이 팩트 세트는 Initial_InputFS로 표시됨) 및 RH(136) 상의 일부 추론 규칙들(이 규칙 세트는 Initial_RS로 표시됨)을 식별하였다. 단계(211)에서, RI(231)는 Initial_InputFS 및 Initial_RS를 이용하여 "연속적인" 시맨틱 추론 동작을 개시하려고 의도한다(예컨대, 트리거에 기반하여 결정한다). 예로서, RI(231)가 추론 요청을 전송하는 트리거는 RI(231)가 이전 발견 동작 동안에 팩트들 및 규칙들의 "비어있지 않은" 세트를 수신하는 것일 수 있다. 한편, 식별된 팩트들 또는 규칙들은 시간의 경과에 따라 변경될 수 있고, 이후 RI(231)를 트리거링하여 연속적인 추론 동작을 위한 요청을 전송할 수 있다. 단계(212)에서, RI(231)는, Initial_InputFS 및 Initial_RS에 관한 정보와 함께, 추론 요청을 SR(232)에 전송한다. 요청 메시지는 새로운 파라미터 추론 유형(rs_ty)을 포함할 수 있다는 점에 유의한다. 추론 유형(rs_ty)은 RI(231)가 어떤 유형의 추론 동작을 요구하는지를 나타낸다. 예를 들어, rs_ty=0은 (이전 섹션에서 논의된 바와 같은) 1회 추론 동작을 의미하고, rs_ty=1은 연속적인 추론 동작을 의미한다. 대안적으로, rs_ty가 요청 메시지에 존재하지 않을 때, 이것은 1회 추론 요청으로서 취급될 것이다.

단계(213)에서, RI(231)로부터 전송된 정보에 기반하여, SR(232)은 FH(132)로부터 Initial_InputFS 및 RH(136)로부터 Initial_RS를 검색한다. SR(232)은 또한 임의의 변경들에 대한 통지를 위해 이들에 가입한다. 단계(214)에서, RI(231)에 의해 제공되는 입력들에 더하여, SR(232)은 또한 추가적인 FS 또는 RS가 이 시맨틱 추론 동작에서 이용될 수 있는지를 결정할 수 있다. 단계(215)에서, SR(232)은 FH(234)로부터 추가 FS(Addi_InputFS로서 표시됨) 및 RH(235)로부터 추가 RS(Addi_RS로 표시됨)를 검색하고, 또한 이들에 가입한다.

단계(216)에서, SR(232)은 모든 InputFS(예컨대, Initial_InputFS 및 Addi_InputFS) 및 RS(예컨대, Initial_RS 및 Addi_RS)를 포함하는 추론 작업(RJ-1로 표시됨)을 생성한다. 그 후, RJ-1이 실행되고, InferredFS를 낳을 것이다. 그 후, Initial_InputFS, Addi_InputFS, Initial_RS 및 Addi_RS 중 임의의 것이 변경되는 한, RJ-1이 다시 실행되도록 트리거링할 것이다. 대안적으로, SR(232)은 또한 이들 리소스들을 주기적으로 체크하고 업데이트가 있는지를 알아보기로 선택할 수 있다. 다른 대안으로서, RI(231)는 또한 RJ-1의 최신 추론 결과를 얻기 위해 선행적으로 그리고 패러디적으로 요청을 전송할 수 있고, 이 경우에, SR(232)이 RI(231)로부터 요청을 수신할 때마다, SR(232)은 또한 이들 리소스들을 체크하고 업데이트가 있는지(그렇다면, 새로운 추론이 트리거링될 것임)를 알아보기로 선택할 수 있다.

단계(217)에서, FH(132)는 Initial_InputFS 상의 변경들에 관한 통지를 전송한다. 단계(218)에서, SR(232)은 Initial_InputFS에 대한 최신 데이터를 검색하고, 이어서 RJ-1에 대한 새로운 추론 프로세스를 실행하고 새로운 InferredFS를 낳을 것이다. 단계(217) 내지 단계(218)는 관련 FS 및 RS(예컨대, 이 예에서 도시된 Initial_InputFS)에 대한 변경들을 고려하기 위해 초기 시맨틱 추론 프로세스 후에 연속적으로 동작할 수 있다는 점에 유의한다. SR(232)은 Initial_InputFS에 대한 변경의 통지를 수신할 때마다, Initial_InputFS에 대한 최신 데이터를 검색하고 새로운 추론 프로세스를 수행하여 새로운 InferredFS를 생성할 것이다. 단계(219)에서, SR(232)은 RJ-1의 작업 ID와 함께 새로운 InferredFS를 RI(231)에 다시 전송한다. RJ-1과 관련된 이러한 전체적인 시맨틱 추론 프로세스는 RJ-1이 SR(232)에서 실행되는 유효한 시맨틱 추론 작업인 한 계속될 수 있다. 또한, RJ-1이 만료되거나, SR(232) 또는 RI(231)가 RJ-1을 종료하기로 선택하면, SR(232)은 RJ-1과 관련된 처리 추론을 중단할 것이고, SR(232)은 또한 관련 FS 및 RS로부터 가입 취소할 수 있다. 도 13에 도시되어 있는 대안은 도 14에 도시된 방법에도 적용될 수 있다.

이 부분은 (시맨틱 질의, 시맨틱 리소스 발견, 시맨틱 매시업 등과 같은) 다른 시맨틱 동작들이 시맨틱 추론으로부터 어떻게 이익을 얻을 수 있는지에 관한 방법들 및 시스템들을 소개한다. 시맨틱 추론기 외에도, 시맨틱 엔진(SE)이 또한 시스템에서 이용가능하며, 이는 이들 시맨틱 동작들에 대한 처리 엔진이다. 일반적인 프로세스는, 시맨틱 사용자(SU)가 SPARQL 질의문을 포함할 수 있는, 요청을 SE에 전송함으로써 시맨틱 동작을 개시할 수 있다는 것이다. 특히, SU는 SE의 배후에서 도움을 제공할 수 있는 SR을 알지 못한다. SE의 경우, 이것은 먼저 대응하는 SPARQL 질의문에 대한 IDB(Involved Data Basis)를 결정할 수 있다. 일반적으로, IDB는 SPARQL 질의문이 실행되어야 하는 팩트들의 세트(예를 들어, RDF 트리플들)를 지칭한다. 그러나, 현재 IDB는 요청에 대한 원하는 응답을 제공하기에 완벽하지 않을 수 있다. 따라서, SE는 SE에서의 시맨틱 동작의 처리를 용이하게 하기 위해 시맨틱 추론 지원에 대해 SR에 추가로 연락할 수 있다. 특히, IDB의 증강이 개시된다. IDB의 증강에 대해, 추론 능력이 이용되고, 따라서 원래의 IDB는 (일부 새로운 추론된 팩트들을 추론의 도움으로 인해 초기 팩트들에 통합함으로써) 증강될 것이지만, 원래의 질의문은 수정되지 않을 것이다. 따라서, SE는 처리 결과를 생성하기 위해 "증강된 IDB"를 통해 원래의 질의문을 적용할 것이다(예를 들어, SE가 시맨틱 질의를 처리하고 있는 경우, 처리 결과는 시맨틱 질의 결과일 것이다. SE가 시맨틱 리소스 발견을 처리하고 있는 경우, 처리 결과는 시맨틱 발견 결과일 것이다).

부분 3(블록(125))에서, 시맨틱 추론은 다른 시맨틱 동작들의 유효성을 증가시키기 위해 "배경 지원"과 더 유사하게 동작하고, 이 경우에, 추론은 프론트-엔드 사용자들에게 투명할 수 있다. 다시 말해서, 부분 3(블록(125)) 내의 사용자들은 그들이 (시맨틱 질의 또는 시맨틱 리소스 발견, 시맨틱 매시업 등과 같은) 특정 시맨틱 동작을 개시하고 있다는 것만을 알 수 있다. 그러나, SE(233)에 의한 이 동작의 처리 동안, SE(233)는 지원을 위해 SR(232)에 추가로 의존할 수 있다(이 작업에서, 용어 SE는 시맨틱 추론 이외의 시맨틱 동작들을 처리하기 위한 엔진으로서 사용된다. 즉, 추론 처리는 SR에 의해 구체적으로 처리될 것이다). 이전의 예를 고려하면, 사용자는 지금 실외 스포츠를 하기 위한 추천들을 질의하기 위해 SE에 대한 시맨틱 질의를 개시할 수 있다. SE가 단지 공원의 현재 실외 온도/습도/바람 데이터와 같은 원시 팩트들을 갖는다면 질의는 응답될 수 없다(SPARQL 질의 처리가 주로 패턴 일치에 기반함을 기억하기 바란다). 실제로, (InputFS로서의) 이들 원시 팩트들은 관련 추론 규칙들을 이용한 추론을 위해 SR에 추가로 전송될 수 있고, (InferredFS로서의) 상위 레벨 추론된 팩트가 추론될 수 있으며, SE는 사용자의 질의에 잘 응답할 수 있다.

이 섹션은 (시맨틱 질의 또는 시맨틱 리소스 발견과 같은) 기존 시맨틱 동작들이 시맨틱 추론으로부터 이익을 얻을 수 있는 방법을 소개한다. 이하의 개시된 절차들에서, FH 및 RH와 같은, 이전에 정의된 "논리적 엔티티들" 중 일부가 여전히 관여된다. SR 외에도, SE는 또한 이들 시맨틱 동작들에 대한 처리 엔진인 시스템에서 이용가능하다. 시맨틱 동작을 개시하라는 요청을 SE로 전송하는 엔티티인 논리적 엔티티가 시맨틱 사용자(SU)라고 불린다.

일반적으로, SU(230)는 SPARQL 질의문을 포함할 수 있는 요청을 SE(233)에 전송함으로써 시맨틱 동작을 개시할 수 있다. 특히, SU는 SE의 배후에서 도움을 제공하는 시맨틱 추론 기능을 알지 못한다. SE(233)의 경우, 이것은 먼저, 예를 들어 SU에 의해 표시된 바와 같은 질의 범위 정보에 기반하여, 대응하는 SPARQL 질의문에 대한 IDB를 수집할 수 있다. IDB에 대한 더 많은 예는 다음과 같이 주어진다: 시맨틱 질의의 경우에, 수신된 SPARQL 질의문이 주어지면, 수집될 관련된 시맨틱 데이터는 통상적으로 질의 범위에 의해 정의된다. oneM2M을 예로서 이용하면, 특정 리소스 하의 디시덴트(decedent) <semanticDescriptor> 리소스들은 IDB를 구성할 것이고, 질의는 이 IDB를 통해 실행될 것이다. 시맨틱 발견의 경우에, 주어진 리소스가 그 시맨틱 주석부기들(예컨대, 그 <semanticDescriptor> 자식 리소스)을 체크함으로써 발견 결과에 포함되어야 하는지를 평가할 때, 이 <semanticDescriptor> 자식 리소스는 IDB일 것이다. 그러나, 현재 IDB는 요청에 대한 원하는 응답을 제공하기에 완벽하지 않을 수 있다(예컨대, IDB에서의 팩트들은 SU(230)로부터의 SPARQL 질의문에서 이용되는 온톨로지와는 상이한 온톨로지를 이용하여 설명된다). 따라서, 시맨틱 추론은 이 경우에 SE(233)에서 시맨틱 동작 처리를 용이하게 하기 위한 특정 도움을 제공할 수 있다.

SE(230)가 SR(232)로부터의 도움을 요청하기로 결정할 때, SE(230) 또는 SR(232) 자체는 추가적인 팩트들 및 규칙들이 활용될 수 있는지를 결정할 수 있다. 그렇다면, (IDB와 함께) 이들 추가적인 팩트들 및 규칙들은 SU로부터 원래의 요청들을 처리하는데 도움이 될 수 있는 추론된 팩트들을 식별하도록 추론을 위해 SR에 의해 이용될 수 있다. 시맨틱 리소스 발견은 단지 용이한 제시를 위한 다음의 절차 설계에서의 예시적인 시맨틱 동작으로서 이용되지만, 개시된 방법들은 또한 (시맨틱 질의, 시맨틱 매시업 등과 같은) 다른 시맨틱 동작들에 적용될 수 있다.

다시, 증강된 IDB에 대해, 주요 아이디어는 추론 능력을 이용함으로써, (추론의 도움으로 인해 일부 새로운 추론된 팩트들을 초기 팩트들과 통합함으로써) IDB가 증강될 것이라는 점이다. 따라서, 원래의 질의문은 발견 결과를 생성하기 위해 "증강된 IDB"에 적용될 것이다. 도 15의 상세한 설명들은 다음과 같다: 단계(221)에서, SU(230)는 예를 들어 시맨틱 리소스 발견 동작인 시맨틱 동작을 개시하려고 의도한다. 예를 들어, SU(230)는 MZ-1에 속하는 방들을 모니터링하는 카메라들을 찾고 있다. 이 발견 요청에서의 SPARQL 질의문은 다음과 같이 작성될 수 있다:

단계(222)에서, SU(230)는, SPARQL 질의문 및 (요구되거나 아니면 계획되는 경우) IDB가 관여되어야 하는 정보와 함께, 시맨틱 발견 동작을 개시하기 위한 요청을 SE(233)에 전송한다. oneM2M 예를 이용하여, 시맨틱 발견의 경우, SU(230)는 (SE를 구현하는) CSE에 발견 요청을 전송할 수 있고, 발견이 시작되어야 하는 곳, 예컨대 이 CSE의 리소스 트리 상의 특정 리소스 <resource-1>를 표시한다. 따라서, <resource-1>의 모든 자식 리소스들은 이들이 발견 결과에 포함되어야 하는지를 알기 위해 각각 평가될 것이다. 특히, 평가될 주어진 자식 리소스(예컨대, <resource-2>)에 대해, SPARQL 질의는 <resource-2>의 <semanticDescriptor> 자식 리소스에 저장된 시맨틱 데이터에 적용되어 일치하는지 여부를 볼 것이다(그렇다면, <resource-2>는 발견 결과에 포함될 것이다). 따라서, 이 경우에, <resource-2>를 평가할 때, <resource-2>의 <semanticDescriptor> 자식 리소스에 저장된 시맨틱 데이터는 IDB이다.

유사하게, 시맨틱 질의의 경우에, SU(230)는 (SE를 구현하는) CSE에 시맨틱 질의 요청을 전송할 수 있고, 관련된 시맨틱 데이터(예컨대, 질의 범위)를 어떻게 수집할지, 예를 들어 특정 oneM2M 리소스 <resource-1> 하에서의 시맨틱 관련 리소스들이 어떻게 수집되어야 하는지를 표시할 수 있다. 따라서, <resource-1>의 디시덴트 시맨틱 관련된 리소스들(예컨대, 이들 <semanticDescriptor> 리소스들)은 함께 수집될 수 있고, SPARQL 질의는 시맨틱 질의 결과를 생성하기 위해 그 시맨틱 관련된 리소스들로부터 집성된 시맨틱 데이터에 적용될 것이다. 따라서, 이 경우, <resource-1>의 모든 디시덴트 시맨틱 관련된 리소스들에 저장된 데이터는 IDB이다.

단계(222)에서, SU(230)로부터 전송된 요청에 기반하여, SE(233)는 시맨틱 리소스 발견 처리를 수행하기 시작한다. 도 5와 연관된 예를 이용하여, <카메라-111>은 후보 리소스 중 하나이고, SU(230)는 그 <semanticDescriptor> 자식 리소스에서 시맨틱 데이터를 검사함으로써 <카메라-111>가 발견 결과에 포함되어야 하는지를 평가할 수 있다. 다시 말해서, <카메라-111>의 <semanticDescriptor> 자식 리소스에 저장된 데이터는 이제 IDB(IDB-1로 표시됨)이다. 예를 들어, 시맨틱 발견 경우에 대해, 하나의 특정 리소스를 평가하기 시작할 때마다, 새로운 IDB가 결정되고, 이것은 이 특정 리소스를 평가하는데 단지 이용될 수 있다. 예를 들어, IDB-1은 단지 다음과 같은 팩트들을 포함할 수 있다:

· 팩트-1: 카메라-111은 카메라이다.

· 팩트-2: 카메라-111은 빌딩-1의 방-109에 위치한다.

SE(233)는 또한 이러한 요청을 처리하기 위해 추론이 관여되어야 하는지를 결정한다.

일반적으로, SE(233)가 추론이 관여되어야 하는지를 결정하기 위한 다음과 같은 잠재적인 방식들이 존재하며(이것은 SE(233) 상에 일부 로컬 정책들 또는 구성들을 설정함으로써 달성될 수 있으며), 이는 다음과 같은 것들을 포함하지만 이에 제한되지는 않는다:

· 원래의 IDB-1에 기반하여 SE(233)에 의해 어떠한 결과도 생성될 수 없는 경우, SE(233)는 IDB-1을 증강시키기 위해 추론을 활용하기로 결정할 수 있다.

· SU(230)가 고품질 발견을 요구하거나 요청하는 바람직한 사용자인 경우, SE(233)는 (예를 들어, SU의 유형에 의존하여) IDB-1을 증강시키기 위해 추론을 활용하기로 결정할 수 있다.

· SE(233)는 또한, IDB-1에서 이용되는 관심있는 용어들/개념들/특성들 또는 특정 온톨로지들을 보는 한, SE(233)가 IDB-1을 증강시키기 위해 추론을 활용하기로 결정할 수 있도록 구성될 수 있다. 예를 들어, SE(233)는 팩트-2를 체크하고, 팩트-2에서 나타나는 빌딩 번호 및 방 번호들(예컨대, "빌딩-1" 및 "방-109")에 관련된 용어들을 찾을 때, IDB-1을 증강시키기 위해 추론을 활용하기로 결정할 수 있다.

SE(233)는 IDB-1을 증강시키기 위해 추론을 활용하기로 결정하면, SR(232)과 추가로 접촉할 수 있다. 단계(224)에서, SE(233)는 SR(232)에서의 추론 프로세스를 위한 Initial_InputFS로서 있을 것인, IDB-1에 관련된 정보와 함께, 추론 프로세스를 위한 요청을 SR(232)에 전송한다. 실제로 SE(233) 및 SR(232)이 함께 통합되고 동일한 엔티티, 예컨대 oneM2M 컨텍스트에서의 동일한 CSE에 의해 구현될 수 있다는 점에 유의한다. SR(232)은 (Addi_InputFS로서의) 추가적인 FS 또는 (Initial_RS로서의) RS가 추론에 이용되어야 하는지를 추가로 결정한다. 도 13에 도시된 바와 같이, 추가적인 FS 및 RS가 이용되어야 하는지를 결정하는 방법에 관한 단계(224)가 여기서 재이용될 수 있다. 하나의 확장은 SR(232)이 IDB-1에 나타나는 키워드들 또는 관심있는 용어들뿐만 아니라, 단계(221)에 도시된 SPARQL 문에 나타나는 것들을 체크할 수 있다는 것이다. 결정 후에, SR(232)은 이들 FS 및 RS를 검색할 것이다. 예를 들어, SR(232)은 각각 FH(132)로부터 Addi_InputFS 및 RH(136)로부터 Initial_RS를 검색한다. 이 예에서, SR(232)은 팩트-2에 나타난 키워드 "~에 위치한다"가 존재하고, 키워드 "~ 내의 방을 모니터링한다"가 단계(221)에서 SU(230)로부터 전송된 SPARQL 질의문에서 나타났다는 것을 발견하고, 이어서 SR(232)은 MZ 정의 및 방 배정에 관한 일부 유용한 정보가 추론에 이용될 수 있다고 결정할 수 있다. 따라서, Addi_InputFS는 다음과 같은 팩트를 포함할 수 있다:

· 팩트-3: 빌딩-1의 방-109는 "MZ-1" 하에 관리된다.

또한, SE(233)는 Initial_RS가 또한 2개의 키워드 "~에 위치한다" 및 "~ 하에 관리된다"를 포함하기 때문에, Initial_RS가 다음의 규칙을 포함할 수 있다고 결정한다:

· 규칙-1: A가 B에 위치하고, B가 C 하에 관리되면, A는 C 내의 방을 모니터링한다.

단계(226)에서, IDB-1 및 수집된 Addi_InputFS 및 Initial_RS에 기반하여, SR(232)은 추론 프로세스를 실행하고 추론된 팩트들(InferredFS-1로 표시됨)을 낳는다. 예를 들어, SR(232)은 다음을 찾는다:

· 팩트-2는 규칙-1의 가정 부분, 즉 A가 B에 위치한다에서의 부분 패턴과 일치할 수 있다.

· 팩트-3은 규칙-1의 가정 부분, 즉 B가 C 하에 관리된다에서의 부분 패턴과 일치할 수 있다.

따라서, 새로운 팩트가 추론될 수 있고, 예컨대 카메라-111이 MZ-1 내의 방을 모니터링하고, 이것은 InferredFS-1로서 표시된다. 단계(227)에서, SR(232)은 다시 InferredFS-1을 SE(233)에 전송한다. 단계(228)에서, SE(233)는 InferredFS-1을 (새로운 IDB-2로서) IDB-1에 통합하고, IDB-2를 통해 원래의 SPARQL 문을 적용하고 대응하는 결과를 낳는다. 이 예에서, 이는 IDB-2를 통해 SPARQL 문을 적용할 때 일치가 있을 것임을 의미한다(이제 새로운 추론된 팩트 InferredFS-1이 IDB-2에 있기 때문에, 이는 SPARQL 문에서의 패턴 "?device monitors-room-in MZ-1"과 일치할 것이고, 따라서 <카메라-111>의 URI는 발견 결과에 포함될 것이다). 그 후, SE(233)는 <카메라-111>에 대한 평가를 완료하고 평가될 다음 리소스를 계속 체크할 수 있다. 단계(229)에서, 모든 발견 처리가 SE(233)에 의해 행해진 후, 이것은 (이 경우에 발견 결과의 관점에서) 처리 결과를 SU(230)에 다시 전송한다. 예를 들어, <카메라-111>의 URI는 (처리 결과인) 발견 결과에 포함되고 SU(230)로 다시 전송될 수 있다.

시맨틱 추론 CSF: 시맨틱 추론 CSF는 도 16에 도시된 바와 같이 oneM2M 서비스 계층에서 새로운 CSF로서 고려될 수 있다(대안적으로, 이것은 또한 oneM2M TS-0001에 정의된 기존 시맨틱 CSF의 일부일 수 있다). 상이한 유형들의 M2M 노드들은 M2M 게이트웨이들, M2M 서버들 등과 같은 시맨틱 추론 서비스를 구현할 수 있다는 점이 이해되어야 한다. 특히, 이들 노드들에 대한 다양한/상이한 하드웨어/소프트웨어 능력들에 따라, 이들 노드들에 의해 구현되는 시맨틱 추론 서비스들의 능력들이 또한 변할 수 있다.

도 17은 FS 인에이블먼트에 대해 정의된 엔티티들에 대한 oneM2M 예들을 도시한다. 예를 들어, 팩트 호스트는 oneM2M 시스템에서 CSE일 수 있고, AE/CSE는 팩트 제공자 또는 팩트 소비자 또는 팩트 수정자일 수 있다.

도 18은 RS 인에이블먼트에 대해 정의된 엔티티들에 대한 oneM2M 예들을 도시한다. 예를 들어, 규칙 호스트는 oneM2M 시스템에서 CSE일 수 있고, AE/CSE는 규칙 제공자 또는 규칙 소비자 또는 규칙 수정자일 수 있다.

도 19는 개별 시맨틱 추론 동작에 수반되는 엔티티들에 대한 oneM2M 예들을 도시한다. 예를 들어, CSE는 시맨틱 추론기를 구비하는 경우에 시맨틱 추론 서비스를 제공할 수 있다. 또한, AE/CSE는 추론 개시자일 수 있다. 앞서 논의된 바와 같이, 본 개시내용에서 정의된 관여된 엔티티들은 대부분 논리적 역할들이다. 따라서, 하나의 물리적 엔티티는 복수의 논리적 역할을 맡을 수 있다. 예를 들어, CSE가 (예를 들어, 도 19에 도시된 바와 같이 SR로서) 시맨틱 추론 능력을 가지며 추론 동작을 위한 입력들로서 특정 FS 및 RS를 검색하도록 요구되거나 요청할 때, 이 CSE는 도 17 및 도 18에 도시된 바와 같이 FC 및 RC의 역할들을 또한 가질 것이다.

도 20은 개별 시맨틱 추론 동작에 수반되는 엔티티들에 대한 다른 유형의 예들을 도시한다. 이 아키텍처에서, oneM2M 시스템은 주로 팩트들 및 규칙들을 제공한다. 예를 들어, oneM2M CSE는 팩트 호스트 또는 규칙 호스트로서 고려될 수 있다. oneM2M 시스템의 상부 상에 다른 계층(예컨대, ETSI 컨텍스트 정보 관리(CIM), W3C WoT 또는 OCF(Open Connectivity Foundation))이 있을 수 있으며, 따라서 사용자의 시맨틱 추론 요청들이 상위 계층으로부터 올 수 있다. 따라서, 외부 CIM/W3C WoT/OCF 엔티티는 시맨틱 추론기를 구비할 수 있고, 추론 개시자들은 주로 CIM/W3C WoT/OCF 시스템들로부터의 이들 엔티티들이다. 다시 말해서, 이들 RI들은 추론 요청들을 시맨틱 추론기에 전송할 것이고, 이는 상호연동 엔티티와 추가로 접촉하고, 상호연동 엔티티는 oneM2M 인터페이스를 통해 oneM2M 엔티티들로부터 관련된 FS 및 RS를 수집할 것이다(FS는 또한 oneM2M이 그것과 상호작용할 수 있는 한 다른 비-oneM2M 엔티티들에 의해 제공될 수 있다는 점에 유의한다. 예를 들어, FS는 또한 트리플 저장소에 의해 제공될 수 있다). oneM2M 시스템에서, 상호연동, 예컨대 IPE 기반 상호연동 및 CSE 기반 상호연동을 처리할 수 있는 두 가지 유형의 엔티티가 있을 수 있다. 따라서, 상호연동 엔티티는 이들 두 가지 유형의 상호연동을 지원하기 위한 (특수 AE인) CSE 또는 IPE 중 어느 하나를 지칭할 수 있다.

도 21은 추론 지원을 이용하여 시맨틱 동작들을 최적화하는데 수반되는 엔티티들에 대한 oneM2M 예들을 도시한다. 예를 들어, CSE는 시맨틱 추론기를 구비하는 경우에 시맨틱 추론 능력을 제공할 수 있고, CSE는 시맨틱 엔진을 구비하는 경우에 다른 시맨틱 동작들(예컨대, 시맨틱 리소스 발견, 시맨틱 질의 등)을 처리할 수 있다. 또한, AE/CSE는 시맨틱 동작을 트리거링하는 시맨틱 사용자일 수 있다. 이 섹션의 모든 예들에 걸쳐, 주어진 논리적 엔티티가 단지 용이한 제시를 위한 것인 단일 AE 또는 CSE에 의해 취해진다는 점에 유의한다. 실제로, 일반적인 경우에, AE 또는 CSE는 복수의 논리적 엔티티들의 역할들을 맡을 수 있다. 예를 들어, CSE는 FH뿐만 아니라 RH일 수 있다. 다른 예로서, CSE는 시맨틱 추론기 및 시맨틱 엔진 둘 다를 호스팅할 수 있다. 다른 예로서, CSE는 추론 개시자일 수 있고, 이 CSE 자체는 또한 시맨틱 추론기를 구비할 수 있다.

도 22는 추론 지원을 이용하여 시맨틱 동작들을 최적화하는데 수반되는 엔티티들에 대한 다른 유형의 예들을 도시한다. 이 아키텍처에서, oneM2M 시스템은 주로 팩트들 및 규칙들을 제공한다. 예를 들어, oneM2M CSE는 팩트 호스트 또는 규칙 호스트일 수 있다. oneM2M 시스템의 상부에는 (CIM, WoT 또는 OCF와 같은) 다른 계층이 있을 수 있으며, 사용자의 시맨틱 추론 요청들은 상위 계층으로부터 올 수 있다. 따라서, 외부 CIM/WoT/OCF 엔티티는 시맨틱 엔진을 구비할 수 있고, 시맨틱 사용자들은 주로 CIM/WoT/OCF 시스템들로부터의 이들 엔티티들이다. 유사하게, 외부 CIM/WoT/OCF 엔티티는 시맨틱 추론기를 구비할 수 있다. 일반적으로, 시맨틱 사용자들은 특정 시맨틱 동작들을 트리거링하기 위한 그 요청들을 시맨틱 엔진에 전송할 것이다. 시맨틱 엔진은 추론 지원을 위해 시맨틱 추론기에 추가로 연락할 수 있고, 추론기는 oneM2M 인터페이스를 통해 oneM2M 엔티티들로부터 관련된 FS 및 RS를 수집하기 위해 상호연동 엔티티를 추가로 살펴볼 것이다. FS는 또한, oneM2M이 그것과 상호작용할 수 있는 한, 다른 비-oneM2M 엔티티들에 의해 제공될 수 있다는 점에 유의한다. 예를 들어, FS는 또한 트리플 저장소에 의해 제공될 수 있다.

이하는 ETSI CIM과 oneM2M 시스템 사이의 추론 지원을 갖는 시맨틱 질의에 대한 도 22의 더 구체적인 예이고, 도 23은 다음과 같은 절차 및 상세한 설명들을 도시한다:

전제 조건 0(단계(307)): CSE-1에 등록된 가로등-1 상에 설치된 카메라 및 <streetCamera-1>은 그 oneM2M 리소스 표현이고, 일부 시맨틱 메타데이터는 또한 이 리소스과 연관된다. 예를 들어, 시맨틱 메타데이터 중 하나는 다음과 같을 수 있다:

· 팩트-1: <streetCamera-1>은 가로등-1 상에 설치된다.

전제 조건 1(단계(308)): IPE는 시맨틱 리소스 발견을 수행했고, 예를 들어 거리 카메라-1을 포함하는, 카메라 리소스들을 CIM 시스템에 등록했다.

전제 조건 2(단계(309)): IPE는 발견된 oneM2M 카메라들을 CIM 레지스트리 서버에 등록했다. 유사하게, <streetCamera-1>에 대한 컨텍스트 정보 중 하나는 그것이 가로등-1 상에 설치되었다는 것이다(예컨대, 팩트-1).

단계(311): CIM 애플리케이션 App-1(도시 도로 모니터링 부서임)은 사고-1이 있었다는 것을 알고 있고, 사고-1에 관한 일부 팩트들 또는 지식, 예컨대 이 사고의 위치를 가진다:

· 팩트-2: 사고-1은 사고-위치 "40.079136, -75.288823"을 갖는다.

App-1은 카메라가 고장났는지를 알기 위해 (사고-1에서 부딪힌) 가로등 상에 설치된 카메라로부터 이미지들을 수집하고자 한다. 따라서, 질의문이 다음과 같이 작성될 수 있다(여기서는 단지 용이한 제시를 위한 것인 SPARQL 언어를 이용하여 문이 작성되었음에 유의한다. 즉, 질의문은 CIM에 의해 지원되는 임의의 형태로 작성될 수 있다):

단계(312): App-1은, (그 위치와 같은) 사고-1에 관한 팩트-2와 함께, 어느 카메라가 사고-1에 관여했는지에 관한 발견 요청을 CIM 발견 서비스에 전송한다.

단계(313): CIM 발견 서비스는 발견 요청에 직접 응답할 수 없고, 시맨틱 추론기에게 도움을 추가로 요청한다.

단계(314): 발견 서비스는 팩트-2, 및 또한 카메라들의 시맨틱 정보(<streetCamera-1>에 관한 팩트-1을 포함함)와 함께 그 요청을 시맨틱 추론기에 전송한다. 즉, 팩트-1 및 팩트-2는 "Initial_InputFS"로서 고려될 수 있다.

단계(315): 시맨틱 추론기는 가로등 위치 맵에 관한 추가의 팩트들을 이용하기로 결정한다. 예를 들어, 팩트-2가 단지 사고에 관한 지리적 위치를 포함하기 때문에, 시맨틱 추론기는 어느 가로등이 관여되는지를 결정하기 위해 가로등들에 관한 더 많은 정보를 요구하거나 요청할 수 있다. 예를 들어, 팩트-3은 가로등-1에 관한 추가적인 팩트이다.

· 팩트-3: 가로등-1은 사고-위치 "40.079236, -75.288623"을 갖는다.

단계(316): 시맨틱 추론기는 추가로 시맨틱 추론을 수행하고 일부 새로운 팩트(<streetCamera-1>이 사고-1에 관여되었음)를 생성한다. 예를 들어, 아래에 도시된 바와 같은 규칙-1은 가로등-1이 사고-1에 관여되었다는 새로운 팩트(추론된 팩트-1)를 추론하는데 이용될 수 있다.

· 규칙-1: A가 위치 코디네이션-1을 갖고, B가 위치 코디네이션-2를 갖고, 거리(코디네이션-1, 코디네이션-2) < 20미터이면, A는 B에 관여된다.

· 추론된 팩트-1: 가로등-1은 사고-1에 관여된다.

또한, 추론된 팩트-1 및 팩트-1에 의해, 다른 추론이 다음의 규칙(규칙-2)을 이용하여 실행될 수 있고, 다른 추론된 팩트(예컨대, 추론된 팩트-2)가 추론될 수 있다:

· 규칙-1: A가 B에 관여되고, C가 A 상에 설치되면, C는 B에 관여된다.

· 추론된 팩트-2: <streetCamera-1>이 사고-1에 관여된다.

단계(317): 새로운 팩트가 CIM 발견 서비스로 다시 전송되었다. 단계(318): 새로운 팩트를 이용하여, CIM 발견 서비스는 이제 App-1로부터의 질의에 응답할 수 있는데, 그 이유는 추론된 팩트-2가 <streetCamera-1>이 사고-1에 관여된 카메라라는 것을 보여주기 때문이다. 단계(319): App-1은 <streetCamera-1>이 사고-1에 관여되었다는 것을 통지받았다. 단계(320): App-1은 <streetCamera-1>의 이미지들을 검색하기 위해 CIM 레지스트리 서버에 추가로 접촉하고, 레지스트리 서버는 oneM2M 시스템에서 <streetCamera-1> 리소스로부터 이미지들을 검색하도록 oneM2M IPE에게 추가로 요청할 것이다.

<facts> 리소스 정의: 주어진 FS는 지식의 상이한 유형들을 지칭할 수 있다. 첫째, FS는 주어진 이용 사례(예컨대, 도 5와 연관된 스마트 도시 이용 사례, 여기서 많은 도메인 개념들/클래스 및 그들의 관계들, 예컨대 병원, 도시 소방서, 빌딩, 방들 등이 정의됨)에 대한 도메인 지식을 기술하는 온톨로지를 지칭할 수 있다. 따라서, 이러한 유형의 FS는 oneM2M <ontology> 리소스로서 구현될 수 있다. 둘째, FS는 또한 시스템에서의 리소스/엔티티/사물에 관한 시맨틱 주석부기를 지칭할 수 있다. 도 5와 연관된 이전의 예를 여전히 이용하면, FS는 빌딩-1의 방-109에 배치되는 카메라-111에 대한 시맨틱 주석부기들일 수 있다. 따라서, 이러한 유형의 FS는 oneM2M <semanticDescriptor> 리소스로서 구현될 수 있다.

FS는 특정 인스턴스들과 관련된 팩트들을 또한 지칭할 수 있다. 도 5와 연관된 이전의 예를 여전히 이용하면, FS는 그 빌딩/방 배열/배정 정보와 같은 병원의 현재 관리 구역 정의들을 기술할 수 있다(예컨대, 관리 구역 MZ-1은 혈액 시험 샘플들을 저장하는데 이용되는 방들, 예컨대 빌딩-1에서의 방-109, 빌딩-3에서의 방-117 등을 포함한다). 이러한 유형의 팩트들에 대해, 이것은 시스템 내에 개별적으로 존재할 수 있고, 예컨대 다른 리소스들/엔티티들/사물들에 대한 시맨틱 주석부기들일 필요는 없다는 점에 유의한다. 따라서, 새로운 유형의 oneM2M 리소스(<facts>라고 함)는 이러한 유형의 FS를 저장하도록 정의된다. 이것은 동일한 목적을 갖는 한, 상이한 이름으로 명명될 수 있다는 점에 유의한다. <facts>의 리소스 구조가 도 24에 도시되어 있다. FS는 또한 이 리소스가 시맨틱 유형의 데이터를 저장하는데 이용될 수 있다면 <contentInstance> 리소스를 지칭할 수 있다. 또한, 더 일반적인 것으로, FS는 이들이 데이터의 시맨틱 유형을 저장할 수 있는 한 oneM2M에 의해 정의되는 임의의 미래의 새로운 리소스 유형들을 지칭할 수 있다.

위의 <facts> 리소스는 표 2에 명시된 자식 리소스들 중 하나 이상을 포함할 수 있다.

<표 2>

위의 <facts> 리소스는 표 3에 명시된 속성들 중 하나 이상을 포함할 수 있다.

<표 3>

아래에 소개된 바와 같은 <facts> 리소스에 대한 CRUD 동작들은 시맨틱 추론 데이터를 인에이블하는 것에 관하여 본 명세서에 소개된 관련 절차들의 oneM2M 예들일 것이라는 점에 유의한다. <semanticDescriptor> 리소스가 또한 (예를 들어, "descriptor" 속성을 이용하여) 팩트들을 저장하는데 이용될 수 있기 때문에, factType, rulesCanBeUsed, usedRules, originalFacts와 같은 속성들은 또한 시맨틱 추론 목적을 지원하기 위한 기존의 <semanticDescriptor> 리소스에 대한 새로운 속성들일 수 있다는 점에 유의한다. 예를 들어, <SD-1> 및 <SD-2>가 <semanticDescriptor> 리소스들의 유형이고, <CSE-1>의 시맨틱 주석부기들인 것으로 가정한다. <SD-1>은 <CSE-1>의 원래의 시맨틱 주석부기일 수 있다. 이에 비해, <SD-2>는 <CSE-1>의 추가적인 시맨틱 주석부기이다. 예를 들어, <SD-2>의 "factType"는 <SD-2> 리소스의 "descriptor" 속성에 저장된 트리플들/팩트들이 시맨틱 추론 동작에 기반한 추론 결과(예컨대, 추론된 팩트들)인 것을 표시할 수 있다. 즉, <SD-2>에 저장된 시맨틱 주석부기는 시맨틱 추론을 통해 생성되었다. 유사하게, <SD-2>의 rulesCanBeUsed, usedRules, originalFacts 속성들은 <SD-2>에 저장된 팩트들이 (inputFS 및 추론 규칙들에 기반하여) 어떻게 생성되었는지, 그리고 <SD-2>에 저장된 팩트들이 다른 추론 동작들에 어떻게 이용될 수 있는지에 관한 상세한 정보를 추가로 표시할 수 있다.

<facts>의 생성: <facts> 리소스를 생성하는데 이용되는 절차.

<표 4>

<facts>의 검색: <facts> 리소스의 속성들을 검색하는데 이용되는 절차.

<표 5>

<facts>의 업데이트: <facts> 리소스의 속성들을 업데이트하는데 이용되는 절차.

<표 6>

<facts>의 삭제: <facts> 리소스를 삭제하는데 이용되는 절차.

<표 7>

<factRepository> 리소스 정의: 일반적으로, <facts> 리소스는 예를 들어 <AE> 또는 <CSEBase> 리소스의 자식 리소스로서 어디에서든 저장될 수 있다. 대안적으로, 새로운 <factRepository>는, 요구되거나 요청된 팩트들을 찾기 위해 더 용이하도록 복수의 <facts>를 저장하는 허브일 수 있는 새로운 oneM2M 리소스 유형으로서 정의될 수 있다. <factRepository> 리소스는 <CSEBase> 또는 <AE> 리소스의 자식 리소스일 수 있다. <factRepository>의 리소스 구조가 도 25에 도시되어 있다.

<factRepository> 리소스는 표 8에 명시된 바와 같은 자식 리소스들을 포함할 것이다.

<표 8>

위의 <factRepository> 리소스는 표 9에 명시된 속성들 중 하나 이상을 포함할 수 있다.

<표 9>

<factRepository>의 생성: <factRepository> 리소스를 생성하는데 이용되는 절차.

<표 10>

<factRepository>의 검색: <factRepository> 리소스를 검색하는데 이용되는 절차.

<표 11>

<factRepository>의 업데이트: 기존의 <factRepository> 리소스를 업데이트하는데 이용되는 절차.

<표 12>

<factRepository>의 삭제: 기존의 <factRepository> 리소스를 삭제하는데 이용되는 절차.

<표 13>

<reasoningRules> 리소스 정의: 새로운 유형의 oneM2M 리소스(<reasoningRules>라고 함)는 (사용자-정의된) 추론 규칙들을 저장하는데 이용되는 RS를 저장하도록 정의된다. 이것은 동일한 목적을 갖는 한, 상이한 이름으로 명명될 수 있다는 점에 유의한다. <reasoningRules>의 리소스 구조가 도 26에 도시되어 있다.

위의 <reasoningRules> 리소스는 표 14에 명시된 자식 리소스들 중 하나 이상을 포함할 수 있다.

<표 14>

위의 <reasoningRules> 리소스는 표 15에 명시된 속성들 중 하나 이상을 포함할 수 있다.

<표 15>

이하는 추론 규칙을 나타내기 위해 RIF를 이용하는 방법의 예이다. 본 개시내용에서 이용되는 다음의 추론 규칙을 고려한다:

· 규칙-1: A가 B에 위치하고, B가 C 하에 관리되면, A는 C 내의 방을 모니터링한다.

규칙-1은 다음의 RIF 규칙으로서 작성될 수 있다(굵은 단어들은 RIF 신택스에 의해 정의되는 키워드들이고, RIF 사양에 대한 더 많은 상세들은 RIF 프라이머, https://www.w3.org/2005/rules/wiki/Primer [12]에서 찾을 수 있다):

위의 규칙들에 대한 설명들은 다음의 5개의 설명에 의해 제공될 수 있다. 설명 1: 위의 규칙은 기본적으로, ~이면, ~한다라는 형태의 관점에서 추상 신택스를 따른다. 설명 2: 2개의 오퍼레이터, 그룹 및 문서가 RIF에서 규칙들을 작성하는데 이용될 수 있다. 그룹은 RIF 문서 내의 규칙들의 세트를 한정하거나 함께 그룹화하는데 이용된다. 문서는 많은 그룹들 또는 단지 하나의 그룹을 포함할 수 있다. 유사하게, 그룹은 단일 규칙으로 구성될 수 있지만, 이들은 일반적으로 복수의 규칙들을 함께 그룹화하도록 의도된다. RIF 문서가 다른 문서들을 가져올 수 있고 따라서 그 자체가 다중 문서 객체일 수 있기 때문에 명시적 문서 오퍼레이터를 가질 필요가 있다. 실제의 목적을 위해, 문서 오퍼레이터가 문서의 시작에서 일반적으로 이용되고, 이어서 프리픽스 선언 및 하나 이상의 규칙 그룹이 후속하는 것을 아는 것으로 충분하다.

설명 3: "~에 위치한다"와 같은 술어 상수들은 "있는 그대로" 바로 이용될 수 없지만 명확하게 될 수 있다. 이러한 명확화는 이 규칙에서 이용되는 상수들이 하나보다 많은 소스로부터 오고 상이한 시맨틱 의미들을 가질 수 있다는 문제를 해결한다. RIF에서, 명확화는 IRI들, 및 프리픽스 선언 Prefix(ns <ThisIRI>)를 작성함으로써 프리픽스 선언의 일반적인 형태를 이용하여 수행된다. 그 다음, 상수 이름이 스트링 ns:name를 이용하여 규칙들에서 명확하게 될 수 있다. 예를 들어, 술어 "~에 위치한다"는 (프리픽스 "exA"를 갖는) 예시적인 온톨로지 A에 의해 정의되는 술어인 반면, 술어 "~ 하에 관리된다"는 (프리픽스 "exB"를 갖는) 다른 예시적인 온톨로지 B에 의해 정의되는 술어이고, 술어 "~ 내의 방을 모니터링한다"는 (프리픽스 "exC"를 갖는) 다른 예시적인 온톨로지 C에 의해 정의되는 술어이다.

설명 4: 유사하게, "?"(예컨대, ?Camera)로 시작하는 변수에 대해, 어느 유형의 인스턴스들이 특수 부호 "#"(RDF 스키마에서 정의되는 바와 같은 술어 "~의 유형인"과 동일함)를 이용함으로써 그 변수에 대한 입력일 수 있다는 것을 정의하는 것이 또한 필요하다. 예를 들어, "?Camera # exA:Camera"는 온톨로지 A에서 정의된 클래스 카메라의 인스턴스들만이 ?Camera 변수에 대한 입력으로서 이용될 수 있다는 것을 의미한다. 설명 5: 위의 규칙은 논리곱을 포함할 수 있고, RIF에서, 논리곱은 프리픽스 표기법으로 재작성되고, 예를 들어 이진수 A 및 B는 논리곱(A B)으로서 작성된다.

아래에 소개된 바와 같은 <reasoningRules> 리소스에 대한 CRUD 동작들은 RS 인에이블먼트와 관련하여 본 명세서에 소개된 관련 절차들의 oneM2M 예들이라는 점에 유의한다.

<reasoningRules>의 생성: <reasoningRules> 리소스를 생성하는데 이용되는 절차.

<표 16>

<reasoningRules>의 검색: <reasoningRules> 리소스의 속성들을 검색하는데 이용되는 절차.

<표 17>

<reasoningRules>의 업데이트: <reasoningRules> 리소스의 속성들을 업데이트하는데 이용되는 절차.

<표 18>

<reasoningRules>의 삭제: <reasoningRules> 리소스를 삭제하는데 이용되는 절차.

<표 19>

<ruleRepository> 리소스 정의: 일반적으로, <reasoningRules> 리소스는, 예를 들어 <AE> 또는 <CSEBase> 리소스의 자식 리소스로서, 어디에서나 저장될 수 있다. 대안적으로, 새로운 <ruleRepository>는, 요구되거나 요청된 규칙들을 찾기 위해 더 용이하도록 복수의 <reasoningRules>를 저장하기 위한 허브일 수 있는 새로운 oneM2M 리소스 유형으로서 정의될 수 있다. <ruleRepository> 리소스는 <CSEBase>의 자식 리소스 또는 <AE> 리소스일 수 있다. <ruleRepository>의 리소스 구조가 도 27에 도시된다.

<ruleRepository> 리소스는 표 8에 명시된 바와 같은 자식 리소스들 중 하나 이상을 포함할 수 있다.

<표 20>

위의 <ruleRepository> 리소스는 표 9에 명시된 속성들 중 하나 이상을 포함할 수 있다.

<표 21>

<ruleRepository>의 생성: <ruleRepository> 리소스를 생성하는데 이용되는 절차.

<표 22>

<ruleRepository>의 검색: <ruleRepository> 리소스를 검색하는데 이용되는 절차.

<표 23>

<ruleRepository>의 업데이트: 기존 <ruleRepository> 리소스를 업데이트하는데 이용되는 절차.

<표 24>

<ruleRepository>의 삭제: 기존 <ruleRepository> 리소스를 삭제하는데 이용되는 절차.

<표 25>

<semanticReasoner> 리소스 정의: <semanticReasoner>라고 불리는 새로운 리소스가 개시되며, 이는 시맨틱 추론 서비스를 노출시킨다. <semanticReasoner>의 리소스 구조가 도 28에 도시되어 있다.

CSE는 시맨틱 추론 능력을 갖는 경우, 시맨틱 추론 처리를 지원하기 위해 (예를 들어, <CSEBase> 하에서) 이에 대한 <semanticReasoner> 리소스를 생성할 수 있다.

위의 <semanticReasoner> 리소스는 표 26에 명시된 자식 리소스들 중 하나 이상을 포함할 수 있다.

<표 26>

위의 <semanticReasoner> 리소스는 표 27에 명시된 속성들 중 하나 이상을 포함할 수 있다.

<표 27>

대안적으로, 시맨틱 추론을 노출시키기 위한 다른 방식은 기존의 <CSEBase> 또는 <remoteCSE> 리소스를 이용하는 것이다. 따라서, 표 27에 도시된 속성들은 <CSEBase> 또는 <remoteCSE> 리소스에 대한 새로운 속성들일 수 있다. <CSEBase>가 시맨틱 추론 요청을 획득(예컨대, 수신)하기 위한 몇 가지 방식이 있을 수 있다: 1) <reasoningPortal> 리소스는 이 작업에 정의된 바와 같은 시맨틱 추론 동작을 트리거링하는 것에 관련된 요청들을 수신하기 위한 <CSEBase> 또는 <remoteCSE> 리소스의 새로운 자식 가상 리소스일 수 있거나; 또는 2) 새로운 리소스를 정의하는 대신에, RI로부터의 요청들은 <CSEBase>로 직접 전송될 수 있고, 여기서 트리거는 요청 메시지에서 정의될 수 있다(예컨대, "reasoningIndicator"라고 불리는 새로운 파라미터가 요청 메시지에 포함되도록 정의될 수 있다).

<semanticReasoner>의 생성: <semanticReasoner> 리소스를 생성하는데 이용되는 절차.

<표 28>

<semanticReasoner>의 검색: <semanticReasoner> 리소스를 검색하는데 이용되는 절차.

<표 29>

<semanticReasoner>의 업데이트: 기존 <semanticReasoner> 리소스를 업데이트하는데 이용되는 절차.

<표 30>

<semanticReasoner>의 삭제: 기존 <semanticReasoner> 리소스를 삭제하는데 이용되는 절차.

<표 31>

<reasoningPortal> 리소스 정의: <reasoningPortal>은 표현을 갖지 않기 때문에 가상 리소스이다. 이것은 <semanticReasoner> 리소스의 자식 리소스이다. 업데이트 동작은 <reasoningPortal> 리소스로 전송될 때, 시맨틱 추론 동작을 트리거링한다.

일반적으로, 발신자는 아래에 개시된 이하의 목적들을 위해 이 <reasoningPortal> 리소스에 요청을 전송할 수 있다. 제1 예에서, 요청은 1회 추론 동작을 트리거링하는 것일 수 있다. 이 예에서, 다음과 같은 정보가 요청에서 운반될 수 있다: a) 이러한 추론 동작에서 제기될 팩트들, b) 추론 동작에서 이용될 추론 규칙들, c) 이것이 1회 추론 동작을 위한 것임을 나타내는 추론 유형, 또는 d) 이전 섹션들에 열거된 바와 같은 임의의 다른 정보. 제2 예에서, 요청은 연속적인 추론 동작을 트리거링하는 것일 수 있다. 이 제2 예에서, 다음과 같은 정보가 요청에서 운반될 수 있다: a) 추론 동작에서 이용될 팩트들, b) 추론 동작에서 이용될 추론 규칙들, c) 이것이 연속적인 추론 동작을 위한 것임을 나타내는 추론 유형, 또는 d) <reasoningJobInstance> 리소스를 생성하기 위한 임의의 다른 정보. 예를 들어, continuousExecutionMode는 <reasoningJobInstance> 리소스 내의 속성들 중 하나이다. 따라서, 요청은 또한 이 속성을 설정하는데 이용될 수 있는 관련 정보를 운반할 수 있다. 제3 예에서, 요청은 기존 추론 작업에 대한 새로운 추론 동작을 트리거링하는 것일 수 있다. 이 제3 예에서, 다음과 같은 정보가 요청에서 운반될 수 있다: jobID: 기존의 <reasoningJobInstance> 리소스의 URI.

또한, 요청에서 운반될 정보, 예컨대 이용될 팩트들 및 추론 규칙들에 대해, 요청에서 이들을 운반하기 위한 복수의 방식들이 존재한다: 1) 팩트들 및 추론 규칙들은 요청의 콘텐츠 파라미터들에서 운반될 수 있거나; 또는 2) 팩트들 및 추론 규칙들은 요청의 새로운 파라미터들에서 운반될 수 있다. 예시적인 새로운 파라미터들은 팩트 파라미터 및 규칙 파라미터들이다. 팩트 파라미터의 경우, 이것은 추론 동작에서 이용될 팩트들을 운반할 수 있다. 규칙 파라미터의 경우, 이것은 추론 동작에서 이용될 추론 규칙들을 운반할 수 있다.

"팩트" 파라미터의 경우, 이것은 다음의 방식들을 이용하여 팩트들에 관한 정보를 포함할 수 있다:

· 사례 1: 팩트 파라미터는 RDF 트리플들과 같은 팩트 데이터를 직접 포함할 수 있다.

· 사례 2: 팩트 파라미터는 이용될 팩트들을 저장하는 하나 이상의 URI를 또한 포함할 수 있다.

"규칙들" 파라미터의 경우, 이것은 다음의 방식들을 이용하여 팩트들에 관한 정보를 포함할 수 있다:

· 사례 1: 규칙 파라미터는 이용될 규칙들을 저장하는 하나 이상의 URI를 포함할 수 있다.

· 사례 2: 규칙 파라미터는 이용될 추론 규칙들의 리스트를 직접 운반할 수 있다.

· 사례 3: 규칙 파라미터는 스트링 값일 수 있으며, 이는 특정 표준 SPARQL 함의 체제를 나타낸다(SPARQL 함의는 상이한 함의 체제들에 의해 정의되는 바와 같은 표준 추론 규칙들을 이용하는 시맨틱 추론의 하나의 유형이라는 점에 유의한다). 예를 들어, 규칙들 = "RDFS"이면, 이것은 RDFS 함의 체제에 의해 정의된 추론 규칙들이 이용될 것임을 의미한다.

구현 선택들을 위해, 위의 사례들 중 하나만을 구현할 수 있거나, 또는 이들 사례들을 동시에 구현할 수 있다. 후자의 경우에, typeofFactsRepresentation 및 typeofUseReasoning이라고 불리는 2개의 새로운 파라미터가 정의될 수 있고, 이는 요청에 포함된 파라미터들일 수 있고, 아래에 도시된 바와 같은 표시자들일 수 있는 예시적인 값들을 가질 수 있다:

· typeofFactsRepresentation = 1, 팩트 파라미터는 URI들을 저장한다.

· typeofFactsRepresentation = 2, 팩트 파라미터는 이용될 팩트들의 리스트, 예컨대 RDF 트리플들을 저장한다.

· typeofRulesRepresentation = 1, 규칙 파라미터는 URI(들)의 리스트를 저장한다.

· typeofRulesRepresentation = 2, 규칙 파라미터는 추론 규칙들의 리스트를 저장한다.

· typeofRulesRepresentation = 3, 규칙 파라미터는 표준 함의 체제를 나타내는 스트링 값을 저장한다.

<reasoningPortal> 리소스는 부모 <semanticReasoner> 리소스가 호스팅 CSE에 의해 생성될 때 생성된다. 생성 동작은 Mca, Mcc 또는 Mcc'를 통해 적용가능하지 않다.

검색 동작은 <reasoningPortal>에 대해서는 적용가능하지 않을 수 있다.

<reasoningPortal>의 업데이트: 업데이트 동작은 시맨틱 추론 동작을 트리거링하는데 이용된다. 연속적인 추론 동작의 경우, 이것은 이하의 방식들로 <reasoningPortal>을 이용할 수 있다. 제1 방식에서, <reasoningPortal> 업데이트 동작을 이용한다. 이러한 제1 방식의 경우, 이러한 요청이 연속적인 추론 동작을 생성할 필요가 있다는 것을 나타내기 위해 추론 유형 파라미터가 요청에서 운반될 수 있다. 제2 방식에서, <reasoningPortal> 생성 동작을 이용한다.

<표 32A>

이하는 표 32A에 도시된 <reasongingPortal> 업데이트 동작의 처리를 위한 대안 버전이다. 예를 들어, 이 버전에서, 팩트들 및 추론 규칙들은 요청에서의 팩트 및 규칙 파라미터들에서 운반된다. 한편, 이것은 단순화를 위해 추가적인 팩트들 및 규칙들을 추가하는 것을 고려하지 않는다.

<표 32B>

<reasoningPortal>의 삭제: <reasoningPortal> 리소스는 부모 <semanticReasoner> 리소스가 호스팅 CSE에 의해 삭제될 때 삭제될 것이다. 삭제 동작은 Mca, Mcc 또는 Mcc'를 통해 적용가능하지 않다.

<reasoningJobInstance> 리소스 정의: 새로운 유형의 oneM2M 리소스(<reasoningJobInstance>라고 지칭됨)는 특정 추론 작업 인스턴스(이것은 1회 추론 동작, 또는 연속적인 추론 동작일 수 있음)를 설명하도록 정의된다. 이것은 동일한 목적을 갖는 한, 상이한 이름으로 명명될 수 있다는 점에 유의한다.

다음은 연속적인 추론 작업을 수행하기 위한 대안적인 방식들일 수 있다는 점에 유의한다. 제1 방식에서, 발신자는, 이 CSE가 시맨틱 추론 능력을 지원할 수 있다면 <reasoningJobInstance> 리소스를 생성하기 위해, CSE의 <semanticReasoner>쪽으로(또는 <CSEBase> 리소스쪽으로) 요청을 전송할 수 있다. 제2 방식에서, 발신자는 <reasoningJobInstance> 리소스를 생성하기 위해, <semanticReasoner> 리소스의 <reasoningPortal>쪽으로 생성 요청을 전송할 수 있다(또는 이것은 업데이트 요청을 <reasoningPortal>에 전송할 수 있지만, 요청에 포함된 추론 유형 파라미터는 이것이 연속적인 추론 동작을 생성하기 위한 것임을 나타낼 수 있다).

<reasoningJobInstance>의 리소스 구조가 도 29에 도시되어 있다. <reasoningJobInstance> 리소스는 표 33에 명시된 자식 리소스들 중 하나 이상을 포함할 수 있다.

<표 33>

위의 <reasoningJobInstance> 리소스는 표 34에 명시된 속성들 중 하나 이상을 포함할 수 있다.

<표 34>

이 절차는 <reasoningJobInstance> 리소스를 생성하는데 이용된다.

<표 35>

<reasoningJobInstance>의 검색: <reasoningJobInstance> 리소스의 속성들을 검색하는데 이용되는 절차.

<표 36>

<reasoningJobInstance>의 업데이트: <reasoningJobInstance> 리소스의 속성들을 업데이트하는데 이용되는 절차.

<표 37>

<reasoningJobInstance>의 삭제: <reasoningJobInstance> 리소스를 삭제하는데 이용되는 절차.

<표 38>

<reasoningResult> 리소스 정의: 새로운 유형의 oneM2M 리소스(<reasoningResult>라고 함)가 추론 결과를 저장하도록 정의된다. 이것은 동일한 목적을 갖는 한, 상이한 이름으로 명명될 수 있다는 점에 유의한다. <reasoningResult>의 리소스 구조가 도 30에 도시되어 있다.

위의 <reasoningResult> 리소스는 표 39에 명시된 자식 리소스들 중 하나 이상을 포함할 수 있다.

<표 39>

위의 <reasoningResult> 리소스는 표 40에 명시된 속성들 중 하나 이상을 포함할 수 있다.

<표 40>

생성 동작은 <reasoningResult>에 대해 적용가능하지 않다. <reasoningResult> 리소스는, <reasoningJobInstance> 부모 리소스에 의해 표현되는 추론 작업에 대한 시맨틱 추론 프로세스를 실행할 때 시맨틱 추론 능력을 갖는 호스팅 CSE에 의해 자동으로 생성된다.

<reasoningResult>의 검색: <reasoningResult> 리소스의 속성들을 검색하는데 이용되는 절차.

<표 41>

검색 동작은 <reasoningResult>에 대해 적용가능하지 않다.

<reasoningResult>의 삭제: <reasoningResult> 리소스를 삭제하는데 이용되는 절차.

<표 42>

<jobExecutionPortal> 리소스 정의: <jobExecutionPortal>은 표현을 갖지 않고 이전에-정의된 <reasoningPortal> 리소스와 유사하게 유사한 기능을 갖기 때문에 가상 리소스이다. 이것은 <reasoningJobInstance> 리소스의 자식 리소스이다. 속성 continuousExecutionMode의 값이 "RI가 작업 실행을 트리거링할 때"로 설정되고, 업데이트 동작이 <jobExecutionPortal> 리소스로 전송되는 경우, 이것은 부모 <reasoningJobInstance> 리소스에 대응하는 시맨틱 추론 실행을 트리거링한다.

<jobExecutionPortal>의 생성: <reasoningPortal> 리소스는 부모 <reasoningJobInstance> 리소스가 생성될 때 생성될 것이다.

<jobExecutionPortal>의 검색: 검색 동작은 <reasoningPortal>에 대해 적용가능하지 않다.

<jobExecutionPortal>의 업데이트: 업데이트 동작은 시맨틱 추론 실행을 트리거링하는데 이용된다. 이것은 jobID로 <reasoningPortal> 리소스에 업데이트 요청을 전송하는 것과 비교되는 대안이다.

<표 43A>

이하는 표 43A에 도시된 <jobExecutionPortal> 업데이트 동작의 처리를 위한 단순화된 또는 대안적인 버전이다. 예를 들어, 이것은 단순화를 위해 추가적인 팩트들 및 규칙들을 제공하는 것을 고려하지 않는다.

<표 43B>

<jobExecutionPortal>의 삭제: <jobExecutionPortal> 리소스는 부모 <reasoningJobInstance> 리소스가 호스팅 CSE에 의해 삭제될 때 삭제될 것이다. 삭제 동작은 Mca, Mcc 또는 Mcc'를 통해 적용가능하지 않다.

개별 시맨틱 추론 프로세스를 가능하게 하고 다른 것의 유효성을 증가시키는 것과 관련하여 도입된 시맨틱 추론 관련 절차들을 위한 oneM2M 예들. 이 섹션은 본 명세서에 개시된 방법들에 대해 몇 가지 oneM2M 예들을 소개한다.

도 13에 개시된 1회 추론 동작의 oneM2M 예. 이 시나리오에서, (RI로서의) AE-1은 일부 관심있는 InputFS(<facts-1>) 및 RS(<reasoningRules-1>를 식별하였고, 일부 새로운 지식/팩트들을 발견하기 위해 (SR로서의) CSE-1에서 1회 추론 동작을 개시하기를 원한다. 도 31은 1회 추론 동작을 위한 oneM2M 절차를 예시하고, 상세한 설명들은 다음과 같다.

전제 조건(단계(340)): AE-1은 (SR로서 동작하는) CSE-1의 존재를 알고, <semanticReasoner> 리소스는 CSE-1 상에서 생성되었다. 발견을 통해, AE-1은 CSE-2 상의 관심있는 <facts-1> 리소스의 세트(<facts-1>은 Initial_InputFS일 것임) 및 CSE-3 상의 일부 <reasoningRules-1>(<reasoningRules-1>은 Initial_RS일 것임)을 식별하였다.

단계(341): AE-1은 일부 새로운 지식을 발견하기 위해 CSE-1에서의 추론을 트리거링하기 위해 입력들로서 <facts-1> 및 <reasoningRules-1>을 이용하려고 의도한다.

단계(342): AE-1은, Initial_InputFS 및 Initial_RS에 관한 정보와 함께, CSE-1 상의 <reasoningPortal> 가상 리소스 쪽으로 추론 요청을 전송한다. 예를 들어, 이용될 팩트들 및 규칙들은 요청에서 새롭게 개시된 팩트 및 규칙 파라미터들에 의해 기술될 수 있다.

단계(343): AE-1로부터 전송된 정보에 기반하여, CSE-1은 CSE-2로부터 <facts-1>를 검색하고, CSE-3으로부터 <reasoningRules-1>을 검색한다.

단계(344): AE-1에 의해 제공되는 입력들에 추가하여, 임의적으로 CSE-1은 또한 CSE-2 상의 <facts-2> 및 CSE-3 상의 <reasoningRules-2>가 또한 이용되어야 한다고 결정할 수 있다.

단계(345): CSE-1은 CSE-2로부터 추가적인 FS(예컨대, <facts-2>) 및 CSE-3으로부터 추가적인 RS(예컨대, <reasoningRules-2>)를 검색한다.

단계(346): 모든 InputFS(예컨대, <facts-1> 및 <facts-2>) 및 RS(예컨대, <reasoningRules-1> 및 <reasoningRules-2>)에 의해, CSE-1은 추론 프로세스를 실행하고 추론 결과를 낳을 것이다.

단계(347): SR(232)은 AE-1에 추론 결과를 다시 전송한다. 또한, 본 명세서에 소개된 바와 같이, SR(232)은 또한 추론 결과를 저장하기 위해 <reasoningResult> 리소스를 생성할 수 있다.

도 14에 개시된 연속적인 추론 동작의 oneM2M 예. 이 시나리오에서, (RI로서의) AE-1은 일부 관심있는 InputFS(<facts-1>) 및 RS(<reasoningRules-1>를 식별하였고, 일부 새로운 지식을 발견하기 위해 (SR로서의) CSE-1에서 연속적인 추론 동작을 개시하기를 원한다(팩트들 및 지식이라는 용어들은 본 명세서에서 동의어적으로 사용될 수 있다). 도 32는 연속적인 추론 동작을 위한 oneM2M 절차를 예시하고, 상세한 설명들은 다음과 같다.

전제 조건(단계(350)): AE-1은 (SR로서 동작하는) CSE-1의 존재를 알고, <semanticReasoner> 리소스는 CSE-1 상에서 생성되었다. 발견을 통해, AE-1은 CSE-2 상의 관심있는 <facts-1> 리소스의 세트(<facts-1>은 Initial_InputFS일 것임) 및 CSE-3 상의 일부 <reasoningRules-1>(<reasoningRules-1>은 Initial_RS일 것임)을 식별하였다.

단계(351): AE-1은 CSE-1에서의 연속적인 추론 동작을 트리거링하기 위해 입력들로서 <facts-1> 및 <reasoningRules-1>을 이용하려고 의도한다.

단계(352): AE-1은 Initial_InputFS 및 Initial_RS에 관한 정보뿐만 아니라, 생성될 <reasoningJobInstance>에 대한 일부 다른 정보와 함께, <reasoningJobInstance> 리소스를 생성하기 위해 <semanticReasoner> 리소스의 <reasoningPortal> 자식 리소스쪽으로 생성 요청을 전송한다. 대안적으로, 다른 가능한 구현은 AE-1이 생성 요청을 <CSEBase> 또는 <semanticReasoner> 리소스쪽으로 전송할 수 있다는 것이다.

단계(353): AE-1로부터 전송된 정보에 기반하여, CSE-1은 CSE-2로부터 <facts-1>를 검색하고, CSE-3으로부터 <reasoningRules-1>을 검색한다. CSE-1은 또한 이들 2개의 리소스에 가입한다.

단계(354): AE-1에 의해 제공되는 입력들에 추가하여, 임의적으로 CSE-1은 또한 CSE-2 상의 <facts-2> 및 CSE-3 상의 <reasoningRules-2>가 또한 이용되어야 한다고 결정할 수 있다.

단계(355): CSE-1은 CSE-2로부터 추가적인 FS(예컨대, <facts-2>) 및 CSE-3으로부터 추가적인 RS(예컨대, <reasoningRules-2>)를 검색한다. CSE-1은 또한 이들 2개의 리소스에 가입한다.

단계(356): 모든 InputFS(예컨대, <facts-1> 및 <facts-2>) 및 RS(예컨대, <reasoningRules-1> 및 <reasoningRules-2>)에 의해, CSE-1은 <semanticReasoner> 리소스(또는 다른 바람직한 위치들) 하에서 <reasoningJobInstance-1> 리소스를 생성할 것이다. 예를 들어, reasoningType 속성은 "연속적인 추론 동작"으로 설정될 것이고, continuousExecutionMode 속성은 "관련 FS/RS가 변할 때"로 설정될 것이다. 그 후, 이것은 추론 프로세스를 실행하고 추론 결과를 낳는다. 그 결과는 <reasoningJobInstance-1>의 reasoningResult 속성에 저장될 수 있거나, 새로운 <reasoningResult> 유형의 자식 리소스에 저장될 수 있다.

단계(357): SR(232)은 AE-1에 추론 결과를 다시 전송한다.

단계(358): <facts-1>, <facts-2>, <reasoningRules-1> 및 <reasoningRules-2>에 대한 임의의 변경들은 단계 3에서 이전에 확립된 가입으로 인해 CSE-1에 대한 통지를 트리거링할 것이다.

단계(359): CSE-1이 통지를 수신하는 한, 관련 FS 및 RS의 최신 값들을 이용함으로써 <reasoningJobInstance-1>의 새로운 추론 프로세스를 실행할 것이다. 새로운 추론 결과는 또한 AE-1로 전송될 것이다.

도 15에 개시된 절차의 oneM2M 예. 이 시나리오에서, (SU로서의) AE-1은 (SE로서의) CSE-1에서 시맨틱 리소스 발견을 수행하려고 의도한다. 리소스 발견 처리 동안, CSE-1은 최적화된 발견 결과를 얻기 위해 CSE-2로부터 추론 지원을 추가로 이용할 수 있다. 도 33a는 추론에 의해 지원되는 IDB를 증강시키기 위한 예시적인 oneM2M 절차를 예시하고, 상세한 설명들은 다음과 같다:

단계(361): AE-1은 시맨틱 리소스 발견 동작을 개시하려고 의도한다.

단계(362): AE-1은 SPARQL 질의문이 포함되는 시맨틱 발견 동작을 개시하기 위해 CSE-1의 <CSEBase>에 요청을 전송한다.

단계(363): AE-1로부터 전송된 요청에 기반하여, CSE-1은 시맨틱 리소스 발견 처리를 수행하기 시작한다. 특히, CSE-1은 이제 <AE-2> 리소스가 <AE-2>의 <semanticDescriptor-1> 자식 리소스를 검사함으로써 발견 결과에 포함되어야 하는지 여부를 평가하기 시작한다. 그러나, <semanticDescriptor-1>에서의 현재 데이터는 AE-1로부터 전송된 SPARQL 질의문과 일치할 수 없다. 따라서, CSE-1은 추론이 이 요청을 처리하기 위해 추가로 관여되어야 한다고 결정한다.

단계(364): CSE-1은 <semanticDescriptor-1>에 저장된 정보와 함께, 추론 프로세스를 요구하기 위해 (시맨틱 추론 능력을 갖는) CSE-2 상의 <reasoningPortal> 리소스쪽으로 요청을 전송한다.

단계(365): CSE-2는 또한 추가적인 FS 및 RS가 이 추론 프로세스에 추가되어야 한다고 결정한다. 예를 들어, CSE-1은 각각 CSE-3으로부터 <facts-1>를 검색하고, CSE-4로부터 <reasoningRules-1>을 검색한다.

단계(366): (IDB로서) <semanticDescriptor-1> 및 추가적인 <facts-1> 및 <reasoningRules-1>에 저장된 정보에 기반하여, CSE-1은 추론 프로세스를 실행하고 추론된 팩트들(InferredFS-1로서 표시됨)을 낳는다.

단계(367): CSE-2는 InferredFS-1을 CSE-1에 다시 전송한다.

단계(368): CSE-1은 InferredFS-1을 <semanticDescriptor-1>에 저장된 데이터와 통합하고, 통합된 데이터를 통해 원래 SPARQL 문을 적용하고, 일치가 획득된다. 그 결과, <AE-2>가 발견 결과에 포함될 것이다. CSE-1은 모든 리소스 발견 처리를 완료할 때까지 <CSEBase> 하에서 다음 리소스를 계속 평가할 것이다.

단계(369): CSE-1은 최종 발견 결과를 AE-1에 다시 전송한다.

도 33a에 도시된 것의 간략화된 버전으로 고려될 수 있는, 도 33a의 대안 절차가 아래에 논의된다. 이 시나리오에서, (SU로서의) AE-1은 요청을 CSE-1에 전송할 수 있고 시맨틱 리소스 발견을 수행하고자 한다. 여기서, 시맨틱 발견은 단지 예이고, 시맨틱 질의 등과 같은 다른 시맨틱 동작일 수 있다는 점에 유의한다. 특히, 이 절차에서, 시맨틱 엔진(SE) 및 시맨틱 추론기(SR)는 CSE-1에 의해 실현될 수 있다. 따라서, 리소스 발견 처리 동안, CSE-1은 최적화된 발견 결과를 얻기 위해 추론 지원을 추가로 이용할 수 있다.

도 33b는 도 33a의 대안 절차를 도시하고, 상세한 설명들은 다음과 같다. 단계(371)에서, AE-1은 시맨틱 리소스 발견 동작을 개시하려고 의도한다. 단계(372)에서, AE-1은 SPARQL 질의문이 포함되는 시맨틱 발견 동작을 개시하기 위해 CSE-1의 <CSEBase>에 요청을 전송할 수 있다. AE-1은 또한 시맨틱 추론이 이용될 수 있는지를 표시할 수 있다. 예를 들어, 새로운 파라미터가 useReasoning라고 불리는 이러한 요청에서 운반될 수 있다. 다음의 사례들과 같은 이 useReasoning 파라미터를 어떻게 이용하는지에 대한 복수의 상이한 방식들이 존재한다:

· 사례 1: 제1 구현은 useReasoning가 0 또는 1일 수 있다는 것이다. useReasoning = 1일 때, 이것은 AE-1이 CSE-1에게 SPARQL 처리 동안 시맨틱 추론을 적용하라고 요청하는 것을 의미하는 반면, useReasoning = 0(또는 useReasoning 파라미터가 요청에 있지 않은 경우)은 AE-1이 CSE-1에게 시맨틱 추론을 적용하지 않도록 요청하는 것을 의미한다. 이 경우에, 어떤 추론 규칙들을 이용할지는 시맨틱 엔진 또는 시맨틱 추론기(예컨대, 이 경우에는 CSE-1)에 의해 완전히 결정된다.

· 사례 2: 제2 구현은 useReasoning가 이용될 추론 규칙들을 저장하는 하나 이상의 특정 <reasoningRule> 리소스(들)를 지칭하는 URI(또는 URI들의 리스트)일 수 있다는 것이다.

· 사례 3: 제3 구현은 useReasoning가 AE-1이 SPARQL 처리 동안 CSE-1이 이용하기를 원하는 추론 규칙들의 리스트를 직접 저장할 수 있다는 것이다.

· 사례 4: 제4 구현은 useReasoning가 특정 표준 SPARQL 함의 체제를 표시하는 스트링 값일 수 있다는 것이다(SPARQL 함의는 상이한 함의 체제들에 의해 정의되는 바와 같은 표준 추론 규칙들을 이용하는 시맨틱 추론의 하나의 유형이라는 점에 유의한다). 예를 들어, useReasoning = "RDFS"이면, 이것은 AE-1이 처리 동안 RDFS 함의 체제에 의해 정의된 추론(본 명세서에서 함의라고 지칭될 수 있음) 규칙들을 적용하도록 CSE-1에게 요청한다는 것을 의미한다.

구현 선택들의 경우, 위의 네 가지 사례 중 하나를 단지 구현할 수 있거나, 이들 네 가지 사례를 동시에 구현할 수 있다. 후자의 경우에, typeofRulesRepresentation이라고 불리는 새로운 파라미터가 정의될 수 있고, 이는 요청에 포함된 파라미터이고, 다음의 값들 및 의미들을 가질 수 있다:

· typeofRulesRepresentation = 1인 경우, useReasoning 파라미터는 0 또는 1일 수 있다.

· typeofRulesRepresentation = 2인 경우, useReasoning 파라미터는 하나 이상의 URI(들)를 저장한다.

· typeofRulesRepresentation = 3인 경우, useReasoning는 추론 규칙들의 리스트를 저장한다.

· typeofRulesRepresentation = 4인 경우, useReasoning는 표준 SPARQL 함의 체제를 표시하는 스트링 값을 저장한다.

단계(373)에서, AE-1로부터 전송된 요청에 기반하여, CSE-1은 시맨틱 리소스 발견 처리를 수행하기 시작한다. 예를 들어, CSE-1은 이제 <AE-2> 리소스가 <AE-2>의 <semanticDescriptor-1> 자식 리소스를 검사함으로써 발견 결과에 포함되어야 하는지 여부를 평가하기 시작한다. 특히, CSE-1이 시맨틱 추론을 적용할 능력을 갖는 경우, CSE-1은 먼저 시맨틱 추론이 적용되어야 하는지를 결정할 수 있다. 따라서, 이것은 또한 단계(372)에서 정의된 바와 같은 상이한 사례들에 기반하여 다음의 동작들을 가질 수 있다:

· 사례 1: useReasoning = 1일 때, CSE-1은 이용될 추론 규칙들의 적절한 세트를 결정할 수 있다.

· 사례 2: useReasoning가 하나 이상의 URI를 포함할 때, CSE-1은 이 파라미터에 의해 참조되는 관련 <reasoningRule> 리소스들에 저장된 추론 규칙들을 검색할 수 있다.

· 사례 3: useReasoning가 추론 규칙들의 리스트를 직접 저장할 때, CSE-1은 추론을 위해 이러한 추론 규칙들을 이용할 수 있다.

· 사례 4: useReasoning가 스트링 값일 때, 이는 특정 표준 SPARQL 함의 체제를 나타낼 수 있다. 그 후, CSE-1은 처리 동안 대응하는 표준 함의 체제에 의해 정의된 추론 규칙들을 이용할 수 있다.

CSE-1이 이러한 능력을 갖지 않는 동안 AE-1이 특정한 유형의 추론을 요청하는 경우에는, 시맨틱 추론 동작이 적용되지 않을 수 있다. 예를 들어, AE-1이 CSE-1에 에러 URI를 제공하면, CSE-1은 CSE-1이 이 에러 URI에 기반하여 추론 규칙들을 검색할 수 없기 때문에 추론을 적용하지 못할 수 있다.

단계(374)에서, <semanticDescriptor-1>에 저장된 정보 및 적용된 추론 규칙들에 기반하여, CSE-1은 먼저 추론 프로세스를 실행하고 추론된 팩트들을 낳을 수 있다. 이어서, CSE-1은 추론된 팩트들을 <semanticDescriptor-1>에 저장된 원래의 데이터와 통합한 다음, 통합된 데이터를 통해 원래의 SPARQL 문을 적용한다. 그 결과, <AE-2>가 발견 결과에 포함될 수 있다. 그 후, CSE-1은 발견 동작들이 완료될 때까지 다음 후보 리소스들을 계속 평가할 수 있다. 단계(375)에서, CSE-1은 최종 발견 결과를 AE-1로 다시 전송할 수 있다.

GUI 인터페이스가 도 34에 제공되는데, 이는 사용자가 시맨틱 추론 동작을 보거나, 구성하거나 또는 트리거링하는데 이용될 수 있다. 예를 들어, 도 34에 설계된 바와 같은 UI를 이용함으로써, 사용자는 추론 동작을 위해 어느 팩트들 및 어느 규칙들을 이용하고자 하는지를 표시할 수 있다. 예를 들어, 이들 팩트들 및 규칙들은 이전에 정의된 <facts> 또는 <reasoningRules> 리소스들에 저장될 수 있다. 사용자는 또한 시맨틱 추론 규칙들(예컨대, 추론된 팩트들)을 어디에 전달할지를 표시할 수 있다. 사용자 인터페이스는 이러한 파라미터들을 디폴트 값들로 구성하거나 프로그래밍하도록 구현될 수 있는 것은 물론, 시맨틱 추론 지원에 대한 특정 특징들을 인에이블링 또는 디스에이블링하기 위한 스위치들을 제어할 수 있다.

아래의 표 44는 본 명세서에서 사용되는 용어의 설명을 제공한다.

<표 44>

개시된 주제는 다른 서비스 계층들에 적용가능할 수 있다는 점에 유의한다. 또한, 본 개시내용은 사용자들의 요건들/제약들을 지정하기 위한 예시적인 언어로서 SPARQL을 이용한다. 그러나, 개시된 주제는 사용자들의 요건들 또는 제약들이 SPARQL 이외의 상이한 언어들을 이용하여 작성되는 다른 경우들에 대해 적용될 수 있다. 본 명세서에 개시된 바와 같이, "사용자"는 서버 또는 모바일 디바이스와 같은 다른 디바이스일 수 있다.

본 명세서에 나타나는 청구항들의 범위, 해석, 또는 적용을 과도하게 제한하지 않고, 본 명세서에 개시되는 예들 중 하나 이상의 기술적 효과는 시맨틱 추론 지원 동작들에 대한 조정들을 제공하는 것이다. 일반적으로, 서비스 계층에서 추론 동작을 트리거링하는 방식들을 제공하는 시스템들, 방법들, 또는 장치들이 본 명세서에 개시된다. (시맨틱 리소스 발견 또는 시맨틱 질의와 같은) 시맨틱 동작이 트리거링될 때, 시맨틱 동작(예컨대, 시맨틱 리소스 발견 또는 시맨틱 질의)의 처리 동안, 시맨틱 추론은 사용자 디바이스가 알지 않고(예컨대, 자동적으로 AE 또는 CSE와 같은 사용자 디바이스에 경고하지 않고) 배경 지원(도 15 참조)으로서 활용될 수 있다. 다시 말해서, 주어진 수신기(예컨대, CSE)의 경우, 이것은 (시맨틱 발견 또는 질의와 같은) 시맨틱 동작들에 대한 요청들을 클라이언트들로부터 수신할 때, 수신기는 이들 요청들을 처리할 수 있다. 특히, 처리 동안, 수신기는 처리를 최적화하기 위해(예컨대, 더 정확한 발견 결과를 위해) 시맨틱 추론 능력을 추가로 이용할 수 있다.

도 35는 도 6의 oneM2M 예를 도시한다. oneM2M에서의 새로운 시맨틱 추론 기능(SRF)이 정의되고, 아래는 SRF의 주요 특징들 및 SRF가 지원할 수 있는 상이한 유형의 기능들의 상세한 설명이라는 것을 알 수 있다. 도 36은 도 35에 대한 대안을 도시한다. 도 36은 도 35의 대안적인 도면이다. (<facts><rules>는 리소스이고, SRF는 기능이기 때문에) <facts> 리소스 및 <rules> 리소스는 SRF의 박스에서 나온다.

특징-1: 시맨틱 추론 관련 데이터를 인에이블하는 것이 아래에 논의된다. 특징-1의 기능은, (도 35에서 화살표(381)로 예시되는) oneM2M 시스템에서 상이한 엔티티들에 걸쳐, 이들 데이터가 발견가능하고 공개가능하게(예컨대, 공유가능하게) 함으로써 시맨틱 추론 관련 데이터(팩트들 및 추론 규칙들로 지칭됨)를 가능하게 하는 것일 수 있다. 시맨틱 추론 관련 데이터는 팩트 세트(FS) 또는 규칙 세트(RS)일 수 있다. FS는 팩트 세트를 지칭한다. 예를 들어, 각각의 RDF 트리플은 팩트를 기술할 수 있고, 따라서, <semanticDescriptor> 리소스에 저장된 RDF 트리플들의 세트는 FS로서 고려된다. 일반적으로, FS는 시맨틱 추론 프로세스에 대한 입력(예컨대, 입력 FS)으로서 이용될 수 있거나, 또는 시맨틱 추론 프로세스의 결과(예컨대, 추론된 FS)로서 추론된 팩트들의 세트일 수 있다. RS는 시맨틱 추론 규칙들의 세트를 지칭한다.

특정 시맨틱 추론 프로세스 A를 실행하기 위해, 다음과 같은 2가지 유형의 데이터 입력들이 이용될 수 있다: 1) 입력 FS(inputFS로서 표시됨), 및 2) RS.

시맨틱 추론 프로세스 A의 출력은 추론된 FS(inferredFS로서 표시됨)를 포함할 수 있는데, 이는 추론 프로세스 A의 시맨틱 추론 결과들이다.

추론 프로세스 A에 의해 생성되는 inferredFS는 미래에 다른 시맨틱 추론 프로세스 B에 대한 inputFS로서 추가로 이용될 수 있다는 점에 유의한다. 따라서, 이하의 설명에서는, 적용가능한 경우에는 일반 용어 FS가 사용될 것이다.

팩트들은 정상 oneM2M 리소스들의 시맨틱 주석부기들(예컨대, <semanticDescriptor> 리소스들에 저장된 RDF 트리플들)에 제한되지 않는다. 팩트들은 oneM2M 시스템에서 이용가능하게 되고 다른 것들에 의해 액세스될 수 있는 임의의 귀중한 정보 또는 지식을 지칭할 수 있다. 예를 들어, oneM2M <ontology> 리소스에 저장된 온톨로지 설명은 FS일 수 있다. 다른 경우, FS는 또한 (도 5의 이전의 이용 사례에서 논의된 바와 같이 병원 방 배정 기록들을 기술하는 RDF 트리플들과 같은) 개별 정보 단편일 수 있고, 이러한 FS는 온톨로지를 기술하지 않거나 다른 리소스의 시맨틱 주석부기를 기술하지 않는다(예컨대, 병원 방 배정 기록들을 기술하는 FS는 개별적으로 존재할 수 있고 반드시 다른 리소스들의 시맨틱 주석부기일 필요는 없다).

RS와 관련하여, 사용자들은 다양한 애플리케이션들을 지원하기 위한 많은 맞춤화된(또는 사용자-정의된) 시맨틱 추론 규칙들을 설계할 필요가 있는데, 그 이유는 oneM2M 시스템이 상이한 도메인들에 걸쳐 애플리케이션들을 가능하게 하는 수평 플랫폼인 것으로 설계되기 때문이다. 따라서, 다양한 사용자-정의된 RS들은 oneM2M 시스템에서 이용가능하게 되고 다른 것들에 의해 액세스되거나 공유되지 않을 수 있다. 유의할 점은, 이러한 사용자-정의된 시맨틱 추론 규칙들이 시스템 유연성을 개선할 수 있는데, 그 이유는 많은 경우들에서, 사용자-정의된 추론 규칙들이 온톨로지 정의를 수정할 필요가 없고, (예를 들어, 온톨로지에서 2개의 클래스 사이의 새로운 또는 일시적 관계를 정의하기 위해) 국부적으로 또는 일시적으로 단지 이용될 수 있기 때문이다.

전체적으로, 특징-1은 적절한 oneM2M 리소스들을 통해 시맨틱 추론 관련 데이터(FS들 및 RS들 양자 모두를 포함함)의 공개 또는 발견 또는 공유를 가능하게 하는 것을 포함한다. 특징-1의 일반적인 흐름은 (발신자로서) oneM2M 사용자들이 대응하는 CRUD 동작들을 통해 FS 관련 리소스들 또는 RS 관련 리소스들을 공개, 발견, 업데이트, 또는 삭제하기 위해 특정 수신기 CSE들에 요청들을 전송할 수 있다는 것이다. 처리가 완료되면, 수신기 CSE는 응답을 다시 발신자에게 전송할 수 있다.

특징-2: 배경 시맨틱 추론 지원으로 다른 시맨틱 동작들을 최적화하는 것이 아래에 개시되어 있다: 특징-1과 연관된 이전 섹션에서 제시된 바와 같이, oneM2M 시스템에서 지원되는 기존 시맨틱 동작들(예컨대, 시맨틱 리소스 발견 및 시맨틱 질의)은 시맨틱 추론 지원 없이 원하는 결과들을 낳지 않을 수 있다. SRF의 특징-2의 기능은 (도 35에서 화살표들(382)로 도시된) 다른 시맨틱 동작들을 최적화하기 위한 "배경 지원"으로서 시맨틱 추론을 활용하는 것이다. 이 경우, 사용자들은 특정 시맨틱 동작들(예를 들어, 시맨틱 질의)을 트리거링하거나 개시한다. 이 동작의 처리 동안, 시맨틱 추론은 배경에서 추가로 트리거링될 수 있지만, 이는 사용자에게 완전히 투명하다. 예를 들어, 사용자는 SPARQL 질의 엔진에 SPARQL 질의를 제출함으로써 시맨틱 질의를 개시할 수 있다. 관여된 RDF 트리플들(FS-1로 표시됨)이 SPARQL 질의에 직접 응답할 수 없는 것이 가능하다. 따라서, SPARQL 엔진은 SR에 추가로 의존할 수 있으며, 이는 시맨틱 추론 프로세스를 수행할 것이다. SR은 (inputFS로서의) FS-1이 불충분한 경우, 예를 들어 특정 액세스 권한들에 기반하여 (RS로서) 적절한 추론 규칙 세트들 및 임의의 추가적인 FS를 결정하고 선택할 것이다. 마지막으로, inferredFS 면에서 시맨틱 추론 결과들이 SPARQL 엔진에 전달될 것이며, 이는 사용자의 SPARQL 질의문에 응답/일치하는데 추가로 이용될 수 있다.

도 5에 제시된 바와 같은 이용 사례를 여전히 이용하여, 이하의 2개의 예가 논의되는데, 이는 SRF가 oneM2M 시스템에서 이들 2개의 예에 제시된 바와 같은 문제들을 어떻게 해결할 수 있는지를 보여주기 위한 것이다. 포커싱된 <카메라-11> 리소스는 그 자식 리소스로서 <semanticDescriptor> 리소스를 추가함으로써 일부 메타데이터로 주석부기된다. 특히, <semanticDescriptor> 자식 리소스는 (기존의 팩트들로서) 2개의 RDF 트리플을 저장한다:

· RDF 트리플 #1(예컨대, 팩트-a): 카메라-11은 ontologyA:VideoCamera이다(여기서, "VideoCamera"는 온톨로지 A에 의해 정의된 클래스이다).

· RFC 트리플 #2(예컨대, 팩트-b): 카메라-11은 빌딩-1의 방-109에 위치한다.

예 1: 사용자가 모든 방들로부터 실시간 이미지들을 검색해야 한다고 고려한다. 이를 위해, 사용자는 다음 SPARQL 문-I를 이용하여 카메라들을 식별하기 위해 시맨틱 리소스 발견을 먼저 수행해야 한다:

실제로, <카메라-11> 및 SPARQL 문-I의 시맨틱 주석부기는 이들이 상이한 당사자들에 의해 제공될 수 있기 때문에 상이한 온톨로지들을 이용할 수 있을 가능성이 매우 크다. 예를 들어, <카메라-11>의 시맨틱 주석부기에 관하여, 팩트-a에서 이용된 온톨로지 클래스 "VideoCamera"는 온톨로지 A에서 온 것이다. 이에 비해, SPARQL 문-I에서 이용된 온톨로지 클래스 "VideoRecorder"은 다른 상이한 온톨로지 B로부터 온 것이다. 시맨틱 추론 능력이 누락되기 때문에, 시스템은 ontologyA:VideoCamera가 실제로 ontologyB:VideoRecorder과 동일하다는 것을 알아낼 수 없다. 그 결과, <카메라-11> 리소스는 시맨틱 리소스 발견 프로세스 동안 원하는 리소스로서 식별될 수 없는데, 그 이유는 SPARQL 처리가 정확한 패턴 일치에 기반하기 때문이다(그러나, 이 예에서, 팩트-a는 SPARQL 문-I에서 패턴 "?device is-a ontologyB:VideoRecorder"과 일치할 수 없다).

예 2: 보다 복잡한 경우가 이 예에 예시되어 있는데, 여기서 사용자는 단지 "특정 관리 구역(예컨대, MZ-1)에 속하는" 방들로부터 실시간 이미지들을 검색하기를 원한다. 이어서, 사용자는 다음의 SPARQL 문-II를 이용하여 시맨틱 리소스 발견을 먼저 수행할 수 있다:

(예-1과 유사한) 예-2에서, 시맨틱 추론 지원의 누락으로 인해, <카메라-11> 리소스는 원하는 리소스로서 식별될 수 없다(이때, 팩트-a는 SPARQL 문-II에서 패턴 "?device is-a ontologyA:VideoCamera"와 일치하지만, 팩트-b는 패턴 "?device monitors-room-in MZ-1"과 일치할 수 없다).

예 2는 또한 추론 프로세스를 위한 충분한 팩트 입력들의 부족으로 인한 중대한 시맨틱 추론 문제를 예시한다. 예를 들어, 시맨틱 추론이 가능하다고 가정하더라도, 다음의 추론 규칙(예컨대, RR-1)이 이용될 수 있다:

· RR-1: X가 Y에 위치하고, Y가 Z 하에 관리되면, X는 Z 내의 방을 모니터링한다.

여전히, 어떠한 추론된 팩트도 시맨틱 추론 프로세스를 통해 팩트-Y에 대해 RR-1을 적용함으로써 도출될 수 없다. 그 이유는 팩트-b가 단지 (예를 들어, X를 <카메라-11>로 대체하고 Y를 "빌딩-1의 방-109"로 대체하기 위해) RR-1에서 "X가 Y에 위치한다" 부분과 일치할 수 있기 때문이다. 그러나, 팩트-a 및 팩트-b에 더하여, RR-1에서 "Y가 Z 하에 관리된다" 부분과 일치시키는데 이용될 수 있는 어떠한 추가 팩트도 없다(예컨대, RR-1을 이용하기에 충분한 팩트들이 없다). 사실상, 여기서 누락된 팩트는 병원 방 배정에 관한 것이다. 병원 방 배정 기록들은 어느 방들이 어느 MZ들에 속하는지를 정의하는 RDF 트리플들의 세트일 수 있고, 예를 들어 이하의 RDF 트리플은 빌딩-1의 방-109가 MZ-1에 속하는 것을 기술한다:

· 팩트-c: 빌딩-1의 방-109가 MZ-1 하에 관리된다.

· .....

팩트-c 없이, 시맨틱 추론은 이 예에서 추론 프로세스의 입력들로서 충분한 팩트들의 부족으로 인해 여전히 도움이 될 수 없다.

특징-2를 활용함으로써, SRF는 이제 예-1에 예시된 바와 같은 문제를 해결할 수 있다. 예를 들어, 추론 규칙(RR-2)은 다음과 같이 정의될 수 있다:

· RR-2: X가 ontologyA:VideoCamera의 인스턴스이면, X는 또한 ontologyB:VideoRecorder의 인스턴스이다.

여기서 X는 변수이고 추론 프로세스 동안 특정 인스턴스(예컨대, 예-1에서의 <카메라-11>)에 의해 대체될 것이다. SPARQL 엔진은 SPARQL 문-I를 처리할 때, (inputFS로서의) 팩트-a를 통해 (RS로서의) RR-2를 적용할, 시맨틱 추론기(SR)에서 시맨틱 추론 프로세스를 추가로 트리거링할 수 있다. 다음과 같은 새로운 팩트를 포함하는 inferredFS가 생성될 수 있다:

· 추론된 팩트-a: 카메라-11은 ontologyB:VideoRecorder이다.

SPARQL 엔진은 이제 SPARQL 문-I에서 패턴 "?device is-a ontologyB:VideoRecorder"을 일치시키기 위해 추론된 팩트-a를 이용할 수 있다. 그 결과, SRF의 도움으로, <카메라-11> 리소스가 이제 시맨틱 리소스 발견 동안 원하는 리소스로서 식별될 수 있다.

SRF의 특징-2는 또한 예-2에 예시된 바와 같은 문제를 해결할 수 있다. 예를 들어, SPARQL 엔진은 SPARQL 문-II를 처리할 때, SR에서 시맨틱 추론 프로세스를 추가로 트리거링할 수 있다. 특히, SR은 (RS로서의) RR-1이 이용되어야 한다고 결정한다. 한편, SR의 로컬 정책은 RR-1을 성공적으로 적용하기 위해, 기존의 팩트-b가 충분하지 않고, 추가적인 팩트-c가 추론 프로세스의 입력으로서 또한 이용되어야 한다는 것으로 구성할 수 있다(예컨대, 팩트-c는 빌딩-1의 방-109가 MZ-1에 속하는 것을 정의하는 병원 방 배정 기록이다). 이 경우, inputFS는 2개의 부분, 즉 initial_InputFS(예컨대, 팩트-b) 및 additional_InputFS(예컨대, 팩트-c)로 추가로 카테고리화된다. 그 결과, "조합된 inputFS"(예컨대, 팩트-b 및 팩트-c)를 통해 RR-1을 적용함으로써, inferredFS가 생성될 수 있으며, 이는 다음의 새로운 팩트를 포함한다:

· 추론된 팩트-b: 카메라-11은 MZ-1 내의 방을 모니터링한다.

SPARQL 엔진은 이제 SPARQL 문-II에서 질의 패턴 "?device monitors-room-in MZ-1"을 일치시키기 위해 추론된 팩트-c를 추가로 이용할 수 있다. 그 결과, <카메라-11>은 이제 예-2에서의 시맨틱 리소스 발견 동작에서 성공적으로 식별될 수 있다.

전체적으로, 특징-2의 일반적인 흐름은 (발신자로서의) oneM2M 사용자들이 (시맨틱 리소스 발견, 시맨틱 질의 등과 같은) 원하는 시맨틱 동작들에 대한 요청들을 특정 수신기 CSE들에 전송할 수 있다는 것이다. 요청 처리 동안, 수신기 CSE는 추론 능력을 추가로 활용할 수 있다. 추론 결과를 이용함으로써, 수신기 CSE는 발신자에 의해 요청된 시맨틱 동작에 대한 최종 결과(예컨대, 시맨틱 질의 결과 또는 시맨틱 발견 결과)를 추가로 생성할 것이고, 그 후 응답을 다시 발신자에게 전송할 것이다.

특징-3: 개별적인 시맨틱 추론 프로세스를 가능하게 하는 것이 아래에 개시되어 있다: 특징-2에 의해 지원되는 바와 같은 이용 사례들에 더하여, 시맨틱 추론 프로세스는 또한 (도 35에서 화살표들(383)로 예시되는) oneM2M 사용자들에 의해 개별적으로 트리거링될 수 있다. 다시 말해서, 시맨틱 추론 프로세스는 반드시 특징-2에서 고려되는 바와 같은 다른 시맨틱 동작들과 결합될 필요는 없다. 특징-3에서, oneM2M 사용자들은 시맨틱 추론 프로세스를 트리거링함으로써 SRF와 직접 상호작용할 수 있다. 그렇게 하기 위해, oneM2M 사용자는 먼저 (initial_inputFS로서의) 관심있는 팩트들은 물론, 그들의 애플리케이션 요구들에 기반한 (RS로서의) 원하는 추론 규칙들을 식별할 것이다. inputFS 및 RS가 식별될 때, oneM2M 사용자는 추론 입력들(예컨대, 식별된 initial_inputFS 및 RS)을 명시함으로써 특정 시맨틱 추론 프로세스를 트리거링하기 위한 요청을 SR로 전송할 것이다. SR은 사용자에 의해 표시된 바와 같은 입력들에 기반하여 시맨틱 추론 프로세스를 개시할 수 있다. 특징-2와 유사하게, SR은 또한 사용자로부터의 입력들이 불충분하다면 어떤 추가적인 FS 또는 RS가 활용될 필요가 있는지를 결정할 수 있다. SR이 시맨틱 추론 결과를 도출하면, 이는 그 요구에 따라 oneM2M 사용자에게 다시 회신될 것이다. 통상적으로, 이하의 사례들은 특징-3에 의해 지원될 수 있다.

제1 사례(사례-1)에서, oneM2M 사용자는 상위 레벨 지식을 획득하기 위해 하위 레벨 데이터에 대한 시맨틱 추론을 수행하기 위해 SRF를 이용할 수 있다. 예를 들어, 회사는 건강 모니터링 제품을 클라이언트들에게 판매하고, 이 제품은 사실상 시맨틱 추론 능력을 활용한다. 이 제품에서, 피스 중 하나는 (oneM2M 사용자로서 동작하는) 건강 모니터링 앱이다. 이 앱은 심장 마비 진단/예측 추론 규칙을 이용하여 특정 페이턴트 A로부터 수집된 실시간 생체 데이터(예컨대 혈압, 심장 박동 등)에 대해 시맨틱 추론 프로세스를 수행하라고 SRF에게 요청할 수 있다. 이 프로세스에서, 심장 마비 진단/예측 추론 규칙은 환자 A 자신의 건강 프로파일 및 그/그녀의 과거 심장 마비 이력에 기반하여 고도로 맞춤화될 수 있는 사용자-정의된 규칙이다. 이러한 방식으로, 건강 모니터링 애플리케이션은 하위 레벨의 생체 데이터(예를 들어, 혈압, 심장 박동 등)를 다룰 필요가 없고, (모든 진단/예측 비즈니스 논리들이 SRF에 의해 이용되는 추론 규칙에서 이미 정의되었기 때문에) 환자 A의 심장 마비 위험의 결정으로부터 벗어날 수 있다. 그 결과, 건강 모니터링 앱은 단지 추론 결과(예컨대, "이용 준비 완료 또는 상위 레벨" 지식인 환자 A의 현재 심장 마비 위험)를 이용하고 필요한 경우에 의사에게 경보를 전송하거나 구급차를 위한 호출(911)을 전송하면 된다.

제2 사례(사례-2)에서, oneM2M 사용자는 SRF를 이용하여 기존의 데이터를 풍부하게 하는 시맨틱 추론을 수행할 수 있다. 여전히 예-1을 예로서 이용하면, oneM2M 사용자(예컨대, 카메라-11의 소유자)는 특징-3 및 RR-2를 이용하여 <카메라-11>의 시맨틱 주석부기(예컨대, 기존의 팩트들로서 팩트-a 및 팩트-b)에 대해 시맨틱 추론 프로세스를 선행적으로 트리거링할 수 있다. 시맨틱 추론 결과(예컨대, 추론된 팩트-a)는 또한 <카메라-11>에 관한 하위 레벨 시맨틱 메타데이터이고, 장기간 유효 팩트이므로, 이러한 새로운/추론된 팩트는 <카메라-11>의 시맨틱 주석부기들에 추가로 추가/통합될 수 있다. 다시 말해서, 기존의 팩트들은 이제 추론된 팩트에 의해 "풍부해지거나 증강된다". 그 결과, <카메라-11>은 미래의 시맨틱 리소스 발견 동작들에 의해 발견될 더 많은 기회를 얻을 수 있다. 이러한 풍부화로부터의 다른 이점은, 미래의 시맨틱 리소스 발견 동작들이 특징-2에 의해 지원되는 바와 같이 매번 배경에서의 시맨틱 추론을 추가로 트리거링할 필요가 없다는 것이며, 이는 처리 오버헤드 및 응답 지연을 감소시키는 것을 돕는다. 그러나, 추론된 팩트들을 모든 이용 사례들에서 기존의 팩트들과 통합하는데 적용가능하지 않을 수 있다는 점이 주목할 가치가 있다. 예-2를 예로서 취하면, 추론된 팩트-b(예컨대, "카메라-11이 MZ-1 내의 방을 모니터링한다")는 비교적 상위 레벨 지식이며, 이는 하위 레벨의 시맨틱 메타데이터(예컨대, 팩트-a 및 팩트-b)와 통합되는 것이 적절하지 않을 수 있다. 한편, 병원 방 배정이 때때로 재배열될 수 있기 때문에, 추론된 팩트-b는 단지 단기 유효 팩트일 수 있다. 예를 들어, 최근의 방 재배정 후에, 카메라-11은 MZ-1에 속하는 방을 모니터링하지 않지만, 카메라-11은 여전히 빌딩-1의 방-109에 위치하지만(예컨대, 팩트-a 및 팩트-b는 여전히 유효하지만), 이 방은 이제 다른 목적을 위해 이용되고 이후 상이한 MZ에 속한다(예컨대, 추론된 팩트-b는 더 이상 유효하지 않고, 삭제될 필요가 있다). 따라서, 이러한 유형의 추론된 팩트 또는 지식을 대규모 카메라들의 시맨틱 주석부기들에 직접 통합하는 것은 의미가 없으며, 아니면 이것은 잠재적으로 상당한 주석부기 업데이트 오버헤드를 초래한다. 특징-2 및 특징-3 둘 다는 SRF의 필요한 특징들이고, 이들 각각은 상이한 사용자 사례들을 각각 지원하는 것임을 알 수 있다.

전체적으로, 특징-3의 일반적인 흐름은 (발신자로서의) oneM2M 사용자들이 추론 능력을 갖는 특정 수신기 CSE들에 요청들을 전송할 수 있다는 것이다. 따라서, 수신기 CSE는 원하는 입력들(예컨대, inputFS 및 RS)을 이용하여 추론 프로세스를 수행하고 추론 결과를 생성하고 마지막으로 응답을 발신자에게 다시 전송할 것이다.

본 개시내용과 연관된 추가적인 고려사항들이 본 명세서에 개시된다. 많은 개념들, 용어들, 이름들이 동등한 이름들을 가질 수 있다. 따라서, 이하는 표 45의 예시적인 리스트이다.

<표 45>

도 37a는 시맨틱 추론 지원 동작의 인에이블링과 연관된 하나 이상의 개시된 개념이 구현(예를 들어, 도 7 내지 도 15 및 이에 수반한 논의)될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT) 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 계층 등의 구성요소일 수 있다.

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

도 37a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치(end-to-end M2M deployment)의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들(area networks)을 지칭한다. 필드 도메인은 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(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 링크, 및 배선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 37b를 참조하면, 필드 도메인에서의 도시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), 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')은 하나 이상의 서버, 컴퓨터, 가상 기계(예를 들어, 클라우드/컴퓨터/스토리지 팜들 등) 등에 의해 구현될 수 있다.

또한, 도 37b를 참조하면, M2M 서비스 계층(22 및 22')은 다양한 애플리케이션들과 버티컬들(verticals)이 활용할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용할 수 있게 하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 청구, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능들을 구현하는 애플리케이션들의 부담을 없애고, 이에 따라 애플리케이션 개발을 단순화하고, 마케팅 비용과 시간을 감소시킨다. 서비스 계층(22 및 22')은 또한 서비스 계층(22 및 22')이 제공하는 서비스들과 관련하여 M2M 애플리케이션들(20 및 20')이 다양한 네트워크들(12 및 12')을 통해 통신하는 것을 가능하게 한다.

일부 예들에서, M2M 애플리케이션들(20 및 20')은 본 명세서에 개시된 바와 같이 시맨틱 추론 지원 동작들을 이용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아닌, 운송, 건강 및 보건, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 전술한 바와 같이, M2M 서비스 계층, 디바이스들에 걸쳐 실행하는 것, 게이트웨이들, 및 시스템의 다른 서버들은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들의 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.

본 출원의 시맨틱 추론 지원 동작은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층은 API들(application programming interfaces) 및 하위 네트워킹 인터페이스들의 세트를 통해 추가 가치의 서비스 능력들을 지원하는 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어 상에서 구현되는 디바이스, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M과 oneM2M 둘 다는 본 출원의 시맨틱 추론 지원 동작을 포함할 수 있는 서비스 계층을 이용한다. oneM2M 서비스 계층은 공통 서비스 기능들(CSF들)(예컨대, 서비스 능력들)의 세트를 지원한다. CSF들 중의 하나 이상의 특정 유형의 세트의 인스턴스화는 공통 서비스 엔티티(CSE)라고 지칭되며, 이는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있다. 또한, 본 출원의 시맨틱 추론 지원 동작은 본 출원의 시맨틱 추론 지원 동작과 같은 서비스들에 액세스하기 위해 SOA(Service Oriented Architecture) 또는 ROA(resource-oriented architecture)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

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

도 37c는 예를 들어 (AE(331)를 포함할 수 있는) M2M 단말 디바이스(18) 또는 (도 13 내지 도 15의 하나 이상의 구성요소를 포함할 수 있는) M2M 게이트웨이 디바이스(14)와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 37c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 트랜시버(34), 전송/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시되는 주제와 일관성을 유지하면서 전술한 요소들의 임의의 서브-조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스(30)(예컨대, CSE(332), AE(331), CSE(333), CSE(334), CSE(335), 및 다른 것들)는 시맨틱 추론 지원 동작들을 위해 개시된 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

프로세서(32)는, 범용 프로세서, 특수 목적 프로세서, 기존의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 관련되는 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 IC(integrated circuit), 상태 기계 등일 수 있다. 프로세서(32)는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 신호 코딩, 데이터 처리, 전력 제어, 입/출력 처리 또는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 전송/수신 요소(36)와 결합될 수 있는 트랜시버(34)와 결합될 수 있다. 도 37c가 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 묘사하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션 계층 프로그램들(예를 들어, 브라우저들) 또는 무선 액세스 계층(RAN) 프로그램들 또는 통신들을 수행할 수 있다. 프로세서(32)는 예를 들어, 액세스 계층 또는 애플리케이션 계층 등에서의 인증, 보안 키 일치 또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.

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

또한, 전송/수신 요소(36)가 단일 요소로서 도 37c에 묘사되지만, 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(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, M2M 디바이스(30) 상에 물리적으로 위치되지 않는 메모리로부터의 정보에 액세스할 수 있고, 이에 데이터를 저장할 수 있다. 프로세서(32)는 본 명세서에서 설명된 예들 중 일부에서의 시맨틱 추론 지원 동작들이 성공인지 또는 실패인지(예를 들어, 시맨틱 추론 리소스들을 획득하는 것 등)에 응답하여 디스플레이 또는 표시기들(42) 상의 조명 패턴들, 이미지들, 또는 컬러들을 제어하거나, 아니면 시맨틱 추론 지원 동작 및 연관된 구성요소들의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시기들(42) 상의 제어 조명 패턴들, 이미지들 또는 컬러들은 본 명세서에서 예시되거나 논의된 도면들(예를 들어, 도 6 내지 도 36 등)에서의 방법의 흐름들 또는 구성요소들 중 임의의 것의 상태를 반영할 수 있다. 본 명세서에는 시맨틱 추론 지원 동작의 메시지들 및 절차들이 개시된다. 메시지들 및 절차들은 사용자들이 입력 소스(예컨대, 스피커/마이크로폰(38), 키패드(40), 또는 디스플레이/터치패드(42))를 통해 서비스 계층 관련 정보를 요청하기 위한 인터페이스/API를 제공하도록 확장될 수 있다. 추가 예에서, 디스플레이(42) 상에 표시될 수 있는 다른 것들 중에서도, 시맨틱 추론 지원의 요청, 구성, 또는 질의가 존재할 수 있다.

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

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

프로세서(32)는 다른 주변기기들(52)에 또한 결합될 수 있으며, 이러한 주변기기들은, 추가적인 특징들, 기능, 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 또는 하드웨어 모듈을 포함할 수 있다. 예를 들어, 주변기기들(52)은 가속도계, 생체측정(예컨대, 지문) 센서들, 전자 나침반(e-compass), 위성 트랜시버, 센서와 같은 다양한 센서들, 디지털 카메라(사진 또는 비디오용), USB(universal serial bus) 포트 또는 다른 상호 접속 인터페이스들, 진동 디바이스, 텔레비전 트랜시버, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

전송/수신 요소들(36)은, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스(eHealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차 또는 비행기와 같은 차량 등의 다른 장치들 또는 디바이스들에 구현될 수 있다. 전송/수신 요소들(36)은, 주변기기들(52) 중 하나를 포함할 수 있는 상호 접속 인터페이스와 같은 하나 이상의 상호 접속 인터페이스를 통해 이러한 장치들 또는 디바이스들의 다른 구성요소들, 모듈들 또는 시스템들에 접속될 수 있다.

도 37d는 예를 들어 도 37a 및 도 37b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예로서, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있고 이러한 명령어들이 무슨 수단에 의하든 저장되거나 액세스되는 컴퓨터 판독가능한 명령어들에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 수행하게 하도록 CPU(91) 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라고 지칭되는 단일-칩 CPU에 의해 구현된다. 다른 기계들에서, 중앙 처리 유닛(91)은 복수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 CPU(91)를 보조하는, 주요 CPU(91)와는 별개인, 임의의 프로세서이다. CPU(91) 또는 코프로세서(81)는 시맨틱 추론 리소스들을 획득하는 것과 같은 시맨틱 추론 지원 동작을 위한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

동작에 있어서, 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)은 컴퓨팅 시스템(90)을 도 37a 및 도 37b의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는데 이용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

본 명세서에서 설명된 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 모두가 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들(예컨대, 프로그램 코드)의 형태로 구현될 수 있고, 명령어들은 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 기계에 의해 실행되는 경우, 본 명세서에서 설명된 시스템들, 방법들 및 프로세스들을 수행 또는 구현한다는 것이 이해된다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체는 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 모두를 포함하지만, 이러한 컴퓨터 판독가능한 저장 매체는 신호들을 그 자체로 포함하지 않는다. 본 명세서의 설명으로부터 명백한 바와 같이, 저장 매체는 법정 주제인 것으로 해석되어야 한다. 컴퓨터 판독가능한 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 저장소, 자기 카세트들, 자기 테이프, 자기 디스크 저장소 또는 다른 자기 저장소 디바이스들, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함한다. 컴퓨터 판독가능한 저장 매체는 저장된 컴퓨터 프로그램을 가질 수 있고, 컴퓨터 프로그램은 데이터 처리 유닛에 로딩될 수 있으며, 컴퓨터 프로그램의 시맨틱 추론 지원 동작들이 데이터 처리 유닛에 의해 실행될 때 데이터 처리 유닛이 방법의 단계들을 실행하게 하도록 적응될 수 있다.

도면들에 도시되는 바와 같이, 시맨틱 추론 지원 동작의 인에이블링 등의 본 개시내용의 주제의 바람직한 방법들, 시스템들, 또는 장치들을 설명함에 있어서, 구체적인 용어가 명료성을 위해 사용된다. 그러나, 청구되는 주제는 그와 같이 선택되는 구체적인 용어로 제한되는 것으로 의도되는 것이 아니며, 각각의 구체적인 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함하는 것으로 이해되어야 한다.

본 명세서에 설명되는 다양한 기술들은 하드웨어, 펌웨어, 소프트웨어 또는, 적절한 경우, 이들의 조합들과 관련하여 구현될 수 있다. 이러한 하드웨어, 펌웨어, 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치되는 장치들에 존재할 수 있다. 이러한 장치는 본 명세서에서 설명된 방법들을 수행하기 위해 단독으로 또는 서로 조합하여 동작할 수 있다. 본 명세서에서 사용되는 바와 같이, 용어들 "장치", "네트워크 장치", "노드", "디바이스", "네트워크 노드" 등은 상호교환 가능하게 사용될 수 있다. 또한, "또는"이라는 단어의 사용은 본 명세서에서 달리 제공되지 않는 한 일반적으로 포함적인 것으로 사용된다.

이러한 작성된 설명은 예들을 이용하여 최선의 모드를 포함하는 주제를 개시하고, 또한 관련 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작 및 이용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 청구된 주제를 실시할 수 있게 한다. 본 주제의 특허가능한 범위는 청구항들에 의해 정의되며, 관련 기술분야의 통상의 기술자에게 떠오르는 다른 예들(예를 들어, 본 명세서에 개시된 예시적인 방법들 사이에서의 단계들의 스킵, 단계들의 결합 또는 단계들의 추가)을 포함할 수 있다. 예를 들어, 단계(344)는 스킵될 수 있다. 다른 예에서, 단계들(204) 및 단계들(205)은 스킵되거나 추가될 수 있다. 이러한 다른 예들은, 이들이 청구항들의 문자 그대로의 표현과 상이하지 않은 구조적 요소들을 가지거나, 또는 이들이 청구항들의 문자 그대로의 표현과 실질적인 차이가 없는 등가의 구조적 요소들을 포함하면, 청구항들의 범위 내에 있는 것으로 의도된다.

본 명세서에서 설명된 바와 같은, 특히, 방법들, 시스템들 및 장치들은 추론 지원을 통해 서비스 계층 시맨틱을 제공하거나 관리하기 위한 수단을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독가능한 저장 매체, 또는 장치는 시맨틱 추론 요청 및 제1 팩트 세트에 관한 정보와 제1 규칙 세트에 관한 정보를 포함하는 메시지를 획득하는 수단; 메시지에 기반하여, 제1 팩트 세트 및 제1 규칙 세트를 검색하는 수단; 제1 팩트 세트 및 제1 규칙 세트에 기반하여 추론된 팩트를 추론하는 수단; 및 후속 시맨틱 동작들을 위해 장치 상에 추론된 팩트 세트를 저장하기 위한 명령어들을 제공하는 수단을 갖는다. 제1 팩트 세트에 관한 정보는 제1 팩트 세트에 대한 통합 리소스 식별자를 포함할 수 있다. 제1 팩트 세트에 관한 정보는 제1 팩트 세트와 연관된 온톨로지를 포함할 수 있다. 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 것은 또한 제1 규칙 세트와 연관된 온톨로지와 일치하는 제1 팩트 세트에 관한 정보에 기반할 수 있다. 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 것은 또한 장치의 구성 표에서 키워드와 일치하는 제1 팩트 세트에 관한 정보에 기반할 수 있다. 동작들은 제1 팩트 세트 및 제1 규칙 세트에 기반하여 추론된 팩트를 추론하는 것을 추가로 포함할 수 있다. 후속 시맨틱 동작은 시맨틱 리소스 발견을 포함할 수 있다. 후속 시맨틱 동작은 시맨틱 질의를 포함할 수 있다. 장치는 시맨틱 추론기(예컨대, 공통 서비스 엔티티)일 수 있다. 이 단락의 모든 조합들(단계들의 제거 또는 추가를 포함함)은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

Claims (15)

1. 서비스 계층에서의 시맨틱 추론을 위한 장치로서,
   프로세서; 및
   상기 프로세서와 결합된 메모리
   를 포함하고,
   상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 실행하게 하는 저장된 실행가능한 명령어들을 포함하며, 상기 동작들은,
   시맨틱 추론 요청 및 제1 팩트 세트에 관한 정보와 제1 규칙 세트에 관한 정보를 포함하는 메시지를 획득하는 것;
   상기 메시지에 기반하여, 상기 제1 팩트 세트 및 상기 제1 규칙 세트를 검색하는 것;
   상기 제1 팩트 세트 및 상기 제1 규칙 세트에 기반하여 추론된 팩트를 추론하는 것; 및
   후속 시맨틱 동작을 위해 상기 장치 상에 추론된 팩트 세트를 저장하기 위한 명령어들을 제공하는 것
   을 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
2. 제1항에 있어서,
   상기 제1 팩트 세트에 관한 정보는 상기 제1 팩트 세트에 대한 통합 리소스 식별자(uniform resource identifier)를 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
3. 제1항에 있어서,
   상기 제1 팩트 세트에 관한 정보는 상기 제1 팩트 세트와 연관된 온톨로지를 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
4. 제1항에 있어서,
   상기 동작들은 검색된 제1 팩트 세트 및 제1 규칙 세트에 기반하여, 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 것을 더 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
5. 제1항에 있어서,
   상기 동작들은 상기 제1 규칙 세트와 연관된 온톨로지와 일치하는 상기 제1 팩트 세트에 관한 정보에 기반하여, 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 것을 더 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
6. 제1항에 있어서,
   상기 동작들은 상기 장치의 구성 표에서 키워드와 일치하는 상기 제1 팩트 세트에 관한 정보에 기반하여, 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 것을 더 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
7. 제1항에 있어서,
   상기 후속 시맨틱 동작은 시맨틱 리소스 발견을 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
8. 제1항에 있어서,
   상기 후속 시맨틱 동작은 시맨틱 질의를 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 장치.
9. 제1항에 있어서,
   상기 장치는 시맨틱 추론기인, 서비스 계층에서의 시맨틱 추론을 위한 장치.
10. 서비스 계층에서의 시맨틱 추론을 위한 방법으로서,
    공통 서비스 엔티티에 의해, 시맨틱 추론 요청 및 제1 팩트 세트에 관한 정보와 제1 규칙 세트에 관한 정보를 포함하는 메시지를 획득하는 단계;
    상기 메시지에 기반하여, 상기 제1 팩트 세트 및 상기 제1 규칙 세트를 검색하는 단계;
    상기 제1 팩트 세트 및 상기 제1 규칙 세트에 기반하여 추론된 팩트를 추론하는 단계; 및
    후속 시맨틱 동작을 위해 상기 공통 서비스 엔티티 상에 추론된 팩트 세트를 저장하기 위한 명령어들을 제공하는 단계
    를 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 방법.
11. 제10항에 있어서,
    상기 제1 팩트 세트에 관한 정보는 상기 제1 팩트 세트와 연관된 온톨로지를 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 방법.
12. 제10항에 있어서,
    검색된 제1 팩트 세트 및 제1 규칙 세트에 기반하여, 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 단계를 더 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 방법.
13. 제10항에 있어서,
    상기 제1 규칙 세트와 연관된 온톨로지와 일치하는 상기 제1 팩트 세트에 관한 정보에 기반하여, 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 단계를 더 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 방법.
14. 제10항에 있어서,
    상기 공통 서비스 엔티티의 구성 표에서 키워드와 일치하는 상기 제1 팩트 세트에 관한 정보에 기반하여, 제2 팩트 세트 또는 제2 규칙 세트를 이용할지를 결정하는 단계를 더 포함하는, 서비스 계층에서의 시맨틱 추론을 위한 방법.
15. 컴퓨터 프로그램을 저장하는 컴퓨터 판독가능한 저장 매체로서,
    상기 컴퓨터 프로그램은, 데이터 처리 유닛에 로딩될 수 있고, 상기 컴퓨터 프로그램이 상기 데이터 처리 유닛에 의해 실행될 때 상기 데이터 처리 유닛으로 하여금 제11항 내지 제14항 중 어느 한 항에 따른 방법의 단계들을 실행하게 하도록 적응되는, 컴퓨터 판독가능한 저장 매체.

Images