KR101027497B1 - Ubiquitous service system and data process method therefor - Google Patents

Abstract

The ubiquitous service system according to the present invention includes: a sensor group sensing a variety of states and including a plurality of sensors generating event information according to a sensing result; A device group including a plurality of devices configured to perform various operations, generate event information according to an operation state, and perform an operation according to a control command received from the outside; A ubiquitous service group provided with a plurality of service modules for implementing a ubiquitous service when a control command is received from the outside; An interface device for interfacing with a plurality of sensors of the sensor group and a plurality of devices of the device group; An ontology repository device having an ontology for situation recognition and storing one or more instances representing the event information; Receiving the event information through the interface device to implement a low-level situation recognition, combines the low-level situation recognition result and the event information to generate one or more instances meeting the ontology schema, and the one or more instances The control command is stored in the ontology repository device, requests the processing of the situation recognition information to the outside, and when a control command for any one or more service modules or any one or more devices is received from the outside, the control command is transmitted to the service module or the corresponding device. A ubiquitous service support device collaborative system to transmit to a server; According to the request for processing the context awareness information, at least one instance corresponding to the request for processing the context awareness information is read from the ontology repository repository, and the at least one read instance is compared with a predetermined knowledge base in advance. The ubiquitous service is supported by performing a situation awareness, determining one or more services corresponding to the high level situation awareness result, and generating a control command for one or more service modules or one or more devices for providing the determined one or more services. It includes; context information-based intelligent service connection and operation system to provide a device collaboration system.

Ubiquitous Service System, Ontology Repository Repository

Description

Ubiquitous service system and data processing method accordingly {UBIQUITOUS SERVICE SYSTEM AND DATA PROCESS METHOD THEREFOR}

The present invention relates to a ubiquitous service system. More particularly, the present invention relates to a ubiquitous service system that collects data from a plurality of various entities, recognizes a situation, and determines and provides a ubiquitous service suitable for the recognized situation. It is about a method.

U-CITY, which is emerging recently, is a city that provides various ubiquitous services such as transportation, environment, and welfare anytime and anywhere by building ubiquitous infrastructure by fusing cutting-edge information and communication technologies to urban infrastructures such as roads, bridges, schools, and hospitals.

The ubiquitous network for the ubiquitous service is an infrastructure that connects a space to any terminal anytime, anywhere, in the connection of various entities.

In the ubiquitous network, data from various media for realizing a function pursued by a user in a connection system between space, objects, and people flows in real time between the space, the object, and the person, and from the data existing in the ubiquitous network to the user. Data processing and management are required to provide the desired service.

Of course, the number of objects connected to the ubiquitous network is large, and the data from the plurality of objects is also very large.

Accordingly, it is urgently needed to develop a technology that can collect data from the plurality of entities to recognize a situation and provide a ubiquitous service appropriate to the recognized situation.

SUMMARY OF THE INVENTION An object of the present invention is to provide a ubiquitous service system and a data processing method thereof, which collect data from a plurality of various entities to recognize a situation and determine and provide a ubiquitous service suitable for the recognized situation.

The ubiquitous network system of the present invention for achieving the above object, the sensor group for sensing a variety of states, the sensor group is provided with a plurality of sensors for generating event information according to the sensing result; A device group including a plurality of devices configured to perform various operations, generate event information according to an operation state, and perform an operation according to a control command received from the outside; A ubiquitous service group provided with a plurality of service modules for implementing a ubiquitous service when a control command is received from the outside; An interface device for interfacing with a plurality of sensors of the sensor group and a plurality of devices of the device group; An ontology repository device having an ontology for situation recognition and storing one or more instances representing the event information; Receiving the event information through the interface device to implement a low-level situation recognition, combines the low-level situation recognition result and the event information to generate one or more instances meeting the ontology schema, and the one or more instances The control command is stored in the ontology repository device, requests the processing of the situation recognition information to the outside, and when a control command for any one or more service modules or any one or more devices is received from the outside, the control command is transmitted to the corresponding service module or the corresponding device. Ubiquitous service support device collaboration system for transmitting to the device; According to the request for processing the situation awareness information, at least one instance corresponding to the request for processing the situation awareness information is read from the ontology repository repository, and the at least one read instance is compared with a predetermined knowledge base to compare a high level situation. The ubiquitous service supporting device by performing a recognition, determining one or more services corresponding to the high level situation recognition result, and generating a control command for one or more service modules or one or more devices for providing the determined one or more services. It includes; context information-based intelligent service connection and operation system to provide a collaboration system.

As described above, the present invention collects data from a plurality of various entities of a ubiquitous network system, recognizes a situation, and provides a ubiquitous service corresponding thereto.

Structure of Ubiquitous Service System

A structure of a ubiquitous service system according to a preferred embodiment of the present invention will be described with reference to FIG. 1.

The ubiquitous network system is largely connected to a sensor group (A100), an interface device (A102), a ubiquitous service support device collaboration system (A108), an ontology repository device (A116), a ubiquitous service bus device (A118), and context information based intelligent service. And an operating system A120, a device group A132, and a ubiquitous service group A134.

The sensor group A100 is composed of a plurality of various sensor nodes, and each sensor node is interspersed in a wide area. As the sensor node, a temperature sensor, a motion sensor, a gas sensor, and the like are employed to sense a situation at a location where the sensor node is installed, to generate event information in the form of raw data, and to generate the event information in the ubiquitous form of the interface device A102. The service platform-based USN interworking system A104 provides the situation recognition collaboration system A110 of the ubiquitous service support device collaboration system A108.

