KR102048648B1 - 시맨틱 IoT에 대한 Restful 오퍼레이션들 - Google Patents

Abstract

RESTful 오퍼레이션들을 위한 액세스 제어가 중앙식 시맨틱 그래프 저장소에 제공될 수 있다. 또한, 오퍼레이션들은 리소스 트리 데이터베이스에 분산된 시맨틱 트리플들에 대해 제공될 수 있다. 일례에서, 시스템은 시맨틱 디스크립터 관계 정보를 유지하기 위해 계층적 리소스 트리 메커니즘들에 분산된 시맨틱 디스크립터들을 사용할 수 있다. 메커니즘들은 시맨틱 디스크립터들의 특정 세트를 함께 사용함으로써 특정 그래프들의 맥락 내에서 시맨틱 쿼리들이 수행되게 할 수 있다. 시맨틱 오퍼레이션 목적들을 위해 그룹의 형성을 사용하는 메커니즘은 또한 상이한 서비스 엔티티들 상에 위치된 멤버들을 포함하여 그룹의 멤버들에게 시맨틱 요청들을 전개하기 위해 그룹 리소스의 사용을 가능하게 할 수 있다.

Description

시맨틱 IoT에 대한 Restful 오퍼레이션들

<관련 출원에 대한 상호 참조>

본 출원은 2015년 10월 30일자로 출원되고 발명의 명칭이 "Restful Operations For Semantic IOT"인 미국 가출원 제62/249,112호, 및 2015년 11월 9일자로 출원되고 발명의 명칭이 "Restful Operations For Semantic IOT"인 미국 가출원 제62/252,940호의 이익을 주장한다. 상기 참조된 출원들 각각의 내용들은 그 전체가 본 명세서에 참조로 포함된다.

시맨틱 웹(Semantic Web)

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

시맨틱 웹 스택(Semantic Web Stack)

