SEMANTIC QUERY PROCESSING WITH INFORMATION ASYMMETRY

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 62/452,779, filed on January 31, 2017, entitled "Semantic Query Processing With Information Asymmetry," and U.S. Provisional Patent Application No. 62/472,909, filed on March 17, 2017, entitled "Semantic Query Processing With Information Asymmetry." The contents of both applications are hereby incorporated by reference herein.

BACKGROUND

[0002] The Semantic Web is an extension of the Web through standards by the World Wide Web Consortium (W3C). The standards promote common data formats and exchange protocols on the Web, most fundamentally the Resource Description Framework (RDF).

[0003] The Semantic Web involves publishing in languages specifically designed for data: Resource Description Framework (RDF), Web Ontology Language (OWL), and Extensible Markup Language (XML). These technologies are combined to provide descriptions that supplement or replace the content of Web documents via web of linked data. Thus, content may manifest itself as descriptive data stored in Web-accessible databases, or as markup within documents, particularly, in Extensible HTML (XHTML) interspersed with XML, or, more often, purely in XML, with layout or rendering cues stored separately.

[0004] The Semantic Web Stack illustrates the architecture of the Semantic Web specified by W3C, as shown in FIG. 1. The functions and relationships of the components can be summarized as follows.

[0005] XML provides an elemental syntax for content structure within documents, yet associates no semantics with the meaning of the content contained within. XML is not at present a necessary component of Semantic Web technologies in most cases, as alternative syntaxes exist, such as Turtle. XML Schema is a language for providing and restricting the structure and content of elements contained within XML documents.

[0006] RDF is a simple language for expressing data models, which refers to objects ("web resources") and their relationships in the form of subject-predicate-object, i.e. S-P-0 triple or RDF triple. An RDF-based model can be represented in a variety of syntaxes, e.g.,

RDF/XML, N3, Turtle, and RDFa. RDF is a fundamental standard of the Semantic Web. [0007] RDF Graph is a directed graph where the edges represent the "predicate" of RDF triples while the graph nodes represent "subject" and/or "object" of RDF triples, In other words, the linking structure as described in RDF triples forms such a directed RDF Graph.

[0008] RDF Schema extends RDF and is a vocabulary for describing properties and classes of RDF-based resources, with semantics for generalized-hierarchies of such properties and classes.

[0009] OWL adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality, richer type of properties, characteristics of properties (e.g. symmetry), and enumerated classes.

[0010] SPARQL is a protocol and query language for semantic web data sources, to query and manipulate RDF graph content (i.e. RDF triples) on the Web or in an RDF store (i.e. a Semantic Graph Store).

[0011] SPARQL 1.1 Query, a query language for RDF graph, can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports aggregation, subqueries, negation, creating values by expressions, extensible value testing, and constraining queries by source RDF graph. The results of SPARQL queries can be result sets or RDF graphs.

[0012] SPARQL 1.1 Update, an update language for RDF graphs. It uses a syntax derived from the SPARQL Query Language for RDF. Update operations are performed on a collection of graphs in a Semantic Graph Store. Operations are provided to update, create, and remove RDF graphs in a Semantic Graph Store.

[0013] oneM2M Functional Architecture

[0014] The oneM2M standard (e.g., oneM2M Functional Architecture -V2.9.0) under development defines a Service Layer called "Common Service Entity (CSE)". The purpose of the Service Layer is to provide "horizontal" services that can be utilized by different "vertical" M2M systems and applications. The CSE supports four reference points as shown in FIG. 2. The Mca reference point interfaces with the Application Entity (AE). The Mcc reference point interfaces with another CSE within the same service provider domain and the Mcc' reference point interfaces with another CSE in a different service provider domain. The Men reference point interfaces with the underlying network service entity (NSE). An NSE provides underlying network services to the CSEs, such as device management, location services and device triggering. [0015] CSE contains multiple logical functions called "Common Service Functions (CSFs)", such as "Discovery" and "Data Management & Repository". FIG. 3 illustrates some of the CSFs defined by oneM2M. The oneM2M architecture enables the following types of Nodes:

[0016] Application Service Node (ASN): An ASN is a Node that contains one CSE and contains at least one Application Entity (AE). Example of physical mapping: an ASN could reside in an M2M Device.

[0017] Application Dedicated Node (ADN): An ADN is a Node that contains at least one AE and does not contain a CSE. There may be zero or more ADNs in the Field Domain of the oneM2M System. Example of physical mapping: an Application Dedicated Node could reside in a constrained M2M Device.

[0018] Middle Node (MN): A MN is a Node that contains one CSE and contains zero or more AEs. There may be zero or more MNs in the Field Domain of the oneM2M System. Example of physical mapping: a MN could reside in an M2M Gateway.

[0019] Infrastructure Node (IN): An IN is a Node that contains one CSE and contains zero or more AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider. A CSE in an IN may contain CSE functions not applicable to other node types.

Example of physical mapping: an IN could reside in an M2M Service Infrastructure.

[0020] Non-oneM2M Node (NoDN): A non-oneM2M Node is a Node that does not contain oneM2M Entities (neither AEs nor CSEs). Such Nodes represent devices attached to the oneM2M system for interworking purposes, including management.

[0021] Some semantic enablement functionalities for oneM2M are defined in oneM2M Functional Architecture -V2.9.0 and oneM2M TR-0007.

[0022] Semantic Description in oneM2M Architecture

[0023] The <semanticDescriptor> resource as shown in FIG. 4 is used to store a semantic description pertaining to a resource and potentially sub-resources. Such a description may be provided according to ontologies. The semantic information is used by the semantic functionalities of the oneM2M system and is also available to applications or CSEs. The <semanticDescriptor> resource include the attributes specified in Table 1. Table 1: Attributes of <semanticDescriptor> Resource

[0024] Semantic Filtering Proposals in oneM2M. Generic filtering is supported by having filter criteria specified in a request operation. In order to provide for semantic filtering, an additional value for the request operation filter criteria has been proposed in, with the definition shown in Table 2. Multiple instances may be used, which according to the general rules for evaluating filter criteria, means that an "OR" semantics applies, i.e. the overall result for the semantics filter criteria is true if one or more of the semantic filters matches the semantic description. Note that semantics in table 2 is defined in oneM2M TR-0007 and it corresponds to request parameter semanticFilter in oneM2M TS-0001. When the SPARQL query contained in the semanticFilter parameter matches semantic triples in the <semanticDescriptor> child resources of a parent resource, it means this semantic filtering is successful and corresponding parent resource will be returned.

Table 2. semantics Filter Criteria

[0025] Below is a semantic filtering example given in oneM2M TR-0007. Example 1: Filter for AE resources representing devices that measure temperature.

Semantic Descriptor of Device 1 AE

my:MyDevicel rdftype base:Device

my:MyDevicel base:hasService my:MyServicel

my:MyServicel base:hasFunctionality my : MyFunctionality 1 my : My Functionality 1 rdftype base:Measuring

my : My Functionality 1 base:refersTo my:MyAspectl

my:myAspectl rdftype aspect: Temperature

Semantic Descriptor of Device 2 AE

my:MyDevice2 rdftype base:Device

my:MyDevice2 base:hasService my:MyService2

my:MyService2 base:hasFunctionality my : my Functionality 2 my : my Functionality 2 rdftype base: Controlling

my : my Functionality 2 base:refersTo my:myAspect2

my:myAspect2 rdftype aspect: Temperature

SPARQL Request 1

SELECT ?device

WHERE { ?device rdftype base:Device .

?device base:hasService ?service .

?service base:hasFunctionality ?functionality .

?functionality rdftype base:Measuring .

?functionality base:refersTo ?aspect .

?aspect rdf:type instance:Temperature }

SPARQL Execution Results

(On Devicel semantic description) --> my: my Devicel

(On Device 2 semantic description) --> empty

[0026] This means that the AE resource that is described by my:myDevicel will be included in the result set, whereas the AE resource described by my:myDevice2 will not be included.

[0027] Semantic Filtering/Discovery vs. Semantic Query in oneM2M Context.

Currently oneM2M already supports semantic resource discovery through semantic filter.

Disclosed herein are descriptions on the differences between the semantic resource discovery and the semantic query. Semantic queries enable the retrieval of both explicitly and implicitly derived information based on syntactic, semantic and structural information contained in data (e.g., RDF triples).

[0028] In particular, the following summarizes some differences between semantic query and semantic resource discovery: 1) Semantic Query is to extract useful knowledge over the RDF data infrastructure; and 2) Semantic resource discovery may be targeted for discovering resources and retum resource URIs based on resource's semantic metadata (note that, semantic query can also return resource URIs, i.e. semantic query can do more than semantic resource discovery); among other things.

[0029] Table 3 shows examples of query results of various semantic queries. Table 3. Example Query Results of Semantic Queries

Query 1:

PREFIX foaf: <http://xmlns.eom/foaf/0.l/>

SELECT ?name

WH ERE {

Pperson foaf:name ?name .

}

Query 1: Expected Results name

"mc schraefel"

"John Klensin"

"Libby Miller"

Query 2:

PREFIX foaf: <http://xmlns.eom/foaf/0.l/>

SELECT *

WH ERE {

Pperson foaf:name Pname .

Pperson foaf:mbox Pemail .

}

Query 2: Expected Results

person name email

<http://www.w3.Org/People/karl/karl-foaf.xrdf#me> "Karl Dubost"

<mailto:karl@w3.org>

<http://www.w3.Org/People/Berners-Lee/card#amy> "Amy van der Hiel"

<mailto:amy@w3.org> <http://www.w3. org/People/Berners-Lee/card#edd> "Edd Duimbill"

<mailto:edd@xnnlhack.conn>

Query 3:

PREFIX foaf: <http://xmlns.eom/foaf/0.l/>

PREFIX card: <http://www.w3.Org/People/Berners-Lee/card#>

SELECT Phomepage

FROM <http://www.w3.org/People/Berners-Lee/card>

WH ERE {

card:i foaf:knows Pknown .

Pknown foaf:homepage Phomepage .

}

Query 3: Expected Results homepage

<http://purl.org/net/eric/>

<http://www.mellon.org/about_foundation/staff/program-are a-staff/irafuchs>

<http://www.johnseelybrown.com/>

<http://heddley.com/edd/>

SUMMARY

[0030] In conventional systems, information asymmetry exists between the data in a service layer resource tree and the data in a semantic Triple Store (e.g., some of

information/knowledge stored in resource tree may not be stored in a Triple Store), which affects the performance of semantic query processing. Due to the information asymmetry, many semantic queries of the Triple Store do not yield desired query results even if they are valid queries. Disclosed herein are methods, systems, and apparatuses that address issues regarding information asymmetry associated with semantic query. [0031] The information asymmetry issue in semantic queries may be addressed based on different implementations as discussed herein. For a category-1 implementation - the process generally manipulates the original semantic query statement and synchronizes

information/knowledge bases. Category-1 implementation may include a new service-layer resource ontology (SRO), information synchronization, semantic query processing for Fully Semantic Capable (FSC) semantic query initiator (SQI), or semantic query processing for resource tree centric (RTC) SQI, among other thing. An SRO may be used for re-representing the information (that is originally only stored in the service layer resource tree) as RDF triples so that the information may also be available at Triple Store. The information synchronization process between resource tree and Triple Store may be performed based on CRUD (create retrieve update delete) operations that occur. New procedures are disclosed for semantic query processing for category-1 implementation that includes multiple types of semantic query initiators (SQI), such as FSC-SQI or RTC-SQI, served with different semantic query processing procedures as provided herein.

[0032] For a category-2 implementation, it may not touch the data infrastructure part, so the information asymmetry between resource tree and Triple Store exists. However, if the original semantic query needs some information that is only available in resource tree, but unavailable in Triple Store, the processing of original query, based on where the needed information resides, may be split into multiple threads called 1) Resource Tree Thread (RT- Thread) and 2) Triple Store Thread (TS-Thread). Accordingly, partial query results may be worked out at both resource tree and Triple Store, and those partial results may be combined together as the final query result of the original semantic query.

BRIEF DESCRIPTION OF THE DRAWINGS

[0033] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0034] FIG. 1 illustrates an exemplary Architecture of the Semantic Web;

[0035] FIG. 2 illustrates exemplary oneM2M Architecture;

[0036] FIG. 3 illustrates an exemplary oneM2M Common Service Functions;

[0037] FIG. 4 illustrates an exemplary Structure of <semanticDescriptor> Resource in a Resource Tree;

[0038] FIG. 5 illustrates an exemplary Semantic-based Smart Home Temperature Control; [0039] FIG. 6A illustrates an exemplary reason a semantic query may not be processed due to information asymmetry;