The device group A132 is a user authentication device, a portable terminal device, an imaging device, a display device, a switchgear device, an air conditioner, etc. for providing various ubiquitous services, and is scattered in a wide area or carried by a user. Each device of the device group A132 transmits event information such as its own identification information or status information to the ubiquitous service supporting device collaboration system A108 through the inter-device interface A106 of the interface device A102. Provided by the recognition collaboration system (A110). In addition, each device of the device group A132 implements various ubiquitous services by performing an operation according to a control command provided by the ubiquitous service providing system A112 of the ubiquitous service supporting device collaboration system A108.

The ubiquitous service group A134 provides various types of ubiquitous services together with a plurality of devices included in the device group A132. The ubiquitous service may be a security service, a media providing service, a shopping service, an education service, a transportation service, a business support service, and the like.

The interface device A102 is composed of a ubiquitous service platform based USN interworking system A104 and an inter-device interface unit A106.

The ubiquitous service platform-based USN interworking system A104 performs communication with a plurality of sensor nodes belonging to the sensor group A100, receives event information from the sensor nodes, and transmits the event information to the situation recognition collaboration system A110. to provide.

The inter-device interface module A106 performs communication with the devices of the device group A132.

The ubiquitous service support device collaboration system A108 is composed of a context-aware collaboration system A110, a ubiquitous service providing system A112, and a ubiquitous service operating platform A114.

The context aware collaboration system A110 receives event information provided by any one or more sensors of the sensor group A100 through the ubiquitous service platform-based USN interworking system A102 and indicates a plurality of instances representing the event information. Generates and stores in the ontology repository device A116 and requests the context information processing to the context information processing system A130. In addition, the context aware collaboration system A110 receives event information provided by any one or more devices in the device group A132 provided from the inter-device interface module A106 and receives a plurality of instances representing the event information. It generates and stores the ontology repository device A116 and requests the context information processing to the context information processing system A130.

The ubiquitous service providing system A112 receives a device or service module control command provided from the ubiquitous service operating system A126 and provides a control command to one or more devices belonging to the device group A132, or a ubiquitous service group A134. Provide control commands to one or more ubiquitous service modules belonging to

The ubiquitous service operating platform A114 provides a platform for ubiquitous service operation.

The ubiquitous service bus A118 forms a communication path for each part of the ubiquitous service system according to the present invention.

The ontology repository device (A116) stores an instance generated from the event information according to a preferred embodiment of the present invention, and stores a plurality of ontology groups according to various environments based on the instance, the situation can be implemented. Classification information for classifying event information, condition information for basic situation awareness, inference information for situation inference, inference history, context awareness reference information, and the like are stored.

The context information-based intelligent service connection and operation system (A120) is a ubiquitous service storage (A122), ubiquitous service infrastructure management system (A124), ubiquitous service operating system (A126), ubiquitous service security unit (A128), situation information processing system A130 is provided.

The contextual information processing system A130 loads instances of the object to be processed from the ontology repository storage A116 according to the contextual information processing request event of the contextual awareness collaboration system A110, infers a situation indicated by the instances, The ubiquitous service corresponding to the inference result is determined, and a ubiquitous service provision command is provided to the ubiquitous service operating system A126.

The ubiquitous service operating system A126 may control the one or more devices of the device group A132 or any one or more of the ubiquitous service group A134 according to the ubiquitous service provision command from the context information processing system A130. A control command for the service module is generated and provided to the ubiquitous service providing system A112.

The ubiquitous service security unit A128 is responsible for the security service according to the provision of the ubiquitous service of the present invention.

The ubiquitous service infrastructure management system A124 is in charge of managing ubiquitous service information stored in the ubiquitous service storage A122.

<Detailed composition of situation recognition collaboration system and situation information processing system>

A detailed configuration of the contextual recognition collaboration system A110 and the contextual information processing system A130 according to an exemplary embodiment of the present invention will be described with reference to FIG. 2.

The context aware collaboration system A110 is composed of a context profiler A200 and an instance generator A210.

The contextual information processing system A130 is composed of a context analyzer A222 and a context service provider A236, and the ontology repository device A116 is an ontology repository repository. A218) and a manager (A220), and the situation information processing system (A130) is composed of.

<Context Profiler (Preprocessor)>

The context profiler A200 classifies the event information received from the device or the sensor according to the type of event information and implements whether it is a basic situation, and performs context information processing according to whether it is a basic situation. Request, and preprocess the event information into context-aware data to provide to the instance generator (A210), sensor and device manager (sensor / device configuration manager) (A202), situation monitor (situation monitor) (A204), operation manager and an activity manager A206 and a status manager A208.

The sensor and device manager A202 manages catalog information of sensors and devices, and sets filter information for classifying a plurality of event information provided in a stream form from the sensors and devices. The filter information is condition information for classifying event information based on when and from which sensor or device at what location.

The situation monitor A204 classifies a plurality of event information provided in a stream form from a sensor and a device according to the filter information and provides the same to the operation manager A208.

The operation manager A206 shifts the basic situation from the event information classified according to the filter information. Condition information for determining a situation according to event information may be provided to determine whether the situation is basic. In more detail, when event information consisting of specific location information and RFID tag information is provided, it is recognized as an ENTER situation, and when event information consisting of specific location information and temperature sensing information is provided, the temperature (TEMP) at the location is provided. May be recognized as).

The state manager A208 receives event information and situation determination information classified according to the filter information, converts the situation information into situation data based on situation or reference information, and temporarily stores the situation data in a storage not shown. If the predetermined condition is satisfied, the temporary generator provides the instance generator A210 whether the temporary storage condition is satisfied.

For example, when the state manager A208 is provided with event information consisting of {234,532,214} and {RFID identification information} having values of X, Y, and Z coordinate formats, and whether the situation is INSIDE, the event information Based on the location information, the RFID identification information, the reception time and the situation determination information contained in the INSIDE (Hong Gil-dong, two-story corridor, 2008: 10: 22: 16: 01: 02) generates situation awareness data.