시맨틱 웹 스택(Description of W3C Technology Stack Illustration, http://www.w3.org/Consortium/techstack-desc.html 참조)은 도 1에 도시된 바와 같이 W3C에 의해 지정된 시맨틱 웹의 아키텍처를 예시한다. 구성 요소들의 기능들 및 관계들은 다음과 같이 요약될 수 있다.

XML은 문서들 내의 컨텐츠 구조에 대한 기본 신택스를 제공하지만, 아직 어떠한 시맨틱스도 그 안에 포함된 컨텐츠의 의미와 연관시키지 않는다. Turtle과 같은 대안적인 신택스들이 존재하기 때문에, 대부분의 경우들에서 XML은 시맨틱 웹 기술들의 필수 구성 요소가 아니다. Turtle은 사실상 표준이지만, 공식적인 표준화 프로세스를 거치지는 않았다.

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

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

RDF 스키마는 RDF를 확장하며, RDF 기반 리소스들의 속성들과 클래스들의 일반화된 계층들에 대한 시맨틱스에 의해 이러한 속성들과 클래스들을 기술하기 위한 어휘이다.

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

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

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

SPARQL 1.1 Update는 RDF 그래프들에 대한 업데이트 언어이다. 이것은 RDF에 대한 SPARQL Query 언어로부터 파생된 신택스를 사용한다. Update 오퍼레이션들은 시맨틱 그래프 저장소의 그래프들의 모음에 대해 수행된다. 오퍼레이션들은 시맨틱 그래프 저장소의 RDF 그래프들을 업데이트, 생성 및 제거하기 위해 제공된다.

RIF는 W3C 규칙 교환 포맷(Rule Interchange Format)이다. 이것은 컴퓨터들이 실행할 수 있는 웹 규칙들을 표현하기 위한 XML 언어이다. RIF는 방언(dialect)들이라고 하는 다수의 버전들을 제공한다. 이것은 RIF-BLD(RIF Basic Logic Dialect) 및 RIF PRD(RIF Production Rules Dialect)를 포함한다.

시맨틱 검색 및 시맨틱 쿼리(Semantic Search and Semantic Query)

관계형 데이터베이스(Relational Database)들은 데이터 간의 모든 관계들을 암시적인 방식으로만 포함한다. 예를 들어, 고객들과 제품들 간의 관계(2개의 컨텐츠 테이블에 저장되고, 추가적인 링크 테이블과 연결됨)는 개발자에 의해 작성된 쿼리문(예를 들어, SQL은 관계형 데이터베이스들의 경우에 사용된다)에서만 존재하게 된다. 쿼리를 작성하려면 데이터베이스 스키마에 대한 정확한 지식이 필요하다. 많은 관계형 데이터베이스들은 데이터가 트리형 구조로 조직되는 계층형 데이터베이스(Hierarchical Database)로서 모델링된다. 데이터는 링크들을 통해 서로 연결되는 레코드들로서 저장된다. 계층형 데이터베이스 모델의 레코드는 관계형 데이터베이스 모델의 행(또는 튜플)에 대응하고, 엔티티 타입은 테이블(또는 관계 - 패런트(parent)와 차일드(child))에 대응한다. 레코드의 검색 또는 쿼리는 SQL 또는 비-SQL 검색 엔진들에 의해 수행될 수 있다.

도 2에 도시된 바와 같이, 종래의 계층형 데이터베이스 모델은 각각의 차일드 레코드는 오직 하나의 패런트만을 갖는 반면, 각각의 패런트 레코드는 하나 이상의 차일드 레코드를 가질 수 있도록 한다. 계층형 데이터베이스로부터 데이터를 리트리브하기 위해서는, 루트 노드로부터 시작하여 전체 트리가 순회(traverse)되어야 한다. 이 구조는 관계가 일 대 다 관계로 국한되기 때문에, 간단하지만 유연하지 않다.

링크드-데이터(Linked-Data)는 데이터 간의 모든 관계들을 명시적으로 포함한다. 관계형 데이터베이스에서 기술된 상술한 예에서는, 쿼리 코드가 작성될 필요가 없다. 각각의 고객에 대한 올바른 제품이 자동으로 페치될 수 있다. 이 간단한 예는 사소하지만, 정보의 네트워크가 생성될 때, 링크드-데이터의 실제 위력이 발휘되기 시작한다(도시, 주 및 국가와 같은 지리적 공간 정보가 있는 고객들; 하위 카테고리 및 상위 카테고리 내에 자신의 카테고리들을 갖는 제품들). 이제, 시스템은 제품 범주와 특정 위치의 연결을 찾는 더 복잡한 쿼리들 및 분석들에 자동으로 응답할 수 있다. 이 쿼리에 대한 개발 노력은 생략되었다. 시맨틱 쿼리(Semantic Query)의 실행은 정보의 네트워크를 탐색하고 매치들을 찾음으로써(데이터 그래프 순회(Data Graph Traversal)라고도 함) 수행된다.

시맨틱 검색(Semantic Search)은 웹 상이든 또는 폐쇄형 시스템 내이든 간에 검색 가능한 데이터 공간에 나타나는 바와 같은 검색자의 의도와 용어들의 맥락적 의미를 이해하여 보다 적절한 결과들을 생성함으로써 검색 정확도를 향상시키려고 한다. 시맨틱 검색 시스템들은 검색, 위치, 의도 및 단어 변형의 맥락, 동의어들, 일반화된 쿼리 및 전문화된 쿼리, 관련 검색 결과들을 제공하기 위한 개념 매칭 및 자연 언어 쿼리들을 포함한 다양한 포인트들을 고려한다. Google 및 Bing과 같은 주요 웹 검색 엔진들은 시맨틱 검색의 일부 엘리먼트들을 통합한다. 시맨틱 검색은 관련성이 높은 검색 결과들을 생성하기 위해 시맨틱스 또는 언어의 의미 과학을 사용한다. 대부분의 경우, 목표는 대략적으로 관련된 키워드 결과들의 리스트를 통해 사용자를 소팅하게 하기보다는 사용자에 의해 쿼리되는 정보를 전달하는 것이다. 예를 들어, 시맨틱스는 계층적 관계형 데이터베이스에서 레코드 검색 또는 쿼리를 강화시키는 데 사용될 수 있다.

시맨틱 쿼리는 연관되고 맥락적인 성질의 쿼리들 및 분석들을 허용한다. 시맨틱 쿼리들은 데이터에 포함된 신택스, 시맨틱 및 구조 정보에 기초하여 명시적으로 및 암시적으로 파생된 정보 모두의 리트리브를 가능하게 한다. 이들은 정확한 결과들을 전달하거나(가능하게는, 하나의 단일 정보 단편의 구별되는 선택), 또는 보다 명확하지 않고 광범위한 개방형 질문들에 패턴 매칭 및 디지털 추리를 통해 대답하도록 설계되었다.

시맨틱 쿼리들은 명명된 그래프들, 링크드-데이터 또는 트리플들 상에서 작동한다. 이는 쿼리가 정보 간의 실제 관계들을 처리하고 데이터 네트워크로부터의 대답들을 추론하게 할 수 있다. 이는 보다 양호한 검색 결과를 생성하기 위해 구조화되지 않은 텍스트에서 시맨틱스(의미의 과학)를 사용하는 시맨틱 검색(예를 들어, 자연 언어 처리)과 대조된다.

기술적 관점에서 볼 때, 시맨틱 쿼리들은 데이터베이스 쿼리와 매우 유사한 정확한 관계형 오퍼레이션들이다. 이들은 구조화된 데이터 상에서 작동하므로, 따라서, 연산자들(예를 들어, >, < 및 =), 네임 스페이스들, 패턴 매칭, 하위 분류, 추이 관계(transitive relation)들, 시맨틱 규칙들 및 맥락형 전체 텍스트 검색과 같은 포괄적인 피처들을 활용할 가능성이 있다. W3C의 시맨틱 웹 기술 스택은 SQL과 유사한 신택스로 시맨틱 쿼리들을 공식화하는 SPARQL을 제공한다. 시맨틱 쿼리들은 트리플 저장소들, 그래프 데이터베이스들, 시맨틱 위키들, 자연 언어, 및 인공 지능 시스템들에서 사용된다.

시맨틱 쿼리들의 다른 양태는 관계의 타입이 지능을 시스템에 통합하는 데 사용될 수 있다는 것이다. 고객과 제품 간의 관계는 이웃과 그 도시의 관계와 근본적으로 상이한 성질을 갖는다. 후자는 시맨틱 쿼리 엔진이 맨해튼에 거주하는 고객이 뉴욕에도 살고 있는 것으로 추론하게 할 수 있는 반면에, 다른 관계들은 보다 복잡한 패턴들 및 "맥락형 분석들"을 가질 수 있다. 이 프로세스는 추론(inference) 또는 추리(reasoning)라고 불리며, 주어진 사실들에 기초하여 새로운 정보를 도출하는 소프트웨어의 능력이다.

시맨틱 사물 인터넷(Internet of Things)(IoT)

우리의 세계에 배치된 네트워크 연결형 디바이스들 및 센서들의 수의 급격한 증가는 다양한 도메인들에서 정보 통신 네트워크들 및 서비스들 또는 애플리케이션들을 변화시키고 있다. 향후 수십 년 내에, 수십 억 개의 디바이스가 스마트 그리드들, 스마트 홈들, 헬스케어, 자동차, 운송, 로지스틱스 및 환경 모니터링과 같은 다양한 영역들에서 많은 애플리케이션들 및 서비스들에 대해 대용량의 실제 데이터를 발생시킬 것으로 예측된다. 사물 인터넷(IoT)은 실제 데이터와 서비스들을 현재 정보 네트워킹에 통합할 수 있게 한다.

다양한 물리적, 사이버 및 소셜 리소스들로부터의 데이터를 통합하면 의사 결정 메커니즘들에 상황 및 맥락-인식을 통합할 수 있는 애플리케이션들 및 서비스들을 개발할 수 있으며, 보다 스마트한 애플리케이션들 및 강화된 서비스들을 생성할 수 있다. 대용량의 분산형의 이종 IoT 데이터를 처리할 때, 상호 운용성(interoperability), 자동화(automation) 및 데이터 분석들과 관련된 이슈들이 공통 디스크립션 및 데이터 표현 프레임워크들 및 머신 판독 가능하고 머신 해석 가능한 데이터 디스크립션들과 함께 사용된다. IoT에 시맨틱 기술들을 적용하면 다양한 리소스들과 데이터 제공자들과 소비자들 간의 상호 운용성을 촉진하고, 효율적인 데이터 액세스 및 통합, 리소스 발견, 시맨틱 추리 및 지식 추출을 용이하게 한다. 시맨틱 주석(semantic annotation)들이 IoT의 다양한 리소스들에 적용될 수 있다. 온톨로지들, 시맨틱 주석, 링크드 데이터 및 시맨틱 웹 서비스들과 같이 시맨틱 웹에서 개발된 일련의 기술들은 IoT를 실현하기 위한 주요 솔루션들로서 사용될 수 있다.

그러나, 실제 데이터에 시맨틱 기술들을 효과적으로 적용하기 위해 특별한 설계 고려 사항들이 고려될 것을 요구하는 IoT의 종래의 구성에 기초하여 몇 가지 도전 과제들이 있다. 도전 과제들에는 역동성(dynamicity) 및 복잡성(complexity), 확장성, 분산형 데이터 스토리지 및 쿼리, 데이터의 품질/트러스트/신뢰성, 보안 및 프라이버시, 또는 데이터의 해석(interpretation) 및 인식(perception)이 포함될 수 있다. 역동성 및 복잡성과 관련하여, 실제 데이터는 보다 일시적이며, 대부분 시간 및 위치에 종속된다. 기본 환경들의 만연성(pervasiveness) 및 변동성(volatility)은 디스크립션들을 지속적으로 업데이트하고 모니터링할 것을 요구한다. 확장성과 관련하여, IoT 데이터는 현실 세계의 상이한 현상들을 나타내기 때문에, 데이터를 사용하는 시맨틱 디스크립션 및 주석이 실제 리소스들 및 엔티티들에 대한 도메인 지식과 연관되어, 상이하고 동적인 현실 세계 상황들로 확장될 수 있어야 한다. 분산형 데이터 스토리지/쿼리와 관련하여, 대용량의 데이터 및 시맨틱 디스크립션들을 사용하면, 특히 포함된 스케일 및 역동성을 고려할 때, 스토리지 및 데이터 핸들링 메커니즘들의 효율성이 중요한 도전 과제가 된다. 데이터의 품질, 트러스트 및 신뢰성과 관련하여, IoT 데이터는 상이한 센서 디바이스들에 의해 제공되는데, 이는 IoT 데이터의 부정확성 및 변화하는 품질들에 대한 우려를 제공한다. 보안 및 프라이버시와 관련하여, IoT 데이터는 종종 개인적이다. 데이터의 보안 및 프라이버시를 제공하고 보장하기 위한 메커니즘은 IoT에서 중요한 이슈들일 수 있다. 마지막으로, 데이터의 해석 및 인식과 관련하여, 머신 판독 가능하고 해석 가능한 포맷들로 제공되는 시맨틱 디스크립션들 및 배경 지식은 머신 및 인간 센서들에 의해 생성되는 엄청난 양의 미가공 인지들(raw observations)을 인간 또는 자동화된 의사 결정 프로세스들에 의미가 있는 상위 레벨의 추상적 개념들로 변환하는 것을 지원한다. 그러나, IoT의 머신 인식은 종래의 AI 방법들이 과거에 해결하려고 시도해왔던 문제들에, 상이한 소스들로부터의 데이터의 통합 및 융합, 객체들 및 이벤트들의 기술, 데이터 집계 및 융합 규칙들, 임계치들 정의, 대규모의 데이터 스트림들의 실시간 처리, 및 품질 및 역동성 이슈들과 같은 추가적인 도전 과제들을 추가한다.

oneM2M 아키텍처

개발 중인 oneM2M 표준(전체적으로 참조로 포함되는 oneM2M-TS-0001 oneM2M Functional Architecture -V2.3.0 참조)은 "공통 서비스 엔티티(Common Service Entity)(CSE)"라 불리는 서비스 계층(Service Layer)을 정의한다. 서비스 계층의 목적은 상이한 "수직형" M2M 시스템들 및 애플리케이션들에 의해 활용될 수 있는 "수평형" 서비스들을 제공하는 것이다.

CSE는 도 3에 도시된 바와 같이 4개의 참조 포인트를 지원한다. Mca 참조 포인트는 애플리케이션 엔티티(Application Entity)(AE)와 인터페이스한다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인 내의 다른 CSE와 인터페이스하고, Mcc' 참조 포인트는 상이한 서비스 제공자 도메인 내의 다른 CSE와 인터페이스한다. Mcn 참조 포인트는 기반 네트워크 서비스 엔티티(network service entity)(NSE)와 인터페이스한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 기반 네트워크 서비스들을 CSE들에 제공한다.

CSE는 "발견(Discovery)", "데이터 관리 및 리포지토리(Data Management & Repository)"와 같은 "공통 서비스 기능(Common Service Function)(CSF)들"이라고 하는 다수의 논리 기능들을 포함한다. 도 4는 oneM2M에서 개발 중인 CSF들을 예시한다.

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

oneM2M 시스템 내에서 지원되는 다양한 엔티티들을 상호-연결하는 가능한 구성들이 도 5에 예시되어 있다.

oneM2M 아키텍처의 시맨틱 디스크립션

<semanticDescriptor> 리소스는 리소스 및 잠재적으로는 하위-리소스들과 관련된 시맨틱 디스크립션을 저장하는 데 사용된다. 이러한 디스크립션은 온톨로지들에 따라 제공될 수 있다. 시맨틱 정보는 oneM2M 시스템의 시맨틱 기능들에 의해 사용되며, 애플리케이션들 또는 CSE들에도 적용 가능하다.

통상적으로, <semanticDescriptor> 리소스는 표 1에 명시된 어트리뷰트들을 포함해야 한다. 도 6은 리소스 트리 내의 <semanticDescriptor> 리소스의 구조를 도시한다.

oneM2M에서의 시맨틱 필터링 제안들

일반적인 필터링은 요청 오퍼레이션에서 지정된 필터 기준들(oneM2M-TS-0001 oneM2M Functional Architecture - V2.3.0 section 8.1.2)을 가짐으로써 지원된다. 시맨틱 필터링을 제공하기 위해, 요청 오퍼레이션 필터 기준들에 대한 추가적인 값이 이하의 표 2에 도시된 정의와 같이 제안되었다. 다수의 인스턴스들이 사용될 수 있는데, 이는 필터 기준들을 평가하기 위한 일반적인 규칙들에 따라, "OR" 시맨틱스가 적용된다는 것을 의미하며, 예를 들어, 시맨틱스 필터 기준들에 대한 전체적인 결과는 시맨틱 필터들 중 하나 이상의 시맨틱 필터가 시맨틱 디스크립션과 매치되는 경우에 참이다.

위의 제안에서는 다음과 같은 가정들을 사용하는데, 즉, 시맨틱 디스크립션들은 RDF 트리플들로서 지정된다(예를 들어, RDF/XML, Turtle, 디스크립션 포맷과 같은 표현은 oneM2M에서 아직 완전히 지정되지는 않았다); 시맨틱스 필터 기준들이 시맨틱 디스크립션들에 대해 실행되는 SPARQL 요청들에 사용될 것이다라는 가정들을 사용한다.

일부 경우들에서, 단일 검색에 대한 관련 시맨틱 정보가 상이한 <semanticDescriptor> 리소스들 간에 분산될 수 있다. 도 7에 제공된 예가 이 경우를 예시한다. 주어-술어-목적어 관계들을 표현하는 시맨틱 그래프가 도시되어 있으며, 이 그래프의 상이한 부분들(타원형들로 표현됨)은 상이한 <semanticDescriptor> 리소스들에 저장된다. 시맨틱 필터링은 완전한 시맨틱 그래프(의 일부분들)에 적용될 필요가 있으며, 이는 시맨틱 오퍼레이션의 실행을 위해 그래프의 여러 상이한 부분들이 합해져야 한다는 문제를 야기한다.

이 문제는 일반적으로 시맨틱 웹의 영역에서는 명백하지 않은데, 왜냐하면 클래스 인스턴스들을 식별하는 URI가 직접적으로 역참조되어(de-referenced), 개념(예를 들어, 클래스, 관계) 정보가 그 URI에 기초하여 발견될 수 있기 때문이다. oneM2M의 경우, 액세스될 수 있는 리소스들 및 시맨틱스만이 리소스 컨텐츠로서 저장된다. 이 경우, 시맨틱 인스턴스들은 제1 클래스의 구성원들이 아니기 때문에, oneM2M 경우에는 URI-기반 접근법이 적용 가능하지 않다.

종래의 SPARQL 1.1은 SERVICE 키워드를 사용하여 연합 쿼리들(federated queries)을 지원하며, 여기서 원격 SPARQL 엔드포인트의 URL이 지정될 수 있다. 이 접근법의 경우, 요청자는 어떤 시맨틱 디스크립터들이 검색에 필요한 시맨틱 인스턴스들을 포함하는지에 대해 선험적으로 알 것이므로, 시맨틱 디스크립터들이 리소스 트리들에서 분산되어 있을 때에는 이 접근법을 일반적으로 적용할 수 없다.

oneM2M에서 제시된 바와 같이, <semanticDescriptor> 리소스들 전반에 걸쳐 저장된 시맨틱 디스크립션들에 대한 시맨틱 필터링을 가능하게 하기 위한 솔루션은 resourceDescriptorLink OWL 주석 속성의 형태로 주석 링크를 도입하는 것이다. 이 주석 속성은 임의의 클래스 인스턴스에 대해 지정될 수 있고, 그 값은 <semanticDescriptor> 리소스의 URL이며, 여기서 주어진 클래스 인스턴스에 대한 추가적인 RDF 트리플들이 발견될 수 있다. 다음의 예는 도 9의 그래프들을 생성하기 위해 oneM2M 베이스 온톨로지(Base Ontology)(도 8)에서 정의되는 클래스들 및 관계들을 사용한다.

이 솔루션은 수신자 측에서의 SPARQL-기반 시맨틱 필터링 엔진을 위한 다음의 기능적 흐름을 수반한다. 첫째, SPARQL 요청으로서 공식화된 시맨틱 필터가 후보 리소스의 시맨틱 디스크립터 리소스의 컨텐츠에 대해 실행된다. 둘째, 실행 과정에서, 하나 이상의 resourceDescriptorLink 주석들을 갖는 클래스 인스턴스와 직면하는 경우, 실행이 중단된다. 셋째, resourceDescriptorLink가 참조하는 <semanticDescriptor> 리소스들 각각의 컨텐츠가 SPARQL 요청이 실행되는 컨텐츠에 추가된다(지연 평가, 대안: 실행 전에 모든 것을 페치하는 것이지만, 페치 과정에서 불필요한 정보를 가져올 수 있음). 넷째, 확대된 컨텐츠에 대해 SPARQL 요청의 실행이 계속된다.

oneM2M의 액세스 제어 정책(Access Control Policy)

도 10에 도시된 바와 같이, 종래의 <accessControlPolicy> 리소스는 privileges 및 selfPrivileges 어트리뷰트들을 포함하며, 이들 어트리뷰트들은 (accessControlOriginators에 의해 정의된) 어느 엔티티들이 (accessControlContexts에 의해 정의된) 지정된 맥락들 내에서 (accessContolOperations에 의해 정의된) 특정 오퍼레이션들을 수행할 권한을 갖고, 특정 리소스들에 대한 액세스 결정(Access Decision)을 행할 때 CSE들에 의해 사용되는지를 정의하는 액세스 제어 규칙들의 세트를 표현한다. 권한에서, 각각의 액세스 제어 규칙은 어느 AE/CSE가 어느 오퍼레이션에 대해 허용되는지를 정의한다. 따라서, 액세스 제어 규칙들의 세트들에 있어서, 세트 내의 하나 이상의 액세스 제어 규칙에 의해 오퍼레이션이 허가되는 경우, 오퍼레이션은 허가된다. <accessControlPolicy> 리소스 타입이 아닌 리소스의 경우, 이러한 리소스들에 대한 공통 어트리뷰트 accessControlPolicyIDs은 해당 리소스를 <accessControlPolicy> 리소스들에 링크하는 식별자들의 리스트를 포함한다. 이러한 리소스에 대한 CSE 액세스 결정은 <accessControlPolicy> 리소스들에서 정의된 privileges 어트리뷰트들에 의해 표현되는 액세스 제어 규칙들의 세트의 평가를 따를 것이다. selfPrivileges 어트리뷰트는 <accessControlPolicy> 리소스 자체에 대한 액세스 제어 규칙들의 세트를 표현할 것이다. <accessControlPolicy> 리소스에 대한 CSE 액세스 결정은 <accessControlPolicy> 리소스 자체에서 정의된 selfPrivileges 어트리뷰트들에 의해 표현되는 액세스 제어 규칙들의 세트의 평가를 따를 것이다.

<accessControlPolicy> 리소스는 통상적으로 표 3에 지정된 어트리뷰트들을 포함한다.

privileges 및 selfPrivileges 어트리뷰트들로 표현된 종래의 액세스 제어 규칙들의 세트는 이하에서 기술되는 3-튜플을 포함한다. accessControlOriginators는 access-control-rule-tuple의 파라미터이다. 이것은 이 액세스 제어 규칙을 사용하도록 허용된 발신자(Originator)들의 세트를 표현한다. 발신자들의 세트는 파라미터들의 리스트로서 기술되며, 여기서 파라미터의 타입들은 리스트 내에서 변할 수 있다. 표 4는 accessControlOriginators에서 지원되는 파라미터들의 타입들을 기술한다.

originatorID가 멤버로서 <AE> 또는 <remoteCSE>를 포함하는 <group> 리소스의 resource-ID이면, 리소스의 호스팅 CSE는 (예를 들어, <group> 리소스를 리트리브하는 것에 의해) 요청의 발신자가 <group> 리소스의 memberIDs 어트리뷰트의 멤버들 중 하나의 멤버와 매치되는지를 결정한다. <group> 리소스가 리트리브될 수 없거나 존재하지 않는 경우, 요청은 거절될 것이다.

accessControlContexts는 리스트를 포함하는 access-control-rule-tuple의 파라미터이며, 여기서 리스트의 각각의 엘리먼트가 존재하면, 이는 이 액세스 제어 규칙을 사용하도록 허가되는 맥락을 표현한다. 각각의 요청 맥락은 파라미터들의 세트에 의해 기술되며, 여기서 파라미터들의 타입들은 세트 내에서 변할 수 있다. 표 5는 accessControlContexts에서 지원되는 파라미터들의 타입들을 기술한다. CSE에 의한 액세스 제어 정책 체크를 위해 다음의 종래의 발신자 accessControlContexts가 고려될 것이다.

accessControlOperations는 이 액세스 제어 규칙을 사용하여 권한 부여되는 오퍼레이션들의 세트를 표현하는 access-control-rule-tuple의 파라미터이다. 표 6은 accessControlOperations에 의해 권한 부여되는 지원되는 오퍼레이션들의 세트를 기술한다. CSE에 의한 액세스 제어 정책 체크를 위해 다음의 accessControlOperations이 고려될 것이다.

M2M 시맨틱스 지원의 제안되는 기능 아키텍처

도 11은 M2M 시맨틱 지원을 위해 제안되는 기능 아키텍처를 도시하며, 주요 컴포넌트들은 리소스 리포지토리, 온톨로지 프로세서, 온톨로지 리포지토리, 시맨틱스 리포지토리, 규칙 리포지토리, 리즈너(reasoner) 또는 시맨틱스 쿼리 프로세서를 포함할 수 있다. 리소스 리포지토리는 물리적 M2M 디바이스들로부터 수집되는 모든 리소스들을 저장한다. M2M 시맨틱 지원은 원래의 리소스들에 대한 보편적인 이해/해석뿐만 아니라 이들에 대한 임의의 고급 처리, 예를 들어, 시맨틱 쿼리, 데이터 분석들 등을 위해 이들에 대한 시맨틱스를 가능하게 하도록 의도된다. 온톨로지 프로세서는 M2M 도메인의 외부 및 내부에 게시/생성되는 온톨로지들의 발견 기능을 처리, 분류, 저장 및 제공하는 역할을 한다. 온톨로지 리포지토리는 온톨로지들을 저장한다. 이러한 온톨로지들은 리소스들에 대한 시맨틱스를 가능하게 하는 데 사용될 수 있다. 시맨틱스 리포지토리는 특정 표현들로 주석이 달린 시맨틱스 정보를 저장하며, 이는 RDF를 활용하는 옵션을 가질 수 있다. 시맨틱스 주석은 바이너리 스트림과 같은 구체적인 포맷으로 리소스의 시맨틱스를 표현하는 프로세스이다. 규칙 리포지토리는 종종 리소스 리포지토리의 리소스들과 연관되는 기존의 시맨틱스를 넘어서는 새로운 지식을 표현하는 데 사용되는 규칙들을 저장한다. 규칙들은 통상적으로 조건문들: if-then 절들이다. 리즈너는 규칙 리포지토리로부터의 입력과 시맨틱스 리포지토리 내의 기존의 리소스 시맨틱스 정보를 취하여, 규칙들의 조건들이 충족되는 경우, 새로운 리소스 시맨틱스 정보를 생성한다. 새로운 리소스 시맨틱스 정보가 시맨틱스 리포지토리에 추가된다. 시맨틱스 쿼리 프로세서는 클라이언트들로부터의 쿼리들을 핸들링하여, 시맨틱스 리포지토리에 저장된 리소스 시맨틱스 정보를 검색하고, 그 결과들을 클라이언트들에게 리턴한다.

본 명세서에서는 중앙식 시맨틱 그래프 저장소에 RESTful 오퍼레이션들을 위한 액세스 제어를 제공하고, 리소스 트리 데이터베이스에 분산된 시맨틱 RDF 트리플들에 대한 오퍼레이션들을 제공하는 방식들이 개시된다.

일례에서는, 중앙식 시맨틱 그래프 저장소에 시맨틱 디스크립터들이 있을 수 있다. 여기에서는, 특히, 중앙식 시맨틱 그래프 저장소에 시맨틱 디스크립터들을 갖는 아키텍처, 중앙식 시맨틱 그래프 저장소에 시맨틱 트리플들 또는 그래프들을 이용한 restful 오퍼레이션들, 액세스 제어 정책에 의해 지정된 액세스 제어 규칙들을 이용한 중앙식 시맨틱 그래프 저장소에 대한 액세스 제어, 및 시맨틱 쿼리에 의한 리소스 발견과 관련된 세부사항들이 제공된다.

다른 예에서는, 계층적 리소스 트리들에 시맨틱 디스크립터들이 있을 수 있다. 여기에서는, 특히, 계층적 리소스 트리들에 분산된 시맨틱 디스크립터들을 갖는 아키텍처, 및 계층적 리소스 트리들 및 임시 시맨틱 그래프 저장소들에 분산된 시맨틱 디스크립터들을 이용한 시맨틱 쿼리와 관련된 세부사항들이 제공된다.

다른 예에서는, 중앙식 시맨틱 그래프 저장소 및 리소스 트리들에 시맨틱 디스크립터들이 있을 수 있다. 여기에서는, 특히, 중앙식 시맨틱 그래프 저장소 및 리소스 트리들에 시맨틱 디스크립터들을 갖는 아키텍처, 및 중앙식 시맨틱 그래프 저장소 및 리소스 트리들의 시맨틱 디스크립터들을 이용한 시맨틱 쿼리와 관련된 세부사항들이 제공된다.

시맨틱 디스크립터 관계 정보를 유지하기 위해 계층적 리소스 트리 메커니즘들에 분산된 시맨틱 디스크립터들을 사용하는 아키텍처가 개시된다. 이 메커니즘들은 시맨틱 디스크립터들의 특정 세트들을 함께 사용함으로써 특정 그래프들의 맥락 내에서 시맨틱 쿼리들이 수행되게 할 수 있다. 시맨틱 오퍼레이션 목적들을 위해 그룹의 형성을 사용하는 메커니즘은 또한 상이한 서비스 엔티티들 상에 위치된 멤버들을 포함하여 그룹의 멤버들에게 시맨틱 요청들을 전개(fan out)하기 위해 그룹 리소스의 사용을 가능하게 한다.

인에이블되는 추가 기능은 전체 그룹과 연관된 합성 그래프를 중앙화된 방식으로 유지하는 것에 의한 쿼리 최적화들을 포함한다. 로컬 트리플 저장소 스토리지, 캐싱 등은 그룹 방법을 사용할 때 쿼리 처리를 추가로 최적화할 수 있다. 또한, 기능은 그룹들을 그래프 명명 규칙들과 함께 사용함으로써, 시맨틱 오퍼레이션들을 타겟으로 하고 이들을 가능한 한 특정되게 또는 넓게 함에 있어서의 보다 큰 세분화(granularity)를 포함한다.

이 발명의 내용 부분은 발명을 실시하기 위한 구체적인 내용 부분에서 이하 추가로 설명되는 개념들의 선택을 간단한 형태로 도입하기 위해 제공된다. 이 발명의 내용 부분은 청구되는 대상의 주요 피처들 또는 본질적인 피처들을 식별하기 위해 의도되지 않으며, 청구되는 대상의 범위를 제한하는 데 사용되는 것으로 의도되지도 않는다. 청구되는 대상은 본 개시내용의 임의의 부분에서 언급되는 임의의 또는 모든 단점들을 해결하는 한정사항들로 제약되지 않는다.

도 1은 시맨틱 웹의 예시적인 아키텍처를 예시한다.
도 2는 예시적인 계층형 데이터베이스를 예시한다.
도 3은 예시적인 oneM2M 아키텍처를 예시한다.
도 4는 예시적인 oneM2M 공통 서비스 기능들을 예시한다.
도 5는 oneM2M 아키텍처에 의해 지원되는 예시적인 구성을 예시한다.
도 6은 리소스 트리 내의 <semanticDescriptor> 리소스의 예시적인 구조를 예시한다.
도 7은 상이한 리소스들에 저장된 시맨틱 정보 전반에 걸친 시맨틱 필터의 예시적인 범위를 예시한다.
도 8은 예시적인 oneM2M 베이스 온톨로지를 예시한다.
도 9는 예시적인 resourceDescriptorLink를 예시한다.
도 10은 <accessControlPolicy> 리소스의 예시적인 구조를 예시한다.
도 11은 M2M 시맨틱 지원의 예시적인 기능 아키텍처를 예시한다.
도 12는 중앙식 시맨틱 그래프 저장소(Centralized Semantic Graph Store) 내의 예시적인 시맨틱 디스크립터(Semantic Descriptor)들을 예시한다.
도 13은 계층적 리소스 트리(Hierarchical Resource Tree)에 분산된 예시적인 시맨틱 디스크립터들을 예시한다.
도 14a는 중앙식 시맨틱 그래프 저장소 내의 시맨틱 디스크립터들에 대한 예시적인 아키텍처를 예시한다.
도 14b는 다수의 시맨틱 그래프 저장소들 내의 시맨틱 디스크립터들에 대한 예시적인 아키텍처를 예시한다.
도 15는 2개의 시맨틱 트리플 간의 예시적인 링크를 예시한다.
도 16은 중앙식 시맨틱 그래프 저장소에 대한 예시적인 일반 오퍼레이션 흐름을 예시한다.
도 17은 트랜짓 SE를 갖는 중앙식 시맨틱 그래프 저장소에 대한 예시적인 일반 오퍼레이션 흐름을 예시한다.
도 18은 CREATE 시맨틱 트리플들에 대한 예시적인 오퍼레이션 흐름을 예시한다.
도 19는 RETRIEVE 시맨틱 트리플들 - 시맨틱 쿼리에 대한 예시적인 오퍼레이션 흐름을 예시한다.
도 20은 UPDATE 시맨틱 트리플들에 대한 예시적인 오퍼레이션 흐름을 예시한다.
도 21은 DELETE 시맨틱 트리플들에 대한 예시적인 오퍼레이션 흐름을 예시한다.
도 22는 시맨틱 그래프 저장소에서 액세스 제어를 위해 <AccessControlTriples>를 사용하는 예를 예시한다.
도 23은 예시적인 eHealth 온톨로지 참조 모델을 예시한다.
도 24는 예시적인 액세스 제어 온톨로지 모델을 예시한다.
도 25는 시맨틱 그래프 저장소 내의 예시적인 eHealth 트리플들을 예시한다.
도 26은 액세스 제어를 갖는 예시적인 eHealth 시맨틱 쿼리를 예시한다.
도 27은 계층적 리소스 트리들에 분산된 시맨틱 디스크립터들의 예시적인 아키텍처를 예시한다.
도 28은 리소스 트리들에 분산된 시맨틱 디스크립터들을 갖는 예시적인 시맨틱 쿼리를 예시한다.
도 29는 시맨틱 그래프 저장소 및 계층적 리소스 트리들 내의 시맨틱 디스크립터들에 대한 예시적인 아키텍처를 예시한다.
도 30은 리소스 트리들 내의 시맨틱 디스크립터들 및 시맨틱 그래프 저장소 내의 시맨틱 트리플들을 이용한 시맨틱 쿼리에 대한 예시적인 방법을 예시한다.
도 31은 동일한 디스크립터들 간의 다중 resourceDescriptionLinks의 예시적인 문제점을 예시한다.
도 32는 예시적인 relatedSemantics 어트리뷰트를 예시한다.
도 33은 상이한 시맨틱 디스크립터들 전반에 걸쳐 분산된 예시적인 그래프를 예시한다.
도 34는 별개의 디스크립터들에 분산된 서브-그래프들로부터의 예시적인 합성 그래프를 예시한다.
도 35는 링크들의 리스트를 갖는 예시적인 use 또는 relatedSemantics 어트리뷰트를 예시한다.
도 36은 예시적인 <semanticGroup> 리소스를 예시한다.
도 37은 <semanticGroup>을 갖는 예시적인 use 또는 relatedSemantics 어트리뷰트를 예시한다.
도 38은 도 31에 표현된 합성 그래프의 예시적인 RDF 디스크립션을 예시한다.
도 39는 <Device12>에 대한 semanticDescriptor 디스크립터 어트리뷰트의 예시적인 컨텐츠를 예시한다.
도 40은 링크들의 리스트 방법이 사용될 때의 예시적인 relatedSemantics 어트리뷰트를 예시한다.
도 41은 링크들의 그룹 방법이 사용될 때의 예시적인 semanticGroupLinks 어트리뷰트를 예시한다.
도 42는 임의적인 그래프-기반 스킴의 <Device12>에 대한 예시적인 시맨틱 주석을 예시한다.
도 43은 임의적인 그래프-기반 스킴의 예시적인 <OperationA> 주석을 예시한다.
도 44는 링크들의 그룹 방법이 사용될 때의 예시적인 semanticGroupLinks 어트리뷰트를 예시한다.
도 45는 RelatedSemantics 링크 접근법을 사용하는 예시적인 시맨틱 쿼리를 예시한다.
도 46은 예시적인 강화된 <semanticGroup> 리소스를 예시한다.
도 47은 oneM2M을 사용하는 개시된 방법들에 대한 예시적인 아키텍처를 예시한다.
도 48은 oneM2M을 사용하는 개시된 방법들에 대한 예시적인 리소스 트리를 예시한다.
도 49a는 시맨틱 그래프 저장소 내의 예시적인 뷰들을 예시한다.
도 49b는 시맨틱 그래프 저장소와 연관된 예시적인 방법을 예시한다.
도 49c는 시맨틱 그래프 저장소와 연관된 액세스 제어를 위한 예시적인 방법을 예시한다.
도 50은 본 명세서의 방법들 및 시스템들에 기초하여 생성될 수 있는 예시적인 디스플레이를 예시한다.
도 51a는 개시된 대상이 구현될 수 있는 예시적인 M2M(machine-to-machine) 또는 IoT(Internet of Things) 통신 시스템의 시스템도이다.
도 51b는 도 51a에 예시된 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 51c는 도 51a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이다.
도 51d는 도 51a의 통신 시스템의 양태들이 구체화될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.
도 52는 시맨틱 그래프 저장소에서의 액세스 제어 정책의 예를 예시한다.
도 53a는 액세스 제어를 갖는 eHealth 시맨틱 쿼리에 대한 예 1을 예시한다.
도 53b는 액세스 제어를 갖는 eHealth 시맨틱 쿼리에 대한 예 2를 예시한다.
도 53c는 액세스 제어를 갖는 eHealth 시맨틱 쿼리에 대한 예 3을 예시한다.
도 54는 시맨틱 쿼리를 통해 리소스 발견을 수행하기 위한 예시적인 방법을 예시한다.

"시맨틱 사물 인터넷"과 관련하여 본 명세서에서 설명되는 바와 같이, 시맨틱 웹과 비교할 때 시맨틱 IoT에 대한 많은 도전 과제들이 있다. 제1 도전 과제는 특히 도 12와 연관된 사용 케이스 I에서 예시된 시나리오로서 보안 및 프라이버시이며, 중앙식 시맨틱 그래프 저장소에 대한 액세스를 제어하는 방법 및 시맨틱 그래프 저장소에 대한 액세스 제어 정책들을 효과적으로 관리하기 위한 방법이 다루어져야 한다. 다른 도전 과제는 도 13과 연관된 사용 케이스 II에 예시된 시나리오로서 RDF 트리플들일 수도 있고 아닐 수도 있는 데이터베이스(들)에 분산된 대용량의 시맨틱 디스크립터들이며, 계층적 리소스 트리들로부터 시맨틱 RDF 트리플들을 추출하고 RDF 트리플들에 대해 오퍼레이션들을 수행하는 방법이 다루어져야 한다. 사용 케이스 II의 분산형 시맨틱 디스크립터들과 관련하여, 다른 쿼리 관련 문제는 쿼리의 범위인데, 이는 검색된 그래프 또는 디스크립터들로부터 기인하는 대응하는 RDF 디스크립션의 범위로서 보일 수 있다. 이 검색은 쿼리 오퍼레이션 타겟으로서 사용되는 리소스와 연관되지만, 디폴트 범위들은 최적화되지 않은 검색 결과로 쉽게 이어질 수 있다.

본 명세서에서는, 시맨틱 IoT 서비스들 또는 애플리케이션들에 대한 시맨틱 디스크립터들에 적용되는 RESTful 오퍼레이션들을 위한 다수의 접근법들이 개시된다. 본 명세서에서는, 중앙식 시맨틱 그래프 저장소의 시맨틱 디스크립터들에 대한 메커니즘들; 계층적 리소스 트리들에 분산된 시매틱 디스크립터들에 대한 메커니즘들; 및 중앙식 그래프 저장소 및 계층적 리소스 트리들 모두에 위치된 시맨틱 디스크립터들에 대한 하이브리드 메커니즘들에 대한 세부사항들이 제공된다. 또한, 서비스 엔티티 내에서 분산된 시맨틱 디스크립터들에 대한 대안들이 논의된다. 본 명세서에서 "그래프(graph)"라는 용어의 사용은 "시맨틱 그래프(semantic graph)"등과 상호 교환 가능하다는 것이 이해되어야 한다.

사용 케이스 I은 도 12를 고려하여 논의된다. 도 12에 도시된 바와 같이, RDF 트리플들(예를 들어, 시맨틱 디스크립터들)의 형태의 시맨틱 디스크립션들이 중앙식 RDF 트리플 데이터베이스, 예를 들어, 시맨틱 그래프 저장소에 보관된다. 예를 들어, 의사-D와 의사-D의 환자 A와 B는 그들의 시맨틱 디스크립터들을 중앙식 RDF 트리플 저장소 또는 시맨틱 그래프 저장소에 저장한 다음, 환자들이 의사-D에게 허가를 승인한 경우에는, 의사-D가 모든 자신의 환자들의 시맨틱 디스크립터들에 대해 시맨틱 쿼리를 수행할 수 있고, 의사-D가 자신의 환자들에게 허가를 승인한 경우에는, 환자들 또한 그들 자신의 시맨틱 디스크립터들 및 의사-D의 시맨틱 디스크립터들 중 일부에 대해 시맨틱 쿼리를 수행할 수 있다. 그러나, 어떤 허가도 승인되지 않은 경우, 환자들은 서로의 시맨틱 디스크립터들에 대해서는 시맨틱 쿼리를 수행할 수 없다. 또한, 의사-D는 자신의 시맨틱 디스크립터들, 및 자신의 환자들에 의해 허가들이 승인되는 경우에는, 아마도 자신의 환자들의 시맨틱 디스크립터들 중 일부를 업데이트 또는 삭제할 수 있고, 마찬가지로 환자는 자신의 시맨틱 디스크립터들, 및 의사-D에 의해 허가가 승인되는 경우에는, 아마도 의사-D의 것 중 일부를 업데이트 또는 삭제할 수 있다.

사용 케이스 II는 도 13을 고려하여 논의된다. 도 13에 도시된 바와 같이, RDF 트리플들(예를 들어, 시맨틱 디스크립터들)의 형태이든 아니든 간에 데이터 및 시맨틱 디스크립션들은 모두 관계형 데이터베이스, 예를 들어, 계층적 리소스 트리에 보관된다. 예를 들어, 의사-D 및 의사-D의 환자 A와 B는 자신들의 데이터 및 시맨틱 디스크립터들을 관계형 데이터베이스 또는 계층적 리소스 트리에 저장한다. 시맨틱 디스크립터 1은 관련된 eHealth 애플리케이션과 관련된 시맨틱 정보를 기술하고, 시맨틱 디스크립터 2는 데이터 컨테이너에 대한 것이고, 시맨틱 디스크립터 3은 특정 데이터 인스턴스에 대한 것이다. 나중에, 의사-D는 시맨틱 디스크립션들을 사용하여 시맨틱 검색을 수행하거나, 환자들이 의사-D에게 허가를 승인하는 경우, 리소스 트리 내의 모든 자신의 환자의 시맨틱 디스크립터들에 대해 시맨틱 쿼리를 수행할 수 있고, 환자들은 시맨틱 디스크립션들을 사용하여 시맨틱 검색을 수행하거나, 자신의 시맨틱 디스크립터들, 및 의사-D가 리소스 트리 내의 자신의 환자들에게 허가를 승인하는 경우, 의사-D의 시맨틱 디스크립터들 중 일부에 대해 시맨틱 쿼리를 수행할 수 있다. 그러나, 어떠한 허가도 승인되지 않은 경우, 환자들은 서로의 시맨틱 디스크립터들에 대해 시맨틱 쿼리를 수행할 수 없다. 또한, 의사-D는 자신의 시맨틱 디스크립터들, 및 자신의 환자들에 의해 허가들이 승인되는 경우에는, 아마도 자신의 환자들의 시맨틱 디스크립터들 중 일부를 업데이트 또는 삭제할 수 있고, 환자는 자신의 시맨틱 디스크립터들, 및 의사-D에 의해 허가들이 승인되는 경우에는, 아마도 의사-D의 것 중 일부를 업데이트 또는 삭제할 수 있다.

일부 일반적인 고려사항들이 이하에 개시된다. 시맨틱 디스크립션은 RDF 트리플형 포맷일 수도 있고 아닐 수도 있다. 예를 들어, 특히 RDF 트리플형 S-P-O 관계 디스크립션이 아닌 일반적인 포맷의 시맨틱 디스크립션은 리소스 트리의 메타데이터 또는 맥락 정보와 같은 다른 리소스들과 동일하다. 여기서는, 예를 들어, RDF 트리플 S-P-O와 같은 관계의 시맨틱 디스크립션에 대해 논의되며, 따라서 용어 시맨틱 디스크립터 또는 시맨틱 트리플은 RDF 트리플형 포맷의 시맨틱 디스크립션에 사용된다. SPARQL은 예시의 목적으로만 RDF 트리플들에 사용된다. 솔루션들은 링크된 데이터에 대한 다른 타입들의 시맨틱스 표현식들 및 시맨틱스 쿼리 언어들에 대해 일반적이다. 본 명세서에서, 데이터는 데이터 샘플들 또는 맥락 정보(예를 들어, 메타 데이터)일 수 있는 리소스 트리의 레코드에 대해 사용되는 일반적인 용어이다. 시맨틱 트리플의 엘리먼트 또는 노드(예를 들어, 트리플 S-P-O의 S, P 또는 O)는 시맨틱 트리플 구문(semantic triple statement)에서 고유 식별자, 예를 들어, IRI(Internationalized Resource Identifier) 또는 URI(uniform resource identifier)에 의해 어드레싱될 수 있다. URI가 사용되지만, IRI 또는 다른 식별자(예를 들어, URL)도 개시된 메커니즘들에 적용될 수 있다. RDF 트리플 S-P-O의 엘리먼트 또는 노드는 URI, 빈 노드 레이블(blank node label) 또는 유니코드 문자열 리터럴(Unicode string literal)로 표현될 수 있다. 구문을 단순화하기 위해, 베이스 또는 네임 스페이스는 시맨틱 트리플들에 대한 일부 예들에서 사용되지 않는다. 시맨틱 트리플들이 RESTful 오퍼레이션 논의들에 사용되지만, 메커니즘들은, 예를 들어, SPARQL Update 1.1에 의해 지원되는 시맨틱 그래프(예를 들어, 링크된 트리플들 또는 링크된 데이터) 오퍼레이션들에도 적용될 수 있다. 하나의 섹션 또는 예의 오퍼레이션들이 다른 섹션 또는 예에 적용될 수 있다는 것이 본 명세서에서 고려된다는 점이 이해되어야 한다. 예를 들어, 중앙식 아키텍처에 대한 중앙식 시맨틱 그래프 저장소에 대한 restful 오퍼레이션들과 관련하여 본 명세서에 개시된 오퍼레이션 메시지들(예를 들어, 요청 및 응답)은 또한 계층적 리소스 트리들에 분산된 시맨틱 디스크립터들 및 시맨틱 그래프 저장소 및 계층적 리소스 트리들 내의 시맨틱 디스크립터들과 같이 본 명세서에 개시된 다른 아키텍처에 대한 오퍼레이션들에도 적용 가능하다.

도 14a에 도시된 바와 같이, 중앙식 아키텍처는 이하의 피처들을 갖는다(이하의 도 14a 및 도 14b의 논의와 추가로 관련하여 사용 케이스 I 및 II 및 도 29 참조). 시맨틱 그래프 저장소는 서비스 엔티티(service entity)(SE), 예를 들어, oneM2M의 CSE 상에 상주할 수 있고, 상이한 리소스 트리들 내의 상이한 리소스들을 가리키는 시맨틱 트리플들을 그들의 개별 URI들을 통해 포함할 수 있다. URI가 IoT 시스템에 도달할 수 있거나 액세스할 수 있는 경우, URI는 URL과 동일하다. URI들(도 14b에 예시됨)을 통해 시맨틱 트리플들에 의해 어드레싱되거나 가리켜지는 리소스들은 서비스 엔티티 상의 동일한 계층적 리소스 트리에 위치할 수도 있고(예를 들어, 모든 의사-D의 리소스들은 SE 1 상의 리소스 트리 1에 보관됨) 또는 다수의 서비스 엔티티들 상의 상이한 계층적 리소스 트리들에 위치할 수도 있다(예를 들어, 환자-A의 리소스들은 SE2 상의 리소스 트리 2에 위치되고, 환자-B의 리소스들은 SE3 상의 리소스 트리 3에 위치되고, 대응하는 시맨틱 트리플들은 SE1에 위치된다). 애플리케이션 엔티티(Application Entity)(AE), 예를 들어, oneM2M의 AE는 리소스 트리의 리소스들 또는 시맨틱 그래프 저장소의 시맨틱 트리플들 중 어느 것에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션들을 위해 인터페이스 AS, 예를 들어, oneM2M의 Mca 인터페이스를 통해 서비스 엔티티와 통신할 수 있다. 서비스 엔티티(service entity)(SE)는 리소스 트리의 리소스들 또는 시맨틱 그래프 저장소의 시맨틱 트리플들 중 어느 것에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션들을 위해 인터페이스 SS, 예를 들어, oneM2M의 Mcc 또는 Mcc' 인터페이스를 통해 다른 서비스 엔티티(SE)와 통신할 수 있다. 데이터 보관소 관리자(Data Depository Manager)는 AE 및/또는 SE와 같은 다른 외부 엔티티들 및 시맨틱 보관소 관리자 및/또는 다른 공통 기능 엔티티들과 같은 내부 엔티티들과의 데이터 교환; CREATE, RETRIEVE, UPDATE, DELETE 등에 대한 커맨드들을 통한 리소스 트리 데이터베이스 오퍼레이션들 및 관리를 담당한다. 시맨틱 보관소 관리자는 AE 및/또는 SE와 같은 다른 외부 엔티티들 및 데이터 보관소 관리자 및/또는 다른 공통 기능 엔티티들과 같은 내부 엔티티들과의 시맨틱 트리플 교환들; 또는 CREATE, RETRIEVE, UPDATE, DELETE 등에 대한 커맨드들을 통한 시맨틱 그래프 저장소 오퍼레이션들 및 관리를 담당한다.

도 14a에는 의사-D의 트리플들 및 데이터 양자가 동일한 SE 상에 위치되어 있는 것으로 도시되어 있지만, 이들이 상이한 SE들에 위치되는 것도 가능하다. 또한, 도 14a에 도시된 중앙식 시맨틱 그래프 저장소가 다른 서비스 도메인에 있는 SE, 예를 들어, 다른 서비스 제공자에 위치되는 것도 가능하다. 이 경우, RESTful 오퍼레이션들은, 예를 들어, oneM2M의 인터페이스 Mcc'를 통해 서비스 도메인들을 가로지른다.

IoT 시스템에 다수의 중앙식 시맨틱 그래프 저장소들을 갖는 다른 아키텍처가 도 14b에 예시되어 있다. 이 아키텍처에서, 시맨틱 그래프 저장소 1은 SE1에 위치되고, 시맨틱 그래프 저장소 2는 SE2에 위치된다. 시맨틱 그래프 저장소 1과 시맨틱 그래프 저장소 2 사이의 오퍼레이션들은 CREATE, RETRIEVE, UPDATE, DELETE 등에 대한 커맨드들을 통해 인터페이스 SS1, 예를 들어, oneM2M의 Mcc/Mcc' 인터페이스에서 수행될 수 있다.

도 14a에 예시된 바와 같이, 트리플들은 시맨틱 그래프 저장소에 연결되거나 링크된다. 예를 들어, 도 15에 도시된 바와 같이, 트리플 1 "Doctor D has Patient A"는 PatientA_URI를 통해 트리플 2 "Patient A has Heart Data X"와 링크된다.

<Doctor D>와 같은 리소스는 리소스 트리 1의 Doctor_URI에 저장되고, <Patient A> 및 <Heart-Data X>(도 14a에서는 도시 생략)와 같은 리소스들은 각각 리소스 트리 2의 PatientA_URI 및 HeartData_URI(도 14a에서는 도시 생략)에 저장된다.

의사-D의 eHealth 애플리케이션(예를 들어, 애플리케이션 엔티티 1)은 인터페이스 AS1을 통해 서비스 엔티티 1에서의 리소스 트리 1, 인터페이스 SS1을 통해 서비스 엔티티 1을 통과하여 서비스 엔티티 2에서의 리소스 트리 2, 및 인터페이스 SS2를 통해 서비스 엔티티 1을 통과하여 서비스 엔티티 3에서의 리소스 트리 3의 자신의 환자의 리소스들(허가가 승인된 경우)에 대한 RESFTful 오퍼레이션들을 위해 인터페이스 AS1을 통해 서비스 엔티티 1과 통신할 수 있다. 의사-D의 eHealth 애플리케이션은 인터페이스 AS1을 통해 서비스 엔티티 1에서의 시맨틱 그래프 저장소의 자신의 환자의 시맨틱 트리플들(허가가 승인된 경우)에 대해 RESTful 오퍼레이션들을 적용할 수도 있다.

환자-A의 심장 모니터 eHealth 애플리케이션(예를 들어, 애플리케이션 엔티티 2)은 인터페이스 AS2을 통해 서비스 엔티티 2에서의 리소스 트리 2, 및 인터페이스 SS1을 통해 서비스 엔티티 2를 통과하여 서비스 엔티티 1에서의 리소스 트리 1의 자신 또는 의사-D의 리소스들(허가가 승인된 경우)에 대한 RESFTful 오퍼레이션들을 위해 인터페이스 AS2를 통해 서비스 엔티티 2와 통신할 수 있다. 환자-A의 심장 모니터 eHealth 애플리케이션은 인터페이스 SS1을 통해 서비스 엔티티 2를 통과하여 서비스 엔티티 1에서의 시맨틱 그래프 저장소의 자신 또는 의사-D의 시맨틱 트리플들(허가가 승인된 경우)에 대해 RESTful 오퍼레이션들을 적용할 수도 있다.

도 16 내지 도 21 및 유사한 도면들에 예시된 단계들을 수행하는 엔티티들은 도 51c 또는 도 51d에 예시된 것들과 같은 디바이스, 서버 또는 컴퓨터 시스템의 메모리에 저장되고 이들의 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들이라는 것이 이해될 것이다. 즉, 도 16 내지 도 22, 도 27 내지 도 30, 도 45 내지 도 49 및 유사한 도면들에 예시된 방법(들)은 도 51c 또는 도 51d에 예시된 디바이스 또는 컴퓨터 시스템과 같은 컴퓨팅 디바이스의 메모리에 저장된 소프트웨어(예를 들어, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행 가능 명령어들은, 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 도 16 내지 도 22, 도 27 내지 도 30, 도 45 내지 도 49 및 유사한 도면들에 예시된 단계들을 수행한다. 일례에서는, M2M 디바이스들의 상호 작용에 관해 이하에서 더 상세히 설명되는 바와 같이, 도 29의 AE(373)는 도 51a의 M2M 단말 디바이스(18) 상에 상주할 수 있고, 도 29의 SE(361)는 도 51a의 M2M 게이트웨이 디바이스(14) 상에 상주할 수 있다.

도 16은 도 14a에 예시된 아키텍처에 대한 예시적인 일반적인 RESTful 시맨틱 트리플 오퍼레이션 흐름을 예시한다(예를 들어, 의사-D의 eHealth 애플리케이션 AE1은 시맨틱 그래프 저장소 내의 트리플들에 대한 시맨틱 트리플 또는 그래프 오퍼레이션들을 요청한다). 도 17은 도 14a에 예시된 아키텍처에 대한 예시적인 일반적인 RESTful 시맨틱 트리플 오퍼레이션 흐름을 예시한다(예를 들어, 환자-A의 심장 모니터 eHealth 애플리케이션 AE2는 시맨틱 그래프 저장소의 트리플들에 대한 시맨틱 트리플 또는 그래프 오퍼레이션들을 요청한다). 도 16 및 도 17은 AS 인터페이스(예를 들어, oneM2M의 Mca 인터페이스)를 통한 AE와 SE 사이 또는 SS 인터페이스(예를 들어, oneM2M의 Mcc 또는 Mcc' 인터페이스)를 통한 SE들 사이의 RESTful 요청 및 응답 메시지들에 기초할 수 있다. 본 명세서에서 설명되는 예시적인 메커니즘들은 또한 SE1에서의 시맨틱 그래프 저장소 1과 SE2에서의 시맨틱 그래프 저장소 2 사이의 그래프 오퍼레이션들과 같이 도 14b에 예시된 아키텍처에 대한 시맨틱 그래프 오퍼레이션들에도 적용 가능하다. 요청 메시지는 상이한 시맨틱 트리플 또는 그래프 오퍼레이션들에 기초하여 필수적, 오퍼레이션 종속적 또는 임의적 파라미터들을 포함할 수 있다. 요청 메시지는 이하의 파라미터들을 포함할 수 있으며, 이는 예들이고 반드시 옵션이거나, 필수적이거나 등등일 필요가 없다. 이것은 구현 종속적이다.

일반적인 RESTful 시맨틱 트리플 오퍼레이션 흐름들(예를 들어, 도 16 및 도 17)을 계속 참조하면, 제1 파라미터들의 세트는 리소스 발견 시의 시도와 연관된 다음을 포함할 수 있다. "To" 필드는 <SemanticGraphStore> 리소스의 어드레스 또는 ID를 포함할 수 있다. <SemanticGraphStore> 리소스는 사전 프로비저닝에 의해 또는 리소스 발견에 의해 알려질 수 있다. "From" 필드는 발신자(151)의 ID(예를 들어, AE ID 또는 SE ID)를 포함할 수 있다. 이는 시맨틱 그래프 저장소에서의 시맨틱 트리플 오퍼레이션들에 대한 발신자의 액세스 권한을 체크하기 위해 수신자(152)(예를 들어, SE)에 의해 사용될 수 있다. 오퍼레이션 필드는 CREATE(C), RETRIEVE(R), UPDATE(U), DELETE(D) 등과 같이 수행될 오퍼레이션을 포함할 수 있다. 오퍼레이션 타입은 리소스 트리에서의 리소스 오퍼레이션들을 위한 "resource", 시맨틱 그래프 저장소에서의 트리플 오퍼레이션들을 위한 "triple", 및/또는 시맨틱 그래프 저장소에서의 그래프 오퍼레이션들을 위한 "graph"일 수 있는 값들을 포함할 수 있다. 디폴트는 "resource"이다. 여기서 주어지는 예들 중 많은 것들은 트리플 및 그래프 오퍼레이션과 관련된다. 요청 식별자는 요청과 응답 사이의 상관을 위해 사용되는 요청 식별자를 포함할 수 있다.

일반적인 RESTful 시맨틱 트리플 오퍼레이션 흐름들(예를 들어, 도 16 및 도 17)을 계속 참조하면, 제2 파라미터들의 세트는 트리플 또는 그래프 오퍼레이션들에 대한 오퍼레이션 종속적 파라미터들로 간주될 수 있다. 이하에서 더 상세히 논의되는 바와 같은 컨텐츠 및 컨텐츠 포맷이 있을 수 있다. 컨텐츠는 전송될 시맨틱 컨텐츠(예를 들어, 트리플들 또는 그래프)를 포함할 수 있으며, 이는 시맨틱 트리플 또는 그래프 오퍼레이션들과 관련하여 상이하게 제시될 수 있다. 일례에서, CREATE와 관련하여, 컨텐츠는 "triple" 또는 "graph"로서 <Operation Type>을 갖는 새로운 시맨틱 트리플(들)의 컨텐츠일 수 있다. 예를 들어, “Doctor-D_URI has PatientA_URI"와 같은 트리플이 있다. 일례에서, UPDATE와 관련하여, 컨텐츠는 기존의 시맨틱 트리플(들) 또는 그래프로 대체될 컨텐츠를 포함할 수 있다. 예를 들어, 도 15에 도시된 트리플(110)에 대해 "Doctor-D_URI has PatientA_URI2"가 "Doctor-D_URI has PatientA_URI1"을 대체한다. 업데이트되거나 대체될 기존의 시맨틱 트리플 또는 그래프는 <SemanticTripleGraphIDs>(예를 들어, 그래프에 대한 고유한 명칭)에 의해 명시적으로 어드레싱되거나, 또는 이 새로운 컨텐츠를 사용하여 시맨틱 그래프 저장소의 트리플들 또는 그래프 관계 네트워크를 매치시킴으로써 시맨틱 쿼리 엔진에 의해 추론될 수 있다. 일례에서, RETRIEVE와 관련하여, 컨텐츠는 쿼리 시맨틱 트리플(들)을 포함할 수 있다. 예를 들어, "?Doctor has Patient-A"(?Doctor는 쿼리에 대한 변수임)는 환자-A의 의사들에게 쿼리하기 위한 것이다. 일례에서, DELETE와 관련하여, 컨텐츠는 삭제될 기존의 시맨틱 트리플(들) 또는 그래프의 컨텐츠를 포함할 수 있다. 기존의 시맨틱 트리플(들) 또는 그래프는 삭제를 위해 <SemanticTripleGraphIDs>(예를 들어, 그래프에 대한 고유한 명칭)에 의해 명시적으로 어드레싱되거나, 또는 이 컨텐츠를 사용하여 시맨틱 그래프 저장소의 트리플들 또는 그래프를 매치시킴으로써 시맨틱 쿼리 엔진에 의해 추론될 수 있다.

위에서 언급한 컨텐츠 포맷을 참조하면, N-Triple, JSON, RDF/XML 또는 트리플들에 대한 Turtle; 쿼리에 대한 SPARQL 또는 SQL; 또는 다른 구조화된 텍스트 또는 리터럴과 같은 컨텐츠 포맷이 시맨틱 트리플 또는 그래프 오퍼레이션 컨텐츠의 포맷으로 간주될 수 있다.

일반적인 RESTful 시맨틱 트리플 오퍼레이션 흐름들(예를 들어, 도 16 및 도 17)을 계속 참조하면, 제3 파라미터들의 세트가 고려될 수 있다. 생성자 파라미터가 있을 수 있으며, 이것은 전송될 시맨틱 컨텐츠의 생성자, 예를 들어, AE ID 또는 SE ID를 나타낸다. Semantic Triple Graph IDs 파라미터가 있을 수 있으며, 이는 발신자(151)에 의해 제시되지 않거나 시맨틱 그래프 저장소의 기존의 트리플들과 충돌하는 경우에는 수신자(152)에 의해 생성될 수 있다. Semantic Triple Graph IDs 파라미터는 시맨틱 트리플 그래프의 ID이며, 시맨틱 그래프 저장소에서 절대적이거나, 상대적이지만 고유할 수 있다. Access Control Policy IDs 파라미터가 있을 수 있으며, 여기서 수신자(152)는 발신자(151)의 ID, 및 발신자(151)에 의해 제시되지 않는 경우에는 서비스 프로파일에 기초하여 생성할 수 있다. 이 파라미터는 발신자의 액세스 제어 권한들을 체크하고, 그에 따라 오퍼레이션의 유효성을 검사하기 위해 수신자(152)에 의해 사용될 수 있다. Ontology Ref 파라미터가 있을 수 있으며, 여기서 수신자(152)는 발신자(151)의 ID, 및 발신자(152)에 의해 제시되지 않는 경우에는 서비스 프로파일에 기초하여 <OntologyRef>를 생성할 수 있다.

제3 파라미터들의 세트를 계속 참조하면, 응답 메시지 타입 파라미터, 결과 컨텐츠 파라미터 또는 필터 기준 파라미터가 있을 수 있다. 응답 메시지 타입 파라미터는 발행된 요청에 어떤 타입의 응답이 전송될 수 있는지, 및 응답이 언제 발신자(151)에게 전송될 수 있는지를 나타낼 수 있다. 특히, 통신, 트리플 오퍼레이션 레이턴시, 시스템 능력, 현재 과정 또는 로딩 상태에 기초하여, 상이한 응답 타입이 발신자(151)에 의해 요청될 수 있다. 응답 메시지 타입들은 특히 ACK sync, ACK async, NoACK sync 또는 ACKnoACK를 포함할 수 있다. ACK sync의 경우, 수신자(152)는, 수락 후에, 수신자(152)가 요청을 추가로 처리할 것임을 확인하는 확인응답으로 응답할 수 있다. 요청된 오퍼레이션의 실행의 성공 또는 실패는 나중에 전달될 것이다. ACK async{통지 타겟들의 리스트}의 경우, 수신자(152)는, 수락 후에, 수신자가 요청을 추가로 처리할 것임을 확인하는 확인응답으로 응답할 수 있다. 요청된 오퍼레이션의 결과는 통지 타겟(들)에게 통지(들)로서 전송되어야 한다. 통신 타겟(들)은 엔티티들의 리스트로서 이 파라미터 내에서 제공될 수도 있고, 또는 어떤 통지 타겟 리스트도 제공되지 않으면, 발신자(151)에게 제공될 수 있다. 빈 통지 타겟 리스트가 발신자(151)에 의해 제공되면, 요청된오퍼레이션의 결과를 갖는 어떤 통지도 전송되지 않을 수 있다. NoACK sync의 경우, 수신자(152)는, 수락 후, 요청된 오퍼레이션의 완료 후에 요청된 오퍼레이션의 결과로 응답할 수 있다. 이것은 요청에 응답 타입 파라미터가 주어지지 않을 때의 디폴트 거동일 수 있다. ACKnoACK{통지 타겟들의 리스트}의 경우, 수신자(152)는, 수락 후, 그 상태 또는 다른 서비스 정책들에 기초하여 어떻게 응답할지 - 위에서 설명된 ACK 또는 NoACK 중 어느 것에 의해 응답할지 - 를 결정할 수 있다.

결과 컨텐츠 파라미터가 있을 수 있으며, 여기서 결과 컨텐츠는 요청된 오퍼레이션의 결과의 예상되는 구성 요소들을 나타낸다. Semantic Triple Graph IDs: 요청 시맨틱 트리플들의 <SemanticTripleGraphIDs>. Semantic Triples 또는 Graph는 컨텐츠로서 리턴되는 요청된 시맨틱 트리플(들) 또는 그래프의 표현이다. Semantic Triple Node는 URI들, 빈 노드 레이블들 또는 요청 시맨틱 트리플들의 트리플 노드에 대한 "리터럴"일 수 있다. URI가 리턴되는 경우, 이것은 <URIType>에 의해 표시될 수 있다. URI Type은 절대적인 또는 상대적인 URI를 나타낸다. 상대적인 URI가 사용되는 경우, <NameSpace> 또는 온톨로지 레퍼런스가 상대적인 URI에 포함될 수 있다. 참/거짓: 예를 들어, SPARQL Query “ASK” 오퍼레이션에 대해, 요청된 오퍼레이션의 부울 논리 결과들.

필터 기준 파라미터가 있을 수 있으며, 이는 시맨틱 그래프 저장소에서 필터링된 시맨틱 트리플 또는 그래프 오퍼레이션들에 대한 필터 기준들을 나타낸다. SPARQL 쿼리에 대한 필터링의 예는 이하와 같다.

SPARQL 내장 필터 함수들이 이하에 열거되어 있다.

○ 논리 : !, &&, ||

○ 수학 : +, -, *, /

○ 비교 : =, !=, >, <, ...

○ SPARQL 테스트들 : isURI, isBlank, isLiteral, bound

○ SPARQL 접근자들 : str, lang, datatype

○ 기타 : sameTerm, langMatches, regex

응답 메시지는 상이한 시맨틱 트리플 오퍼레이션들에 기초하여 모든 타입들의 파라미터들을 포함할 수 있다. 파라미터들은 상이한 방식들로 제공될 수 있으며, 이하는 예들이다. 구현에 따라, 일부 파라미터들은 임의적일 수도 있고 아닐 수도 있고, 필수적인 것으로 간주될 수도 있고 아닐 수도 있다. 예시적인 파라미터들은 이하와 같다. 제1 파라미터들의 세트는 응답 상태 또는 요청 식별자를 포함할 수 있다. 응답 상태는 요청된 오퍼레이션의 결과가 성공적인지, 성공적이지 않은지, 확인응답인지(예를 들어, 결과가 나중에 전달됨) 또는 인증 타임아웃과 같은 처리 상태 등임을 나타낼 수 있다. 요청 식별자(ID) 파라미터는 대응하는 요청을 식별할 수 있다.

오퍼레이션 종속적인 것으로 간주될 수 있는 제2 파라미터들의 세트는 다음의 예들: 컨텐츠 또는 컨텐츠 상태를 포함할 수 있다. 컨텐츠는, 응답 상태가 성공적인 경우, 1) CREATE - 컨테츠는 시맨틱 그래프 저장소의 <SemanticTripleGraphIDs>이다 -; 2) UPDATE - 컨텐츠는 시맨틱 그래프 저장소에서 대체된 시맨틱 트리플들 또는 그래프이다 -; 3) DELETE - 컨텐츠는 삭제된 시맨틱 트리플들 또는 그래프이다 -; 또는 4) RETRIEVE - 요청 메시지의 <ResultContent>에 의해 표시된 바와 같이, 컨텐츠는 <SemanticTripleGraphIDs>, <SemanticTriples/Graph>, <SemanticTripleNodes>, 또는 <True/False> 부울 논리 결과들을 포함할 수 있는 시맨틱 쿼리 결과들이다 - 와 같은 응답 컨텐츠를 포함할 수 있다. 응답 상태가 성공적이지 않은 경우, 응답의 컨텐츠 파라미터는 에러 정보를 포함할 수 있다. 응답 상태가 확인응답인 경우, <ResponseType>이 요청에서 지정된 바와 같이 ACK 기반이면, 컨텐츠 파라미터는 <SemanticTripleGraphIDs>를 포함할 수 있다. 응답 상태가 성공적인 경우, 컨텐츠를 리턴한 시맨틱 쿼리가 부분적이면, 컨텐츠 상태 파라미터는 리트리브 오퍼레이션에 대한 응답으로 나타낼 수 있다.