[0040] FIG. 6B illustrates an exemplary category-1 implementation;

[0041] FIG. 6C illustrates an exemplary SRO process;

[0042] FIG. 7 illustrates exemplary Logical Entities Related to Semantic Query and Their Interactions;

[0043] FIG. 8 illustrates an exemplary Procedure for Information Synchronization Due to CREATE Resource Operation;

[0044] FIG. 9 illustrates an exemplary Procedure for Information Synchronization Due to UPDATE Resource Operation;

[0045] FIG. 10 illustrates an exemplary Procedure for Information Synchronization Due to DELETE Resource Operation;

[0046] FIG. 11 illustrates an exemplary Procedure for Semantic Query Processing for Fully Semantic Capable SQI (Category-1);

[0047] FIG. 12 Procedure for Semantic Query Processing for Resource-Tree Centric SQI (Category-1 Implementation);

[0048] FIG. 13 illustrates an exemplary procedure for semantic query processing for FSC-SQI (Category-2, TS-Thread-First Strategy);

[0049] FIG. 14 illustrates an exemplary procedure for semantic query processing for FSC-SQI (category-2 implementation, RT-Thread-First strategy);

[0050] FIG. 15 illustrates exemplary alternative interactions between different entities of FIG. 7;

[0051] FIG. 16 illustrates an exemplary DAS CSF for oneM2M Service Layer;

[0052] FIG. 17 illustrates exemplary oneM2M Entites;

[0053] FIG. 18 illustrates a new oneM2M Resource <semantic-query-portal>;

[0054] FIG. 19 illustrates a new oneM2M Resource <RDFTripleManipulation>;

[0055] FIG. 20 illustrates an exemplary oneM2M Procedure for Information

Synchronization Due to CREATE Resource operation;

[0056] FIG. 21 illustrates an exemplary oneM2M Procedure for Semantic Query Processing for Fully Semantic Capable SQI (Category-2 Implementation, RT-Thread-First Strategy);

[0057] FIG. 22 illustrates an exemplary user interface for semantic query as disclosed herein; [0058] FIG. 23 illustrates an exemplary oneM2M Resource's Attributes in RDF

Triples;

[0059] FIG. 24 illustrates an exemplary oneM2M Resource's Attributes in RDF Triples

[0060] FIG. 25 illustrates an exemplary oneM2M Resource's Attributes in RDF

Triples;

[0061] FIG. 26A illustrates an exemplary machine-to-machine (M2M) or Internet of Things (IoT) communication system in which the disclosed subject matter may be implemented;

[0062] FIG. 26B illustrates an exemplary architecture that may be used within the M2M / IoT communications system illustrated in FIG. 26 A;

[0063] FIG. 26C illustrates an exemplary M2M / IoT terminal or gateway device that may be used within the communications system illustrated in FIG. 26A; and

[0064] FIG. 26D illustrates an exemplary computing system in which aspects of the communication system of FIG. 26A may be embodied.

DETAILED DESCRIPTION OF ILLUSTRATIVE EXAMPLES

[0065] In conventional systems, information asymmetry exists between the data in a service layer resource tree and the data in a semantic Triple Store (e.g., some of

information/knowledge stored in resource tree may not be stored in a Triple Store), which affects the performance of semantic query processing. Due to the information asymmetry, many semantic queries of the Triple Store do not yield desired query results even if they are valid queries. Disclosed herein are methods, systems, and apparatuses that address issues regarding information asymmetry associated with semantic query.

[0066] In general, semantic queries enable the retrieval of both explicitly and implicitly derived information/knowledge based on syntactic, semantic and structural information, such as information contained in the RDF triples stored in a Triple store. Semantic query may retum any format of query results in terms of "knowledge," not just URIs of resources. Semantic query may be considered an advanced semantic-centric feature in semantic web, while semantic resource discovery is more service layer-oriented feature to support resource discovery. That being said, semantic query may be associated with semantic-centric infrastructure such as Triple Store, while semantic resource discovery may be associated with resource tree infrastructure, such as oneM2M resource tree defined in the service layer.

[0067] A query process includes the following significant parts: 1) the query statement to be processed and 2) the data infrastructure, such as terms of RDF triples stored in the Triple Store. In view of these significant parts of the query process, disclosed herein are category- 1 implementation and category-2 implementation discussed in more detail herein.

[0068] Discussed below is an exemplary use case to give additional perspective to issues with regard to information asymmetry associated with conventional semantic query. FIG. 5 illustrates an exemplary semantic-based smart home temperature control system. This smart home temperature control system is also supported by a service layer such as oneM2M, which exposes its access interfaces as resources (e.g., in a RESTful way) and has certain semantic capabilities. It is contemplated herein that, although this use case is illustrated in the context of oneM2M service layer, the scope of this disclosure is not just limited to oneM2M. Mobile device

111 includes a smart home temperature application. Mobile device 111 is communicatively connected with triple store 109 in cloud 110. Triple store 109 is communicatively connected with home gateway 113, which connects with temperature sensor 112 and temperature sensor

114 located within a home. Temperature sensor 112 and temperature sensor 114 act as oneM2M AEs, which register with the home gateway 113 (that is an oneM2M MN-CSE). An IN-CSE in cloud 110 may host triple store 109 that stores RDF triples, in which RDF triples are the semantic descriptions of the resources created on home gateway 113, such as temperature sensor

112 and temperature sensor 114 (e.g.,., <AE> resources), as well as their readings (e.g., stored in the <contentInstance> child resources of those <AE> resources). Different rooms may have fluctuating temperature values over time due to their respective locations, orientations, and exposure to the sun. In order to support intelligent temperature monitoring/control, the smart home temperature application on mobile phone 111 remotely monitors real-time temperatures in each room, and in particular, conducts various aggregated analytics (for example, the user may want to know the average temperature in the first floor or the average temperature of all the bedrooms in the second floor). Retrieving aggregated analytics may be realized by sending appropriate semantic queries to triple store 109. Semantic queries may be an efficient approach for knowledge discovery and aggregated analytics.

[0069] In this use case associated with smart home temperature control system, for a given semantic query posed via the smart home temperature application of mobile phone 111 (e.g., a SPARQL query), triple store 109 may return valid results if certain information stored in triple store 109 meets the constraints specified by the semantic query statement, e.g., the patterns described in a SPARQL query. As discussed before, for conventional systems, even if a semantic query itself is valid, triple store 109 still may not return any results based on asymmetric information, in which the requested information of the query is missing from triple store 109. [0070] FIG. 6A illustrates an exemplary reason a semantic query may not be processed due to information asymmetry associated with the above use case. As can be seen, the semantic information, such as RDF triples stored in two <semanticDescriptor> resources 117 and 118, may be stored in resource tree 119 for supporting resource annotation and semantic resource discovery (which are more resource tree-centric features). In addition, service layer centric information at block 115 and block 116 may be stored in resource 119 and not be stored in triple store 109 in terms of RDF triples. Conventionally, Triple store 109 cannot answer the queries involving information that is not available in triple store 109 because of information asymmetry between resource tree 119 infrastructure and triple store 109 infrastructure.

[0071] For example, assume a user issues the following query, which needs to be answered by the Triple Store: "Please return me the creation time of the resource, which is represented as a temperature sensor and manufactured by ABC Company; meanwhile, the expiration time of this resource is before 20:00:00 05-15-2016." Unfortunately, the conventional triple store defined in the service layer cannot serve the above query because it does not store all the necessary information. In a conventional service layer, the information underlined ("the creation time of the resource" and "the expiration time of this resource is before 20:00:00 05-15- 2016") in the above query is basically service layer resource-centric information, which is conventionally stored in the resource tree 119 as resource attributes. On the other hand, the information highlighted in bold ("represented as a temperature sensor and manufactured by ABC Company") in the above query is basically semantic-centric information, which may be stored in a triple store 109 for supporting semantic-centric features, such as semantic query. Therefore, based on conventional practice, the semantic query cannot be processed by a triple store 109 if some of the needed information is not stored in the triple store 109, but instead is only stored in the resource tree 119.

[0072] From the above use case, it is observed that the information asymmetry exists between the service layer resource tree 119 and triple store 109. In other words, some information stored in resource tree 119 may not be represented in triple store 109 as RDF triples. Conventionally a triple store 109 is used to just represent application domain specific knowledge. The methods, systems, and apparatuses disclosed herein provide information symmetry that will allow for robust semantic queries. For example, the information shown in resource tree 119 may be appropriately queried when mobile device 111 queries triple store 109.

[0073] With reference to FIG. 6B, in a first scenario, resource tree 119, in which resources have attributes, and a value to a resource attribute can be assigned. Temperature- Sensor-1 114 has registered to home gateway 113 (an MN-CSE) and accordingly an oneM2M AE resource (e.g., < Temperature-Sensor- 1 >) was created on home gateway 113. For this < Temperature-Sensor- 1 > resource, it has two attributes in terms of "creationTime" and

"expirationTime" and each of those attributes is assigned with a date value (e.g., "creationTime = 05-20-2016" and "expirationTime = 06-11-2016" shown in block 115). In addition, a

<semanticDescriptor> child resource 117 was also created for < Temperature-Sensor- 1 >, which include a number of RDF triples as the semantic annotations of < Temperature-Sensor- 1 >.

[0074] With continued reference to FIG. 6B, the information stored on the resource tree side (resource tree 119) may be synched to Triple Store 109 side in real-time, which has the following couple cases. First, the RDF triples stored in the <semanticDescriptor> child resource of < Temperature-Sensor- 1> (, e.g., block 117) may be directly copied into Triple Store 109 so that those information can be also available at Triple Store 109. Second, the information "creationTime = 05-20-2016" and "expirationTime = 06-11-2016", need to be transformed into "RDF" form first. In order to do so, the SRO ontology disclosed herein in more detail is leveraged. For example, first the information "creationTime = 05-20-2016" may be transformed to the following RDF triple (in which the "has CreationTime" is a term defined by the SRO ontology):

URI-of-Temperature-Sensor-1 hasCreationTime 06-11-2016

[0075] Then, this RDF triple may be cloned to the Triple Store 109, which is shown in FIG. 6B. In this way, all the information originally at Resource tree 119 side will also now be available in Triple Store 109 (especially for information that was originally not in RDF form as illustrated in the above example). Here, < Temperature-Sensor- 1> is the subject part, hasCreationTime is the predicate part (which is a term/vocabulary defined by "Service-layer Resource Ontology" (SRO) herein, and "06-11-2016" is the object part. See below SRO discussion, which includes Table 4 and associated discussion.

[0076] Due to the information asymmetry between Triple Store and service layer Resource Tree, many semantic queries cannot be well served by the Triple Store (in terms or yielding desired query results). In particular, it is identified that the conventional service layer does not have a capability for fully supporting semantic query because of the information asymmetry. The subject matter disclosed herein may be applicable to any service layer that has resource tree (e.g., built with RESTful architecture) or is equipped with semantic

capabilities/infrastructures, such as triple store 109. The subject matter disclosed herein may support full semantic query over a oneM2M resource tree, for example. [0077] It is understood that the entities performing the steps illustrated herein, such as FIG. 7 - FIG. 21, may be logical entities. The steps may be stored in a memory of, and executing on a processor of, a device, server, or computer system such as those illustrated in FIG. 26C or FIG. 26D. In an example, with further detail below with regard to the interaction of M2M devices, RC/M 151 of FIG. 7 may reside on M2M terminal device 18 of FIG. 26A, while triple store 154 and TSI-SLN 155 of FIG. 14 may reside on M2M gateway device 14 of FIG. 26A.

[0078] As disclosed herein, logical entities may have certain roles in the semantic query process. FIG. 7 illustrates exemplary logical entities related to semantic query. The logical entities may include resource hosting service-layer node (RH-SLN) 151, resource

creator/modifier (RC/M) 152, semantic query initiator (SQI) 153, or triple store 154. RH-SLN 151 is basically a service layer node that is built with RESTful architecture. In other words, the service layer of RH-SLN 151 exposes a resource-tree as an operation interface. RC/M 152 may be a logical entity that creates/updates/deletes resource(s) at an RH-SLN 151. SQI 153 may be a logical entity that has business needs and needs to initiate a semantic query. There may be multiple types of SQI, which may include fully semantics-capable SQI (FSC-SQI) or partially semantics-capable SQI (e.g., a resource-tree-centric SQI (RTC-SQI)). "Fully" as disclosed herein may be associated with a FSC-SQI that may understand semantic domain technologies

(including the SRO as discussed herein) and may utilize SPARQL semantic query interface. "Not fully", such as RTC-SQI, may have more limited semantic capabilities, for example RTC- SQI may just support resource tree-oriented interfaces, such as the existing (semantic) resource discovery interface and may not use the proposed SRO.

[0079] With continued reference to FIG. 7, triple store 154 may be incorporated. Triple store 154 is generally a data repository that stores semantic information, such as RDF triples, and it may also support semantic-centric features such as semantic query, semantic mashup, or semantic reasoning, etc. Triple store 154 may be hosted by a physical node. It is contemplated herein that triple store 154 may provide different types of interfaces. If triple store just supports a non-service-layer interface, then the interactions between the triple store 154 and other service- layer entities defined above (such as SQI) may go through triple store interworking service layer node (TSI-SLN) 155. TSI-SLN 155 may expose triple store 154 to service layer entities through normal service layer interfaces, such as service layer resources. TSI-SLN 155 may interact with triple store 154 through a non-service-layer interface that may be hidden from service layer entities, such as SQI.

[0080] Triple store 154 may be hosted by a physical node (e.g., server), which is not necessarily a service layer node. For a case where a service layer node directly hosts triple store 154 (in which triple store 154 has a service-layer interface), this service layer node may be regarded as TSI-SLN 155. In this case the interactions between TSI-SLN 155 and the triple store 154 are within the physical node. For the case where triple store 154 has the service layer interface, the triple store 154 in FIG. 7 may be inside TSI-SLN 155.

[0081] Discussed in more detail below are the interactions of the different logical entities as shown in FIG. 7. RC/M 152 may create/update/delete resources at RH-SLN 151, which is illustrated as the "Service-layer Resource CRUD Operation" at 156 of FIG. 7.

Accordingly, information stored in RH-SLN 151 may also be re-represented and stored in triple store 154 as RDF triples, which may be done through the "RDF Triple Manipulation Operation" at 157 of FIG. 7. SQI 153 may send its semantic query to TSI-SLN 155, illustrated as "Semantic Query Request Reception Operation" at 158. And TSI-SLN 155 may be responsible for interacting with triple store 154 for query processing, which may include fetching query results.

[0082] Processing of a given semantic query by triple store 154 generally include a) a semantic query statement to be executed (e.g., written as a SPARQL query statement); and b) data infrastructure in terms of RDF triples stored in triple store 154 (e.g., the place where the query in part a) is to be executed on). The information asymmetry issue in the semantic query, as disclosed herein, may be addressed in view of 1) data infrastructure or 2) the semantic query statement, for example. Discussed below are the data infrastructure angle (e.g., Category-1 implementation) and the semantic query angle (Category -2 implementation).