In addition, the state manager A208 receives the event information including the temperature sensing information of 20 degrees Celsius, the {234,332,414} location information, and the determination whether the situation of the TEMP, the TEMP {20 degrees Celsius, LOCATION (402)} Generate situational data.

The context-aware reference information may include a mapping table in which location information in X, Y, and Z coordinate formats is mapped into intuitive location information, and a mapping table in which portable terminal identification information such as RFID is mapped to user identification information.

 The predetermined condition may be a pool of temporary storage buffers or the like at each arrival of a predetermined period.

<Instance generator>

The instance generator A210 is responsible for processing situational awareness data into an instance based on a situation model and storing it in an ontology repository repository A116, an instance builder A212, and a context model matcher. (A214), an instance manager (A216).

The context model matcher (A214) is responsible for matching the domain and higher ontology model configured for the basic situation to apply to various situations.

The instance builder A212 processes the situation awareness data into one or more instances. The instance has a triple form consisting of subject + predicate + object.

For example, {"SEO" is a graduate of "SSU". } Is the first instance of {seo is a person}, that is,

"<http://www.owl-ontologies.com/u-City_Agent# seo >

<http://www.w3.org/1999/02/22-rdf-syntax-ns# type >

<http://www.owl-ontologies.com/u-City_Agent# Person >. "

a second instance meaning {seo is a graduate},

<http://www.owl-ontologies.com/u-City_Agent# seo >

<http://www.owl-ontologies.com/u-City_Agent# title >" graduate student "

<http://www.w3.org/2001/XMLSchema# string >.

a third instance with the meaning of {seo is related to ssu}, i.e.

<http://www.owl-ontologies.com/u-City_Agent# seo >

<http://www.owl-ontologies.com/u-City_Agent# affiliatedWith >

<http://www.owl-ontologies.com/u-City_Agent# SSU >.

In other words, context-aware data is processed into multiple instances that have a triple format divided into subject + predicate + object.

In particular, the instance builder A212 processes the situational awareness data according to a predetermined context model schema.

The instance manager A216 stores one or more instances generated by the instance builder A212 in an ontology repository A218.

Context analyzer

The context analyzer A222 infers whether it is a high-level situation according to an event provided by the operation manager A206, and provides the high-level situation or result information to the context service provider A236. an event trigger (A224), a context reasoner (A226), a context tracker (A232), and a context recognizer (A234).

The event trigger A224 generates an event for processing situation information based on the low-level situation recognition result information provided from the context profiler A200.

The context reasoner A226 includes a DL reasoner A228 and a rule reasoner A230. The DL reasoner A228 reads and interprets the meanings of ontology. By inferring, the processing speed is low but inferring complex data is possible, and the rule inferencing machine A230 performs inference according to a predetermined definition, and the processing speed is high, but only inference about simple data is possible. Accordingly, the present invention selectively drives a predetermined reasoner according to a low-level situational recognition result, performs DL reasoning on complex data, and rules reasoning on simple data, thereby increasing the reliability of the reasoning result and providing fast reasoning. Make it possible.

Here, the operation of the DL reasoner A228 will be briefly described with reference to FIG. 3. The DL reasoner A228 is composed of a DL reasoning module A300 and a knowledge base A302.

The knowledge base A302 is composed of a T-box A304 and an A-box A306. The T-box A304 combines a plurality of individual subjects into predetermined role constructors to give a new meaning. The role configurator includes a universal roll, a roll intersection, a roll union, a complement, an inverse roll, a roll composition, a transitional closure, a reflective transitional closure, and the like. This may be included. Examples of the knowledge provided in the T box A304 are "HAPPYMAN ≡ HUMAN (human) П MALE (male) ПE MARRIED. DOCTOR (married doctor) П [≥ 5 GASCHILD (5 or more children)] ПA HASCHILE. PROFESSOR ", which means that humans, men, married doctors, five children, and a number of individuals, all of whom are professors, are given a new meaning of HAPPYMAN.

In this way, a number of different individual entities are combined in various ways to create a large number of knowledge making new meanings, which are registered in the T-box A304 of the knowledge base A302.

The A-box A306 has a declarative form for specifying the properties of a specific entity, and declaratively shows high-level situational awareness results for individual subjects based on the concepts and roles expressed in the T-box A304. There is a lot of knowledge to express.

When a reasoning about the result of which low level situation is requested, the DL inference module A300 calls instances corresponding to the result of the low level situation, and uses the knowledge provided in the T-box A304. Combining on the basis of the new meaning to give a new meaning, based on the knowledge provided in the A-box (A306) to derive a high-level situation recognition result expressed by the individual subjects given the new meaning.

The context tracker A232 tracks the inference based on the inference history of the context inferor A226.

The context recognizer A234 provides a result of the high level situation inferred by the DL inferred A228 or the rule inferred A230 to the service matcher A238 of the context service provider A236.

<Context service provider>

The context service provider 236 includes a service matcher 238, a synchronizer 240, and an optimizer 242.

When the context service provider 236 receives the high level situation awareness result, the context service provider 236 derives one or more services corresponding to the high level situation awareness result, and the service providing state information provided by the synchronization unit 240 and the Based on the service optimization information provided by the optimizer 242, a device or service module control command for providing the one or more services is generated and provided to the ubiquitous service providing system A112.

The synchronization unit 240 synchronizes the service provision state information of the device or the service module so that the service according to the reception of the high level situation recognition result can be smoothly provided.

The optimizer A242 includes service optimization information that defines an optimal service according to whether the high level situation exists.

Ontology Repository Device

The ontology repository device 116 is comprised of an ontology repository repository 218 and a manager 220.

The ontology repository storage 218 has a context aware ontology, and registers a plurality of instances created corresponding to the event information in the context aware ontology.