제3 파라미터들의 세트는 다음의 예들: "To" 또는 "From"일 수 있다. "to"파라미터는 발신자(151) 또는 트랜짓 SE(150)의 어드레스 또는 ID를 나타낼 수 있다. "from" 파라미터는 수신자(152)의 ID를 나타낼 수 있다.

위에서 언급된 오퍼레이션들 중 일부 오퍼레이션들의 일부 추가적인 세부사항들은 이하의 도면들에서 "트리플"로 예시된다. 도 18은 CREATE 시맨틱 트리플들에 대한 오퍼레이션 흐름을 제공한다. 도 19는 RETRIEVE 시맨틱 트리플들 - 시맨틱 쿼리에 대한 오퍼레이션 흐름을 제공한다. 도 20은 UPDATE 시맨틱 트리플들에 대한 오퍼레이션 흐름을 제공한다. 도 21은 DELETE 시맨틱 트리플들에 대한 오퍼레이션 흐름을 제공한다.

도 18 내지 도 21에 상세히 설명된 메커니즘들은 또한 시맨틱 그래프 저장소에 대한 또는 시맨틱 그래프 저장소들 간의 시맨틱 그래프 오퍼레이션들에도 적용 가능하다. 도 18은 CREATE 시맨틱 트리플들에 대한 예시적인 오퍼레이션 흐름을 예시한다. 단계(201)에서, 시맨틱 트리플 CREATE 오퍼레이션 요청이 전송된다. 단계(201)의 요청은 1) To: SemanticGraphStore 및 From: 발신자 ID(예를 들어, AE ID 또는 SE ID); 2) Operation: CREATE; 3) Parameters: RequestID, ContentFormat(예를 들어, RDF XML), AccessControlPolicyIDs, OntologyRef, Creator, ResponseType, ResultContent(이는 SemanticTripleIDs임); 및 4) Content: SemanticTriples를 포함할 수 있다.