[0083] The Category-1 implementation may include the following considerations: 1) a service-layer resource ontology (SRO), 2) information synchronization, or 3) semantic query processing. Each discussed in turn herein.

[0084] SRO may be used for representing the information that is originally only stored in the resource tree as RDF triples so that this information is available at triple store 154.

Originally stored information As mentioned, on a resource tree, different resources may be created/modified/deleted by a RC/M 152. A given service layer may have many types of resources defined and each resource may have a list of attributes that are used to describe a certain aspect of a resource. For example, <contentInstance> resource, as provided in a oneM2M service layer may have an attribute called "contentSize," that is used to store the size in bytes of the data stored in the "content" attribute of this <contentInstace> resource. Conventionally, such resource-centric information is stored only in the resource tree and not in triple store 154.

[0085] In order to also store this information in triple store 154, such that the information between triple store 154 and the resource tree is synchronized, a "Service-layer Resource Ontology" (SRO) is defined. An SRO includes new properties that correspond to existing service layer resource attributes. Table 4 shows some popular attributes of the resources for a given service layer and corresponding new properties defined in SRO (with the prefix "SRO"). To make SRO more generic, the attribute names as shown in the Table 1 are also in a generic form, which means the SRO has a specific embodiment when applied to a given service layer. A oneM2M example is discussed in more detail herein.

Table 4. Examples of Properties Defined in the SRO

[0086] FIG. 6C illustrates an exemplary method for using SRO. At step 61, SRO is defined. SRO may specify a list of shared vocabularies. For example, for a specific resource attribute (e.g., attribute-1), a corresponding predicate SRO: attribute-1 may be defined in SRO and therefore automatically configured. Alternatively, to make this predicate like a verb, the predicate may automatically be configured as SRO: has Attribute-1. These are examples. At step 62, SRO may be shared and used by entities, which may be CSEs, such as MN-CSE of home gateway 113. At step 63, a resource is created on MN-CSE of home gateway 113. Resource may include an attribute. At step 64, when a <resource-l> is created on a CSE, and <resource-l> has an attribute-1. Then, MN-CSE can construct a RDF triple: 1) The subject part of the triple may be the URI of <resource-l>, 2) the predicate part may be the corresponding predicate of attribute-1, e.g., "SRO:hasAttribute-l; 3) the object part may be the value of attribute-1. MN- CSE may have an internal table or program, in which it knows an attribute-1 corresponds to a predicate "SRO:hasAttribute-l" in SRO. If <resource-l> has many attributes, a RDF triple may be generated for each of those attributes as disclosed herein.

[0087] In an example for SRO, if a resource <resource-l> is created and its URI is URIl and the attribute-1 is "09:20:34 08-05-2016", such information may be re-represented as a RDF triple as follows (and such a triple can now also be stored in the triple store 154):

URIl (subject part) SRO: attribute-1 (property part) "09:20:34 08-05-2016" (object part) [0088] By utilizing SRO, resource-centric information may be cloned to triple store 154. Or in other words, resource-centric information is sufficiently represented so that a query of conventional resource-centric information may be found in triple store 154.

[0089] With that said, there may be need for information synchronization. Information stored in the resources hosted by RH-SLNs 151 may undergo dynamic changes due to CRUD operations initiated by RC/Ms 152. For the disclosed category- 1 implementation, CRUD operation at the resource-tree may affect information availability at triple store 154. The synchronization process makes sure that the information is synchronized between the resource tree and triple store 154. Disclosed below are procedures for how to synchronize information between resource tree and triple store 154 due to Create, Update, or Delete operations (Retrieve operation normally does not change resources, so it may not incur a synchronization process). Resource CRUD operations that occur between RC/M 152 and RH-SLN 151 may trigger RDF triple manipulation operations for information synchronization between RH-SLN 151 and the triple tore 154.

[0090] FIG. 8 illustrates an exemplary method for information synchronization due to CREATE resource operation, in which a more detailed description is disclosed below. At step 160, there may be a pre-condition. The pre-condition may be that TSI-SLN 155 has the capability to interact with triple store 154 and RH-SLN 151 is aware that TSI-SLN 155 assists with interaction with triple store 154 when providing an out-of-band interaction interface (e.g., non-service-layer interface). Throughout this disclosure, semantic query with information asymmetry will mainly be discussed under this general case. At step 161, RC/M 152 determines that it will create a new resource at RH-SLN 151.

[0091] At step 162, RC/M 152 sends a normal service layer request message for creating a new resource, e.g., <reading-l> resource, associated with related data or parameters to be stored in this resource. Below are two example cases. In a first case, RC/M 152 is a node such as a MN-CSE having more capabilities. RC/M 152 may directly include the address of TSI-SLN 155 in order to direct RH-SLN 151 where to contact TSI-SLN 155. RC/M 152 may also proactively indicate to RH-SLN 151 whether the information stored in the resource to be created should also be synced up to triple store 154. Accordingly, in this first case, the request message may include the following new parameters: 1) Address_of_TSI-SLN 155: This is to indicate where to contact TSI-SLN 155; or 2) Sync_up_flag: Sync_up_flag=l means the resource to be created should also be stored in triple store 154. Otherwise, Sync_up_flag=0. In a second case, RC/M 152 is relatively more capability -constrained, such as an AE having limited

knowledge/capabilities. RC/M 152 does not know the address of TSI-SLN 155, and relies on RH-SLN 151 to take care of contacting TSI-SLN 155. And RC/M 152 may also not be configured to decide whether the resource to be created should be also stored in triple store 154. In this second case, RH-SLN 151 handles what RC/M 152 handled in the first case.

[0092] With continued reference to FIG. 8, at step 163, RH-SLN 151 conducts normal request processing after receiving the request of step 162 from RC/M 152 and creates a new resource <reading-l>, in which various attributes have also been configured. At step 164, if RC/M 152 belongs to the second case as mentioned above, RH-SLN 151 acknowledges that the resource has already been successfully created and also returns the URI of the created resource. If RC/M 152 belongs to the first case as mentioned above (e.g., the Sync_up_flag was included in the request message), this step becomes the last step of this procedure (i.e., after step 168) since RH-SLN 151 needs to acknowledge RC/M 152 whether the resource to be created is also successfully stored in triple store 154. Accordingly, in this first case, the response message may include the parameter Ack sync up flag, in which Ack_sync_up_flag=l means the resource was already stored in triple store 154 as well and Ack_sync_up_fiag=0 otherwise, as an example.

[0093] At step 165, RH-SLN 151 extracts the available information stored in this resource, and describes them as RDF triples, by using various ontologies. See FIG. 6C and accompanying description. In particular, the SRO is used to describe resource-centric information. RH-SLN 151 may also store the RDF triples of step 165 locally in certain resources or attributes which may be accessed by other entities, such as RC/M 152, TSI-SLN 155, or another RH-SLN.

[0094] At step 166, RH-SLN 151 sends a request to TSI-SLN 155 for assistance and sends the RDF triples generated in step 165 to TSI-SLN 155. If RC/M 152 included an

Address_of_TSI-SLN 155 in an earlier message (e.g., the request message in step 162), RH-SLN 151 may use the Address_of_TSI-SLN 155 to contact TSI-SLN 155. If RC/M 152 did not include the Address_of_TSI-SLN 155 in the request message in step 162, then RH-SLN 151 uses another way to contact TSI-SLN 155. For example, RH-SLN 151 may be pre-configured. The request message in this step 166 may include a new parameter: purpose id. The information of purpose_id may indicate how the RDF triples will be handled by triple store 154. For example, when purpose_id=l, it may mean those triples should be directly stored in triple store 154 due to a creation of a new resource at RH-SLN 151. When purpose_id=2 (which will be discussed in more detail herein), it may mean the triples should replace some existing triples stored in triple store 154, because those triples are storing updated information of a resource due to a UPDATE operation. [0095] In a more complex scenario at step 166, there may be multiple triple stores 154 behind TSI-SLN 155 or multiple semantic graphs in triple store 154. When RH-SLN 151 is allowed to decide which triple store 154 should be used to store triples related to the newly- created resource (or which semantic graphs in triple store 154 should be used to store this triples), it can also include a Desired Triple Store (desired triple store) parameter in the request message of step 166. Desired_Triple_Store (desired_triple_store) may indicate which triple store 154 should be used first, if available, to store triples related to the newly-created resource when there are multiple triple stores 154 behind TSI-SLN 155. In the complex scenario in which there is one triple store 154 behind TSI-SLN 155, but this triple store 154 has multiple semantic graphs, the parameter may be called "desired_semantic_graphs". This desired_semantic_graphs parameter may indicate which semantic graph(s) is the preferred one to store triples. For "preferred" or "desired" as disclosed herein it may be considered a ranking of which triple store is to be used as storage, therefore if one triple store is not available then another (e.g., the second ranked triple store) may be used.

[0096] With continued reference to FIG. 8, at step 167, subsequent to TSI-SLN 155 receiving the message from RH-SLN 151 in step 166, TSI-SLN 155 may store those RDF triples of step 166 in its local resources or attribute; then the locally stored RDF triples may be accessed by other entities such as another TSI-SLN or an RH-SLN. TSI-SLN 155 may further interact with the desired triple store 154 and store the RDF triples into triple store 154, so that the triples may support semantic queries or other semantic related applications later on. At step 168, TSI- SLN 155 acknowledges that the RDF triples have been successfully stored in triple store 154. The response message may include the process result (result) parameter. The process result parameter may indicate whether the intended action at triple store 154 has been successfully executed. In the more complex scenario where multiple triple store 154 are behind TSI-SLN 155, the TSI-SLN 155 may also acknowledge to RH-SLN 151 which triple store 154 was used for storing the RDF triples related to the newly-created resource (in the case where the RH-SLN 151 did not decide which Triple store 154 should store the triples in step 166 and let TSI-SLN 155 decide), by using a Triple_store_id (triple_store_id) parameter in the response message.