Instances recorded in the context-aware ontology represent general instances, derived facts derived from semantic relations between primitive facts and primitive facts obtained from sensors or devices, and semantic extensions to description logic and personal and intelligent contexts. It consists of specific instances.

As shown in FIG. 4, the situation awareness ontology is composed of a human ontology, a device ontology, a space ontology, an action ontology, and a situation ontology. Here, the human ontology defines the characteristics of the person, and the device ontology defines the characteristics of each device, the spatial ontology defines the characteristics of the space, the action ontology is an instance created through the action event To define a basic schema to include, the context ontology is defined as a semantic group through axiom definition to define what the meaning of the situation instance. In particular, the action event is created as an instance due to the action event using has who, has what, has event, haswhere, and has action time.

The manager 220 is in charge of managing the ontology repository repository 218, and the management includes server management, data management, monitoring, and the like.

<Detailed Description of Ontology Repository Device>

Now, the ontology repository device 118 configured as described above will be described in more detail.

Prior to the description of the ontology repository device 118, terms used in the following specification are defined as follows.

Resource Description Framework (RDF) is a language for representing information about resources on the Web. It is a data model that expresses objects ("resources") and relationships between objects, and RDF is a simple semantics for this data model. It provides a simple data model that can be processed by a machine and a simple syntax that can be processed by a computer.

In addition, the RDF triple data is composed of a subject referred to as a subject, a predicate referred to as a predicate, and an object referred to as an object. The subject refers to a resource. Or, expressed as a part of the URI, the predicate represents a specific aspect, property, characteristic relationship for describing the resource (main), the object represents an attribute value or a resource corresponding to the attribute.

OWL (Web Ontology Language) is a semantic markup language designed for sharing and publishing ontology. It is based on DAML + OIL. It provides the ability to express various logical relationships to classes and properties. Propose a range of or provide a vocabulary limiting the number.

The SWRL (Semantic Web Rules Language) is an ontology and web rule language. Unlike the existing rule language, SWRL is a rule language defined as an extension of OWL. Since the OWL is an extension of the OWL document, SWRL rules can be included in the OWL document. Also, since the SWRL is based on RDF, it cannot express a predicate having two or more terms.

SPARQL (SPARQL Protocol and RDF Query Language) is a semantic query language, a query language for querying RDF data, a W3C working draft, and a format similar to existing RDF query languages (RDQL, RQL, and seQL).

<Configuration of Ontology Repository Device>

Now, the configuration of the ontology repository device A116 according to a preferred embodiment of the present invention will be described with reference to FIG. 5.

The ontology repository device A116 includes a repository 100, a client API module 120, a manager 122, and a repository service management module 124.

The repository 100 stores an instance of a triple format (hereinafter, referred to as triple data above) in the store 120, and executes a query process such as finding the stored triple data.

The client API module 120 is responsible for an interface between the instance generator A210, the context analyzer A222, and the ontology repository device A116.

The manager 122 generally controls each part of the ontology repository device A116 of the present invention.

The repository service management module 124 manages the repository service module 104, the index service module 106, the query processor 108, and the conceptual model module 110 included in the repository 100. A task request for registering, finding, and deleting triple data provided through the client API module 120 is scheduled, and a task is requested to the service modules according to the schedule.

The repository 100 includes a plurality of stores 120, each of which is a repository service module 104, an index service module 106, and a query processor. Query Processor 108 is provided, and optionally a Conceptual Model 110 may be provided.

The repository service module 104 stores actual data for triple data and includes node ID information, node data information, node segment information, resource information, lido log information, and namespace name information.

The node ID information, node data information, node segment information, resource information, lido log information, and namespace name information will be described in more detail with reference to FIG.

The node ID information stores node ID data in units of segments. The node ID data includes ID of a subject node, ID of a predicate node, and ID of an object node. And a flag indicating whether to delete or not. The node ID data is collected by a predetermined number of segments, and the segment ID is added to the segment. The segment is collected by a predetermined number and consists of a file. The file includes a file header consisting of the last triple ID, the number of deletions, the number of segments, and the size. The triple ID is reference information for finding a node ID registered in the segment, and the reason for recording only the last triple ID is that triple IDs for the node IDs are sequentially assigned, so that only the last triple ID is desired. This is because the node IDs having can be detected.

The node data information stores node data in segments. The node data includes data of a subject node constituting triple data, data of a predicate node, data of object nodes, and type information. The node data is composed of segments by collecting a predetermined number, and a segment header indicating the current number of segments is added to the segment. The segment is composed of a predetermined number of files, and a file header including the last node ID and the number of segments is added to the file. The node ID is reference information for finding node data registered in the segment, and the reason for recording only the last node ID is that node IDs for the node data are sequentially assigned, so that only the last node ID detects the desired node data. Because you can do it.

The node segment information stores location information of segments stored in the store 102 in a file form. The node segment information file is composed of a predetermined number of segment position information, a file header including an ID of the last segment and a last file position.

The resource information is for managing duplicate resources in order to prevent duplication of node data. The resource information is the content of a key that is adopted by using a B-Tree, and the value is configured as a node ID.

The redo log information is to support the backup logic to store the change information log for the change in the store 102, such as addition or deletion, to be restored later. The redo log information includes a start time, an end time, an added first ID, an added last ID, deleted IDs, and a redo log ID. The redo log information includes a predetermined number of segments. A segment header indicating the number of redo log information is added to the segment. The segment is composed of a predetermined number of redo log files, and the redo log file is appended with a file header consisting of the number per segment and the last ID.

The namespace file is composed of a predetermined number of namespace pairs, and the namespace pair is composed of a URL and prefix data that simplifies the URL. The namespace file is appended with a file header consisting of number and length information.

Meanwhile, the index service module 106 provides index information on triple data stored in the store 102, thereby enabling accurate and fast retrieval of the triple data.