계속해서 도 18을 참조하면, 단계(202)에서, 예를 들어, 시맨틱 트리플 CREATE 오퍼레이션 처리가 수신자(152)에서 발생한다. 시맨틱 그래프 저장소(154)에서 시맨틱 트리플 CREATE 오퍼레이션의 유효성 검사가 있을 수 있다. 유효성 검사에는 다음이 포함될 수 있다. 발신자(151)가 <AccessControlPolicyIDs>에 의해 지정된 타겟 시맨틱 트리플들을 CREATE하거나, <ServiceSubscriptionPolicy>에 기초하여 <AccessControlPolicyIDs>을, <AccessControlPolicyIDs>가 존재하지 않는 경우에는, 다른 서비스 정책들을 생성 및 할당할 권한들을 갖는지에 대한 결정. 또한, <ontologyRef>의 유효성 검사, 및 이것이 발신자(151)에 의해 제공되지 않은 경우에는, <ontologyRef>이 할당이 있을 수 있다. 또한, <SemanticTripleIDs>가 단계(201)의 CREATE 요청에서 발신자(151)에 의해 제공되는 경우, 이는 시맨틱 그래프 저장소(154)에 아직 존재하지 않는 것으로 입증될 수 있다. 이것이 제공되지 않은 경우, 발신자(151)에 의해 제안되는 <SemanticTripleIDs>가 사용될 수 있고, 그렇지 않으면 고유한 <SemanticTripleIDs>가 생성될 시맨틱 트리플들과 함께 사용된다. 또한, "AccessControlTriples"(예를 들어, Who-What-How를 정의하는 액세스 제어 규칙 튜플)은 <AccessControlPolicyIDs>에 의해 식별되는 <AccessControlPolicy> 아래의 <privileges>에 의해 지정된 액세스 제어 정책 규칙들에 기초하여 생성될 시맨틱 트리플들과 연관될 수 있다. <creator>가 단계(201)의 요청에 포함되는 경우, "CreatorTriple"이 생성될 시맨틱 트리플들과 연관될 수 있다. 마지막으로, 단계(201)의 CREATE 요청의 성공적인 유효성 검사시, 시맨틱 트리플 CREATE 오퍼레이션 커맨드가 단계(201)의 요청에서 제공되지 않은 경우, 이를 생성한다. 예를 들어, SPARQL Update 언어에서, 시맨틱 그래프 저장소(154)에 트리플들을 "삽입"하거나 그래프를 "추가"한다.

계속해서 도 18을 참조하면, 단계(203)에서, 수해되는 시맨틱 그래프 저장소(154)의 수행되는 시맨틱 CREATE 오퍼레이션이 있다. 예가 도 18에 도시되어 있다. SPARQL 1.1 Update를 통해, 예를 들어, CREATE 오퍼레이션을 매핑하는 데 사용될 수 있는 이러한 그래프 관리 오퍼레이션들을 제공하는 것이 가능한데, 1) CREATE: 빈 그래프들을 지원하는 저장소들에 새로운 그래프를 생성한다; 2) COPY: 다른 것의 사본을 포함하도록 그래프를 수정한다; 3) MOVE: 하나의 그래프로부터 다른 그래프로 모든 데이터를 이동시킨다; 또는 4) ADD: 하나의 그래프로부터 다른 그래프로 모든 데이터를 재생성한다. 단계(204)에서, CREATE 오퍼레이션 결과들로 응답을 구성한다. 단계(205)에서, 시맨틱 트리플 CREATE 오퍼레이션 응답이 있다. 응답은 1) To: 발신자 ID(예를 들어, AE ID 또는 SE ID) 및 From: 수신자 ID(예를 들어, SE ID); 2) Parameters: RequestStatus(이는 성공적임), RequestID; 및 3) Content: SemanticTripleIDs(ResponseType이 NoACKsync인 경우)를 포함할 수 있다.

도 19는 RETRIEVE 시맨틱 트리플들 - 시맨틱 쿼리에 대한 예시적인 오퍼레이션 흐름을 예시한다. 단계(211)에서, 시맨틱 트리플 RETRIEVE 오퍼레이션 요청이 전송된다. 단계(211)의 요청은 1) To: SemanticGraphStore 및 From: 발신자 ID(예를 들어, AE ID 또는 SE ID); 2) Operation: RETRIEVE; 3) Parameters: RequestID, ContentFormat(예를 들어, SPARQL), FilterCriteria 또는 ResultContent; 및 4) Content: SemanticTriples를 포함할 수 있다.