Triple store id may indicate which triple store 154 of the multiple triple store 154 was used to actually store the triples related to the newly-created resource. It is contemplated herein that RH- SLN 151 may store the triple_store_id for the newly-created resource (in fact, it may be a new attribute for this resource), which will be used when the newly-created resource is to be updated/deleted in a later time such that the RH-SLN 151 knows which triple store 154 should be contacted in order to handle the related RDF triples. [0097] FIG. 9 illustrates an exemplary method for information synchronization due to UPDATE resource operation. At step 170, there may be a pre-condition. The pre-condition may be that a service layer resource <App-l> has already been created at RH-SLN 151 and resource- centric triples of <App-l> have also been stored in triple store 154. At step 171, RC/M 152 determines that it will update an existing resource at RH-SLN 151, e.g., <App-l> resource. At step 172, RC/M 152 sends a normal service layer request message for updating <App-l> resource, associated with updated data or parameter values of this resource. The request message in this step 172 may also include the similar parameters as defined in step 162 of FIG. 8. At step 173, RH-SLN 151 conducts normal request processing after receiving the request from RC/M 152 and updates <App-l> resource. Accordingly, some attribute values are changed. Some changes on the attribute values may be based on the request originator (e.g., RC/M 152), but some changes may also be based on the request recipient (e.g., RH-SLN 151). For example, the "creationTime" attribute of <App-l> may normally be updated by the RH-SLN 151 itself. At step 174, RH-SLN 151 acknowledges that <App-l> has already been successfully updated. The response message in this step 174 may also include similar parameters and similar operations as defined in step 164 of FIG. 8.

[0098] At step 175, RH-SLN 151 determines what information stored in <App-l> resource has been changed and RH-SLN 151 may describe the changed information as new RDF triples. In particular, the SRO may be used to describe resource-centric information. RH-SLN 151 may use those new RDF triples to update local RDF triples which have been created or stored previously in certain resources or attributes, or RH-SLN 151 may simply store those new RDF triples in certain local resources or attributes.

[0099] At step 176, RH-SLN 151 sends a request to TSI-SLN 155 for assistance and sends the RDF triples generated in step 175 to TSI-SLN 155. RH-SLN 151 may also indicate those triples are not new triples, but the updated triples. The request message may include a Purpose (purpose id) parameter. The information of the purpose id indicates how the RDF triples may be handled by triple store 154. The purpose id may be 2, which means the RDF triples should replace some existing triples stored in triple store 154 due to the UPDATE operation. In a complex scenario, there may be multiple triple stores 154 behind TSI-SLN 155. In this case, since RH-SLN 151 knows which triple store 154 stores the related RDF triples (during the resource creation stage), it now also needs to indicate TSI-SLN 155 which Triple store 154 is storing the triples that need to be updated, then it may include the Triple store id (triple_store_id) parameter in the request message to indicate which triple store 154 should be contacted. [00100] With continued reference to FIG. 9, at step 177, subsequent to TSI-SLN 155 receiving the message from RH-SLN 155 in step 176, TSI-SLN 155 may use those RDF triples to update local RDF triples that have been created or stored previously in certain resources or attributes, or TSI-SLN may simply store those new RDF triples in certain local resources or attributes. TSI-SLN 155 may further interact with the desired triple store 154. Triple store 154 needs to first sort out which triples should be updated and then replace them with new triples and this process may be internal processing stage inside triple store 154. At step 178, TSI-SLN 155 acknowledges that the RDF triples have been successfully updated in triple store 154. The response message may include the Process Result (result) parameter that indicates whether the intended action at triple store 154 has been successfully executed.

[00101] FIG. 10 illustrates an exemplary procedure for information synchronization due to DELETE resource operation. At step 180, there may be a pre-condition. The precondition may be that a service layer resource <App-l> has already been created at RH-SLN 151 and resource-centric triples of <App-l> have also been stored in triple store 154. At step 181, RC/M 152 determines that it will delete an existing resource from RH-SLN 151, e.g., <App-l> resource. At step 182, RC/M 152 sends a normal service layer request message for deleting the <App-l> resource. The request message in this step 182 may also include similar parameters as defined in step 162 of FIG. 8. At step 183, RH-SLN 151 conducts normal request processing after receiving the request from RC/M 152 and deletes <App-l> resource. At step 184, RH-SLN 151 acknowledges that <App-l> has already been successfully deleted. The response message in this step may also include the similar parameters and has similar operation as defined in the step 184 of FIG. 8. At step 185, RH-SLN 151 deletes the RDF triples stored in triple store 154, which are related to the <App-l> resource. The deletion of <App-l> resource should also lead to deletion of the child resources of <App-l>. Therefore, the RDF triples related to <App-l>'s child resources will also need to be deleted. If those RDF triples are stored in local resources or attributes at RH-SLN 151, RH-SLN 151 will delete them from the local resources or attributes directly.

[00102] With continued reference to FIG. 10, at step 186 RH-SLN 151 sends a request to TSI-SLN 155 for assistance and sends URIs of <App-l> and its child resources to TSI-SLN 155 for deletion of the related RDF triple. For example, for a given triple (s, p, o), if s is the URI of <App-l> or one of its child resources, such a triple should be deleted from triple store 154. The request message may include a Purpose (purpose id) parameter or a URI List (urls) parameter. The purpose_id for a DELETE operation may be 3. The urls of the deleted resources should be sent to triple store 154. As an example, the URIs of <App-l> and its child resources may be included in urls. In the complex scenario, there may be multiple triple store 154s behind TSI-SLN 155. In this case, since RH-SLN 151 knows which triple store 154 stores the related RDF triples (during the resource creation stage), it now also indicates to TSI-SLN 155 which triple store 154(s) are storing the triples to be deleted, then it may include the Triple_Store_ids (triple_store_ids) parameter in the request message. The triple_store_ids indicates which Triple store 154(s) should be contacted. Multiple triple stores 154 may be involved since it is possible that the related RDF triples of <App-l> and its child resources were not stored in the same Triple store 154.

[00103] At step 187, TSI-SLN 155 may further interact with triple store 154 and in particular, triple store 154 may delete the RDF triples related to <App-l> and its child resources. If those RDF triples are stored in local resources or attributes at TSI-SLN 155, TSI-SLN 155 may delete them from the local resources or attributes directly. At step 188, TSI-SLN 155 acknowledges that all the RDF triples related to <App-l> and its child resources have been successfully deleted from triple store 154. The message may include the Process Result (result) parameter that indicates whether the intended action at triple store 154 has been successfully executed.

[00104] Although the CRUD operations disclosed herein may be initiated by RC/M 152, in fact the CRUD operations may also be initiated by RH-SLN 151 itself. For example, RH- SLN 151 may conduct certain resource management operations, which may lead to resource creation, update, or deletion, and accordingly, the procedures disclosed herein (e.g., FIG. 8 - FIG. 10) are also applied to those cases. For example, a resource may have an "expirationTime" attribute which indicates when the resource is going to expire. So if a resource reaches its expiration time, it may be automatically deleted by RH-SLN 151, which may also trigger RH- SLN 151 to request TSI-SLN 155 to delete related RDF triples stored in triple store 154.

[00105] The semantic query processing details disclosed below define how a semantic query by a SQI may be processed under a category-1 implementation. A category-1

implementation does not generally manipulate the original semantic query statement.

Information asymmetry may be addressed through synchronization as disclosed herein (e.g., FIG. 8 - FIG. 10). There may be multiple types of SQIs, therefore exemplary semantic query procedures for different types of SQIs are discussed below. For example, for fully Semantics- Capable SQI (FSC-SQI) case, it may be assumed that SRO will also be published to and known by FSC-SQIs 191. Accordingly, the FSC-SQIs 191 may construct their semantic queries by using SRO and other ontologies in their SPARQL query statements. For a resource tree-centric SQI (RTC-SQI) case, it may be assumed that they can only describe their query through existing semantic resource discovery interface, e.g., oneM2M filterCriteria. In this case, TSI-SLN 155 further transforms the received request from RTC-SQI 192 to a valid SPARQL query statement before sending it to triple store 154 for SPARQLsemantic query processing.

[0106] FIG. 11 illustrates an exemplary Procedure for Semantic Query Processing for Fully Semantic Capable SQI (Category-1). At step 200, there may be pre-conditions. Preconditions may include that TSI-SLN 155 has been configured to interact with triple store 154 and TSI-SLN 155 advertises that it may accept semantic queries towards triple store 154. FSC- SQI 191 is fully semantics-capable and has already learned the SRO. At step 201, FSC-SQI 191 determines a query (question) that may be answered by triple store 154. Accordingly, FSC-SQI 191 formulates a SPARQL query statement to describe its query. At step 202, FSC-SQI 191 sends a service layer request message to TSI-SLN 155, in which it indicates that this request is related to a semantic query to be processed by triple store 154. The message may include a semantic query indicator (sq), a query statement (qs), or a result format (rf) parameter. A semantic query indicator (sq) parameter may indicate that FSC-SQI 191 is sending a semantic query to be executed on triple store 154. Query statement (qs) parameter may store the query statement specified by FSC-SQI 191, which may be a SPARQL query statement. Alternatively, FSC-SQI 191 may also re-utilize the existing "semantics" filter criteria parameter used for semantic resource discovery. Result format (rf) parameter is an indicator for how the query result should be, such as plan text, JSON, or XML format result.

[0107] With continued reference to FIG. 11, at step 203, TSI-SLN 155 conducts normal request processing after receiving the request from FSC-SQI 191. TSI-SLN 155 may also validate the received SPARQL query using semantic domain specific knowledge. TSI-SLN 155 may also just forward the query to triple store 154. At step 204, TSI-SLN 155 may further send the SPARQL query to triple store 154, and get back the query result. Note that, since the information in triple store 154 is now synchronized with that in resource tree(s), the query may be processed within triple store 154 by using existing technology. At step 205, for the query result from triple store 154, TSI-SLN 155 may include them in the normal service layer response message by using the format as indicated by FSC-SQI 191. The message may also include the query result (qr) parameter that stores the query result yielded by triple store 154. Alternatively, when FSC-SQI 191 needs XML or JSON-based result set, the result may be directly stored in the payload of the response message. At step 206, TSI-SLN 155 sends back a response message to FSC-SQI 191, in which the query result of the SPARQL query is included. At step 207, FSC- SQI 191 receives the response message and reads the semantic query result. [0108] FIG. 12 illustrates an exemplary procedure for semantic query processing for resource-Tree Centric SQI (Category- 1 implementation). At step 210, there may be preconditions. Pre-conditions may include that TSI-SLN 155 has been configured to interact with triple store 154 and TSI-SLN 155 advertises that it may accept semantic queries towards triple store 154. RTC-SQI 192 is a resource tree-centric SQI (e.g., RTC-SQI 192 does not have a way to know and utilize the SRO). In an example, RTC-SQI 192 has an interface for semantic resource discovery by using the existing filterCriteria defined in oneM2M. At step 211, RTC- SQI 192 determines a query (question) that may be answered by triple store 154. Accordingly, RTC-SQI 192 formulates its question by using filterCriteria, which is normally used for semantic resource discovery. For example, consider the following semantic query:

Needs: Please return me 1) the firmware version of a

temperature sensor, and 2) also the creation time of the

corresponding resource which is representing this sensor.

Constraints: 1) This sensor is manufactured by ABC Company

and 2) the expiration time of this corresponding resource is after

20:00:00 05-15-2016.

[0109] As shown above, for the needs part, RTC-SQI 192 may need information from both the resource tree and triple store 154. Similarly, for the constraints part, those constraints span in both the resource tree and triple store 154. To be more clear, the text underlined in above semantic query is basically service layer resource-related (e.g., normally available in the resource tree side). On the other hand, the text in bold in above semantic query is basically semantic or triple store 154-related (e.g., normally available in triple store 154 side).

[0110] With continued reference to step 211 of FIG. 12, in order to represent this query, the following may be considered:

1. The constraints that are resource-tree related may be represented by using existing non- semantic filterCriteria.

2. The queried information that is resource-tree related may be represented by using a new parameter called "query for" parameter to be carried in the request message.

3. The queried information and constraints that are triple store 154 related may be

represented by the existing semantic filterCriteria (e.g.. semantic filter). The SPARQL query specified in the semantic filter may represent both queried information (written in SELECT part) and constraints (written in WHERE part). [0111] Below is an example usage, in which a RETRIEVE operation may have the following format to represent the above semantic query statement:

RETRIEVE /<TSI-SLN 155> sq ="semantic query" &

query_for={x} &

expireAfter=20:00:00 05-15-2016 & semantics={y}

in which x and y include the following information respectively:

x={ creationTime }

y= { SELECT ?device ?firmware_version

WHERE {

?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

}

}