The index service module 106 has index data having an inverse file structure for each of a subject node, a predicate node, and an object node. That is, the index data has a B-Ttree index structure in which the IDs of the nodes are configured with the value VALUE as the key of the data of each node.

As shown in FIG. 7, the index information includes B-Tree index information A1, overflow index information A2, and temporal index information A3.

The B-Tree index information A1 is actually the main structure constituting the index, and the overflow index information A2 stores the remaining part when the triple ID list, which is a value for the key, exceeds the limit of the B-Tree. The temporal index information A3 temporarily stores index information added dynamically.

The B-Tree index information (A1) is a main structure constituting the basic index, the key is the content of each node, the value is composed of triple IDs containing the node. The internal processing process of the B-Tree uses a MRU (Most Recently Used) cache structure to speed up processing of a node's access. The node type supports variable length data and has a maximum size limit for keys and values, respectively. Node information that is not used internally is stored separately in the header to reuse the nodes, and these frozen nodes are treated as a linked list structure. The key part of the leaf node is processed as a generalized form for the various input types as the content of the node. The value part of the leaf node is a list of triple IDs to which the node belongs, and the byte value for the difference between each triple ID is minimized to minimize the size of the triple IDs fixed to a size of 4 bytes (int type). Process by storing only the valid value with the previous zero part removed.

For example, if there are two triple ID 1 and triple ID 10 of int type, they may be processed as follows.

-2 ID difference calculation: 10-1 = 9

-Convert ID difference to byte: 0x0000000000001001 (4 byte)

-Save valid value by removing the part treated as 0: Only save Ox1001 (1 byte)

When the length of the value portion of the leaf node exceeds the limit length, a part of the leaf node is stored in the overflow index information A2 and the information about the leaf node is processed as a linked list structure.

The overflow index information A2 is to be stored separately when the size of the triple ID list, which is the value portion of the B-Tree index information, is larger than the limit size. It is composed of structure and processed by fixed size block unit. Also, internally, the MRU (Most Recently Used) cache structure is used to increase the processing speed of the block access. And blocks for values of the same value are treated as a linked list structure.

The temporal index information A3 temporarily stores index data that is dynamically added. This temporal index portion exists only in memory and is temporarily stored in the temporal index information A3 instead of being directly added to the B-Tree index information A1 to reduce the overhead of the index service module 106. In order to manage the hash structure.

The query processor 108 parses and processes a query provided from a client through a client API module 120. When a command for a search is input, the query processor 108 performs the corresponding query through the index service module 16 according to the command. Triple ID is extracted, and triple data corresponding to the triple ID is obtained from the repository service module 104 and returned to the client API module 22.

Now, the operation of each component of the repository system according to the preferred embodiment of the present invention described above will be described in more detail.

<Repository Service Module>

Repository Service Module-Processing New Triple Data

A process of processing triple data according to an exemplary embodiment of the present invention to add new triple data to the triple store 100 during operation of the repository service module 104 will now be described with reference to FIG. 8.

When the triple data is input (step 200), the repository service module 104 extracts each node of the triple data, that is, a subject node, a predicate node, and an object node (step 202). Here, the triple data is composed of a subject node, a predicate node, and an object node, and each node includes data. In addition, since the data of the subject and the predicate node are path information or resources such as URL, they may be identical to other triple data. Accordingly, the present invention checks whether the value is already stored in the node data for the subject node and the predicate node (step 204).

If the value of the subject or predicate node is already stored (step 206), the repository service module 104 reads IDs of the already stored subject node and predicate node from ID data (step 208).

On the other hand, the values of the subject node and the predicate node are not stored (step 206) or for the object node, the repository service module 104 stores the values and resources of the node in the node data (step 210). In the case of storing the node data, a namespace is applied to replace the node data with simplified data.

The repository service module 104 then generates a node ID for the node (step 212).

As a result, an ID for each of the subject node, the predicate node, and the object node of the input triple data is obtained (step 214).

The repository service module 104 stores IDs of each of the subject node, the predicate node, and the object node of the triple data in node ID information (step 216).

Thereafter, the repository service module 104 generates a triple ID, generates the triple ID, and outputs the triple ID to the index service module 106 (steps 218 and 220).

<Repository Service Module-Find Triple Data>

Now, a process of outputting triple data stored in the repository according to the triple data ID provided by the index service module 106 during the operation of the repository service module 104 will be described in detail with reference to FIG. 9.

When the repository service module 104 is provided with the triple ID from the index service module 106 according to the occurrence of the triple data search request, the repository service module 104 searches for the node ID corresponding to the triple ID in the node ID information (step 300 and 302).

When the node ID corresponding to the triple ID in the node ID information, that is, the subject node ID, the predicate node ID, and the object node ID of the triple data to be searched for is obtained (step 304), the repository service module 104 determines the node. In operation 306 and 310, data is obtained from node data information including node data corresponding to the node ID.

The obtained node data is restored to original node data by reversely applying the namespace (step 312), and triple data having a triple form is formed using the restored data, and the triple data is returned (step 314).

<Index service module>

In the case where new triple data is added to the repository 100 by the operation of the index service module 106 of the present invention, the process of reflecting the index information and the process of finding the ID of the triple data using the index information will be described.

Index Service Module-Processing New Triple Data

First, a process of generating index information will be described with reference to FIG. 10.

When the triple data and triple ID are input (step 400), the index service module 106 performs inverted conversion on the triple data (step 402, 404). The invert converting converts triple data and triple IDs consisting of subject node data, pretty node data, and object node data into subject node data, triple ID, predicate node data, triple ID, object node data, and triple ID. will be.

Each of the inverted converting results is normalized according to the preferred embodiment of the present invention, and the normalization follows the rules shown in the table shown in FIG. 11 (step 406). Here, the normalized completed subject node data and triple ID are subject index data, and the normalized completed predicate node data and triple ID become predicate index data, and the normalized completed object node data and triple The ID becomes the object index data.