계속해서 도 19를 참조하면, 단계(212)에서, 예를 들어, 시맨틱 트리플 RETRIEVE 오퍼레이션 처리가 수신자(152)에서 발생한다. 시맨틱 그래프 저장소(154)에서 시맨틱 트리플 RETRIEVE 오퍼레이션의 유효성 검사가 있을 수 있다. 유효성 검사는 다음을 포함할 수 있다. 발신자(151)(AE ID 또는 SE ID 사용)가 트리플들과 연관된 <AccessControlPolicy>에 기초하여 그 쿼리 시맨틱 트리플들에 의해 지정된 시맨틱 트리플들 또는 다른 정보를 RETRIEVE할 권한들을 갖는지에 대한 결정. 필요한 경우, <ontologyRef>도 유효성 검사될 수 있다. 또한, FilterCriteria가 유효한지에 대한 결정이 있을 수 있다. 마지막으로, 단계(211)의 RETRIEVE 요청의 성공적인 유효성 검사시, 시맨틱 쿼리 커맨드가 생성될 수 있다. 예를 들어, SPARQL Query 언어에서, 결과 값들의 테이블에 대해 SELECT”, RDF 그래프에 대해 "CONSTRUCT", "True/False" 부울 결과에 대해 "ASK", 또는 시맨틱 그래프 저장소(154)가 리턴하는 것은 무엇이든지 "DESCRIBE"한다.

계속해서 도 19를 참조하면, 단계(213)에서, 수행되는 시맨틱 그래프 저장소(154)의 시맨틱 쿼리 오퍼레이션이 있다. 예가 도 19에 도시되어 있다. 단계(214)에서, RETRIEVE 오퍼레이션 결과들로 응답을 구성한다. 단계(215)에서, 시맨틱 트리플 RETRIEVE 오퍼레이션 응답이 있다. 응답은 1) To: 발신자 ID(예를 들어, AE ID 또는 SE ID) 및 From: 수신자 ID(예를 들어, SE ID); 2) Parameters: RequestStatus(이는 성공적임), RequestID; 및 3) Content: SemanticTriples(ResponseType이 NoACKsync인 경우)를 포함할 수 있다.

도 20은 UPDATE 시맨틱 트리플들에 대한 예시적인 오퍼레이션 흐름을 예시한다. 단계(221)에서, 시맨틱 트리플 UPDATE 오퍼레이션 요청이 전송된다. 단계(221)의 요청은 1) To: SemanticGraphStore 및 From: 발신자 ID(예를 들어, AE ID 또는 SE ID); 2) Operation: UPDATE; 3) Parameters: RequestID, SemanticTripleIDs, ContentFormat(예를 들어, RDF XML), FilterCriteria, ResultantContent; 및 4) Content: SemanticTriples을 포함할 수 있다.

계속해서 도 20을 참조하면, 단계(222)에서, 예를 들어, 시맨틱 트리플 UPDATE 오퍼레이션 처리가 수신자(152)에서 발생한다. 시맨틱 그래프 저장소(154)에서 시맨틱 트리플 UPDATE 오퍼레이션의 유효성 검사가 있을 수 있다. 유효성 검사는 다음을 포함할 수 있다. 발신자(151)가 트리플들과 연관된 <AccessControlPolicy>에 의해 지정된 타겟 시맨틱 트리플들을 UPDATE할 권한들을 갖는지에 대한 결정. 또한, <ontologyRef>의 유효성을 검사하고, FilterCriteria가 유효한지에 대해 결정할 수 있다. 마지막으로, 단계(221)의 UPDATE 요청의 성공적인 유효성 검사시, 시맨틱 트리플 UPDATE 오퍼레이션 커맨드가 단계(221)의 UPDATE 요청에서 제공되지 않은 경우, 이를 생성한다. 예를 들어, SPARQL Update 언어에서, 트리플을 업데이트하기 위해 "DELETE" 및 "INSERT"한다.

계속해서 도 20을 참조하면, 단계(223)에서, 수행되는 시맨틱 그래프 저장소(154)의 시맨틱 UPDATE 오퍼레이션이 있다. SPARQL 1.1 Update를 통해, 예를 들어, UPDATE 오퍼레이션을 매핑하는 데 사용될 수 있는 이들 그래프 관리 오퍼레이션들을 제공할 수 있으며, 또한, 1) CREATE: 빈 그래프들을 지원하는 저장소들에 새로운 그래프를 생성한다; 2) COPY: 다른 것의 복사본을 포함하도록 그래프를 수정한다; 3) MOVE: 하나의 그래프로부터 다른 그래프로 모든 데이터를 이동시킨다; 4) ADD: 하나의 그래프로부터 다른 그래프로 모든 데이터를 재생성한다; 또는 5) DROP: 그래프와 그 컨텐츠 전부를 제거한다. 단계(224)에서, UPDATE 오퍼레이션 결과들로 응답을 구성한다. 단계(225)에서, 시맨틱 트리플 UPDATE 오퍼레이션 응답이 있다. 응답은 1) To: 발신자 ID(예를 들어, AE ID 또는 SE ID) 및 From: 수신자 ID(예를 들어, SE ID); 2) Parameters: RequestStatus(이는 성공적임), RequestID; 및 3) Content: SemanticTriples(ResponseType이 NoACKsync인 경우)를 포함할 수 있다.

도 21은 DELETE 시맨틱 트리플들에 대한 예시적인 오퍼레이션 흐름을 예시한다. 단계(231)에서, 시맨틱 트리플 DELETE 오퍼레이션 요청이 전송된다. 단계(231)의 요청은 1) To: SemanticGraphStore 및 From: 발신자 ID(예를 들어, AE ID 또는 SE ID); 2) Operation: DELETE; 3) Parameters: RequestID, SemanticTripleIDs, ContentFormat(예를 들어, RDF XML), FilterCriteria, ResultantContent; 및 4) Content: SemanticTriples를 포함할 수 있다.

계속해서 도 21을 참조하면, 단계(232)에서, 예를 들어, 시맨틱 트리플 DELETE 오퍼레이션 처리가 수신자(152)에서 발생한다. 시맨틱 수신자(152)(예를 들어, 시맨틱 그래프 저장소(154))에서 시맨틱 트리플 DELETE 오퍼레이션의 유효성 검사가 있을 수 있다. 유효성 검사는 다음을 포함할 수 있다. 발신자(151)가 트리플들과 연관된 <AccessControlPolicy>에 의해 지정된 타겟 시맨틱 트리플들을 DELETE할 권한들을 갖는지에 대한 결정. 또한, FilterCriteria가 유효한지에 대한 결정이 있을 수 있다. 마지막으로, 단계(231)의 DELETE 요청의 성공적인 유효성 검사시, 시맨틱 트리플 DELETE 오퍼레이션 커맨드가 단계(231)의 요청에서 제공되지 않은 경우, 이를 생성한다. 예를 들어, SPARQL Update 언어에서, 특정 그래프의 모든 트리플들을 제거하기 위해 "DELETE" 및 "CLEAR"한다.

계속해서 도 21을 참조하면, 단계(233)에서, 수행되는 시맨틱 그래프 저장소(154)의 시맨틱 DELETE 오퍼레이션이 있다. SPARQL 1.1 Update를 통해, 예를 들어, DELETE 오퍼레이션을 매핑하는 데 사용될 수 있는 이들 그래프 관리 오퍼레이션들을 제공할 수 있으며, 또한 1) MOVE: 하나의 그래프로부터 다른 그래프로 모든 데이터를 이동시킨다; 또는 2) DROP: 그래프와 그 컨텐츠 전부를 제거한다. 단계(234)에서, DELETE 오퍼레이션 결과들로 응답을 구성한다. 단계(235)에서, 시맨틱 트리플 DELETE 오퍼레이션 응답이 있다. 응답은 1) To: 발신자 ID(예를 들어, AE ID 또는 SE ID) 및 From: 수신자 ID(예를 들어, SE ID); 2) Parameters: RequestStatus(이는 성공적임), RequestID; 및 3) Content: SemanticTriples(ResponseType이 NoACKsync인 경우)를 포함할 수 있다.

본 명세서에서 논의된 바와 같이, <AccessControlPolicyIDs>에 의해 지정된 <AccessControlPolicy>는 그래프 뷰들에 의한 액세스 제어 또는 <AccessControlTriples>에 의한 액세스 제어와 같이 메소드들에 기초한 시맨틱 그래프 저장소에서의 액세스 제어를 위해 사용될 수 있다. 그래프 뷰들에 의한 액세스 제어와 관련하여, 시맨틱 그래프 저장소의 그래프 뷰(도 49a에 도시된 예)는 베이스 그래프 저장소 위에 구성된 서브-그래프이며, 이는 애플리케이션과 관련된 데이터에 대해 구체적으로 구성된 액세스를 제공함으로써 데이터의 활용성을 강화할 수 있고, 또는 승인된 액세스 권한들에 따라 데이터에 액세스를 부여함으로써 데이터에 대한 액세스 제어를 가능하게 할 수 있다. 그래프 뷰 접근법은 도 49b에 도시된 바와 같은 다음의 단계들을 포함할 수 있다. 단계(311)에서, <AccessControlPolicy>에 의해 지정된 각각의 액세스 제어 규칙마다 상이한 그래프 뷰들(예를 들어, 환자-A에 대한 그래프 뷰(304), 환자-B에 대한 그래프 뷰(306) 또는 의사-D에 대한 그래프 뷰(308))이 생성될 수 있다. 그래프 뷰(304)는 환자-A가 액세스 가능한 트리플들을 갖는 환자-A의 서브-그래프일 수 있다. 그래프 뷰(306)는 환자-B가 액세스 가능한 트리플들을 갖는 환자-B의 서브-그래프일 수 있다. 그래프 뷰(308)는 환자들이 액세스할 수 없는 의사-D의 트리플들일 수 있다. 원(309)은 의사-D의 그래프 뷰(예를 들어, 의사-D의 트리플들, 환자-A의 트리플들, 환자-B의 트리플들의 합집합인 의사-D가 액세스 가능한 트리플들을 갖는 의사-D의 서브-그래프)일 수 있다.

계속해서 단계(311)를 참조하면, 액세스 제어 정책에 기초하여 그래프 뷰를 생성하는 일부 다수의 방법들이 있다. 첫 번째 방법으로, 서브-온톨로지 레퍼런스 모델을 갖는 그래프 뷰의 서브-그래프가 구성될 수 있다. 이 서브-그래프는 액세스 제어 정책에 기초하여 구성될 수 있으며, 그 후, 서브-그래프에 시맨틱 쿼리가 수행될 수 있다. 두 번째 방법으로, 시맨틱 쿼리에 의한 그래프 뷰에 대한 서브-그래프가 이하의 예에 도시된 바와 같이 구성될 수 있다.

그래프 뷰(304)(예를 들어, 환자-A의 그래프 뷰):

계속해서 도 49b를 참조하면, 단계(312)에서, AE 또는 SE의 각각의 시맨틱 트리플 오퍼레이션 요청에 대해, 타겟 시맨틱 트리플들의 <AccessControlPolicy>에 의해 정의되는 발신자의 권한들에 기초하여 뷰가 선택될 수 있다. 단계(313)에서, 시맨틱 트리플 오퍼레이션들은 요청된 시맨틱 트리플 오퍼레이션에 대해 발신자가 허용한 시맨틱 그래프 저장소로부터의 해당 시맨틱 트리플들만을 포함하는 선택된 뷰에서 수행된다.

도 49c는 <AccessControlTriples>에 의한 액세스 제어에 기초하여 시맨틱 그래프 저장소의 액세스 제어에 사용되는 <AccessControlPolicyIDs>에 의해 지정된 <AccessControlPolicy>에 대한 예시적인 방법의 요약을 예시한다. 단계(316)에서, 시맨틱 그래프 저장소의 <AccessControlPolicy>에 의해 지정된 액세스 제어 규칙들이 구성될 수 있다. 단계(317)에서, 타겟 SemanticTriples은 액세스 제어 규칙들과 관련된 그들의 <AccessControlPolicyIDs> 또는 <AccessControlPolicy>와 연관될 수 있다. 단계(318)에서, 시맨틱 트리플 오퍼레이션들은 발신자가 동작할 수 있게 하는 액세스 제어 규칙들과 연관된 선택된 시맨틱 트리플들에 의해 수행될 수 있다.

도 52는 시맨틱스 그래프 저장소와 연관된 예시적인 액세스 제어 정책을 예시한다. 도 22는 (도 52에서와 같은) 시맨틱 그래프 저장소의 액세스 제어 정책의 예에 대한 예시적인 호출 흐름(메소드)을 예시한다. 도 22의 메소드는 타겟 트리플들에 의한 액세스 제어 정보를 사용하고 이들을 시맨틱스 그래프 저장소에 삽입하는 방법의 예를 예시한다. 도 22의 단계(240)에서, (도 23에 도시된 바와 같은) eHealth 온톨로지 레퍼런스 모델이 사전 구성될 수 있고, (도 24에 도시된 바와 같은) 액세스 제어 온톨로지 모델이 사전 구성될 수 있다. 단계(241)에서, 발신자(162)는 액세스 제어 정책들을 호스팅하는 SE(163)에서 <AccessControlPolicy> 리소스를 생성하도록 요청한다. 단계(242)에서, SE(163)는 리소스 트리에 <AccessControlPolicy> 리소스를 생성한다. 단계(243)에서, SE(163)는 성공적인 결과의 표시로 발신자(162)에게 응답한다. 단계(244)에서, SE(163)는 SE(164)에게이 <AccessControlPolicy>를 시맨틱 그래프 저장소에 삽입하도록 요청한다. 단계(245)에서, SE(164)는 시맨틱 그래프 저장소에 <AccessControlPolicy>를 생성한다. 이것은 액세스 제어 온톨로지(도 24에 도시됨)를 사용하여 이 <AccessControlPolicy> 아래의 액세스 제어 규칙들을 표현하기 위해 <AccessControlTriples>을 생성하는 것 및 시맨틱 그래프 저장소에 <AccessControlTriples>을 삽입하는 것을 포함할 수 있다.

계속해서 도 22를 참조하면, 단계(246)에서, SE(164)는 SE(163)에게 성공적인 결과의 표시로 응답한다. 단계(247)에서, 발신자(162)는 시맨틱 그래프 저장소에 <SemanticTriples>를 생성하도록 요청한다. 단계(248)에서, SE(163)는 단계(247)의 요청을 시맨틱 그래프 저장소를 호스팅하는 SE(164)에게 포워딩한다. 단계(249)에서, SE(164)는 시맨틱 트리플 CREATE 오퍼레이션을 수행한다. SE(164)는 발신자(162)의 ID 및 관련 <AccessControlPolicy>를 사용함으로써 시맨틱 그래프 저장소에서 CREATE 오퍼레이션의 유효성을 검사할 수 있다. <AccessControlPolicy>가 존재하지 않는 경우, 이것이 생성될 수 있다. SE(164)는 도 25에 도시된 바와 같은 시맨틱 그래프 저장소에 생성되는 트리플들과 <AccessControlPolicy>를 바인딩할 수 있다. SE(164)는 <AccessControlTriples>과 연관된 트리플들을 시맨틱 그래프 저장소에 삽입할 수 있다. 단계(250)에서, SE(164)는 성공적인 결과와 함께 SE(163)에게 메시지를 전송할 수 있다. 단계(251)에서, SE(163)는 성공적인 결과로 발신자(162)에게 응답할 수 있다.

도 22를 참조하면, 단계(252)에서, 발신자(161)는 시맨틱 트리플 RETRIEVE 오퍼레이션을 요청한다. 단계(253)에서, SE(163)는 단계(252)의 요청을 SE(164)에게 전송한다. 단계(254)에서, SE(164)는 시맨틱 트리플 RETRIEVE 오퍼레이션을 수행한다. SE(164)는 발신자(161)의 ID를 사용함으로써 리트리브 오퍼레이션의 유효성을 검사하고, 도 26에 도시된 바와 같은 <AccessControlPolicy>를 갖는 시맨틱 쿼리 커맨드들을 구성할 수 있다. SE(164)는 <Access ControlPolicy>를 사용하여 쿼리를 수행할 수 있다. 단계(255)에서, SE(164)는 성공적인 결과와 함께 SE(163)에게 메시지를 전송한다. 단계(256)에서, SE1(163)은 성공적인 결과와 함께 발신자(161)에게 메시지를 전송한다.

일반적으로, 애플리케이션이 발신자(161)에 의해 제공되는 트리플들에 대해 시맨틱스 쿼리를 개시하는 경우, SE(164)의 쿼리 엔진은 시맨틱 그래프 저장소에 삽입된 AccessControlTriples을 자동으로 사용하는 쿼리 검색을 수행한다. 이는 발신자(161)에 의해 생성된 트리플들과 <AccessControlTriples> 사이의 바인딩 때문일 수 있다. 단, 쿼리 AE 또는 SE는 도 26에 도시된 액세스 제어 규칙들을 식별하기 위해 단지 예를 들어, AE ID 또는 SE ID와 같은 그 식별정보만을 제공하면 된다는 것에 유의하도록 한다.

시맨틱 그래프 저장소에서의 액세스 제어를 위한 예시적인 파일들이 도 23, 도 24, 도 25, 도 26 및 도 53a 내지 도 53c에 도시되어 있다. 메커니즘들은 중앙식 시맨틱 그래프 저장소를 갖는 예들이지만, 일반적인 절차들이 모든 종류의 시맨틱 그래프 저장소들에 적용될 수 있다.

시맨틱 쿼리를 통한 리소스 발견이 이하에서 논의된다. 도 54는 시맨틱 쿼리를 포함하는 리소스 발견을 수행하기 위한 예시적인 방법을 예시한다. 단계(321)에서, 발신자(161)(예를 들어, AE 또는 SE)는 시맨틱 그래프 저장소를 호스팅하는 SE(164)에게 시맨틱 쿼리를 전송할 수 있다. 요청에 응답하여, SE(164)는 시맨틱 그래프 저장소에서 시맨틱 쿼리를 수행할 수 있다. 단계(322)에서, 발신자(161)는 단계(321)에서의 성공적인 쿼리에 응답하여 SE(164)로부터 트리플(들) 또는 트리플 노드(들)를 수신할 수 있다. 단계(322)의 트리플들 수신하는 것에 후속할 수 있는 단계(323)에서, 발신자(161)는 리소스 트리를 호스팅하는 SE(164)에게 리소스에 대한 RETRIEVE 요청을 전송할 수 있다. 리소스는 SE(164)의 리소스 트리에 있고, 단계(322)에서 수신된 트리플 또는 트리플 노드에 지명되거나 이와 연관된 URI 또는 URL(uniform resource locator)에 의해 어드레싱될 수 있다. SE(164)는 리소스 트리에서 리트리브 오퍼레이션을 수행한다. 단계(323)에 응답할 수 있는 단계(324)에서, 발신자(161)는 성공적인 리트리브 오퍼레이션으로부터 트리플 또는 트리플 노드를 수신한다.

도 27은 계층적 리소스 트리들에 분산된 시맨틱 디스크립터들의 예시적인 아키텍처를 예시한다. 이 분산형 아키텍처는 복수의 피처들을 갖는다. 시맨틱 쿼리를 위해 사용되는 임시 시맨틱 그래프 저장소(예를 들어, 임시 시맨틱 그래프 저장소(330) 또는 임시 시맨틱 그래프 저장소(338))는 oneM2M의 CSE와 같은 서비스 엔티티(예를 들어, SE(331) 또는 SE(332)) 상에 국부적으로 상주할 수 있고, 계층적 리소스 트리들에 분산된 시맨틱 디스크립터들(예를 들어, 시맨틱 디스크립터(333) 또는 시맨틱 디스크립터(334))로부터 추출된 시맨틱 트리플들을 포함할 수 있다. 시맨틱 트리플들을 포함하는 시맨틱 디스크립터들은 다수의 서비스 엔티티들 상의 상이한 계층적 리소스 트리들 상에 위치될 수 있다. 예를 들어, 시맨틱 디스크립터(334)는 SE(332) 상의 리소스 트리(337)에 위치될 수 있고, SE(331) 상의 리소스 트리(339) 상에 위치될 수 있다. oneM2M 내의 AE와 같은 애플리케이션 엔티티(예를 들어, AE(335))는 리소스 트리의 시맨틱 디스크립터 리소스들에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션들을 위해 oneM2M의 Mca 인터페이스와 같은 인터페이스 AS(340)를 통해 SE(332)와 통신할 수 있다. SE(332)는 리소스 트리의 시맨틱 디스크립터 리소스들에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션들을 위해 oneM2M의 Mcc 또는 Mcc' 인터페이스와 같은 인터페이스 SS(336)를 통해 다른 SE(331)와 통신할 수 있다.