[0112] As seen above, the "sq" parameter (as disclosed herein) indicates this is a semantic query (alternatively, it may also re-use the "usage" parameter as defined in existing filterCriteria, i.e., the usage will have a new value as "semantic query"). The "query for" parameter may include the information to be queried and such information is in the resource tree side. In this example, the creationTime is the information queried/needed by RTC-SQI 192. The "expireAfter", defined in conventional filterCriteria, carries a constraint, which is also related to the resource tree side. The "semantics" include a SPARQL query statement, in which the SELECT part includes the queried information that is stored in triple store 154 (e.g., firmware version which is normally described as RDF triples), and WHERE part includes other semantics- related constraints (e.g., the required resource should be represented as a temperature sensor and should be manufactured by ABC company).

[0113] At step 212, RTC-SQI 192 sends a service layer request message to TSI-SLN 155 according to the detailed query composition guide as specified in step 211. The message may include the following Result format (rf) parameter: The rf parameter stores how the query result should be represented, which could be plain text, JSON or XML format. At step 213, TSI- SLN 155 conducts normal service layer request processing after receiving the request from RTC- SQI 192. TSI-SLN 155 may transform the received query description to a valid SPARQL query statement by utilizing the SRO. In particular, such a SPARQL query may be based on the query statement stored in the "semantics" filter of filterCriteria sent from RTC-SQI 192. Non- semantics filter part as specified in the filterCriteria may now be re-represented in the new SPARQL query statement by using SRO. For example, the previous query as specified in step 211 may be transformed to the following new SPARQL statement:

SELECT ?device ?firmware_version ?creationTime

WHERE {

?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

?device SRO:expireAfter 20:00: 00 05-15-2016

?device SRO:hasCreationTime ?creationTime

}

}

[0114] As shown above, the bold part highlights the part which is re-represented directly in a SPARQL statement by using the disclosed SRO. At step 214, TSI-SLN 155 may further send the created SPARQL query to triple store 154, and get back the query result. At step 215, For the query result from triple store 154, TSI-SLN 155 may include them in a normal service layer response message by using the format as indicated by RTC-SQI 192. The message may include the query result (qr) parameter. The qr parameter may store he query result yielded by triple store 154. Alternatively, when RTC-SQI 192 needs XML or JSON-based result set, the result may be directly stored in the payload of the response message. At step 216, TSI-SLN 155 sends a response message to RTC-SQI 192, in which the processed result of the SPARQL query is included. At step 217, RTC-SQI 192 receives the response message and reads the semantic query result.

[0115] Discussed below is the category-2 implementation. Unlike the category-1 implementation, in the category-2 implementation, information asymmetry will still exist between resource tree and triple store 154 (e.g., no sync-up operation will be executed).

Accordingly, during the semantic query processing stage, the original semantic query may be split into multiple threads: 1) the processing thread at resource tree side is called RT-Thread or 2) the processing thread at triple store 154 side is called TS-Thread. With category-2 some work is done on both the resource tree and triple store 154, depending on where the needed information resides. In addition, partial query results may be worked out at both resource trees side and triple store 154 side and those partial results may be composed together as the final query result of the original semantic query. The semantic query processing procedures disclosed below have different scenarios in which thread may be processed first. For example, there may be a TS- Thread-First Strategy that first conducts processing at triple store 154 side and then at resource tree side and there may be a RT-Thread-First Strategy that first conducts processing at resource tree side, and then at triple store 154 side. Each scenario has its own applicable sub-scenarios with pros and cons.

[0116] Again a category-2 implementation may not touch data infrastructure part in the sense that the information asymmetry will still exist between resource tree and Triple Store. However, if the original semantic query needs some information that is only available in resource tree, but not in Triple Store, the processing of original query may be separated into multiple threads depending on where the needed information resides (e.g., stored in resource tree or in Triple Store). Accordingly, partial query results will be worked out at both resource tree and Triple Store, and those partial results may be combined together as the final query result of the original semantic query. New semantic query processing procedures are disclosed for category-2 implementation. For example, as shown in FIG. 7 during the processing of a specific query, the Triple Store needs to also interact with the involved RH-SLN(s) in order to retrieve the required information needed by the query since some of the needed information may not be stored in the Triple Store, but in the resource tree, and the corresponding processing is called the "Resource-tree-side Query Processing Operation" as shown in FIG. 7.

[0117] FIG. 13 illustrates an exemplary procedure for semantic query processing for FSC-SQI 191 (Category-2, TS -Thread-First Strategy). At step 220, there may be pre-conditions. The pre-condition may include that FSC-SQI 191 is a fully semantics-capable user and it already learned how to use the SRO. TSI-SLN 155 may have the capability to interact with triple store 154 and TSI-SLN 155 advertises that it may accept semantic queries towards triple store 154. It is contemplated herein that although a category-2 implementation does not have to use the SRO to sync-up information between resource tree side and triple store 154 side, the SRO may still be used by the FSC-SQI 191 to facilitate them to shape their SPARQL query statements. At step 221, FSC-SQI 191 determines a query (question) that may be answered by triple store 154. Accordingly, FSC-SQI 191 formulates a SPARQL query statement to describe its question. For example, consider the following semantic query:

Needs: Please return me 1) the firmware version of a

temperature sensor, and 2) also the creation time of the

corresponding resource which is representing this sensor.

Constraints: 1) This sensor is manufactured by ABC Company and 2) the expiration time of this corresponding resource is after 20:00:00 05-15-2016. [0118] By utilizing the SRO ontology, FSC-SQI 191 is able to shape the corresponding SPARQL query as follows:

SELECT ?device ?firmware_version ?creationTime

WHERE {

?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

?device SRO: expire After 20:00:00 05-15-2016

?device SRO:hasCreationTime ?creationTime

}

}

[0119] At step 222, FSC-SQI 191 sends a request message to TSI-SLN 155, in which it indicates that the above request is related to a semantic query to be processed by triple store 154. At step 223, TSI-SLN 155 conducts the normal service layer request processing after receiving the request from FSC-SQI 191. FSC-SQI 191 may modify the original SPARQL query so that the new query does not include the part related to the SRO. The new query may include: 1) the needed information that is specified in the original query and this information is stored in triple store 154; and 2) the URIs of involved resources (which satisfy the constraints in the new query). It can be seen that in TS-Thread-First Strategy, TS-Thread will be processed first. In an example, the original query may be changed to a new query as follows (and the changed parts are in Bold):

SELECT ?device ?firmware_version ?crcationTimc

WHERE {

?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

?dcvicc SRO;cxpircAftcr 20;00;00 05 15 2016

?dcvicc SRO;hasCrcationTimc ?crcationTimc

}

}

[0120] At step 224, TSI-SLN 155 may further send new SPARQL query to triple store 154, and get back the query result. The result may also include the following: 1) the needed information that is specified in the original query and this information is stored in triple store 154, as well as 2) the URIs of involved resources. As an example, assuming after processing the new query, two involved resource URIs are returned (say URI1 and URI2) by triple store 154, which are representing two temperature sensors. Their corresponding firmware version information is also returned by triple store 154 (say the temperature sensor corresponding to URI1 has the firmware version of v. 1.3.9 while the temperature sensor corresponding to URI2 has the firmware version of v. 2.0.1). At step 225, TS-Thread is done and now RT-Tread starts to work. For the URIs of involved resources obtained in step 224, TSI-SLN 155 may decide which RH-SLN nodes should be contacted. For each involved resource URI, TSI-SLN 155 needs to transform the SRO-related patterns as specified in the original SPARQL query to filterCriteria format and also indicates which information should be retrieved from those involved resources if the resources satisfy the constraints specified in filterCriteria. As an example, it may be assumed that the two involved resources representing temperature sensors (e.g., URI1 and URI2) are stored in RH-SLN 151.

[0121] At step 226, TSI-SLN 155 sends a request to RH-SLN 151 (or multiple RH- SLNs), where the involved resources identified in step 224 are hosted, along with the evaluation criteria as specified in filterCriteria. In the example, a RETRIEVE operation may be sent from TSI-SLN 155 to RH-SLN 151 having the following format:

RETRIEVE /<RH-SLN 151> sq ="semantic query" &

query for = { creationTime } & involvedResources={URIl,

URI2}

expireAfter = 20:00: 00 05-15-2016

A new parameter is disclosed here, which is called "involvedResources" that is to indicate which resources should be evaluated with the filterCriteria. The previously- proposed "sq" as well as "query for" parameter may also be re-utilized.

[0122] At step 227, RH-SLN 151 evaluates whether the involved resources satisfy the constraints as specified in filterCriteria. If so, it may further retrieve the information required by the original semantic query, from the attributes of these resources. In our example, assuming that only URI1 satisfied the constraint as specified in filterCriteria (e.g., satisfying the "expireAfter" constraint in the above example), so only URI1 and its corresponding creationTime, e.g. say 18:53:00 05-15-2016 (which is the required information as specified in "query for" parameter), will be returned. At step 228, RH-SLN 151 returns the processed result as done in step 227, which includes the required information as specified in the original SPARQL query. A more native approach for steps 226 through 229 is that TSI-SLN 155 just conducts normal resource retrieval operation to get back the involved information of the resources included in the involvedResources and then may evaluate by itself. [0123] At step 229, based on the retrieved information sent back from RH-SLN 151, which is the information requested by the original semantic query but is stored in the resource tree side, TSI-SLN 155 may further combine them with the information retrieved from triple store 154 (as done in step 224). The combination may be used to construct the final result of the original SPARQL query. In the above example regarding URIl and URI2, the partial result from triple store 154 side as done in step 224 (URIl, firmware version: v. 1.3.9) may be combined with partial result from resource tree side (URIl, creationTime: 18:53:00 05-15-2016). The final query result may be <URI1, firmware version: v. 1.3.9, creationTime: 18:53:00 05-15-2016>. At step 230, TSI-SLN 155 finally returns the query result of the original SPARQL query.

[0124] Note that, the procedure above with regard to FIG. 13 is for TSI-SQI case. For RTC-SQI case, it has the following working operation details. For example, since RTC-SQI 192 cannot use the SRO, RTC-SQI 192 may still formulate its question by using filterCriteria, which means that the first two steps may be the same as step 211 and step 212 of the category-1 implementation for RTC-SQI case (as shown in FIG. 12). Other steps of the RTC-SQI case may be the same as the procedure of category-2 implementation for TSI-SQI case (as shown in FIG. 13), except step 223. For alternative step 223 for RTC-SQI case, at this time, the TSI-SLN 155 receives a semantic query that is not in SPARQL format but in filterCriteria format. For example, using the URIl and URI2 example above, the query sent from RTC-SQI 192 may be as follows (the same example as used in step 211 of FIG. 12):

RETRIEVE /<TSI-SLN 155> sq ="semantic query" &

query _f or = {x} &

expireAfter = 20:00: 00 05-15-2016 & semantics={y}

in which x and y include the following information:

x = { creationTime }

y = { SELECT ?device ?firmware_version

WHERE {

?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

}

}

Accordingly, TSI-SLN 155 may send the following query to triple store 154:

SELECT ?device ?firmware_version

WHERE { ?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

}

For the other part specified in filterCriteria, it may be used in the later steps, which are the same as the remaining steps described FIG. 13.

[0125] FIG. 14 illustrates an exemplary procedure for semantic query processing for FSC-SQI (category-2 implementation, RT-Thread-First strategy). FIG. 13 is about TS-thread- first strategy while here FIG. 14 is about RT-thread strategy first strategy. At step 239, there may be pre-conditions that FSC-SQI 191 is fully semantics-capable and it already learned how to use the SRO. TSI-SLN 155 has been configured to interact with triple store 154 and it may advertise that it accepts semantic queries towards triple store 154. At step 241, FSC-SQI 191 determines a query (question), which may be answered by triple store 154. Accordingly, FSC-SQI 191 formulates a SPARQL query statement to describe its question. For example, consider the following semantic query by FSC-SQI 191 :

Needs: Please return me 1) the firmware version of a

temperature sensor, and 2) also the creation time of the

corresponding resource which is representing this sensor.

Constraints: 1) This sensor is manufactured by ABC Company and 2) the expiration time of this corresponding resource is after

20:00: 00 05-15-2016."

By utilizing the SRO, FSC-SQI 191 is able to shape the corresponding SPARQL query as follows:

SELECT ?device ?firmware_version ?creationTime

WHERE {

?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

?device SRO: expire After 20:00:00 05-15-2016

?device SRO:hasCreationTime ?creationTime

}

}

[0126] With continued reference to FIG. 14, at step 242, FSC-SQI 191 sends a request message to TSI-SLN 155, in which it indicates that this request is related to a semantic query to be processed by triple store 154. At step 243, TSI-SLN 155 conducts a normal service layer request processing after receiving the request from FSC-SQI 191. FSC-SQI 191 may extract the SRO-related part from the original SPARQL query and represent it using filterCriteria. The filterCriteria may be used for resource discovery. In particular, filterCriteria specifies 1) the constraints for resource discovery, and 2) if such resources can be identified, which information as required by the original semantic query should be retrieved back. In RT-thread-first strategy, RT-thread may be processed first. In the example, a RETRIEVE operation sent from TSI-SLN 155 to RH-SLN 151 may have the following format:

RETRIEVE /<RH-SLN 151>

query _for={ creationTime }

expireAfter=20:00: 00 05-15-2016

As long as the request has the parameter "query for", the RH-SLN 151 may be able to determine that this resource discovery may do more than the traditional resource discovery. TSI-SLN 155 may then decide which RH-SLNs should be contacted based on various rules. For example, FSC- SQI 191 may indicate to TSI-SLN 155 which RH-SLNs 151 are its targeted nodes, or TSI-SLN 155 may also contact potential RH-SLNs, 151 (e.g., those having asked its help for creating triples at triple store 154).

[0127] At step 244,_TSI-SLN 155 sends a request to RH-SLN 151 (or multiple RH- SLNs 151), along with the evaluation criteria as specified in filterCriteria. At step 245, RH-SLN 151 conducts normal resource discovery and identifies the candidate resources. If a candidate resource is found, RH-SLN 151 may further retrieve the information requested by the original semantic query, from the attributes of those candidate resources. In an example, assuming that URI3 and URI4 are identified through resource discovery since they satisfied the constraint as specified in filterCriteria, so only URI3 and URI4 and their corresponding creationTime (say 08:00:00 06-25-2016 and 08:00:00 05-17-2016, respectively) will be returned. In addition, it is worth noting that during step 245, there are multiple ways to indicate RH-SLN 151 where the resource discovery process should be started in its resource tree. For example, TSC-SQI or TSI- SLN 155 may indicate such information, and in such a case, there may be another new parameter defined in step 242 and step 244 to carry this information about resource discovery scope. If there is no such indication by TSC-SQI and TSI-SLN 155, RH-SLN 151 may start resource discovery directly from the root of resource tree of RH-SLN 151.

[0128] With continued reference to FIG. 14, at step 246, RH-SLN 151 returns the processed result, which includes the URIs of candidate resources, and the required information of those resources (which are specified in the original SPARQL query). At step 247, RT-Thread is done and now TS-Thread starts to work. TSI-SLN 155 may modify the original query by 1) deleting the SRO-related part and 2) adding a new constraint that limits the query result only to those candidate resources identified in step 245. This new query may be sent to triple store 154. For example, the new query may be changed as follows (and the changed parts are in Bold):

SELECT ?device ?firmware_version ?crcationTimc

WHERE {

?device example:is-a temperature-sensor

?device example:manufactured-by ABC-company

?device example:firmware-version-is ?firmware_version

?dcvicc SRO;cxpircAftcr 20;00;00 05 15 2016

?dcvicc SRO;hasCrcationTimc ?crcationTimc

FILTER (?device = URI3 or URI4)

}

}

[0129] At step 248, TSI-SLN 155 may further use non-service-layer capability to send the new SPARQL query to triple store 154, and get back the query result. The result may include the information that is requested by the original SPARQL query. In the example, assuming only URI3 satisfied all the constraints specified in the new SPARQL query as described in step 247, and the query result from triple store 154 is as follows: URI3, firmware version: v. 1.7.6. At step 249, based on the retrieved information sent back from triple store 154, the TSI-SLN 155 may further combine them with the required information retrieved from the resource tree side (as done in step 245). The combined information may be used to construct the final result of the original SPARQL query. In the example, the partial result from the resource side as done in step 245 (URI3, creatimeTime: 08:00:00 06-25-2016) may be combined with the partial result from triple store 154 side (URI3, firmware version: v. 1.7.6). The final query result may be as follows: <URI3, firmware version: v. 1.7.6, creationTime: 08:00:00 06-25-2016>. At step 250, TSI-SLN 155 finally returns the query result of the original SPARQL query. Note that, the above procedure of FIG. 14 is for TSI-SQI case, for RTC-SQI case, we can use the exactly same adaption process as discussed in the previous section.

[0130] FIG. 15 illustrates exemplary alternative interactions between different entities of FIG. 7. In an example with regard to FIG. 7, RC/M(s) 152 mainly interact with RH-SLN(s) 151 for service-layer resource CRUD, while RH-SLN 151 interacts with TSI-SLN 155 for RDF triple manipulation operations. FIG. 15 illustrates an example, wherein RC/M 152 is relatively a more powerful node having more capabilities. In FIG. 15, RC/M 152 is shown directly interacting with TSI-SLN by itself for conducting RDF triple manipulation operations, instead of relying on RH-SLN 151 to do so. Accordingly, for the previous procedures associated with information synchronization due to CREATE resource operation, information synchronization due to UPDATE resource operation, and information synchronization due to DELETE resource operation, may be adopted, under FIG. 15, in a way that the RDF triple manipulation operation may be directly handled by RC/M 152 instead of TSI-SLN 155. Similarly, in some scenario, a SQI (e.g., a capability-constrained AE) may not be able to directly interact with TSI-SLN 155. Accordingly, instead of directly sending query requests to TSI-SLN 155, an SQI may request other entities for help as well (e.g., a SQI may send query to a RH-SLN, which can further acts as a relay to contact TSI-SLN 155).

[0131] Discussed below are considerations of semantic query with information asymmetry with reference to oneM2M examples. oneM2M service layer has capabilities referred to as Capability Service Functions (CSFs). The oneM2M service layer is referred to as a Capability Services Entity (CSE). Accordingly, the disclosed methods and systems for semantic query associated with information asymmetry may be regarded as a new CSF in service layer (semantic query service 254), as shown in FIG. 16. The semantic query information asymmetry may be part of the existing semantic-related CSF defined in oneM2M TS-0001. Procedures as well as the new parameters disclosed may happen on Mca and mcc/mcc' reference point as illustrated in FIG. 16. Different types of M2M nodes may implement the semantic query service, such as M2M Gateway, M2M Server, M2M Devices, etc. In particular, depending on the various/different hardware/software capacities for those nodes, the capacities of semantic query services 254 implemented by those nodes may also vary.

[0132] FIG. 17 illustrates exemplary oneM2M entity examples. As mentioned in earlier sections, several logical entities have been defined related to semantic query processing, such as RC/M 152, SL SQI 153, RH-SLN 151, TSI-SLN 155, triple store 154, etc. FIG. 17 illustrates exemplary entities for the oneM2M context. For example, a RC/M 152 may be considered AE/CSE 262, RH-SLN 155 may be considered CSE 261, TSI-SLN 155 may be considered CSE 265, and SL-SQI 153 may be considered AE/CSE 263. Accordingly, the communications between RC/M 152 and RH-SLN 151 may interact through Mca/Mcc reference points. TSI-SLN 155 may interact with RH-SLN 151 through Mcc, and SQI 153 may interact with TSL-SLN 155 through Mca/Mcc. In addition, TSI-SLN 155 may interact with triple store 154 through Mcc interface (e.g., triple store 154 may also be hosted by a CSE), or non-M2M interface. FIG. 17 illustrates the alternative interactions between different entities as disclosed in FIG. 7 or FIG. 15. [0133] As mentioned herein, on the resource tree side, different resources may be created/modified/deleted by RC/M 152. For example, in oneM2M context, AEs and CSEs may create or modify resources. In particular, as defined in oneM2M functional architecture -V2.9.0, each resource may have a list of attributes which may be used to describe a certain aspect of a resource. For example, a <contentInstance> resource has an attribute called "contents ize", which is used to store the size in bytes of the data stored in the "content" attribute of this

<contentInstance> resource. As mentioned earlier, such resource-centric information is currently stored only in the resource tree and not in a triple store 154. SRO is disclosed herein in a generic service layer. When SRO concept is applied in oneM2M service layer, an example may be associated with Table 5. SRO includes new properties that correspond to existing oneM2M resource attributes. Table 5 shows some universal attributes of oneM2M resources and their corresponding new properties defined in SRO (with the prefix "SRO").

Table 5. Examples of New Properties Defined in the SRO oneM2M

[0134] In general, when applying the general SRO in the context of oneM2M service layer, this service layer resource ontology may co-exist with the existing oneM2M Base Ontolgoy. The oneM2M Base Ontology is used to describe the nodes, functionalities, services or other entities in a M2M/IoT system, which means in general the Base Ontology is to model real world. By comparison, the SRO is for re-representing the information, which is originally only stored in the resource tree, as RDF triples. In other words, the SRO is not to model the physical world, but to re-represent the information stored in the resource tree into RDF format. The SRO is not necessarily to be used when semantically annotating a normal oneM2M resource. In addition to re-representing information as RDF triples by using SRO, the SRO may also be published to service layer entities, such as SQI 153, especially to FSC-SQIs 191. Accordingly, FSC-SQIs 191 may leverage SRO to shape SPARQL statements, which are richer in semantic expressivity than the case where SRO cannot be used. For example, with SRO ontology, a SPARQL statement may include resource-related constraints.

[0135] Disclosed below are oneM2M resource attributes for the semantic query disclosed herein. Herein, a complex scenario is discussed in which multiple triple store 154s are behind TSI-SLN 155 and the TSI-SLN 155 may acknowledge RH-SLN 151 (using

"triple_store_id" parameter carried in the response message) which triple store 154 was used for storing the RDF triples related to a given newly-created resource. In particular, the RH-SLN 151 may store the triple store id for the newly-created resource, which will be used when the newly- created resource is to be updated/deleted at a later time such that RH-SLN 151 knows which triple store 154 should be contacted in order to handle the related RDF triples. For a given resource, its related triple-store_id could be stored in an attribute of this resource. Accordingly, for all the oneM2M resources, a new attribute called "tripleStorelD" is disclosed to store this information.

[0136] In addition, a new attributed called "tripleStoreCloned" is disclosed for a normal oneM2M resource, which is to indicate whether the information in this resource are cloned to triple store 154.

[0137] A new resource called <semantic-query-portal> is disclosed in FIG. 18. The <semantic-query-portal> may generally be used as a child resource of a CSE, which is acting as a TSI-SLN 155. Since <semantic-query-portal> is just an access portal, it may just include common attributes for service layer resources (not shown in FIG. 18). Accordingly, semantic query requests from one or more SQI 153 may be targeted to this <semantic-query-portal> resource hosted by TSI-SLN 155. When a CSE can take the role as a TSI-SLN 155, a <semantic- query-portal> may be created through pre-configuration.

[0138] An example is shown in FIG. 21, which illustrates how <semantic-query-portal> resource may be used and how TSI-SLN 155 may process the request. Here, the basic details are presented. In general, it is disclosed that once the <semantic-query-portal> resource is created, TSI-SLN 155 may be ready for receiving semantic query requests. In particular, any SQI 153 may initiate a semantic query request using an UPDATE request message carrying a semantic query statement (see FIG. 21), and target to this <semantic-query-portal> resource. Once TSI- SLN 155 receives an UPDATE request targeted to its <semantic-query-portal> resource, TSI- SLN 155 may start to process this request based on different scenarios. Example scenarios for different category implementations are disclosed below. For category- 1 implementation, in a FSC-SQI case, the TSI-SLN 155 may directly forward the semantic query statement to the Triple store 154 for processing. For category-1 implementation, in a RTC-SQI case, TSI-SLN 155 may extract the semantic query statement from the UPDATE request, in which the semantic query was described using existing filterCriteria. Accordingly, TSI-SLN 155 may generate a new semantic query statement using the disclosed SRO ontology, which may be further sent to triple store 154 for processing.

[0139] For a category-2 implementation, in a FSC-SQI case, TSI-SLN 155 may separate the original semantic query statement into two parts, which may be processed through the two threads, e.g., the TS-Thread and RT-Thread. Note that, in the FSC-SQI case, the original semantic query statement may be directly described as a complete semantic query statement using the disclosed SRO. Then, TSI-SLN 155 may complete the TS-Thread and RT-thread and each of them may yield partial results, which may be combined as the final query result. FIG. 21 mainly illustrates an example of the semantic query procedure for this case by using the <semantic-query-portal> resource, and for other cases as listed herein, the scenarios will be largely similar. For a category-2 implementation, in a RTC-SQI case, the major process is similar to the FSC-SQI case, but the difference is that in this RTC-SQI case, the original query statement was described using existing filterCriteria. Accordingly, it may be considered a simpler case for TSI-SLN 155 to extract the original query and process it through the TS-Thread and RT-Thread.

[0140] A new resource called <RDFTripleManipulation> is shown in FIG. 19.