The index service module 106 temporarily stores the subject index data, the predicate index data, and the object index data in a storage area of temporal index information (step 408).

When the storage area of the temporal index information becomes full (step 410), the index service module 106 may delete the subject index data, the predicate index data, and the object index data stored in the storage area of the temporal index information. It is registered in the B-Tree index information (step 412).

A process of registering the subject index data, the predicate index data, and the object index data with the B-Tree index information will be described in detail with reference to FIG. 12.

When the index service module 106 is loaded with temporal index information (step 500), the B-Tree according to the preferred embodiment of the present invention until the index data is no longer stored in the temporal index information storage area. The index information registration process (steps 508 to 518) is repeated (step 502).

The index service module 106 loads any index data from the temporal index information and adds the loaded index data to the B-Tree index information (steps 506 and 508).

When the prescribed size of the B-Tree index information is exceeded according to the addition of the index data, that is, when the B-Tree index information storage area becomes full (step 510), the overflow index data In operation 512, the overflow index data is added to the overflow index information in operation 514. Thereafter, the index service module 16 assigns the overflow ID, and records the information linking the overflow ID and the corresponding index data of the B-Tree index information in the B-Tree index information (steps 516 and 518).

The process of registering B-Tree index information (steps 508 to 518) is repeated until the index data is no longer stored in the temporal index information storage area, and the index data stored in the temporal index information storage area is repeated. When the processing is completed, the temporal index information storage area is cleared and ends (step 504).

<Index Service Module-Triple ID Detection>

A triple ID detection process for searching for triple data during the operation of the index service module 106 will be described in detail with reference to FIG. 13.

When the index service module 106 receives a triple ID find command such as a graph pattern among SPARQLs from the query processor 108, the SPARQL provides some or all of the data of the subject node to find the triple ID. In order to check whether the triple ID is provided by providing some or all of the data of the predicate node, or searching the triple ID by providing some or all of the data of the object node (step 600).

When the index service module 106 provides data of the subject node to provide the SPARQL for finding the triple ID, the index service module 106 performs normalization according to FIG. 7 with respect to the search word, and outputs the normalized result from the subject index information. The index data having the key is extracted to obtain a triple ID for the triple data requested to be searched (steps 602 to 606). In the present invention, the object ID that is overlaid due to the characteristics of the B-Tree structure is divided into overflow index value information and stored temporarily in temporal index information when it does not become a predetermined number. Extract index data having the content of the subject node among tree index information, overflow index value information, and temporal index information, merge the index data, and extract a triple ID set registered as a value in the index information. (Step 608).

When the index service module 106 provides data of a predicate node to provide a SPARQL for finding an RDF triple ID, the index service module 106 performs normalization of the search word and uses the normalized result as a key in the predicate index information. The index data having the same is extracted, and a triple ID for the triple data requested to be found is obtained (steps 610 to 614). In particular, the index service module 106 extracts index data having contents of the predicate node among B-Tree index information, overflow index value information, and temporal index information constituting the predicate index information. The index data is merged, and a triple ID set registered as a value in the index information is extracted (step 616).

When the index service module 106 provides data of an object node and provides a SPARQL for finding a triple ID, the index service module 106 performs normalization on the search word and an index having the normalized result as a key in predicate index information. Extract the data (steps 618 and 620). In particular, the index service module 106 extracts index data having the content of the predicate node among B-Tree index information, overflow index value information, and temporal index information constituting object index information, and extracts the index data. In operation 624, the triple ID set registered as a value in the index information is merged.

In this case, the SPARQL may be a command for inputting a part or all of data for a plurality of nodes with respect to triple data to instruct the search of an RDF triple ID. Thus, the index service module 106 may include the subject index information and the predicate index. End operation is performed on the triple ID sets found from one or more of the information and the object index information to generate the final triple ID set (steps 626 and 628).

<Query processor>

The operation of the query processor 108 among the components of the present invention will be described in more detail with reference to FIG. 14.

The query processor 108 includes a client API module 120, a query parse module 700, a SPARQL parse module 702, and a SPARQL processor module 704.

The client API module 100 provides a query to the repository 100 from a real web server or a general application.

The query parse module 700 parses the request from the client and extracts and processes server information, triple repository name, additional information, and SPARQL.

The SPARQL parse module 702 parses SPARQL, which is an actual query part, and converts the SPARQL into a form that can be processed internally. In this case, the SPARQL is a query language for RDF, and is about RECOMMENDATION of W3C. Here, if an error occurs during the parsing, the SPARQL parse module 702 stops the parsing and reports the cause of the error to the client.

The SPARQL process module 704 generates an actual query result having an internal processing form that is a parsing result provided by the SPARQL parse module 702, and is implemented through ARQ. The ARQ is an open source that implements parsing and processing of SPARQL as a SPARQL processor. In addition, the SPARQL process module 704 is preferably implemented to be optimized (OPTIMIZE) with reference to the ARQ.

Now, the operation of the repository system according to the preferred embodiment of the present invention will be described by dividing the process of registering new triple data into the repository and the process of searching for triple data registered in the repository.

<Triple data registration process>

First, a process of registering new triple data in the repository 100 will be described in detail with reference to FIG. 15.

The manager 122 of the repository system stores triple data provided through the client API module 120 in a predefined storage area in the form of a file.

The repository 100 loads a file from the predefined storage area to check whether the file is readable, parses the file if the file is readable, and stores triple data in the parsed file. It is checked whether there exists, and whether the triple data is valid (steps 802 to 810). That is, it is checked whether there is valid triple data corresponding to the triple data format in the predefined storage area.