계층적 리소스 트리들의 시맨틱 디스크립터들에 대한 CREATE, RETRIEVE, UPDATE, 및 DELETE와 같은 RESTful 오퍼레이션들은 리소스 트리들의 다른 리소스들에 대한 오퍼레이션들과 유사하다. 배경기술 부분에서 언급된 바와 같이, 시맨틱 쿼리는 시맨틱 검색과 상이하며, 시맨틱 쿼리는 시맨틱 그래프 저장소에 링크된 모든 시맨틱 트리플들에 의해 수행되어야 한다. 따라서, 본 명세서에는 시맨틱 쿼리 목적을 위한 로컬 임시 시맨틱 그래프 저장소가 개시된다.

도 28은 리소스 트리들에 분산된 시맨틱 디스크립터들을 갖는 예시적인 시맨틱 쿼리를 예시한다. 단계(351)에서, 시맨틱 트리플 RETRIEVE 오퍼레이션을 포함하는 요청이 수신자(332)(즉, SE(332))에 의해 수신될 수 있다. 요청은 1) 타겟 리소스의 어드레스 또는 ID(예를 들어, To 어드레스); 2) 발신자 ID(예를 들어, AE ID 또는 SE ID); 3) 오퍼레이션(예를 들어, RETRIEVE); 4) 파라미터들(예를 들어, RequestID, ContentFormat(예를 들어, SPARQL), FilterCriteria(이는 시맨틱임), ResultContent); 또는 5) 컨텐츠(예를 들어, QuerySemanticTriples)를 포함할 수 있다. 단계(352)에서, 단계(351)의 요청에 기초하여, 수신자(332)는 시맨틱 트리플 RETRIEVE 오퍼레이션들과 연관된 처리를 수행할 수 있다. 수신자(332)는 리소스 트리들 간에 시맨틱 디스크립터 발견을 수행할 수 있다. 수신자(332)는 리소스 트리에서 시맨틱 트리플 RETRIEVE 오퍼레이션의 유효성을 검사할 수 있다. 예를 들어, 발신자(335)는 각각의 시맨틱 디스크립터에 대해 <AccessControlPolicy>에 의해 지정된 액세스 제어 정책 규칙들에 기초하여 리소스 트리들의 시맨틱 디스크립터들을 RETRIEVE하기 위한 권한들을 갖는다고 결정한다. 수신자(332)는 FilterCriteria가 유효한지를 결정할 수 있다. RETRIEVE 요청의 성공적인 유효성 검사에 기초하여, 수신자(332)는 발견된 시맨틱 디스크립터들을 RETRIEVE할 수 있다. 수신자(332)는 리트리브된 시맨틱 디스크립터들로부터 시맨틱 트리플들을 추출하여, 이들을 로컬 임시 시맨틱 그래프 저장소에 보관할 수 있다. 임시 시맨틱 그래프 저장소를 로딩하는 데 SPARQL 업데이트 오퍼레이션들이 사용될 수 있다. (예를 들어, SPARQL 쿼리 언어에서) 시맨틱 쿼리 커맨드가 요청에서 제공되지 않은 경우, 수신자(332)는 이를 구성할 수 있다. 수신자(332)는 임시 시맨틱 그래프 저장소의 타겟 쿼리 시맨틱 트리플들 및 FilterCriteria에 의해 시맨틱 쿼리를 수행할 수 있다. 수신자(332)는 임시 시맨틱 그래프 저장소의 시맨틱 트리플들을 (예를 들어, 전부) 제거할 수 있다. 단계(353)에서, 수신자(332)는 시맨틱 쿼리 결과들을 갖는 메시지를 구성하여, 이를 발신자(335)에게 전송할 수 있다.

본 명세서에서, 임시 시맨틱 그래프 저장소는, 예를 들어, 시맨틱 쿼리에 대한 관계 그래프를 형성하기 위해, 리소스 트리(들)로부터 발견된 시맨틱 디스크립터들로부터 추출된 시맨틱 트리플들을 링크시키는 데 사용될 수 있는 것으로 고려된다. 이 임시 시맨틱 그래프 저장소는 각각의 시맨틱 쿼리 후에 클리어될 수 있고, 다른 시맨틱 쿼리에 대해 발견된 시맨틱 디스크립터들로부터 추출된 다른 그룹의 시맨틱 트리플들에 의해 로딩될 수 있다. 따라서, 임시 시맨틱 그래프 저장소는 쿼리 그래프를 형성하는 시맨틱 트리플들이 이 임시 시맨틱 그래프 저장소에서 발신자가 오퍼레이션들을 행하도록 허용받는 유일한 트리플들임을 보장하기 위해 각각의 쿼리 이후에는 시맨틱 트리플을 유지하지 않을 수 있다.

여기에서는, 시맨틱 그래프 저장소 및 계층적 리소스 트리들 모두에 시맨틱 디스크립터들을 갖는 하이브리드 아키텍처가 개시된다. 도 29는 시맨틱 그래프 저장소 및 계층적 리소스 트리들의 시맨틱 디스크립터들에 대한 예시적인 아키텍처를 예시한다. 하이브리드 아키텍처는 다음과 같은 피처를 가질 수 있다. 시맨틱 쿼리를 위해 사용되는 중앙식 시맨틱 그래프 저장소(360)가 있을 수 있고, 이것은 SE(361)(예를 들어, oneM2M의 CSE) 상에 상주할 수 있다. 중앙식 시맨틱 그래프 저장소(360)는 리소스 트리(364), 리소스 트리(365) 또는 리소스 트리(366)와 같은 계층적 리소스 트리들에 분산된 시맨틱 디스크립터들로부터의 시맨틱 트리플들을 포함할 수 있다. 리소스 트리(364)의 시맨틱 디스크립터(368), 리소스 트리(365)의 시맨틱 디스크립터(369), 또는 리소스 트리(366)의 시맨틱 디스크립터(370)가 있을 수 있다. 도시된 바와 같이, 시맨틱 트리플들을 포함하는 시맨틱 디스크립터들은 다수의 서비스 엔티티들 상의 상이한 계층적 리소스 트리들에 위치될 수 있다.

계속해서 도 29를 참조하면, 이하는 시맨틱 디스크립터에 대한 예시적인 옵션들이다. 제1 옵션에서, 리소스 트리의 시맨틱 디스크립터들은 시맨틱 트리플들을 포함하는 실제 리소스들이다. CREATE, RETRIVE, UPDATE, 또는 DELETE의 오퍼레이션은 리소스 트리들의 임의의 다른 타입 리소스들에 대한 오퍼레이션들과 같이 리소스 트리(들)의 시맨틱 디스크립터들에 대해 수행될 수 있다. 그러나, 중앙식 시맨틱 그래프 저장소(360)의 시맨틱 그래프는 리소스 트리(들)의 시맨틱 디스크립터들에 대해 오퍼레이션이 수행될 때마다 해당 시맨틱 디스크립터들과 동기화될 수 있다. 중앙식 시맨틱 그래프 저장소(360)는 시맨틱 쿼리 및 다른 시맨틱 분석 오퍼레이션들에 대해 사용될 수 있다. 이 첫 번째 옵션은 분산형 접근 방식으로 좀더 간주될 수 있다.

계속해서 도 29를 참조하면, 제2 옵션에서, 리소스 트리의 시맨틱 디스크립터들은 시맨틱 트리플들을 포함하지 않는 가상 리소스들일 수 있다. 리소스 트리(들)의 가상 리소스 시맨틱 디스크립터들에 대해 수행되는 CREATE, RETRIVE, UPDATE, 또는 DELETE의 오퍼레이션은 중앙식 시맨틱 그래프 저장소(360)에서 실제 오퍼레이션을 트리거할 수 있다. 중앙식 시맨틱 그래프 저장소(360)는 시맨틱 쿼리뿐만 아니라 시맨틱 트리플들을 저장하는 데에도 사용될 수 있다. 이 제2 옵션은 중앙식 접근 방식으로 좀더 간주될 수 있다.

도 29를 참조하면, 애플리케이션 엔티티(예를 들어, AE(367))는 리소스 트리(예를 들어, 365)의 시맨틱 디스크립터 리소스들(예를 들어, 시맨틱 디스크립터(369))에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션들뿐만 아니라, 중앙식 시맨틱 그래프 저장소(360)의 시맨틱 트리플들에 대한 시맨틱 쿼리를 위해 인터페이스 AS(371), 예를 들어, oneM2M의 Mca 인터페이스를 통해 서비스 엔티티(예를 들어, SE(362))와 통신할 수 있다. 일례에서, SE(362)는 리소스 트리(예를 들어, 리소스 트리(364))의 시맨틱 디스크립터 리소스들에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션들뿐만 아니라, 중앙식 시맨틱 그래프 저장소의 시맨틱 트리플들에 대한 시맨틱 쿼리를 위해 인터페이스 SS(372), 예를 들어, oneM2M의 Mcc 또는 Mcc' 인터페이스를 통해 다른 SE(363)와 통신할 수 있다. 제1 옵션에서, 계층적 리소스 트리들의 시맨틱 디스크립터들에 대한 CREATE, RETRIEVE, UPDATE, 및 DELETE와 같은 RESTful 오퍼레이션들은 리소스 트리들의 다른 리소스들에 대한 오퍼레이션들과 유사하다. 제2 오퍼레이션의 경우, 중앙식 접근법에 관해 설명된 것과 유사한 중앙식 시맨틱 그래프 저장소(360)의 시맨틱 트리플들에 대한 CREATE, RETRIEVE, UPDATE, 및 DELETE와 같은 오퍼레이션들은 리소스 트리들의 다른 리소스들에 대한 오퍼레이션들과 유사하다.

도 30은 리소스 트리들에 시맨틱 디스크립터들을 갖는 시맨틱 쿼리에 대한 예시적인 방법을 예시한다. 단계(375)에서, 수신자(361)(예를 들어, SE(361))는 시맨틱 트리플 RETRIEVE 오퍼레이션에 대한 요청을 수신할 수 있다. 단계(376)에서, 단계(375)의 요청에 기초하여, 수신자(361)는 시맨틱 트리플 RETRIEVE 오퍼레이션을 처리할 수 있다. 수신자(361)는 시맨틱 디스크립터 발견을 수행할 수 있다. 수신자(361)는 리소스 트리에서 시맨틱 트리플 RETRIEVE 오퍼레이션의 유효성을 검사할 수 있다. 이것은 발신자(373)가 각각의 시맨틱 디스크립터에 대해 <AccessControlPolicy>에 의해 지정된 액세스 제어 정책 규칙들에 기초하여 리소스 트리들에서 발견된 시맨틱 디스크립터들을 RETRIEVE할 권한들을 갖는지를 결정하는 것을 포함할 수 있다. 또한, FilterCriteria가 유효한지 여부에 대해 결정될 수 있다. 제1 옵션에서, RETRIEVE 오퍼레이션의 성공적인 유효성 검사에 기초하여, 수신자(361)는 리소스 트리들에서 발견된 시맨틱 디스크립터들을 RETRIEVE할 수 있다. 수신자(361)는 RETRIEVE 오퍼레이션의 성공적인 유효성 검사 후에 시맨틱 트리플들의 리스트를 갖는 그래프 뷰를 구성할 수 있다. 제1 옵션에서, 수신자(361)는 리트리브된 시맨틱 디스크립터들로부터 시맨틱 트리플들을 추출하여, 이들을 구성된 그래프 뷰를 갖는 시맨틱 그래프 저장소(360)에 보관할 수 있다. (예를 들어, SPARQL 쿼리 언어에서) 시맨틱 쿼리 커맨드가 요청에서 제공되지 않은 경우, 수신자(361)는 이를 구성할 수 있다. 수신자(361)는 시맨틱 그래프 저장소에 구성된 뷰 내의 타겟 쿼리 시맨틱 트리플들 및 FilterCriteria에 의해 시맨틱 쿼리를 수행할 수 있다.

단계(377)에서, 수신자(361)는 메시지(예를 들어, 응답)를 구성하여, 이를 AE(373)에게 전송할 수 있다. 단, "그래프 뷰들에 의한 액세스 제어" 스킴은 도 30 및 본 명세서의 다른 부분들에서 예로서 도시되며, "<AccessControlTriple>에 의한 액세스 제어" 스킴은 제1 옵션 또는 제2 옵션에도 적용될 수 있다는 것에 유의하도록 한다.

분산형 시맨틱 디스크립터들 간의 관계들을 가능하게 할 수 있는 대안적인 접근 방식이 여기에 개시되어 있다. 분산된 디스크립션들 전반에 걸친 필터링 또는 쿼리는 oneM2M에서의 종래의 시맨틱 필터링과 관련하여 여기에서 설명되는 다른 접근법들에 대한 대안을 제공한다. 단, 여기에서 논의된 중앙식 접근법에서 행해지는 일반적인 가정들이 적용되므로, 시맨틱 디스크립션들은 RDF 트리플 포맷일 수도 있고 아닐 수도 있다는 것에 유의하도록 한다. 여기서, 시맨틱 인스턴스들에 의해 생성된 전체 그래프들에 중점을 두고, 이와 같이, 시맨틱 인스턴스들의 예시적인 사용이 트리플들의 형태로 개시된다. 임의의 포맷들(예를 들어, RDF)의 시맨틱 디스크립션들에 대해 "시맨틱 디스크립터" 또는 "시맨틱 트리플들"(복수형)이란 용어가 사용될 수 있다. 단일 구문, 예를 들어, RDF-트리플에 대한 "시맨틱 인스턴스"란 용어가 사용될 수 있다. 쿼리들은, 예를 들어, SPARQL을 통해 RDF 트리플들에 대해 예시될 수 있다.

이 접근법에서 다뤄지는 분산형 아키텍처는 다음과 같은 피처를 가질 수 있다. 시맨틱 디스크립터들이 단일 서비스 엔티티들 상의 상이한 계층적 리소스 트리들 상의 리소스들에 걸쳐 위치될 수 있다. 여러 서비스 엔티티들에 걸친 시맨틱 오퍼레이션들에 대한 요청들은 개별 서비스 엔티티들로 라우팅된 요청들로 분류될 수 있으므로, 여기서 어드레싱된 시맨틱 오퍼레이션들은 어드레싱된 서비스 엔티티 내에 분산된 디스크립터들을 타겟으로 한다. 애플리케이션 엔티티(AE), 예를 들어, oneM2M의 AE는 리소스 트리의 시맨틱 디스크립터 리소스에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션들을 위해 인터페이스 AS, 예를 들어, oneM2M의 Mca 인터페이스를 통해 SE와 통신할 수 있다. SE는 리소스 트리의 시맨틱 디스크립터 리소스들에 대한 CREATE, RETRIEVE, UPDATE, DELETE 등과 같은 RESTful 오퍼레이션을 위해 인터페이스 SS, 예를 들어, oneM2M의 Mcc 또는 Mcc' 인터페이스를 통해 다른 SE와 통신할 수 있다. 시맨틱 쿼리를 위해 사용되는 임시 시맨틱 그래프 저장소는 서비스 엔티티(SE), 예를 들어, oneM2M의 CSE 상에 상주할 수 있고, 계층적 리소스 트리들에 분산된 시맨틱 디스크립터들로부터 추출된 시맨틱 트리플들을 포함할 수 있다. 단, 이 아키텍처에서, 보안 및 프라이버시 문제는 oneM2M의 종래의 액세스 제어 정책과 관련하여 설명된 액세스 제어 정책들을 통해 해결된다는 것에 유의하도록 한다. 시맨틱 디스크립터들은 리소스-레벨 정책들을 가지고 있으며, 이것은 각각의 CRUD 오퍼에이션에 대해 어떤 엔티티들이 액세스할 수 있는지를 결정한다.

중요한 이슈는 서비스 엔티티에서 사용할 수 있는 가능한 많은 양의 리소스들의 시맨틱 디스크립터들을 쿼리하는 것에 있을 수 있다. 이하에서 논의되는 것과 같은 몇 가지 선택 사항이 있다. 제1 선택 사항은 각각의 쿼리를 전체 SE 트리에 대해(예를 들어, 각각의 쿼리를 리소스 트리의 베이스(예를 들어, oneM2M의 CSEBase)를 타겟으로 하는 것처럼 처리) SE의 모든 시맨틱 디스크립터들이 각각의 쿼리와 관련된 것처럼 처리하는 것을 포함할 수 있다. 이것은 비효율적인 검색 방법으로 간주될 수 있다. 제2 선택 사항은 오퍼레이션 타겟의 시맨틱 디스크립터를 고려하여 각각의 쿼리를 처리하는 것을 포함할 수 있다. oneM2M의 종래의 시맨틱 필터링 제안들과 관련하여 설명된 경우이다. 이로 인해 <device12>에 지시된 쿼리가 <operationX>에서 사용할 수 있는 시맨틱 디스크립터 정보를 전혀 사용하지 못하게 될 수 있다. 제3 선택 사항은 본 명세서에서 논의된 oneM2M의 종래의 시맨틱 필터링 제안들에서 설명된 resourceDescriptionLink 방법을 사용하여 각각의 쿼리를 처리하는 것을 포함할 수 있다. 이 경우, 2개 이상의 공통 개념을 포함하는 2개 (이상의) 디스크립터들이 동일한 2개의 디스크립터들 간에 여러 링크들이 확립되게 할 수 있다. 절차 디스크립션에 기초하여, 새로운 링크가 발생할 때마다, 쿼리 오퍼레이션을 처리하는 엔티티는 대응하는 시맨틱 디스크립터(이 경우, 오퍼레이션 X에 대한 것)를 페치할 것이다. 이것은 동일한 디스크립터를 여러 번 리트리브하게 할 것이다. 또한, 리트리브들은 디스크립터 컨텐츠의 시맨틱 이해에 기초하여 처리될 수 있다. 제4 선택 사항은 의미와 관련된 디스크립터들의 세트에 대해 각각의 쿼리를 처리하는 것을 포함할 수 있다. 세트는 정확성을 위해 쿼리 효율성을 조정하는 정책들에 기초하여 더 넓어질 수도 있고 더 작아질 수도 있다. 다음에 설명된 방법이 이 범주에 속한다. 이것은 시맨틱 인스턴스 또는 서브그래프가 다른 것들과 어떻게 관련되는지에 관해 주석 시간(annotation time)에 사용 가능한 지식을 사용하는 이점을 갖는데, 왜냐하면 이것은 어디에(어느 리소스 트리 레벨에) 해당 인스턴스 또는 디스크립션을 배치할지를 알고 있기 때문이다.

도 31은 종래에 행해진 것과 같이 동일한 디스크립터들 간의 다중 resourceDescriptionLinks의 문제점을 예시한다. 본 개시내용에서, 관련 컨텐츠를 갖는 시맨틱 디스크립터들은 "oneM2M에서의 시맨틱 필터링 제안들"의 섹션에서 논의된 솔루션과는 반대로 서로에게 링크들이 제공될 수 있으며, 여기서 제공된 링크들은 시맨틱 디스크립터들의 시맨틱 인스턴스들에서 구현되는 관련 개념들 간에 있다. 특히, 새로운 어트리뷰트(예를 들어, relatedSemantics)가 시맨틱 디스크립터 리소스에 추가되어 관련 시맨틱스 디스크립터들에 대한 링크들을 제공하는 것으로 개시되어 있다.