<RDFTripleManipulation> is normally used as a child resource of a CSE, which is acting as a TSI-SLN 155. Since <RDFTripleManipulation> is an access portal, it may just include common attributes for service layer resources (not shown in FIG. 19). The <RDFTripleManipulation> resource is to support RDF triple manipulation operations. Accordingly, all the RDF triple manipulation related operations may be targeted to this <RDFTripleManipulation> resource hosted by TSI-SLN 155. Normally, when a CSE takes the role as a TSI-SLN 155, a

<RDFTripleManipulation> may be created, which may be during pre-configuration step.

[0141] The <RDFTripleManipulation> resource may often be used when the system adopts a category-1 implementation. An example is shown in FIG. 20, which illustrates how <RDFTripleManipulation> resource may be used and how TSI-SLN 155 may process the received RDF triples due to a CREATE resource operation. Here, the basic details are presented. In general, it is proposed that once <RDFTripleManipulation> is created, the RDF triple manipulation requests may be carried in a UPDATE request. Accordingly, after TSI-SLN 155 receives an UPDATE request targeted to its <RDFTripleManipulation> resource, TSI-SLN 155 may start to process this request based on different scenarios. In a first example, for RDF triple manipulation due to a CREATE resource operation, TSI-SLN 155 may store the newly- generated RDF triples into triple store 154. FIG. 20 mainly illustrates an example for this case by using the <RDFTripleManipulation> resource, and for other cases as listed herein, the examples will be largely similar. In a second example, for RDF triple manipulation due to a UPDATE resource operation, TSI-SLN 155 replaces old RDF triples with the updated RDF triples. In a third example, for RDF triple manipulation due to a DELETE resource operation, the TSI-SLN 155 may delete RDF triples related to the resource that was being deleted as well as all the RDF triples related to its child resources.

[0142] It is contemplated herein that the triple store may be generalized in oneM2M system, such that a <semanticDescriptor> is used to store RDF triples. Conventionally

<semanticDescriptor> are often the child resources of normal resources (e.g., semantic descriptors may store semantic annotations of normal resources). Disclosed herein a

<semanticDescriptor> or another newly-defined resource that has a similar purpose as the <semanticDescriptor> (e.g., as long as it stores RDF triples) may also be a standalone resource for storing RDF data basis/set. In other words, in this case, a <semanticDescriptor> may be regarded as a triple store and not used for annotating its parent resource. Accordingly, a new attribute may be defined for <semanticDescriptor> resource which indicates whether this resource may be regarded as a triple store. If so, semantic query may be sent towards this resource, which may trigger the semantic query processing as disclosed herein.

[0143] FIG. 20 illustrates an exemplary oneM2M procedure for information synchronization due to CREATE operation which was disclosed herein (note that, the same example maybe done for the UPDATE/DELETE operations). It may be seen that in this example, AE 262 is a RC/M 152, CSE 261 is a RH-SLN 151 and CSE 265 is a TSI-SLN 155. Accordingly, the messages between AE 262, CSE 261 and CSE 265 are oneM2M

request/response messages. When CSE 261 interacts with CSE 265 for RDF triple manipulation operation, the request message is targeted to <RDFTripleManipulation> resource hosted on CSE 265. In addition, the detailed descriptions of the procedure steps are substantially the same ones in FIG. 8. There may be a pre-condition in which CSE-2 has the capability to interact with a Triple Store 264 and CSE 261 knows that CSE-2 may help with interactions with Triple Store 264, if Triple Store 264 provides out-of-band interaction interface (e.g., non-oneM2M interface). At Step 301, AE-1 intends to create a new resource at CSE 261. At step 302, AE-1 sends a normal service layer request message for creating a new resource, e.g., <contentinstance-l> resource. At step 303, CSE 261 conducts normal request processing after receiving the request from AE-1 and creates a new resource <contentinstance-l>, in which various attributes have also been configured. At step 304, CSE 261 acknowledges (acks) that the resource has already been successfully created and returns the URI of the created resource. At step 305, CSE 261 extracts the available information stored in this resource and describes them as RDF triples, by using any existing ontology. In particular, SRO ontology may be used to describe resource-centric information. At step 306, CSE 261 asks CSE 263 for help and sends those RDF triples to CSE 261. At step 307: CSE 263 may further interact with Triple Store 264 and store those RDF triples into the Triple Store 264, so that those triples can support later semantic queries or other semantic related applications. At step 308: CSE 263 acks that the RDF triples have been successfully stored in Triple store 264.

[0144] FIG. 21 illustrates an exemplary oneM2M Procedure for Semantic Query Processing for Fully Semantic Capable SQI (Category-2 Solution, RT-Thread-First Strategy) (note that, the same examples may be done for other query processing procedures). In this example, CSE 263 is a FSC-SQI 191, CSE 265 is TSI-SLN 155 and CSE 261 is a RH-SLN 151. Accordingly, the messages between CSE 263, CSE 265 and CSE 261 are oneM2M

request/response messages. When CSE 263 interacts with CSE 265 for initiating a semantic query, the query message is targeted to <semantic-query-portal> resource hosted on CSE 265. In addition, the detailed descriptions of the procedure steps are substantially the same as the ones in FIG. 14. There may be a pre-condition in which CSE 263 is a fully semantics-capable user and it already learned how to use SRO ontology. There may be a pre-condition in which CSE 265 has the capability to interact with a Triple Store 264 and it advertises that it can accept semantic queries towards Triple Store 264. At step 311, based on needs, CSE 263 raises a question, which is expected to be answered by the Triple Store 264. Accordingly, CSE 263 formulates a complete SPARQL query statement to describe its question. At step 312, CSE 263 sends a request message to CSE 265, in which it indicates that this request is related to a semantic query to be processed by Triple Store 264. At step 313, CSE 265 conducts normal service layer request processing after receiving the request from CSE-2. In the meantime, it will extract SRO-related part from the original SPARQL query and represented it using filterCriteria. The filterCriteria will be used for resource discovering. In particular, it specifies 1) the constraints for resource discovering and 2) if such resources can be identified, which information as required by the original semantic query should be retrieved back. CSE 265 will then decide which RH-SLNs should be contact based on various rules, in this case, CSE 261 for example.

[0145] With continued reference to FIG. 21, at step 314, CSE 265 sends a request to CSE 261, along with the evaluation criteria as specified in filterCriteria. At step 315, The CSE 261 conducts normal resource discovery and identifies all the candidate resources. If candidate resource is found, CSE 261 will further retrieve the information required by original semantic query, from the attributes of those candidate resources. At step 316, CSE 261 returns the processed result, which includes the URIs of candidate resources, and the required information of those resources (which are specified in the original SPARQL query). At step 317, The CSE 263 will modify the original query by 1) deleting the SRO-related part and 2) adding a new constraint that limits the query result only to those candidate resources as identified in Step 5. This new query will be send it to Triple Store 264. At step 318, The CSE 263 will further send the new SPARQL query to Triple Store 264, and get back the query result. The result may include the information that is required by the original SPARQL query. At step 319, Based on the retrieved information sent back from Triple Store 264, the CSE 263 may further combine them with the required information retrieved from Resource Tress side. Those two-part information may finally construct the final result of the original SPARQL query. At step 320, CSE 263 finally returns the query result of the original SPARQL query.

[0146] A graphical user interface (GUI) 270 is in FIG. 22, which may be used for supporting the necessary configurations for semantic query processing. For example, since there is more than one implementation category that has been disclosed, each of implementation categories may have their own application scenarios. The semantic query processing operations may depend on different situations (e.g., adopt Category-1 or Category-2 implementation). There are also multiple types of strategies that may be used for a category-2 implementation (e.g., the Resource-Tree First Strategy or the Triple-Store First Strategy). Based on the choice, the system may then conduct appropriate settings and configurations in order to execute the selected semantic query processing operations.

[0147] Disclosed below is additional subject matter that supports semantic query over a oneM2M resource tree. For each oneM2M resource <resourceType>, its original attributes may be represented as RDF triples (or other semantic representations) based on the SRO ontology as disclosed herein. Those RDF triples may be stored in one or multiple <semanticDescriptor> child resources (see FIG. 23), or in a new attribute semanticAttributes (FIG. 24). Also, RDF triples of each <resourceType>'s original attribute may be stored in a new semantic attribute of <resourceType> (FIG. 25).

[0148] In FIG. 23, RDF triples of <resourceType>'s original attributes (e.g., attribute 281, attribute 282, etc.) may be stored in one or multiple child resource <semanticDescriptor> 285. As an alternative, those RDF triples may also be stored in <resourceType>'s parent resource's child resource <semanticDescriptor>.

[0149] In FIG. 24, a new attribute semanticAttributes 284 is disclosed. RDF triples of <resourceType>'s original attributes (e.g. attribute 281, attribute 282, etc.) may be stored in this new attribute semanticAttributes 284. Note that semanticAttributes 284 may also be a child resource of <resourceType>. RDF triples of <resourceType>'s original attributes (attribute 281, attribute 282, etc.) may be stored as semanticAttributes's 284 attribute. In this case,

semanticAttributes 284 may be referred by or linked to semanticAttributes of another resource or <semanticDescriptor> 285 of the same or different resource. The semanticAttributes 284 may also store RDF triples which represent original attributes of <resourceType>'s child resources. This new semanticAttributes 284 may be referred by or linked to one or multiple

<semanticDescriptor> 285 resource. When conducting semantic resource discovery over the <resourceType>, not only the RDF triples stored in the existing <semanticDescriptor> 285 resource, but also the RDF triples stored in this semanticAttributes 284 may be evaluated during the semantic resource discovery processing. Conventionally, existing attributes of an oneM2M resource may not be represented in RDF triples and as such, semantic query cannot be performed or executed over them since semantic query works only for RDF triples. This semanticAttributes 284 enables the existing attributes of an oneM2M resource are now represented in RDF triples, therefore semantic query may be performed over them now.

[0150] In FIG. 25, a new semantic attribute is introduced for each original attribute of <resourceType> and may be used to store RDF triples of each attribute. For example, Table 6 lists the peer semantic attribute name for each original oneM2M universal attribute, although the name of each peer semantic attribute may have other options. Table 7 lists the peer semantic attribute name for each original oneM2M common attribute, although the name of each peer semantic attribute may have other options. When conducting semantic resource discovery over the <resourceType>, not only the RDF triples stored in the existing <semanticDescriptor> 285 resource, but also the RDF triples stored in each of those new semantic attributes may be evaluated during the semantic resource discovery processing.

Table 6. Peer Semantic Attributes for oneM2M Universal Attributes

Table 7. Peer Semantic Attributes for oneM2M Common Attributes

[0151] With continued reference to FIG. 25, there may be the following alternative, for a given <resourceType-A>, as an example, a corresponding new semantic resource type may be defined, which may be called <semanticResourceType-A>. In particular, in this

<semanticResourceType-A>, all its attributes are the semantic attributes that correspond to the normal attributes of the original <resourceType-A>. For example, if <resourceType-A> has an Attribute 281 and an Attribute 282, the <semanticResourceType-A> may have a corresponding attribute semanticAttribute 291 and semanticAttribute 292. In addition to the RDF triple(s) that describe the attribute value of attribute 281 by using the disclosed SRO, semanticAttribute 291 may also include other RDF triples using other ontologies to give more detailed information related to attribute 281. Similarly, in addition to the RDF triple(s) that describe the attribute value of attribute 282 by using the disclosed SRO, semanticAttribute 292 may also include other RDF triples using other ontologies to give more detailed information related to attribute 282. Taking oneM2M as an example, a given <AE-1> resource may have a corresponding

<semanticAE-l> resource, in which the semanticCreationTime attribute is corresponding to the "creationTime" attribute of <AE-1>. In addition to storing a RDF triple to describe the attribute value of "creationTime" of <AE-1> (such as "URI_of_<AE-l> SRO reationTime 20:01 :56 09-24-2016"), it also can have RDF triples providing more information, such as the time zone information (e.g., 20:01 :56 09-24-2016 is a PST time (Pacific Standard Time) time), for example. In addition, it is possible that both <AE-1> resource and <semanticAE-l> co-exist in the system (e.g., to allow for different type of users), the information synchronization between <AE-1> resource and corresponding <semanticAE-l> may be needed, which may also utilize the solutions in this disclosure.

[0152] Using the approaches associated with FIG. 23, FIG. 24, and FIG. 25, original attributes of oneM2M resource may be represented as RDF triples, which are stored as new attributes, new child-resource, or a part of existing <semanticDescriptor> child resource of this particular oneM2M resource. The Hosting CSE, which hosts this particular oneM2M resource, may automatically update RDF triples when any original attribute has a change (e.g., being updated or being removed) for synchronization purpose, for example, triggered by another CSE or AE. Alternatively, another CSE or AE may actively update RDF triples for one or more original attributes of this particular resource. In addition, the Hosting CSE, which hosts this particular oneM2M resource, may extract those RDF triples of original attributes from