If there is the triple data, the repository 100 generates a triple object for registering the triple data and executes the triple object (steps 812 and 814). The triple object stores the triple data in a predetermined temporary storage area in step 816.

When the temporary storage area becomes full (step 818), the triple object loads the temporarily stored triple set (step 824) and registers the triple data in the repository 100 through the repository service module 104 (step 826). ). Here, since the repository registration process through the repository service module 104 has already been described above, a description thereof will be omitted.

In addition, after registering the triple data in the repository 100, the triple object reflects the index data for the triple data in the index information through the index service module 106 (step 828). Here, since the index data registration process through the index service module 106 has been described above, a description thereof will be omitted.

The process of registering the triple data in the repository 100 and registering the index data thereof in the index information is repeated until the triple data stored in the temporary storage area is exhausted.

In addition, the process of adding triple data by storing triple data in the temporary storage area is performed until processing of triple data existing in the file is completed, and when processing of triple data existing in the file is completed, The repository service module 122 adds redo log data for processing the triple data to the repository 100 (step 830).

<Query processing>

Now, a process of processing a query for the repository 100 will be described in detail with reference to FIG. 16.

The manager 122 provides the SPARQL query to the query processor 108 when a SPARQL query is input from the client through the client API module 120.

The query processor 108 parses the SPARQL query to check whether the query is a valid query (steps 900 to 904).

If the query is a valid query, the query processor 108 performs a process corresponding to the query by using ARQ (step 906.908), generates a result according to the process, and returns the result to the client (step 910, 912). ).

<Triple data search process>

Here, a process according to a graph pattern, that is, a request for finding triple data, in the query processing process will be described in detail with reference to FIG. 17.

When the graph pattern is provided in the query (step 1000), the query processor 108 receives a part or all of data about one or more of a subject, predicate, and object node included in the graph pattern (step 1002). .

A triple ID set corresponding to a part or all of data of one or more of the subject, predicate, and object node is obtained through the index service module 106 (steps 1004 and 1006). Here, since the triple ID set acquisition process through the index service module 106 has been described in detail with reference to FIG. 9, description thereof will be omitted.

When the triple ID set is obtained, the query processor 108 finds and acquires triple data for each triple ID included in the triple ID set through the repository service module 104 to construct a triple data set, and generates the triple data set. Return the data set to the client (steps 1008-1020).

1 is a block diagram of a ubiquitous service system according to a preferred embodiment of the present invention.

FIG. 2 is a detailed configuration diagram of each part of FIG. 1. FIG.

3 is a T detail configuration diagram of the DL reasoner.

4 is a view showing an ontology configuration example according to a preferred embodiment of the present invention.

5 is a configuration diagram of a repository system according to a preferred embodiment of the present invention;

6 and 7 are repository information structure diagrams in accordance with a preferred embodiment of the present invention.

8 to 10 and 12 to 17 are process flowcharts for each part of the repository system.

11 illustrates a generalization rule in accordance with a preferred embodiment of the present invention.

Claims (20)