oneM2M 맥락에서 시맨틱 디스크립터 리소스의 예를 사용하면, 어트리뷰트 relatedSemantics가 relatedSemantics 어트리뷰트를 예시하는 도 32에 도시된 바와 같은 <semanticDescriptor> 리소스에 추가된다.

여기에서 논의되는 링크들의 리스트 및 링크들의 그룹과 관련하여 설명된 바와 같이 relatedSemantics 어트리뷰트에 대해 구상 가능한 다수의 구현들이 있다. 제1 구현에서, relatedSemantics 어트리뷰트는 관련된 시맨틱 디스크립터들에 대한 개별 링크들의 리스트를 포함할 수 있다. 제2 구현에서, relatedSemantics 어트리뷰트는 그룹을 가리킨다. 이 옵션의 경우, <semanticGroup> 리소스기 여기에 개시되어 있지만, 범용 <group> 리소스가 이 목적을 위해 사용될 수도 있다.

단, 이 맥락에서, "관련" 시맨틱 디스크립터들의 개념은 다음의 의미를 가질 수 있는데, 즉, 2개 이상의 시맨틱 디스크립터가 시맨틱 쿼리들의 목적들을 위해 더 큰 그래프를 형성하도록 함께 사용되는 경우, 이들은 "관련"된다. 여기서, 초기 주체-기반 스킴에 기초한 제1 예 및 관련 시맨틱 디스크립터들을 생성하기 위한, 예를 들어, 시맨틱 디스크립터들이 관련되어 있음을 결정하기 위한 스킴들을 제공하고 대응하는 링크들을 제공하는 임의적인 그래프-기반 스킴을 사용하는 제2 예가 제공된다. 여기서 도입된 디스크립터 간 링크들을 제공하는 방법은 2개 이상의 시맨틱 디스크립터가 관련되어 있다고 최종적으로 결정하는 알고리즘들을 구현하기 위해 특정 시스템이 선택하는 방법과 무관한 것으로 간주될 수 있다는 것에 유의하여야 한다.

oneM2M 분산형 그래프들(본 명세서에서 논의된 oneM2M에서의 종래의 시맨틱 필터링 제안들과 유사하게 연관됨)의 다음의 예가 이하에서 사용될 것이다. 이 예에서, 독립적인 리소스들에 저장된 그래프들은 서로 관련된 정보를 포함하는데, 즉, 제1 그래프로부터의 OperationA는 제2 디스크립터에서 추가로 기술되고, 관계 exposesCommand와 목적어 commandK는 둘 다에 포함되어 있다. 추가적인 그래프 디스크립션(첫 번째 그래프에서 주어 commandK를 사용하고 리소스 operationA 디스크립터와 관련된 추가 잠재적인 트리플들 등)이 이 경우의 그래프들 간에 추가적인 종속성들을 생성할 수 있다.

도 33은 상이한 시맨틱 디스크립터들에 걸쳐 분산된 예시적인 그래프를 예시한다. 일례에서, 다음과 같은 필터 요청이 있을 수 있다: "그 출력이 온도 양태를 정량화하는 오퍼레이션을 갖는 서비스를 갖는 모든 디바이스들을 찾고, 출력=OutputX, 커맨드=commandK를 갖는 디바이스들에 대해 필터링한다(Find all devices that have a service that has an operation whose output quantifies a temperature aspect, and filter it for those with the output = OutputX and command = commandK)"

이하는 요청의 대응하는 SPARQL 표현이다.

목표는 도 34에 도시된 바와 같이 SPARQL 쿼리를 평가하기 위해 더 큰 결과 그래프의 생성이 제출될 수 있도록 하는 것이다.

이 구현에서, relatedSemantics 어트리뷰트는 다른 리소스들과 연관된 디스크립터들을 가리키는 링크들의 리스트를 포함하며, 이 링크들의 리스트는 시맨틱 쿼리들을 수행하기 위해 주어진 <semanticDescriptor> 리소스의 디스크립터와 함께 사용되어야 한다.

도 35는 링크들의 리스트를 갖는 use 또는 relatedSemantics 어트리뷰트의 예이다. 이것은 보다 제한된 수의 시맨틱 디스크립터들이 관련되어, 링크 리스트가 짧아질 때 제시되는 것과 같은 경우들에서 유용하다. 이 옵션을 추가로 단순화하기 위해, 표준화된 규칙은 차일드 리소스들의 모든 시맨틱 디스크립터들이 디폴트로 관련되어 있는 것으로 간주된다고 지정할 수 있으며, 이는, 쿼리가 패런트로 지향되는 경우, 모든 차일드 리소스 디스크립터들(존재하는 경우)이 패런트의 것에 자동으로 추가되어야 함을 의미하는 것으로 구상될 수 있다. 이 방식에서, 패런트의 relatedSemantics 어트리뷰트는 차일드들의 모든 디스크립터들에 대한 링크들을 포함할 필요가 없다.

이 구현에서, relatedSemantics 어트리뷰트는 도 36에서와 같이 새롭게 개시된 리소스인 <semanticGroup>을 가리키는 링크를 포함한다. semanticGroupLinks는 시맨틱 쿼리들을 수행할 때 함께 사용되는 디스크립터들을 식별하는 데 사용된다. 개개의 시맨틱 리소스들의 relatedSemantics 어트리뷰트들은 <semanticGroup> 리소스, semanticGroupLinks 어트리뷰트를 직접 가리키거나, 또는 연관된 semanticGroupID를 나타낼 수 있다. 위의 예에서, <semanticGroup> 리소스는 <Device12> 및 <operationA> 리소스들에 걸쳐 합성 그래프를 분산시킬 때 형성될 수 있다. 이 리소스의 경우, semanticGroupID, 예를 들어, 56이 할당될 수 있고, semanticGroupLinks 어트리뷰트는 관련 시맨틱 디스크립션들에 대한 링크들의 리스트를 포함할 수 있으며, 예를 들어, 링크들은 <Device12> 및 <OperationA>를 가리킨다. 다른 구현들에서, 링크들은 각각의 <semanticDescriptor> 리소스들의 디스크립터 어트리뷰트들 각각, 또는 차일드 <semanticDescriptor> 리소스들 자체를 대신에 가리킬 수 있다. 도 37은 <semanticGroup>을 사용한 예시적인 use 또는 relatedSemantics 어트리뷰트이다.

분산형 시맨틱 디스크립터들 간의 관계 링크 생성 및 유지. 분산형 시맨틱 디스크립터 아키텍처는 시맨틱스 기술들을 사용하는 플랫폼 기능의 가용성에 의존할 수 있다. 이것은 CRUD 오퍼레이션들을 사용하여 시맨틱 디스크립터들을 제공하는 시맨틱적으로-사용 가능한 플랫폼 기능들이 있음을 의미한다. 유사하게, CRUD 오퍼레이션들은 시맨틱 인스턴스들의 업데이트들을 수행하는 것을 포함하여 이러한 디스크립터들을 관리하는 데 사용될 수 있다. 이러한 주석 기능들의 합은 시맨틱 주석 기능으로 간주된다.

여기서는, 리소스들을 생성하는 기능에 대해 개시되는데, 여기서 주석 기능들은 생성된 리소스들이 어디에 저장되어야 하는지, 액세스 제어 어트리뷰트들이 어떻게 설정되어야 하는지 등에 대한 규칙들 및 정책들을 가질 수 있다.

이하는 제안된 시맨틱 디스크립터 링크 방법들이 어떻게 사용될 수 있는지를 예시하기 위해 주석 생성 프로세스에서 사용될 수 있는 관계-유지 스킴들에 대한 예들이다.

이전 섹션의 예는 도 33에 도시된 바와 같이 리소스들 <Device12> 및 <operation A>에 주석을 달기 위해서는 도 34의 보다 큰 그래프를 사용한 시맨틱 주석 기능에 의존한다. 이것은 그래프의 처리의 논리적 표현이다. 특정 구현들에서, 이 그래프를 처리하는 것은 로컬 임시 또는 영구 트리플 저장소를 사용할 수 있다. 이것은 트리플 저장소가 로컬이고 서비스 엔티티들 간에 공유될 필요가 없기 때문에, 여기서 논의된 하이브리드 접근법과 상이할 수 있다.

그러나, 시맨틱 주석 기능은 생성된 다양한 시맨틱 디스크립터들 간의 링크들을 생성하고, 서브-그래프들 및 주석들을 생성하는 동시에 relatedSemantics 어트리뷰트들을 채우는 데 사용될 수 있다.

이하의 설명들은 oneM2M 베이스 온톨로지(도 8)를 예로서 사용한다. 시맨틱 주석 엔진은 이 온톨로지를 사용하여 RDF로 표현되는 도 34의 그래프를 생성한다. 단, 도시된 텍스트는 디스크립터들 내의 정확한 RDF 신택스에 맞게 포맷되지 않고, 오히려 전체 그래프의 개념 표현임에 유의하도록 한다.

초기 주체-기반 스킴에 기초한 예가 이하에 제공된다. 이 스킴에서, 각각의 rdf: Description은 대응하는 리소스의 시맨틱 디스크립터에 저장되어, "Subject-based Scheme"으로서 지정된다. 이 접근법을 사용하면, 그 객체가 다른 리소스인 트리플을 형성하거나 업데이트할 때, 주석 엔진이 동일한 <semanticDescriptor> 리소스의 relatedSemantics 어트리뷰트에 엔트리를 생성한다.

도 37의 예시적인 그래프를 사용하면, 리소스 <Device12>와 연관된 <semanticDescriptor> 차일드 리소스의 descriptor 및 relatedSemantics 어트리뷰트들은 도 39에 도시된 바와 같을 것이다. 단, 이 경우, 그래프는 <Device12>, <OperationA> 리소스들뿐만 아니라 <Service23> 및 <OperationX>에 걸쳐 분산된다는 것에 유의하도록 한다. 마지막 3개의 리소스에 대한 대응하는 RDF는 대응하는 디스크립션들을 분리함으로써 도 38로부터 용이하게 추출될 수 있다.

<Device12>의 <semanticDescriptor> 리소스에서 relatedSemantics 어트리뷰트를 채우기 위해 링크들의 리스트 방법을 채택하는 경우, 도 40에 도시된 이하의 리스트가 생성될 것이다. 도 40은 링크들의 리스트 방법이 사용될 때의 relatedSemantics 어트리뷰트의 예이다.

링크들의 그룹 방법을 채택하는 경우, <Device12>의 semanticDescriptor 리소스의 relatedSemantics 어트리뷰트는 대응하는 <semanticGroup> 리소스를 가리킬 수 있다. 사실, <Service23>, <OperationA> 및 <output>의 semanticDescriptor 리소스의 relatedSemantics 어트리뷰트들은 동일한 대응하는 <semanticGroup> 리소스를 가리킨다. <semanticGroup> 리소스 내에서, semanticGroupLinks 어트리뷰트는 도 41에 도시된 바와 같은 링크들의 리스트를 포함할 수 있다. 도 41은 링크들의 그룹 방법이 사용될 때의 semanticGroupLinks 어트리뷰트의 예이다.

임의적인 그래프-기반 스킴을 사용한 예. 임의적인 그래프-기반 스킴을 사용하면, 임의적인 그래프들이 리소스들의 시맨틱 디스크립터에 저장되게 할 수 있으며, 이것은 oneM2M 사양들에서의 현재 가정이다. 이 접근법은 전체 그래프의 개개의 부분들이 어디에 저장되어야 하는지에 대한 결정과 관련하여 주석 엔진의 구현에 임의의 로직이 사용되게 할 수 있다.

이것은 분산형 시맨틱 디스크립터들 간의 관계들을 가능하게 하기 위한 논의와 연관된 예와 대략 연관되며, 여기서 각각의 <Device12> 및 <operationA>에 저장된 그래프들은 2개의 리소스와 상이한 주체들을 갖는 트리플들을 포함한다. 그러나, 이 예에서, 각각의 리소스는 그 자신의 디스크립션에 그 자체와 관련된 트리플들을 포함하기 때문에, 그래프 선택들이 완전히 임의적이지는 않다는 것에 유의하도록 한다.

이 예의 경우, 도 38의 RDF에서 기술되는 합성 그래프는 <Device12> 및 <OperationA>의 디스크립터들에 저장되는 것으로 결정된 정보를 각각 표현하기 위해 컬러들, 숫자들 또는 일부 메커니즘을 사용할 수 있다. 브래킷(101)의 선은 두 위치 모두에 저장되는 트리플을 나타낸다. 단, 도시된 텍스트는 디스크립터들 내의 정확한 RDF 신택스에 맞게 포맷되지 않고, 오히려 전체 그래프뿐 아니라 각각의 디스크립터 내에서 캡처된 트리플들의 개념 표현이라는 것에 유의하도록 한다.

이 예에서, 리소스들 <Device12> 및 <OperationA>과 연관된 시맨틱 디스크립터들은 도 42 및 도 43에 도시된 바와 같다. 도 42는 임의적인 그래프-기반 스킴에서의 <Device12>에 대한 예시적인 시맨틱 주석이다. 도 43은 임의적인 그래프-기반 스킴에서의 예시적인 <OperationA> 주석이다.

이 경우, 링크들의 리스트 방법을 채택하는 경우, <Device12> 및 <OperationA>의 relatedSemantics 어트리뷰트들은 서로를 가리킬 것이다. 이것은, 시맨틱 쿼리가 디스크립터들 중 하나의 디스크립터에 걸쳐 수행될 때, 다른 디스크립터 또한 쿼리 목적들을 위해 그래프를 완료하도록 리트리브되어야 한다는 것을 나타낼 것이다.

링크들의 그룹 방법을 채택하는 경우, <Device12> 및 <OperationA> 둘다의 relatedSemantics 어트리뷰트들은 동일한 <semanticGroup> 리소스를 가리킬 것이고, 여기서 semanticGroupLinks 어트리뷰트는 도 44에 도시된 링크들의 리스트를 포함할 것이다. 도 44는 링크들의 그룹 방법이 사용될 때의 예시적인 semanticGroupLinks 어트리뷰트들이다.

시맨틱 디스크립터들 간의 관계 유지는 또한 스킴들을 생성하는 주석 엔진에 의해 수행되며, 이것은 디스크립터들 간의 "관련" 관계가 확립된 방식과 동일하게 독립적이다. 여기서, "주체-기반 스킴" 및 "임의적인 그래프 기반 스킴"과 같은 예시적인 스킴들이 있다. 주체 기반 스킴에 의하면, 동일한 디스크립터의 트리플들은 동일한 주체를 가지며, 주체는 패런트 리소스이다. 임의적인 스킴에서, 트리플들은 주체에 의해서가 아니라 임의적으로 저장될 수 있다.

유지보수 방법은 그룹 접근법에서 더 간단한데, 왜냐하면 관계들이 변경되도록 디스크립터가 생성, 업데이트 또는 삭제되면, 특히 관련 디스크립터들의 더 큰 그룹들에 대한 <semanticGroup> 리소스에 업데이트들이 주로 발생하기 때문이다. 대조적으로, 링크들의 리스트 구현에서 관계들을 유지하는 것은 몇 개의 디스크립터들이 관련된 경우에만 최적이다.

<semanticGroup> 리소스의 사용에 관계없이, relatedSemantics 어트리뷰트들에 의해 연결된 다수의 리소스들에 걸쳐 저장된 시맨틱 디스크립션들에 대해 시맨틱 필터링을 가능하게 하기 위해, 시맨틱 쿼리 엔진은 도 45의 단계들을 사용할 수 있다. 도 45는 relatedSemantics 접근법을 사용하는 시맨틱 쿼리에 대한 예시적인 방법을 예시한다. 단계(381)에서, 수신자(152)는 요청 파라미터들을 유효성 검사함으로써 수신된 RETRIEVE 요청(단계(380))을 처리한다. 이 인스턴스에서는 단계(380)에서 RETRIEVE 요청이 시작하는 것으로 여기에서 논의되지만, 다른 시맨틱 리소스 발견이 일반적으로 적용 가능하다. 단계(382)에서, 수신자(152)는 대응하는 필드에서 어드레싱된 리소스와 연관된 시맨틱 디스크립터를 발견한다. semanticDescriptor 자체는 획득할 다른 디스크립터들을 식별하는 relatedSemantics라고 불리는 어트리뷰트를 가질 수 있다. 단계(383)에서, 수신자(152)는 발신자(151)가 메시지 타겟(예를 들어, 시맨틱 디스크립터)에 대한 RETRIEVE 권한들을 갖는 것을 검증한 다음, descriptor 및 relatedSemantics 어트리뷰트들을 추출한다. 메시지 타겟에 대한 권한들이 없는 경우, 대응하는 리턴 코드가 생성된다. 시맨틱 디스크립터의 컨텐츠는 국부적으로 저장될 수 있으며, 이는 문서로서 또는 로컬 또는 임시 그래프 저장소에 있을 수 있다. 문서는 도 42와 같은 시맨틱 디스크립터 등의 표현이다. 그래프 저장소는 도 25와 같다. 관련된 시맨틱스는 리트리브되는 다른 시맨틱 디스크립터들의 리스트(즉, 세트)를 생성하는 데 사용될 수 있다. 이 리스트는 직접적으로 또는 relatedSemantics 어트리뷰트에 의해 가리켜지는 <semanticGroup> 리소스에 액세스함으로써 제공될 수 있다. 발신자(151)가 <semanticGroup>에서 RETRIEVE 권한들을 갖지 않는 경우, 어떤 다른 디스크립터들도 수집되지 않는다.

계속해서 도 45를 참조하면, 단계(384)에서, 수신자(152)는 이전 단계에서 생성된 관련 디스크립터들의 리스트를 사용할 수 있다. 수신자(152)는 액세스 제어 규칙들에 따라 각각의 descriptor 어트리뷰트들 각각의 컨텐츠를 리트리브한다. 액세스되는 것이 허용되는 경우, 링크된 <semanticDescriptor> 리소스들의 descriptor 어트리뷰트들 각각의 컨텐츠가 SPARQL 요청이 실행되는 컨텐츠에 추가된다. SPARQL 요청에 따른 전체 또는 확장된 컨텐츠는 처리를 위해 SPARQL 엔진에 제공된다. 단계(385)에서, 수신자(152)는 결과 그래프 상에 제공된 시맨틱 쿼리 커맨드(또는 다른 시맨틱 리소스 발견)을 수행한다. 단계(386)에서, 수신자(152)는 시맨틱 쿼리에 대한 응답을 구성한다. 단계(387)에서, 로컬 그래프 저장소가 사용된 경우, 수신자는 로컬 규칙들 및 정책들에 기초하여 생성된 그래프를 유지 또는 삭제할 수 있다.

시맨틱 필터링 또는 발견을 위한 개시된 접근법의 기술적 효과들은 다음을 포함할 수 있다: 1) 요청된 시맨틱 정보가 발견될 수 있다; 2) 오퍼레이션의 실행 시에 정보에 액세스될 수 있기 때문에, 일부 인스턴스들에서는 리소스-기반 액세스 제어가 보다 용이하게 시행될 수 있고, 요청자의 액세스 권한들이 적용될 수 있다; 3) 처리하기 전에 SPARQL 엔진에 의해 처리될 컨텐츠가 수집되어, 외부의 비-oneM2M 특정 시맨틱 쿼리 엔진들의 사용을 가능하게 할 수 있다; 또는 4) 2개 이상의 공통 개념을 포함하는 디스크립터들은 오직 하나의 링크에 의해 링크되며, 이는 요청 처리를 위해 고려되는 중복된 컨텐츠를 더 쉽게 피할 수 있게 한다.

"분산형 시맨틱 디스크립터들 간의 관계를 가능하게 하는 것"과 연관된 예를 사용하면, 합성 그래프(도 34)가 위의 단계들(예를 들어, 도 45)을 사용하여 구성되고, 처리를 위해 SPARQL 엔진에 제공된다. SPARQL 엔진은 그래프들을 임시로 저장하기 위해 로컬 트리플 저장소를 사용할 수 있으며, 어떤 경우에는 이것이 HYBRID 접근법이 될 수 있다.