<semanticDescriptor> 285 (FIG. 23), semanticAttributes 284 (FIG. 24), or peer semantic attribute 291 (FIG. 25). Then the Hosting CSE may store those RDF triples to a temporary triple store or a centralized triple store, in order to perform semantic query. This may be triggered when the Hosting CSE receives a semantic query request or a resource discovery request with a semantic filter from another CSE or AE.

[0153] Without in any way unduly limiting the scope, interpretation, or application of the claims appearing herein, a technical effect of one or more of the examples disclosed herein is to provide adjustments to semantic query processing. Given a semantic query to be conducted on the data stored in the Triple Store, designed herein are at least to implementations (with multiple variations) that may address the information asymmetry issue. For a category-1 implementation, the original semantic query statement is generally not manipulated and the information asymmetry may be addressed by both the resource tree and Triple Store side having generally the same information bases. Since any CRUD operation at the resource-tree side may affect the information (or knowledge) availability at the Triple Store, the information synchronization process makes sure that the information is synchronized between the resource tree and the Triple Store. For example, FIG. 8 addresses a Create case, FIG. 9 addresses an Update case, and FIG. 10 addresses a Deletion case. In addition, a new "Service-layer Resource Ontology" (SRO) is defined (e.g., Table 4 and FIG. 6C). SRO is generally used for representing the information conventionally just stored in the resource tree as RDF triples so that this information may also be available at the Triple Store.

[0154] Also disclosed herein is a category-2 implementation. Category-2

implementation does not generally touch the data stored in the triple store, e.g., the information asymmetry between resource tree and Triple Store may still exist (e.g., information is not synchronized between resource tree and triple store). However, if the original semantic query needs some information that is only available in resource tree but unavailable in Triple Store, the original semantic query may be split into two threads: the processing thread at resource tree side called RT-Thread and the processing thread at Triple Store side called TS-Thread. In this implementation, in order to process the query, part of the work shouldo be done at resource tree side and part of work should be done at Triple Store side, depending on where the needed information resides. In particular, partial query results may be worked out at both resource tress side and Triple Store side respectively and those partial results may be composed together as the final query result of the original semantic query. Example category-2 implementation includes the procedures shown in FIG. 13 and FIG. 14. A combination of aspects of a category- 1 implementation and a category-2 implementation is contemplated herein.

[0155] FIG. 26 A is a diagram of an example machine-to machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed concepts associated with semantic query with regard to information asymmetry may be implemented (e.g., FIG. 7 - FIG. 22 and accompanying discussion). Generally, M2M

technologies provide building blocks for the IoTAV oT, and any M2M device, M2M gateway or M2M service platform may be a component of the IoTAVoT as well as an IoTAVoT service layer, etc.

[0156] As shown in FIG. 26 A, the M2M/ IoTAVoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network 12 may comprise of multiple access networks that provides content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network 12 may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[0157] As shown in FIG. 26 A, the M2M/ IoTAVoT communication system 10 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain includes M2M gateways 14 and terminal devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M/ IoT/WoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M terminal devices 18 are configured to transmit and receive signals via the communication network 12 or direct radio link. The M2M gateway device 14 allows wireless M2M devices (e.g. cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M service layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example.

[0158] Referring to FIG. 26B, the illustrated M2M service layer 22 in the field domain provides services for the M2M application 20 (e.g., smart home temperature control application of mobile device 111 or RC/M 152), M2M gateway devices 14, and M2M terminal devices 18, and the communication network 12. It will be understood that the M2M service layer 22 may communicate with any number of M2M applications, M2M gateway devices 14, M2M terminal devices 18, and communication networks 12 as desired. The M2M service layer 22 may be implemented by one or more servers, computers, or the like. The M2M service layer 22 provides service capabilities that apply to M2M terminal devices 18, M2M gateway devices 14 and M2M applications 20. The functions of the M2M service layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[0159] Similar to the illustrated M2M service layer 22, there is the M2M service layer 22' in the Infrastructure Domain. M2M service layer 22' provides services for the M2M application 20' and the underlying communication network 12' in the infrastructure domain. M2M service layer 22' also provides services for the M2M gateway devices 14 and M2M terminal devices 18 in the field domain. It will be understood that the M2M service layer 22' may communicate with any number of M2M applications, M2M gateway devices and M2M terminal devices. The M2M service layer 22' may interact with a service layer by a different service provider. The M2M service layer 22' may be implemented by one or more servers, computers, virtual machines (e.g., cloud/computer/storage farms, etc.) or the like.

[0160] Referring also to FIG. 26B, the M2M service layer 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The service layer 22 and 22' also enables M2M applications 20 and 20' to communicate through various networks 12 and 12' in connection with the services that the service layer 22 and 22' provide.

[0161] In some examples, M2M applications 20 and 20' may include desired applications that communicate using systems as discussed herein. The M2M applications 20 and 20' may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20'.

[0162] The methods and systems for semantic query with regard to information asymmetry of the present application may be implemented as part of a service layer. The service layer is a middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. An M2M entity (e.g., an M2M functional entity such as a device, gateway, or service/platform that is implemented on hardware) may provide an application or service. Both ETSI M2M and oneM2M use a service layer that may include the methods and systems for semantic query with regard to information asymmetry of the present application. The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). Further, the methods and systems for semantic query with regard to information asymmetry of the present application may be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) or a resource-oriented architecture (ROA) to access services such as the methods and systems for semantic query with regard to information asymmetry of the present application.

[0163] As discussed herein, the service layer may be a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home networks. A M2M service layer can provide applications r various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware or software and that provides (service) capabilities or functionalities exposed to various applications or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

[0164] FIG. 26C is a system diagram of an example M2M device 30, such as an M2M terminal device 18 (which may include smart home temperature application of mobile device 111) or an M2M gateway device 14 (which may include one or more components of FIG. 15), for example. As shown in FIG. 26C, the M2M device 30 may include a processor 32, a transceiver 34, a transmit/receive element 36, a speaker/microphone 38, a keypad 40, a display/touchpad 42, non-removable memory 44, removable memory 46, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. It will be appreciated that the M2M device 30 may include any sub-combination of the foregoing elements while remaining consistent with the disclosed subject matter. M2M device 30 (e.g., AE/CSE 262, RH-SLN 155, CSE 261, TSI-SLN 155, CSE 265, SL-SQI 153, and others) may be an exemplary

implementation that performs the disclosed systems and methods for semantic query with regard to information asymmetry.

[0165] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 32 may perform signal coding, data processing, power control, input/output processing, or any other functionality that enables the M2M device 30 to operate in a wireless environment. The processor 32 may be coupled to the transceiver 34, which may be coupled to the transmit/receive element 36. While FIG. 26C depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip. The processor 32 may perform application-layer programs (e.g., browsers) or radio access-layer (RAN) programs or communications. The processor 32 may perform security operations such as authentication, security key agreement, or cryptographic operations, such as at the access-layer or application layer for example.

[0166] The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, an M2M service platform 22. For example, the transmit/receive element 36 may be an antenna configured to transmit or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an example, the transmit/receive element 36 may be an emitter/detector configured to transmit or receive IR, UV, or visible light signals, for example. In yet another example, the

transmit/receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit or receive any combination of wireless or wired signals.

[0167] In addition, although the transmit/receive element 36 is depicted in FIG. 26C as a single element, the M2M device 30 may include any number of transmit/receive elements 36. More specifically, the M2M device 30 may employ MIMO technology. Thus, in an example, the M2M device 30 may include two or more transmit/receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0168] The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the M2M device 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the M2M device 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0169] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 or the removable memory 46. The nonremovable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other examples, the processor 32 may access information from, and store data in, memory that is not physically located on the M2M device 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42 in response to whether the methods and systems for semantic query with regard to information asymmetry in some of the examples described herein are successful or unsuccessful (e.g., information synchronization, query result combination , etc.), or otherwise indicate a status of a semantic query of triple store 154 or a resource tree and associated components. The control lighting patterns, images, or colors on the display or indicators 42 may be reflective of the status of any of the method flows or components in the FIG. 's illustrated or discussed herein (e.g., FIG. 7 - FIG. 21, etc). Disclosed herein are messages and procedures of semantic query with regard to information asymmetry. The messages and procedures may be extended to provide interface/ API for users to request service layer related information via an input source (e.g., speaker/microphone 38, keypad 40, or display/touchpad 42). In an addition example, there may be a request, configure, or query of semantics information, among other things that may be displayed on display 42.

[0170] The processor 32 may receive power from the power source 48, and may be configured to distribute or control the power to the other components in the M2M device 30. The power source 48 may be any suitable device for powering the M2M device 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0171] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the M2M device 30. It will be appreciated that the M2M device 30 may acquire location information by way of any suitable location-determination method while remaining consistent with information disclosed herein. [0172] The processor 32 may further be coupled to other peripherals 52, which may include one or more software or hardware modules that provide additional features, functionality or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., fingerprint) sensors, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0173] The transmit/receive elements 36 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The transmit/receive elements 36 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52.

[0174] FIG. 26D is a block diagram of an exemplary computing system 90 on which, for example, the M2M service platform 22 of FIG. 26A and FIG. 26B may be implemented. Computing system 90 (e.g., M2M terminal device 18 or M2M gateway device 14) may comprise a computer or server and may be controlled primarily by computer readable instructions by whatever means such instructions are stored or accessed. Such computer readable instructions may be executed within central processing unit (CPU) 91 to cause computing system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, that performs additional functions or assists CPU 91. CPU 91 or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for semantic query with regard to information asymmetry, such as determining types of implementations, responding to semantic queries based on implementation, or receiving instructions execute RT-Thread before TS -Thread or vice versa.

[0175] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus. [0176] Memory devices coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally include stored data that cannot easily be modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

[0177] In addition, computing system 90 may include peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0178] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0179] Further, computing system 90 may include network adaptor 97 that may be used to connect computing system 90 to an external communications network, such as network 12 of FIG. 26 A and FIG. 26B.

[0180] It is understood that any or all of the systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, or the like, perform or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above may be implemented in the form of such computer executable instructions. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, but such computer readable storage media do not include signals per se. As evident from the herein description, storage media should be construed to be statutory subject matter. Computer readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium which can be used to store the desired information and which can be accessed by a computer.

[0181] In describing preferred methods, systems, or apparatuses of the subject matter of the present disclosure - semantic query processing - as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[0182] The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effectuate the methods described herein. As used herein, the terms "apparatus," "network apparatus," "node," "device," "network node," or the like may be used interchangeably. In addition, the use of the word "or" is generally used inclusively unless otherwise provided herein.

[0183] This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art (e.g., skipping steps, combining steps, or adding steps between exemplary methods disclosed herein). Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.

[0184] Methods, systems, and apparatuses, among other things, as described herein may provide for means for semantic query processing. A method, system, computer readable storage medium, or apparatus has means for receiving a CRUD (create retrieve update delete) request associated with a resource; manipulating the resource based on the CRUD request; and based on the manipulating of the resource, describing the manipulated resource as a triple (e.g., RDF triple). The describing may be based on a service-layer resource ontology. The describing may be further based on information of the resource being resource-centric information conventionally stored in the resource tree. The method, system, computer readable storage medium, or apparatus has means for sending the triple to a triple store. All combinations in this paragraph (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

[0185] Methods, systems, and apparatuses, among other things, as described herein may provide for means for semantic query processing. A method, system, computer readable storage medium, or apparatus has means for receiving a request to create a resource for a resource tree; creating the resource based on the request to create the resource; generating a subject-predicate-object triple based on the resource; and in response to generating the subject- predicate-object triple, providing instructions to transmit the resource to a triple store for semantic operation (e.g., semantic query or semantic discovery). The generating the subject- predicate-object triple may be based on a service-layer resource ontology. The generating the subject-predicate-object triple may be further based on information of the resource being resource-centric information conventionally stored in the resource tree. The generating the subject-predicate-object triple may be further based on an attribute of the resource. The method, system, computer readable storage medium, or apparatus has means for providing further instructions to store the resource in an attribute of the resource tree on the apparatus. The method, system, computer readable storage medium, or apparatus has means for sending a purpose identifier that indicates whether the triple store should replace an existing triple on the triple store. The method, system, computer readable storage medium, or apparatus has means for providing a parameter that indicates a preferred semantic graph to store the subject-predicate- object triple. A computer-readable storage medium having a computer program stored thereon, the computer program being loadable into a data-processing unit and adapted to cause the data- processing unit to execute method steps according to any of the semantic query processing subject matter herein when the computer program is run by the data-processing unit. All combinations in this paragraph (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.