In the ubiquitous service system, A sensor group configured to sense various states and include a plurality of sensors generating event information according to a sensing result; A device group including a plurality of devices configured to perform various operations, generate event information according to an operation state, and perform an operation according to a control command received from the outside; A ubiquitous service group provided with a plurality of service modules for implementing a ubiquitous service when a control command is received from the outside; An interface device for interfacing with a plurality of sensors of the sensor group and a plurality of devices of the device group; An ontology repository device having an ontology for situation recognition and storing one or more instances representing the event information; Receiving the event information through the interface device to implement a low-level situation recognition, combines the low-level situation recognition result and the event information to generate one or more instances meeting the ontology schema, and the one or more instances Store in the ontology repository device, request the processing of the situation recognition information to the outside, A ubiquitous service support device cooperation system that transmits the control command to the service module or the device when the control command is received from at least one service module or at least one device; According to the request for processing the situation awareness information, at least one instance corresponding to the request for processing the situation awareness information is read from the ontology repository repository, and the at least one read instance is compared with a predetermined knowledge base to compare a high level situation. Fulfilling cognition, Determining at least one service corresponding to the high level situation recognition result, generating a control command for at least one service module or at least one device for providing the determined at least one service, and providing the same to the ubiquitous service supporting device collaboration system; Intelligent information linkage and operation system based on context information; Including; The ubiquitous service support device collaboration system includes a situation-aware collaboration system that receives the event information and generates one or more instances. The situation recognition collaboration system, Receiving the event information in the form of a stream and classifying according to predetermined filter information, and transitions from the classified event information to a low-level situation according to the low-level situation or determination information, and the result and the classified A context profiler that combines event information to generate contextual information; And an instance generator for processing the context awareness information into one or more instances having a triple format and storing the one or more instances in an ontology repository device. delete The method of claim 1, The contextual information based intelligent service connection and operation system, In accordance with the situation information processing request is provided with a situation information processing system for performing a high level situation whether the corresponding service is determined, The situation information processing system, Read at least one instance according to the context information processing request from the ontology repository device, Infer a high level situation from the one or more instances by using a knowledge base equipped with a plurality of knowledge information defined as a high level situation after combining a plurality of individual objects to give meaning. A context analyzer that infers a high level situation from the one or more instances according to a predefined simplified rule; Ubiquitous service system, characterized in that configured as a context service provider for determining a ubiquitous service corresponding to the high-level situation recognition result. The method of claim 3, The context analyzer, A context tracker that stores the high level situation reasoning history and implements tracking in accordance with the stored history; Ubiquitous service system characterized in that it further comprises. The method of claim 3, The context service provider, By synchronizing service provision status information with a service module and device providing the ubiquitous service, A synchronization unit for determining a ubiquitous service that can be actually provided according to the high level situation recognition result; Ubiquitous service system characterized in that it further comprises. The method of claim 1, The ontology repository device, A client API module for providing an interface with a client; When a request for registration of an instance, which is a triple data structure consisting of a subject node, a predicate node, and an object node, is requested through the client API module, a triple ID is assigned to the instance, and nodes constituting the instance are extracted. Assigns node IDs for the nodes, stores node data for the nodes in node data information corresponding to the first reference information including the node IDs, and includes node IDs and the triple IDs for the nodes. Register the instance by storing the information in the node ID information corresponding to the second reference information  When a search for an instance including a triple ID is requested, node IDs corresponding to the triple ID are searched using the second reference information, and node data corresponding to the node IDs are searched using the first reference information. A repository including a repository service module that reads and combines the read node data and returns as an instance; Ubiquitous service system comprising a. The method of claim 6, The repository is The triple ID and the instance are provided from the repository service module, and the index data for each node is generated by inverting the triple ID with a data key as a value for each node of the context information and generating the index data B-. Register in Tree index information, When an instance find command is input for one or more of the nodes of the instance, the search term including a search word composed of all or part of the node data is input. When the instance find command is input, the search word included in the instance find command is included. Index service module for retrieving index data from the B-Tree index information and providing the triple ID included in the retrieved index data to the repository service module. Ubiquitous service system characterized in that it further comprises. The method of claim 6, Namespace information for storing node data and prefix data in association with each other is added to the repository. The repository service module converts and stores the node data into prefix data according to the namespace information at the time of registration of the node data, The ubiquitous service system, characterized in that for retrieving the node data, restores node data converted to prefix data to original node data. The method of claim 6, And a plurality of the node data information and the node ID information form a segment, and the first and second reference information are added and stored in units of segments. The method of claim 6, The repository service module temporarily stores the triple data requested for registration, and if more than a predetermined number, the repository service module performs the registration of the repository. The method of claim 7, wherein The index service module, In addition to storing node data in excess of the limit size of the B-Tree index information in the overflow index information, The ubiquitous service system, characterized in that the connection information to the overflow index information is added to the B-Tree index information. The method of claim 7, wherein The index service module, The ubiquitous service system, characterized in that after receiving the triple ID and the triple data from the repository service module and temporarily storing the triple ID and the triple data, and registers in the B-Tree index information when a predetermined number or more. The method of claim 7, wherein The index service module, Generalizing and storing the node data according to a predetermined generalization rule, When the triple data search command including the search word is input, the search term is generalized according to the generalization rule, and the search is performed on the B-Tree index information with respect to the generalized search term. The method of claim 6, A repository service management module that performs scheduling for an input repository work request through the client API module; A manager for managing the client API module, the repository service management module, and the repository Ubiquitous service system characterized in that it further comprises. In the data processing method for a ubiquitous service system, A first step of receiving event information according to a sensing result of sensing various states from at least one sensor of a sensor group including a plurality of sensors; A second step of receiving event information according to an operation state from any one or more devices in the device group including a plurality of devices; Receive the event information and implement the low level situation recognition based on the low level situation determination information, and combines the low level situation recognition result and the event information to create one or more instances having a triple data structure conforming to the ontology schema Storing the at least one instance in the ontology repository device and requesting processing of the situation awareness information; According to the request for processing the situational awareness information, one or more instances corresponding to the request for processing the situational awareness information are read from the ontology repository device, and the inferred one or more instances are deduced based on a predetermined knowledge base and have a high level. Fulfill the situation, Determine one or more services corresponding to the high level situation recognition result, and generate a control command for one or more service modules or one or more devices for providing the determined one or more services to the one or more service modules or one or more devices. Providing a fourth step; The third step, Receiving the event information in the form of a stream and classifying according to predetermined filter information, and transitions from the classified event information to a low-level situation according to the low-level situation or determination information, and the result and the classified A preprocessing step of generating event awareness information by combining event information; And an instance generation step of processing the situation awareness information into one or more instances having a triple format and storing the one or more instances in an ontology repository device. delete The method of claim 15, The fourth step, Read one or more instances according to the request for processing the situation awareness information from the ontology repository device, Infer a high level situation from the one or more instances by using a knowledge base equipped with a plurality of knowledge information defined as a high level situation after combining a plurality of individual objects to give meaning. An inference step of inferring a high level situation from the one or more instances according to a predefined simplified rule; And determining a ubiquitous service corresponding to the high level situation recognition result. The method of claim 15, When a repository service module of the ontology repository device is requested to register an instance through a client API module, it gives a triple ID to the instance, extracts nodes constituting the instance, and gives a node ID to each node. And store node data for the nodes in node data information in correspondence with the first reference information including the node IDs, and correspond to node reference information for the nodes and second reference information including the triple ID. Storing the node ID information so as to register the instance; When the repository service module is requested to find an instance including a triple ID, the node service module searches for node IDs corresponding to the triple ID using the second reference information, and uses the first reference information to search for the node IDs. Reading node data corresponding to and combining the read node data into an instance; Data processing method of the ubiquitous service system comprising a. The method of claim 18, The index service module of the ontology repository device receives the triple ID and the triple data from the repository service module, inverts the triple ID into a data key for each of the nodes of the triple data, and inverts the triple ID into a value. Generating index data and registering the index data with B-Tree index information; If the index service module receives a triple data search command including a search word composed of part or all of node data for one or more of the nodes of the triple data, the triple data search command is input, and the triple Searching for index data including a search word included in a data search command in the B-Tree index information, and providing a triple ID included in the searched index data to the repository service module. Data processing method of the ubiquitous service system, characterized in that it further comprises. The method of claim 18, The ontology repository device is added with name space information for storing node data and prefix data in association with each other. The repository service module converts and stores the node data into prefix data according to the namespace information at the time of registration of the node data, And the node data, which has been converted to prefix data, is restored to the original node data when the node data search request is made.

Images