이하에서는 <semanticGroup>에 기초한 예들이 논의된다. 분산형 시맨틱 디스크립터들의 구현이 주어지면, 이하에서 도입되는 강화된 <semanticGroup> 리소스는 디스크립터들 간의 관계들을 유지할 뿐만 아니라 보다 효과적인 시맨틱 필터링 오퍼레이션들을 위해 제공할 수 있다.

도 46은 강화된 <semanticGroup> 리소스의 예를 예시한다. 강화는 리소스 <semanticFanOutPoint>의 도입을 포함하며, 리소스 <semanticFanOutPoint>는 개개의 리소스들 대신에 <semanticGroup> 리소스가 시맨틱 쿼리들의 타겟이 될 수 있게 한다. 이는 쿼리 발신자(예를 들어, 발신자(151))가 이전의 발견들에 기초하여 리소스 트리를 과소 평가할 때 유용성의 계층을 추가할 수 있다. <semanticGroup> 리소스의 <semanticFanOutPoint>에 쿼리들을 어드레싱함으로써, 기술적인 효과는 수신자(152)에서의 시맨틱 엔진이 전체 그룹과 연관된 합성 그래프를 보다 쉽게 유지하고 검색할 수 있다는 것일 수 있다. 로컬 트리플 저장소 스토리지, 캐싱 등은 추가로 보다 빠른 결과들을 위해 수신자에서의 시맨틱 엔진에서 쿼리를 보다 효율적으로 처리하게 할 수 있다. 또한, <semanticGroup> 리소스는 상이한 SE들에 속하는 리소스들에 대한 쿼리들을 타겟으로 하는 데 사용될 수 있다. 제1 SE 상에 상주하는 <semanticGroup> 리소스가 제2 SE 및 제3 SE 상의 멤버 리소스들을 각각 포함하는 경우, 리트리브 오퍼레이션은 제2 SE 및 제3 SE 상의 대응하는 리소스들로 전개(fanned out)될 수 있다. 그 후, 쿼리들은 위에서 설명된 개개의 SE들 내에서 처리될 수 있다.

<semanticGroup> 리소스를 사용할 때의 다른 강화는 시맨틱 디스크립터에 포함된 각각의 그래프에 대해 그래프 명칭들의 사용에 대한 명령어들을 제공함으로써 행해질 수 있으며, 예를 들어, 생성된 각각의 시맨틱 디스크립터는 명명될 수 있고, 고유한 명칭이 그에 할당되어야 한다. 또한, 그래프 명칭은 디스크립터의 위치와 연관되어 제공될 수 있다. 명명은 그룹 내의 모든 그래프들이 함께 어드레싱될 수 있도록 계층적일 수도 있고, 할당된 명칭들은 서로 독립적일 수도 있다. 어느 경우든, 새로운 어트리뷰트 groupGraphNames가 리스트 또는 루트 명칭을 통해 그룹 내의 그래프들에 대한 명칭을 제공하는 데 사용될 수 있다.

이 방법의 기술적인 효과는 시맨틱 오퍼레이션들을 가능한 한 특정되게 또는 넓게 함으로써 이들의 발신자에게 보다 큰 세분화를 제공하는 것일 수 있다. 수신자 측에서는, <semanticFanOutPoint>에 어드레싱된 쿼리 요청을 수신하지만, 여기서 SPARQL 페이로드가 특정 그래프를 나타낼 때, 엔진이 주어진 그래프와 연관된 디스크립터만을 어드레싱하기 위해 그래프 명칭과 semanticGroupLinks에서 제공된 링크들 간의 관계를 사용하도록, 시맨틱 엔진이 더 효율적일 수 있다.

도 4에 도시된 oneM2M 아키텍처를 고려하면, 시맨틱 그래프 저장소 및 시맨틱 보관소 관리자는 CSF 시맨틱스에 상주할 수 있고, 리소스 트리 및 데이터 보관소 관리자는 CSF 데이터 관리 및 리포지토리에 상주할 수 있다. 도 47은 oneM2M을 고려한 시맨틱 그래프 저장소를 갖는 예시적인 아키텍처를 예시한다. 도 48은 oneM2M을 사용하는 개시된 방법들에 대한 예시적인 리소스 트리를 예시한다. 도 48에 도시된 바와 같이, 새로운 리소스 <SemanticGraphStore>가 <CSEbase> 아래에 추가된다. 일례에서, 상이한 semanticDescriptor 리소스의 relatedSemantics 어트리뷰트는 관련된 디스크립터들을 나타내기 위해 <semanticGroup>을 가리킬 수 있다. 완료되고 나면, 그룹의 semanticFanOutPoint가 모든 관련된 디스크립터들과 관련된 시맨틱 오퍼레이션들을 전송하는 데 사용될 수 있다.

도 50은 여기서 논의된 방법들 및 시스템들에 기초하여 생성될 수 있는 예시적인 디스플레이(예를 들어, 그래픽 사용자 인터페이스)를 예시한다. 디스플레이 인터페이스(901)(예를 들어, 터치 스크린 디스플레이)는 여기서 논의된 바와 같은 액세스 제어를 갖는 eHealth 시맨틱 쿼리와 같이 시맨틱 IoT에 대한 RESTful 오퍼레이션들과 연관된 블록(902)에서 텍스트를 제공할 수 있다. 다른 예에서, 여기서 논의된 단계들 중 임의의 단계의 프로그레스(예를 들어, 전송된 메시지들 또는 단계들의 성공)가 블록(902)에 디스플레이될 수 있다. 또한, 그래픽 출력(903)이 디스플레이 인터페이스(901) 상에 디스플레이될 수 있다. 그래픽 출력(903)은 시맨틱스 그래픽 저장소의 토폴로지일 수 있으며, 여기서 논의된 임의의 방법 또는 시스템들(예를 들어, 특히, 도 18 내지 도 21)의 프로그레스에 대한 그래픽 출력 등일 수 있다. 도 53a 내지 도 53c는 디스플레이 인터페이스(901) 상에 있을 수 있는 출력을 예시한다. 다운로드 포맷을 선택하는 옵션을 갖는 쿼리 결과가 있을 수 있다. 도시된 바와 같이, Svalue, Dvalue, 시맨틱 디스크립터, 및 도 53a 내지 도 53c의 예 및 대응하는 결과에서 제공되는 바와 같이 도시된 샘플이 있을 수 있다.

도 51a는 시맨틱 IoT에 대한 RESTful 오퍼레이션들과 연관된 하나 이상의 개시된 개념(예를 들어, 도 16 내지 도 49c 및 도 54)이 구현될 수 있는 예시적인 머신-투-머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(Web of Things)(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT를 위한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 IoT/WoT뿐만 아니라 IoT/WoT 서비스 계층 등의 컴포넌트일 수 있다.

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

도 51a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 전개의 네트워크 측을 지칭하고, 필드 도메인은 대개 M2M 게이트웨이 뒤에 있는 영역 네트워크들을 지칭한다. 필드 도메인은 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, 블루투스), 직접적인 무선 링크 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

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

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

일부 예들에서, M2M 애플리케이션들(20 및 20')은 본 명세서에서 논의된 시맨틱 IoT에 대한 RESTful 오퍼레이션들을 사용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은 운송, 건강 및 웰니스(wellness), 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 및 보안 및 감시와 같은 다양한 산업 분야들(그러나, 이에 제한되지 않음)의 애플리케이션들을 포함할 수 있다. 위에서 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들 및 기타 서버들에 걸쳐 실행되는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, M2M 애플리케이션들(20 및 20')에 대한 서비스들로서 이러한 기능들을 제공한다.

본 출원의 시맨틱 IoT에 대한 RESTful 오퍼레이션들은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층은 애플리케이션 프로그래밍 인터페이스(API)들 및 기반 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 디바이스, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M과 oneM2M은 모두 본 출원의 시맨틱 IoT에 대한 RESTful 오퍼레이션들을 포함할 수 있는 서비스 계층을 사용한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(Service Capability Layer)(SCL)이라고 지칭된다. SCL은 M2M 디바이스(디바이스 SCL(device SCL)(DSCL)이라고 지칭됨), 게이트웨이(게이트웨이 SCL(gateway SCL)(GSCL)이라고 지칭됨) 또는 네트워크 노드(네트워크 SCL(network SCL)(NSCL)이라고 지칭됨) 내에서 구현될 수 있다. oneM2M 서비스 계층은 공통 서비스 기능(CSF)들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 타입의 CSF들의 세트를 인스턴스화한 것은 공통 서비스 엔티티(Common Services Entity)(CSE)라고 지칭되며, 이는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있다. 또한, 본 출원의 시맨틱 IoT에 대한 RESTful 오퍼레이션들은 서비스 지향 아키텍처(Service Oriented Architecture)(SOA) 또는 리소스 지향 아키텍처(resource-oriented architecture)(ROA)를 사용하여 본 출원의 시맨틱 IoT에 대한 RESTful 오퍼레이션들과 같은 서비스들에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.

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

도 51c는, 예를 들어, M2M 단말 디바이스(18)(예를 들어, AE(367), AE(335), 또는 발신자(151)) 또는 M2M 게이트웨이 디바이스(14)(예를 들어, SE(361) 또는 수신자(152))와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 51c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시된 대상과 일관성을 유지하면서 전술한 엘리먼트들의 임의의 하위 조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스(30)(예를 들어, 서비스 엔티티(163), 도 22의 수신자 및 도 22의 발신자(161), 도 47의 MN-CSE, 도 29의 애플리케이션 엔티티(373), 도 47의 IN-CSE 등)는 시맨틱 IoT에 대한 RESTful 오퍼레이션들을 위한 개시된 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

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

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

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

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

프로세서(32)는 비이동식 메모리(44) 또는 이동식 메모리(46)와 같은 임의의 타입의 적절한 메모리로부터의 정보에 액세스할 수 있고, 그러한 메모리에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 랜덤 액세스 메모리(random-access memory)(RAM), 판독 전용 메모리(read-only memory)(ROM), 하드 디스크, 또는 임의의 다른 타입의 메모리 스토리지 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 식별 모듈(subscriber identity module)(SIM) 카드, 메모리 스틱, 보안 디지털(secure digital)(SD) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는 서버 또는 가정용 컴퓨터와 같은 M2M 디바이스(30) 상에 물리적으로 위치하지 않은 메모리로부터의 정보에 액세스하고, 그러한 메모리에 데이터를 저장할 수 있다. 프로세서(32)는, 본 명세서에 설명된 예들 중 일부 예들에서의 단계들이 성공했는지 또는 실패했는지 여부(예를 들어, 시맨틱 트리플 CREATE 오퍼레이션 요청 또는 시맨틱 트리플 RETRIEVE 오퍼레이션 요청 등)에 응답하여, 디스플레이 또는 지시자들(42) 상의 조명 패턴들, 이미지들, 또는 컬러들을 제어하거나, 또는 본 명세서에서 논의된 시맨틱 IoT에 대한 RESTful 오퍼레이션들 및 연관된 컴포넌트들의 상태를 다른 방식으로 나타내도록 구성될 수 있다. 디스플레이 또는 지시자들(42) 상의 제어 조명 패턴들, 이미지들 또는 컬러들은 본 명세서에서 예시되거나 논의된 도면들(예를 들어, 도 16 내지 도 49c 및 도 52 내지 도 54 등)에서의 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영할 수 있다. 본 명세서에는 시맨틱 IoT에 대한 RESTful 오퍼레이션들의 메시지들 및 절차들이 개시되어 있다. 메시지들 및 절차들은 사용자들이 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40) 또는 디스플레이/터치패드(42))를 통해 리소스-관련 리소스들을 요청하고, 특히 디스플레이(42) 상에 디스플레이될 수 있는 시맨틱 IoT에 대한 RESTful 오퍼레이션들의 리소스들을 요청, 구성 또는 쿼리하는 인터페이스/API를 제공하도록 확장될 수 있다.

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

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

프로세서(32)는 다른 주변 장치들(52)에 추가로 결합될 수 있으며, 이들은 추가적인 피쳐들, 기능 또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 또는 하드웨어 모듈을 포함할 수 있다. 예를 들어, 주변 장치들(52)은 가속도계, 생체 인식(예를 들어, 지문) 센서들, 전자 나침반, 위성 송수신기, 센서, 디지털 카메라(사진 또는 비디오용), 범용 직렬 버스(USB) 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비젼 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, 주파수 변조(frequency modulated)(FM) 무선 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등과 같은 다양한 센서들을 포함할 수 있다.

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

도 51d는, 예를 들어, 도 51a 및 도 51b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독 가능 명령어들에 의해 제어될 수 있으며, 컴퓨터 판독 가능 명령어들은 소프트웨어의 형태로, 어디에서든, 또는 그러한 소프트웨어가 저장되거나 액세스되는 모든 수단을 통해 이루어질 수 있다. 이러한 컴퓨터 판독 가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 수행하게 하기 위해 중앙 처리 장치(CPU)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들 및 퍼스널 컴퓨터들에서, 중앙 처리 장치(91)는 마이크로프로세서라고 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 장치(91)는 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가 기능들을 수행하거나 또는 CPU(91)를 보조하는 프로세서로서, 메인 CPU(91)와 구별된다. CPU(91) 또는 코프로세서(81)는 도 18의 단계(202)에서와 같이 CREATE하라는 요청을 처리하는 것과 같이 시맨틱 IoT에 대한 RESTful 오퍼레이션들을 위한 개시된 시스템들 및 방법들과 관련된 데이터를 수신, 생성 및 프로세싱할 수 있다.

동작 시에, CPU(91)는 명령어들을 인출(fetch), 디코딩 및 실행하고, 컴퓨터의 메인 데이터-전달 경로인 시스템 버스(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)을 도 51a 및 도 51b의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는 데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

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

도면들에 예시된 바와 같이, 본 개시내용의 대상 - 시맨틱 IoT에 대한 RESTful 오퍼레이션들 - 의 바람직한 방법들, 시스템들 또는 장치들을 설명함에 있어서, 명확함을 위해 구체적인 용어가 사용된다. 그러나, 청구 대상은 그렇게 선택된 특정 용어에 제한되는 것으로 의도되지 않고, 각각의 특정 엘리먼트는 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함한다는 점이 이해되어야 한다.

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

이 기술된 설명은 예들을 사용하여 최상의 모드를 포함한 본 발명을 개시하고, 또한 본 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작 및 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있게 한다. 본 발명의 특허 가능한 범위는 청구 범위에 의해 규정되며, 본 기술분야의 통상의 기술자에게 가능한 다른 예들(예를 들어, 단계들을 건너뛰거나, 단계들을 결합하거나, 본 명세서에 개시된 예시적인 방법들 사이에 단계들을 추가하는 것)을 포함할 수 있다. 그러한 다른 예들은, 청구 범위의 문자 언어와 상이하지 않은 구조적 엘리먼트들을 갖는 경우, 또는 청구 범위의 문자 언어와 비실질적인 차이들을 갖는 등가의 구조적 엘리먼트들을 포함하는 경우, 청구 범위의 범주 내에 있는 것으로 의도된다.

Claims (20)

1. 장치로서,
   프로세서; 및
   상기 프로세서와 결합된 메모리
   를 포함하고, 상기 메모리는 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 수행하게 하는 실행 가능한 명령어들을 포함하고, 상기 동작들은,
   시맨틱 발견(semantic discovery)을 위한 메시지를 수신하는 동작 - 상기 메시지의 타겟 리소스는 가상 전개 리소스(virtual fanout resource)를 포함하고, 상기 가상 전개 리소스는 그룹 리소스의 차일드 리소스(child resource)임 - ;
   상기 메시지에 기초하여, 상기 그룹 리소스의 멤버 리소스들의 시맨틱 디스크립터(semantic descriptor)들의 어트리뷰트(attribute)들로부터 컨텐츠를 리트리브(retrieve)하는 동작 - 복수의 멤버 리소스는 통신 네트워크의 다수의 공통 서비스 엔티티(common service entity)에 걸쳐 분산되어 있음 - ;
   상기 리트리브된 컨텐츠에 기초하여 시맨틱 그래프(semantic graph)를 생성하는 동작; 및
   상기 시맨틱 그래프 상에서 시맨틱 발견을 수행하기 위한 명령어들을 제공하는 동작
   을 포함하는 장치.
2. 제1항에 있어서, 상기 동작들은 상기 생성된 시맨틱 그래프를 임시 그래프 저장소(temporary graph store)에 저장하는 동작을 추가로 포함하는 장치.
3. 제1항에 있어서, 상기 동작들은 상기 시맨틱 그래프를 위한 명칭을 할당하는 동작을 추가로 포함하는 장치.
4. 제1항에 있어서, 상기 동작들은 상기 시맨틱 그래프를 위한 명칭을 할당하는 동작을 추가로 포함하고, 상기 시맨틱 그래프의 상기 명칭은 상기 시맨틱 디스크립터들의 제1 시맨틱 디스크립터의 위치와 연관되어 있는, 장치.
5. 제1항에 있어서, 상기 동작들은 상기 시맨틱 그래프를 위한 계층적 명칭을 할당하는 동작을 추가로 포함하는 장치.
6. 제1항에 있어서, 상기 동작들은:
   상기 시맨틱 그래프를 위한 명칭을 할당하는 동작;
   그룹 내의 시맨틱 그래프들을 위한 명칭들을 제공하는데 사용되는 어트리뷰트에 상기 명칭을 삽입하는 동작
   을 추가로 포함하는 장치.
7. 방법으로서,
   시맨틱 발견을 위한 메시지를 수신하는 단계 - 상기 메시지의 타겟 리소스는 가상 전개 리소스이고, 상기 가상 전개 리소스는 그룹 리소스의 차일드 리소스임 - ;
   상기 메시지에 기초하여, 상기 그룹 리소스의 멤버 리소스들의 시맨틱 디스크립터들의 컨텐츠를 리트리브하는 단계 - 복수의 멤버 리소스는 다수의 공통 서비스 엔티티에 걸쳐 분산되어 있음 - ;
   상기 리트리브된 컨텐츠에 기초하여 시맨틱 그래프를 생성하는 단계; 및
   상기 시맨틱 그래프 상에서 시맨틱 발견을 수행하기 위한 명령어들을 제공하는 단계
   를 포함하는 방법.
8. 제7항에 있어서, 상기 생성된 시맨틱 그래프를 임시 그래프 저장소(temporary graph store)에 저장하는 단계를 추가로 포함하는 방법.
9. 제7항에 있어서, 상기 시맨틱 그래프를 위한 명칭을 할당하는 단계를 추가로 포함하는 방법.
10. 제7항에 있어서, 상기 시맨틱 그래프를 위한 명칭을 할당하는 단계를 추가로 포함하며, 상기 시맨틱 그래프의 상기 명칭은 상기 시맨틱 디스크립터들의 제1 시맨틱 디스크립터의 위치와 연관되어 있는, 방법.
11. 제7항에 있어서, 상기 시맨틱 그래프를 위한 계층적 명칭을 할당하는 단계를 추가로 포함하는 방법.
12. 제7항에 있어서,
    상기 시맨틱 그래프를 위한 명칭을 할당하는 단계; 및
    그룹 내의 시맨틱 그래프들을 위한 명칭들을 제공하는데 사용되는 어트리뷰트에 상기 명칭을 삽입하는 단계
    를 추가로 포함하는 방법.
13. 컴퓨터 프로그램이 저장된 컴퓨터 판독가능 저장 매체로서, 상기 컴퓨터 프로그램은 데이터 프로세싱 유닛에 로딩 가능하고, 상기 컴퓨터 프로그램이 상기 데이터 프로세싱 유닛에 의해 실행될 때, 상기 데이터 프로세싱 유닛으로 하여금 제7항 내지 제12항 중 어느 한 항에 따른 방법의 단계들을 실행하게 하도록 구성되는 컴퓨터 판독가능 저장 매체.
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images