diff --git a/oneM2M_Base_Ontology-V_0_5_0.owl b/oneM2M_Base_Ontology-V_0_5_0.owl deleted file mode 100644 index 4d982008841dbbde0022302e52b4d5389d300f3b..0000000000000000000000000000000000000000 --- a/oneM2M_Base_Ontology-V_0_5_0.owl +++ /dev/null @@ -1,150 +0,0 @@ -Prefix(:=) -Prefix(owl:=) -Prefix(rdf:=) -Prefix(xml:=) -Prefix(xsd:=) -Prefix(rdfs:=) - - -Ontology( - - -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(Class()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(ObjectProperty()) -Declaration(DataProperty()) -Declaration(DataProperty()) -Declaration(DataProperty()) -Declaration(DataProperty()) -SubClassOf( ) -AnnotationAssertion(rdfs:comment "A Device is a object designed to accomplish a particular task. -In the context of oneM2M a Device is always assumed to be capable of communicating electronically via a network (oneM2M or interworked non-oneM2M network). -In order to accomplish its task, the device performs one or more functions. These functions are represented in the network as Services that are exposed / offered by the Device. -A Device contains some logic and is producer and/or consumer of data that are exchanged via its Services with other entities (Devices, Things) in the network -- A Device must offer at least one Service or interface: \"offers min 1 (Service or Interface)\" -- A Device may only be composed of several (sub-) Devices: \"consistsOf only Device\"") -SubClassOf( ) -SubClassOf( ObjectAllValuesFrom( )) -SubClassOf( ObjectMinCardinality(1 )) -SubClassOf( ObjectMinCardinality(1 )) -AnnotationAssertion(owl:priorVersion "A Function (Class: Function) represents the functionality necessary to accomplish the task for which a Device is designed. A device can be designed to perform more than one function. -Note, the Class: Function exhibits the – human understandable – meaning what the device “does”. -E.g. considering a subclass “LightSwitch” of (Class: Device) then a related subclass of (Class: Function) could be “Turn_Light_On_or_Off”. -Similarly, considering a subclass “Watervalve” of (Class: Device) a subclass of (Class: Function) could be “Open_or_Close_Valve”.") -SubClassOf( ) -SubClassOf( ) -AnnotationAssertion(rdfs:comment "An Operation provides the capability to - (a) influence a Function (e.g. \"Turn Waterflow Off\" or - (b) receive information from a Function, e.g. \"Room Temperature is 21 degrees Celsius\" -NOTE: in SAREF \"Operation\" is called \"Command\" and is only used in the sense of (a)") -SubClassOf( ObjectMinCardinality(1 )) -AnnotationAssertion(rdfs:comment "A service is a representation of a function to a network that makes the function discoverable, registerable, remotely controllable in the network. A service can represent one or more functions. A Service is offered by a device that wants (a certain set of) its function(s) to be discoverable, registerable, remotely controllable by other devices in the network. -Every Service represents at least one Function. -=> \"represents min 1 Function\" -A Service may be composed of several (sub-) Service [aka: building blocks]: -=> \"consistsOf only Service\" -Every Service can be identified -=> \"hasNameID exactly 1 Literal\" - -While several kinds of devices may support the same Function (e.g. the basic function that temperature sensors support is \"provide temperature\") the Services - and their interfaces - that represent this function may be different. Since services are specific to the network over which they are offered, services will depend on the technology (e.g. Area Network technology) that is used by the Device for communication.") -SubClassOf( ObjectMinCardinality(1 )) -AnnotationAssertion(rdfs:comment "A Thing is an entity that can be identified in the oneM2M System. A Thing may have ThingProperties that can be described by data in the oneM2M System.") -SubClassOf( ObjectAllValuesFrom( )) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -AnnotationAssertion(rdfs:comment "ObjectPropery \"consistsOf\" indicates an exclusive recurrence relation: -a device only consists of (sub-) devices - => Subclass Device consistsOf only Device -a service only consists of (sub-) services - => Subclass Service consistsOf only Service") -ObjectPropertyDomain( ObjectUnionOf( )) -ObjectPropertyRange( ) -InverseObjectProperties( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -InverseObjectProperties( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -ObjectPropertyDomain( ) -ObjectPropertyRange( ) -AnnotationAssertion(rdfs:comment "Identification of a communication protocol (e.g. ZigBee_1_0)") -DataPropertyDomain( ) -AnnotationAssertion(rdfs:comment "Identification of the physical properties of a Area Network technology (e.g. IEEE_802_15_4_2003_2_4GHz).") -DataPropertyDomain( ) -AnnotationAssertion(rdfs:comment "Identification of a profile (e.g. ZigBee_HA) of a Area Network technology.") -DataPropertyDomain( ) -DataPropertyDomain( ObjectUnionOf( )) -) \ No newline at end of file diff --git a/oneM2M_Base_Ontology-V_0_6_0.owl b/oneM2M_Base_Ontology-V_0_6_0.owl deleted file mode 100644 index 9c08ab84f8d20ed81f8d1db2946a629359635d71..0000000000000000000000000000000000000000 --- a/oneM2M_Base_Ontology-V_0_6_0.owl +++ /dev/null @@ -1,717 +0,0 @@ - - - - - - - -]> - - - - - - - - - - - - - - - - - - An Aspect of a Thing-Value or Input/Output of an Operation can have MetaData (like units, precision-ranges …). - - - - - - - - - - A Value of a Thing can concern a certain Aspect (a quality or kind). -e.g. an indoor temperature concerns the Aspect “Temperature” that could be measured by a temperature sensor - - - - - - - - - - A Device can consist of (i.e. be composed) of several (sub-) Devices - - - - - - - - An Input- or Output variable of an Opertation describe an Aspect (a quality or kind) - - - - - - - - - - - - - - - - - A –machine interpretable- Operation exposes a –human understandable- Command to a network - - - - - - - - - - A Service exposes a Functionality to the network and makes it discoverable, registerable and remotely controllable in the network - - - - - - - - - - A Functionality of a Device can be influenced / observed by a human user through the Commands that this Functionality has and that are offered to the user - - - - - - - - - - In order to accomplish its task, a Device performs one or more Functionalities - - - - - - - - An Operation of a Service of the Device or a Command of a Functionality of the Device can have Input data. - - - - - - - - - - - - - - - - - The Input of an Operation has a Target that describes a destination (e.g. a URL) where the Input values are to be stored - - - - - - - - - - A Value of a Thing can have MetaData (like units, precision-ranges …). - - - - - - - - - - Each Operation needs to have a Method that describes the way (e.g. RESTful or RPC based, subscribed, event based, polled, pushed..) how data input/output is offered by that Operation of the Device and/or InterworkedDevice - - - - - - - - - - A Service communicates by means of Operations over the network to transmit data to/from other devices - - - - - - - - An Operation may have an OperationState that is exposed - - - - - - - - - - The OperationState of an Operation has a Target that describes a destination (e.g. a URL) where the OperationState values are to be stored - - - - - - - - - - An Operation of a Service of the Device or a Command of a Functionality of the Device can have Output data. - - - - - - - - - - - - - - - - - The Output of an Operation has a Target that describes a destination (e.g. a URL) where the Output values are to be stored - - - - - - - - - - The Functionalities of a Device are exposed in the network as Services of the Device - - - - - - - - A Service may be composed of smaller, independent (sub)Services, e.g. re-usable servicemodules - - - - - - - - - - The Operation has a Target that describes a destination (e.g. a URL) where the data of the Operation are to be stored - - - - - - - - - - A Thing may have properties that can be described by Values - - - - - - - - - - A Thing may have relations to itself or to other Things (e-g. a Thing "Room" could have a relation "has_Door" with a Thing "Door") - - - - - - - - An AreaNetwork can be controlled by an Interworked Device though the IPE. - - - - - - - - - - A –human understandable- Command is exposed by an Operation to the network - - - - - - - - - - - A –human understandable- Functionality of a Device is exposed by a Service to the network - - - - - - - - - - - An InterworkedDevice constitutes a part of an AreaNetwork - - - - - - - - - - A Functionality of a Device can refer to a certain Aspect (a quality or kind) that is measured or controlled by that Functionality. -e.g. a temperature sensor would refer to the Aspect “Temperature” that it measures - - - - - - - - - - - - - - - This Data Property specifies the data type and –range for Input, Output, Value and OperationState - - - - - - - - - - - - - - - - - - Identification of a communication protocol (e.g. ZigBee_1_0) - - - - - - - - - - Identification of the physical properties of a Area Network technology (e.g. IEEE_802_15_4_2003_2_4GHz). - - - - - - - - - - Identification of a profile (e.g. ZigBee_HA) of a Area Network technology. - - - - - - - - - - - - - - - An AreaNetwork (Class: AreaNetwork) is a Network that provides data transport services between an Interworked Device and the oneM2M System. Different area Networks can use heterogeneous network technologies that may or may not support IP access - - - - - - - - An Aspect (Class: Aspect) describes the real-world aspect that a functionality or a property of a thing relates to. Aspect is also used to describe a the quality or kind of an Input- or Output variable of an Opertation refers to. -The Aspect could be a (physical or non-physical) entity or it could be a quality. - - - - - - - - - CRUDNMethod (Class: CRUDNMethod) is the method how data input/output is offered by the AE (or proxied device) in the oneM2M Sytem (.e. one of CREATE, RETRIEVE, UPDATE, DELETE, NOTIFY) - - - - - - - - - - - - - - - - - - - - A Command (Class: Command) represents an action that can be performed to support the Functionality. A Command is the –human understandable- action that is invoked in a device or is reported by the device. A Command is exposed by an Operation to the network. Input and Output of the related Operation can parameterize the command. -e.g. the Functionality “dimming-functionality” of a light switch that remotely controls a light could have a Command “setLightIntensity”, with a parameter that has values 0 – 100 %. - - - - - - - - - A ControllingFunctionality (Class: ControllingFunctionality) represents a functionality that has impacts on the real world, but does not gather data. In general a ControllingFunctionality has Commands (and/or Operations of its related Services) that receives Input data -E.g. a thermostat would have “temperature-adjustment” as a ControllingFunctionality - - - - - - - - - - - - - - - - - - - 1 - - - - - - - 1 - - - A Device (Class: Device) is a object designed to accomplish a particular task. A Device contains some logic and is producer and/or consumer of data that are exchanged via its Services with other oneM2M entities (Devices, Things) in the network. A Device may be a physical or non-physical entity. -In the context of oneM2M a Device is always assumed to be capable of communicating electronically via a network. - - In order to accomplish its task, the device performs one or more functionalities - - These functionalities are exposed in the network as Services of the Device. - - A Device can be composed of several (sub-) Devices - - Each Device (including sub-Devices) needs to be individually addressable in the network. - - - - - - - - A Functionality (Class: Functionality) represents the functionality necessary to accomplish the task for which a Device is designed. A device can be designed to perform more than one functionality. -The functionality exhibits the – human understandable – meaning what the device “does”. -A Functionality refers to (e.g. observes or influences) some real-world aspect(s), that can be modelled as a Class: Aspect. -E.g. considering a “light switch” then a related Functionality could be “Controlling_ON_OFF” or “Controlling Brightness”. These functionalities would refer to an Aspect “light-control”. - -A Functionality of a Device can be influenced / observed by a human user through the Commands that this Functionality has and that are offered to the user - - - - - - - - - - - 1 - - - Input (Class: Input) describes the type of input of an Operation of a Service of the Device. Input also describes the type of input of an Command of a Functionality of the Device. -NOTE: The Input of a Command may differ from the Input to its exposed Operation. -E.g. while the Input to a “setLightIntensity” Command may take values 0 – 100 % the corresponding Input values for the related Operation may be restricted to integers 0 – 63. -An application (e.g. AE) that implements a human-machine interface for invoking the Operation needs to take care of such differences. - - The Input class shall represent all possible values for that input (data types and -ranges). - - An Operation/Command may have multiple Inputs and/or Outputs. If an instance of an Operation is invoked then the input value to that Operation shall be an instance of its Input class -(e.g, instances “ON” or “OFF” for an Input class consisting of the enumeration {“ON”,“OFF”} that sets the state of a switch or a real number within a certain range for a “Temperature” Input class for a thermostat.) - - The Input has a Target (via Object Property: “hasInputTarget”) that describes a destination (e.g. a URL) where the Input values are to be stored. - - The Input describes an Aspect (e.g. a desired state like “ON” or “OFF” or a temperature to be set). - - - - - - - - - An InterworkedDevice (Class: InterworkedDevice) is a Device – e.g. in an Area Network – that does not support oneM2M interfaces and can only be accessed from the oneM2M System by communicating with a “proxied” (virtual) device that has been created by an Interworking Proxy Entity - - - - - - - - - InterworkedMethod (Class: InterworkedMethod) is the method of the offered by a InterworkedDevice in an interworked, non-oneM2M technology - - - - - - - - - InterworkedTarget (Class: InterworkedTarget) is the target of data in the interworked, non-oneM2M technology - - - - - - - - - A MeasuringFunctionality (Class: MeasuringFunctionality) represents a functionality that has no impacts on the real world, but only gathers data. In general a MeasuringFunctionality has Commands (and/or Operations of its related Services) that generate Output data -E.g. a temperature sensor would have “temperature-sensing” as a MeasuringFunctionality - - - - - - - - MetaData (Class: MetaData) contain data (like units, precision-ranges …) about the Values of a Thing or about an Aspect. -E.g. the indoor temperature could have meta data: “Degrees Celsius”. - - -... Editor's Note: NEED TO BE RENAMED - - - - - - - - A Method (Class: Method) describes the way (e.g. RESTful or RPC based, subscribed, event based, polled, pushed..) how data input/output is offered by an Operation of the Device and/or InterworkedDevice. -Since the method how an operation is offered by a oneM2M Device (or a proxied device in the oneM2M Sytem) will differ from the method how an operation is offered by a InterworkedDevice in an interworked technology two sub-classes of class “Method” are defined in the base ontology: -“CRUDNMethod” and “InterworkedMethod” to emphasize that while the method in oneM2M will always be one of CREATE, RETRIEVE, UPDATE, DELETE, NOTIFY the method of the data in the interworked, non-oneM2M technology may e.g. be a certain, operation specific value at a defined position in a byte string that is sent via a technology specific protocol to the interworked, non-oneM2M device - - - - - - - - - OneM2MTarget (Class: OneM2MTarget) is the target of data (i.e. a oneM2M Resource) in the oneM2M System - - - - - - - - - - - - - - - - - - - - - - - - - - OperationState (Class: OperationState) describes the current state of an Operation. The OperationState class represents all possible values for that state (enumerated individuals). The OperationState is set during the progress of the operation by the CSE and, optionally, the entity that is the target of the operation, e.g. a device (or for interworked devices by the IPE). - - The OperationState has a Target (via Object Property: “has OperationStateTarget”) that describes a destination (e.g. a URL) where the OperationState values are stored - - -Editors Note: Standardized operation states are FFS: States could e.g describe "Operation_Initiated" (initiating entity has UPDATEd <operation> input data), "Operation_Input_transmitted" (CSE has transmitted input data to AE), "Operation_Executing"(IPE has transmitted input data to InterworkedDevice), "Operation_Output_created" (CSE has received output data from AE), "Operation_Ended" (provided by CSE if no output is expected or upon a time-out of the operation or provided by AE, e.g. after sending last output) - - - - - - - - - - - 1 - - - - - - - - - - - - - 1 - - - Output (Class: Output) describes the type of output of an Operation of a Service of the Device. Output also describes the type of output of an Command of a Functionality of the Device. -NOTE: The Output of a Command may differ from the Output to its exposed Operation. -E.g. while the Output of a “currentLightIntensity” Command may take values 0 – 100 % the corresponding Output values for the related Operation may be restricted to integers 0 – 63. -An application (e.g. AE) that implements a human-machine interface for presenting the Output of the Operation to the human user needs to take care of such differences. - - The Output class shall represent all possible values for that output (data types and -ranges). - - An Operation/Command may have multiple Outputs and/or Outputs. The the output value of an instance of an Operation shall be an instance of the Operation’s Output class -(e.g, instances “ON” or “OFF” for an Output class consisting of the enumeration {“ON”,“OFF”} that shows the state of a switch or a real number within a certain range for a “Temperature” Output class for a temperature sensor.) - - The Output has a Target (via Object Property: “hasOutputTarget”) that describes a destination (e.g. a URL) where the Output values are to be stored. - - The Output describes an Aspect (e.g. the state of a light switch like “ON” or “OFF” or a measured temperature). - - - - - - - - - - - - 1 - - - A Service (Class: Service) is a representation of a Functionality in a network. The Service exposes the Functionality to the network and makes it discoverable, registerable and remotely controllable in the network. -A Service is offered by a device that wants (a certain set of) its Functionalities to be discoverable, registerable, remotely controllable by other devices in the network. -A Service can expose one or more Functionalities and a Functionality can be exposed by one or more Services. -NOTE: While a Functionality describes the – human understandable – meaning of a functionality of the device the Service is used to describe how such functionality is represented in a communication network and can be accessed by electronic means. The Service and its Operations is therefore dependent on the technology of the network, hard- and software of the device. -E.g. the Functionality: “turn_light_On_or_Off” could be exposed in the network by a Service “UPDATE Binary Value”. - - Object Property “hasSubService” is expresses the fact that Services can be composed of independent (sub)Services. -E.g. a Service could thus be composed out of multiple (reusable) service modules. A Dimmer could contain a module “binaryActuator” to turn on/off and additionally “setInteger0-255Actuator” to set the dimming level - - - - - - - - Target (Class: Target) describes a destination (e.g. a URL) to which the Operation and input data of the Operation should be sent and from where Output- or State data can be obtained. -The Target class is dependent on the technology (e.g. oneM2M RESTful style or RPC style Area Network technologies) on which the Operation is applied. -Since the target of data in the oneM2M Sytem will differ from the target in an interworked technology two sub-classes of class “Target” are defined in the base ontology: -“OneM2MTarget” and “InterworkedTarget” to emphasize that while the target of data in oneM2M will always be some oneM2M resource (e.g. a contentInstance in a container) the target of the data in the interworked, non-oneM2M technology may e.g. be a certain position in a byte string that is sent via a technology specific protocol to the interworked, non-oneM2M device - - OneM2MTarget (Class: OneM2MTarget) is the target of data in the oneM2M System - - InterworkedTarget (Class: InterworkedTarget) is the target of data in the interworked, non-oneM2M technology - - - - - - - - - - - - - - A Thing in oneM2M (Class: Thing) is an entity that can be identified in the oneM2M System. A Thing may have properties (Object Property: hasThingProperty) that can be described by Values. A Thing can have relations to other things (Object Property: hasThingRelation) -E.g. A room that is modelled in oneM2M would be a Thing that could have a room-temperature as a Value and could have a relationship “isAdjacentTo” to another room - - - - - - - - - - - 1 - - - A Value (Class: Value) denotes a property of a Thing. A Value can e.g. be observed or influenced by devices, or it constitutes static data about a Thing. -E.g. the indoor temperature of the room could be a Value of a Thing “room”. -A Value of a thing can concern a certain Aspect, e.g. the indoor temperature concerns the Aspect “Temperature” that could be measured by a temperature sensor. -A Value of a Thing can have meta data - - - - - - - diff --git a/oneM2M_Base_Ontology-V_0_9_0.owl b/oneM2M_Base_Ontology-V_0_9_0.owl deleted file mode 100644 index c5b5fb0754dffdd127bfc8f646bd3503ab2b91d4..0000000000000000000000000000000000000000 --- a/oneM2M_Base_Ontology-V_0_9_0.owl +++ /dev/null @@ -1,1054 +0,0 @@ - - - - - - - - - -]> - - - - - This file contains the Base Ontology of oneM2M as specified in TS-0012 - - - - - - - - - - - - - - The resourceDescriptorLink annotation property is used to refer to a semanticDescriptor resource that contains more information about its subject. Its subject may be any individual and the range shall be the data literal or URI reference that represents the address of the semanticDescriptor - - - - - - - - - - - - - - - A Device can consist of (i.e. be composed) of several (sub-) Devices - - - - - - - - - - A Variable describes an Aspect (a quality or kind) - - - - - - - - - - A –machine interpretable- Operation or an Input/OutputDataPoint of a Service exposes a –human understandable- Command to a network - - - - - - - - - - A Service exposes a Functionality to the network and makes it discoverable, registerable and remotely controllable in the network - - - - - - - - - - A Functionality of a Device can be influenced / observed by a human user through the Commands that this Functionality has and that are offered to the user - - - - - - - - - - In order to accomplish its task, a Device performs one or more Functionalities - - - - - - - - - - An Operation of a Service of the Device or a Command of a Functionality of the Device can have transient OperationInput data. - - - - - - - - - - - - - - - - - A Service or an Operation of a Service of the Device can have InputDataPoints. Communicating entities write data into InputDataPoints and the Device retrieves the data at times according to an internal schedule. - - An InputDataPoint is a persistent resource - - - - - - - - - - - - - - - - - A Value of a Thing can have MetaData (like units, precision-ranges). - - - - - - - - - - - - - - - - - A Service communicates by means of Operations over the network to transmit data to/from other devices - - - - - - - - - - An Operation may have an OperationState that is exposed - - - - - - - - - - An Operation of a Service of the Device or a Command of a Functionality of the Device can have transient OperationOutput data. - - - - - - - - - - - - - - - - - A Service or an Operation of a Service of the Device can have OutputDataPoints. The Device writes data into OutputDataPoints at times according to an internal schedule and the communicating entitis retrieves the data. - - An OutputDataPoint is a persistent resource - - - - - - - - - - - - - - - - - The Functionalities of a Device are exposed in the network as Services of the Device - - - - - - - - - - A Service may be composed of smaller, independent (sub)Services, e.g. re-usable servicemodules - - - - - - - - - - A structured Variable can be composed of (sub-)Variables - - - - - - - - - - A Thing may have properties that can be described by Values - - - - - - - - - - A Thing may have relations to itself or to other Things (e-g. a Thing "Room" could have a relation "has_Door" with a Thing "Door") - - - - - - - - - - An InterworkedDevice constitutes a part of an AreaNetwork - - - - - - - - - - A Functionality of a Device can refer to a certain Aspect (a quality or kind) that is measured or controlled by that Functionality. -e.g. a temperature sensor would refer to the Aspect "Temperature" that it measures - - - - - - - - - - - - - - - This Data Property specifies the restrictions on the data type of the SimpleTypeVariable. -The Data Property "hasDataRestriction" shall always be sub-classed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This Data Property specifies the data type of the SimpleTypeVariable as text string - - - - - - - owl:rational - - - - owl:real - - - - rdf:PlainLiteral - - - - rdf:XMLLiteral - - - - xsd:NCName - - - - xsd:NMTOKEN - - - - xsd:Name - - - - xsd:anyURI - - - - xsd:base64Binary - - - - xsd:boolean - - - - xsd:byte - - - - xsd:dateTime - - - - xsd:dateTimeStamp - - - - xsd:decimal - - - - xsd:hexBinary - - - - xsd:int - - - - xsd:integer - - - - xsd:language - - - - xsd:long - - - - xsd:negativeInteger - - - - xsd:nonNegativeInteger - - - - xsd:nonPositiveInteger - - - - xsd:normalizedString - - - - xsd:positiveInteger - - - - xsd:short - - - - xsd:string - - - - xsd:token - - - - xsd:unsignedByte - - - - xsd:unsignedInt - - - - xsd:unsignedLong - - - - xsd:unsignedShort - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This data property contains the value of the Variable if that value is part of the semantic description and is not contained in a different resource (identified by the oneM2MTargetURI data property). Storing the value of a Variable in a semantic description (i.e. as part of the RDF description in the semanticDescriptor resource) is useful for values that are relatively static (e.g. the name of the manufacturer). - - Data properties "hasValue" and "oneM2MTargetURI" are mutually exclusive. Only one of the two shall be instantiated. - - - - - - - - - - Identification of a communication protocol (e.g. ZigBee_1_0) - - - - - - - - - - Identification of the physical properties of a Area Network technology (e.g. IEEE_802_15_4_2003_2_4GHz). - - - - - - - - - - Identification of a profile (e.g. ZigBee_HA) of a Area Network technology. - - - - - - - - - - This Data Property contains the name of the attribute of the oneM2M resource of type <flexContainer> or the the child resource of the oneM2M resource of type <container> that is referenced with the oneM2MTargetURI and that stores the value of the SimpleTypeVariable - - if the resource-type of the oneM2M resource that is referenced with the oneM2MTargetURI is <container> then this Data Property shall contain the text string "#latest" - - - - - - - - - - This data property contains a oneM2M CRUD Method through which the oneM2M instantiation of the value of the Variable can be manipulated by the communicating entity. - - It contains the string "RETRIEVE" for retrieving the variable when the oneM2M resource is of type <container> or <flexContainer>. This applies to sub-classes: OperationOutput, OutputDatapoint, ThingProperty and OperationState - - It contains the string "CREATE" for updating the variable when the oneM2M resource is of type <container>. This applies to sub-classes: OperationInput, InputDatapoint, ThingProperty - - It contains the string "UPDATE" for updationg the variable when the oneM2M resource is of type <flexContainer>. This applies to sub-classes: OperationInput, InputDatapoint, ThingProperty - - - - - - - - - - - - - - - - - oneM2MTargetURI (range data type: rdfs: Literal) -This data property contains the URI of a oneM2M resource (<container> or <flexContainer>) through which the oneM2M instantiation of the value of the Variable can be manipulated by the communicating entity. It can contain an absolute address or an address relative to the <semanticDescriptor> resource that holds the RDF description of the Variable. -That address could be e.g. - - The value of the parentID for the <container> or <flexContainer> of a Input- or OutputDataPoint which has child-resource of type <semanticDescriptor> that holds the RDF description of the DataPoint - - - - - - - - - - - - - - - - - - - - - - An AreaNetwork (Class: AreaNetwork) is a Network that provides data transport services between an Interworked Device and the oneM2M System. Different area Networks can use heterogeneous network technologies that may or may not support IP access - - - - - - - - An Aspect (Class: Aspect) describes the real-world aspect that a functionality relates to. Aspect is also used to describe the quality or kind OperationInput- or OperationOutput variables. -The Aspect could be a (physical or non-physical) entity or it could be a quality - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A Command (Class: Command) represents an action that can be performed to support the Functionality. A Command is the human understandable name of that action that is invoked in a device or is reported by the device. An Operation exposes a Command to the network. OperationInput and OperationOutput of the related Operation can parameterize the command. -e.g. the Functionality "dimming-functionality" of a light switch that remotely controls a light could have a Command "setLightIntensity", with a parameter that has values 0 - 100 %. - - Also InputDataPoints and OutputDataPoints expose Commands to the network. When a Device communicates in a RESTful way then changing (UPDATEing) an InputDataPoint triggers an action in the Device once the Device has read out the data from the InputDataPoint. - - Similarly, when a Device sets the data of an OutputDataPoint then it provides state information about the Device. -Note: In RESTful systems the names of Input- and OutputDataPoints are usually chosen in such a way that they express the Command, i.e. the human-understandable meaning (e.g. a binary InputDataPoint of a lightswitch could have a name "Set_Light_Status"). In such a case the Command coincides with the DataPoint. - - - - - - - - - A ControllingFunctionality (Class: ControllingFunctionality) represents a functionality that has impacts on the real world, but does not gather data. In general a ControllingFunctionality has Commands (and/or Operations of its related Services) that receives Input data -E.g. a thermostat would have "temperature-adjustment" as a ControllingFunctionality - - - - - - - - - - - - - 1 - - - - - - - - - - - - - 1 - - - A Device (Class: Device) is a object designed to accomplish a particular task. A Device contains some logic and is producer and/or consumer of data that are exchanged via its Services with other oneM2M entities (Devices, Things) in the network. A Device may be a physical or non-physical entity. -In the context of oneM2M a Device is always assumed to be capable of communicating electronically via a network. - - In order to accomplish its task, the device performs one or more functionalities - - These functionalities are exposed in the network as Services of the Device. - - A Device can be composed of several (sub-) Devices - - Each Device (including sub-Devices) needs to be individually addressable in the network. - - - - - - - - A Functionality (Class: Functionality) represents the functionality necessary to accomplish the task for which a Device is designed. A device can be designed to perform more than one functionality. -The functionality exhibits the – human understandable – meaning what the device "does". -A Functionality refers to (e.g. observes or influences) some real-world aspect(s), that can be modelled as a Class: Aspect. -E.g. considering a "light switch" then a related Functionality could be "Controlling_ON_OFF" or "Controlling Brightness". These functionalities would refer to an Aspect "light-control". - -A Functionality of a Device can be influenced / observed by a human user through the Commands that this Functionality has and that are offered to the user - - - - - - - - - InputDataPoint (Class: InputDataPoint) is a Variable of a Service that is accessed by a RESTful Device in its environment and that the Device reads out autonomously (e.g. at periodic times). -To enable a third party to instruct the device to retrieve (out of schedule) the current value of a InputputDataPoint devices often also offer a GET_InputDataPoint Operation to trigger the device to retrieve the data from the InputDataPoint - - - - - - - - - An InterworkedDevice (Class: InterworkedDevice) is a Device – e.g. in an Area Network – that does not support oneM2M interfaces and can only be accessed from the oneM2M System by communicating with a "proxied" (virtual) device that has been created by an Interworking Proxy Entity - - - - - - - - - A MeasuringFunctionality (Class: MeasuringFunctionality) represents a functionality that has no impacts on the real world, but only gathers data. In general a MeasuringFunctionality has Commands (and/or Operations of its related Services) that generate Output data -E.g. a temperature sensor would have "temperature-sensing" as a MeasuringFunctionality - - - - - - - - MetaData (Class: MetaData) contain data (like units, precision-ranges …) about a Variable or about an Aspect. -E.g. the indoor temperature could have meta data: "Degrees Celsius" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - An Operation (Class: Operation) is the means of a Service to communicate in a procedure-type manner over the network (i.e. transmit data to/from other devices). It is the –machine interpretable- exposure of a –human understandable- Command to a network. -An Operation is transient. I.e. an Operation can be invoked, possibly produces output and is finished. - - A non-oneM2M Device or a oneM2M entity (e.g. an AE) can invoke an Operation of the Device (oneM2M Device or InterworkedDevice) and that invocation can trigger some action in the Device. If an Operation has input data it may receive input data from - - InputDataPoints (persistent resources) and/or - - OperationInput (transient resources, that are deleted when the Operation finished) -and potentially produce output data into - - OutputDataPoints (persistent resources) and/or - - OperationOutput (transient resources, that are deleted when the Operation finished) -An Operation correlates the output data of the Operation to the input data that were used at Operation invokation. - - - - - - - - - OperationInput (Class: OperationInput) describes an input of an Operation of a Service. OperationInput also describes the input of an Command. - - - - - - - - - OperationOutput (Class: OperationOutput) describes an output of an Operation. OperationOutput also describes the output of a Command. - - An Operation/Command may have multiple OperationInputs and/or OperationOutputs - - - - - - - - - - - - - - data_received_by_application - - - - data_transmitted_to_interworked_device - - - - operation_ended - - - - operation_failed - - - - - - - - 1 - - - - - - - 1 - - - - describes the current state during the lifetime of an Operation. The OperationState class represents all possible values for that state (enumerated individuals). The OperationState is set during the progress of the operation by the entity invoking the operation, the entity that is the target of the operation, e.g. a device (or for interworked devices by the IPE) and the CSE. It takes values like -"data_received_by_application", "operation_ended", "operation_failed", "data_transmitted_to_interworked_device". - - - - - - - - - OutputDataPoint (Class: OutputDataPoint) is a Variable of a Service that is set by a RESTful Device in its environment and that the Device updates autonomously (e.g. at periodic times). To enable a third party to instruct the device to update (out of schedule) the current value of a OutputputDataPoint devices often also offer a SET_OutputDataPoint Operation to trigger the device to update the data of the OutputDataPoint - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A Service (Class: Service) is a electronic representation of a Functionality in a network. The Service exposes the Functionality to the network and makes it discoverable, registerable and remotely controllable in the network. -A Service is offered by a device that wants (a certain set of) its Functionalities to be discoverable, registerable, remotely controllable by other devices in the network. -A Service can expose one or more Functionalities and a Functionality can be exposed by one or more Services. -The Input- and Output DataPoints and Operations of a Service may have the same names as for a different Service, however the Service to which they belong differentiates how they are addressed in the Device (e.g. via a port specific to the Service). -NOTE: While a Functionality describes the – human understandable – meaning of a Service of the device the Service is used to describe how such functionality is represented in a communication network and can be accessed by electronic means. The Service and its Operations is therefore dependent on the technology of the network, hard- and software of the device. - - - - - - - - - - - - 1 - - - - SimpleTypeVariable (Class: SimpleTypeVariable) is a sub-class of class:Variable that only consists of Variables of simple xml types like xsd:integer, xsd:string…, potentially including restrictions - -The simple datatypes and –restrictions contained in "OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)" are supported. (see http://www.w3.org/TR/owl2-syntax/) - - - - - - - - - - - - - - A Thing in oneM2M (Class: Thing) is an entity that can be identified in the oneM2M System. -A Thing that is not a Device is not able to conmmunicate electronically with its environment. However, the sub-class of Thing that is able to interact electronically is called a "Device". -A Thing may have ThingProperties (Object Property: hasThingProperty). A Thing can have relations to other things (Object Property: hasThingRelation). -Since a Thing that is not a Device is not able to conmmunicate electronically it cannot influence the value of its ThingProperties or being influenced by it. Similarly a Thing cannot document its - real-world - relationships (via hasThingRelation) to other Things. - -E.g. A room that is modelled in oneM2M would be a Thing that could have a room-temperature as a ThingProperty and could have a relationship "isAdjacentTo" to another room - - - - - - - - - A Value (Class: Value) denotes a property of a Thing. A Value can e.g. be observed or influenced by devices, or it constitutes static data about a Thing. -E.g. the indoor temperature of the room could be a Value of a Thing "room". -A Value of a thing can concern a certain Aspect, e.g. the indoor temperature concerns the Aspect "Temperature" that could be measured by a temperature sensor. -A Value of a Thing can have meta data - - - - - - - - A Variable (Class: Variable) constitutes a super class to the following classes: ThingProperty, OperationInput, OperationOutput, OperationState, InputDataPoint, OutputDataPoint, SimpleTypeVariable. Its members are entities that store some data (e.g. integers, text, or structured data) that can change over time. -These data of the Variable usually describe some real-world Aspects (e.g. a temperature) and can have MetaData (e.g. units, precision..) - - - - - - - diff --git a/oneM2M_Base_Ontology.owl b/oneM2M_Base_Ontology.owl deleted file mode 100644 index c5b5fb0754dffdd127bfc8f646bd3503ab2b91d4..0000000000000000000000000000000000000000 --- a/oneM2M_Base_Ontology.owl +++ /dev/null @@ -1,1054 +0,0 @@ - - - - - - - - - -]> - - - - - This file contains the Base Ontology of oneM2M as specified in TS-0012 - - - - - - - - - - - - - - The resourceDescriptorLink annotation property is used to refer to a semanticDescriptor resource that contains more information about its subject. Its subject may be any individual and the range shall be the data literal or URI reference that represents the address of the semanticDescriptor - - - - - - - - - - - - - - - A Device can consist of (i.e. be composed) of several (sub-) Devices - - - - - - - - - - A Variable describes an Aspect (a quality or kind) - - - - - - - - - - A –machine interpretable- Operation or an Input/OutputDataPoint of a Service exposes a –human understandable- Command to a network - - - - - - - - - - A Service exposes a Functionality to the network and makes it discoverable, registerable and remotely controllable in the network - - - - - - - - - - A Functionality of a Device can be influenced / observed by a human user through the Commands that this Functionality has and that are offered to the user - - - - - - - - - - In order to accomplish its task, a Device performs one or more Functionalities - - - - - - - - - - An Operation of a Service of the Device or a Command of a Functionality of the Device can have transient OperationInput data. - - - - - - - - - - - - - - - - - A Service or an Operation of a Service of the Device can have InputDataPoints. Communicating entities write data into InputDataPoints and the Device retrieves the data at times according to an internal schedule. - - An InputDataPoint is a persistent resource - - - - - - - - - - - - - - - - - A Value of a Thing can have MetaData (like units, precision-ranges). - - - - - - - - - - - - - - - - - A Service communicates by means of Operations over the network to transmit data to/from other devices - - - - - - - - - - An Operation may have an OperationState that is exposed - - - - - - - - - - An Operation of a Service of the Device or a Command of a Functionality of the Device can have transient OperationOutput data. - - - - - - - - - - - - - - - - - A Service or an Operation of a Service of the Device can have OutputDataPoints. The Device writes data into OutputDataPoints at times according to an internal schedule and the communicating entitis retrieves the data. - - An OutputDataPoint is a persistent resource - - - - - - - - - - - - - - - - - The Functionalities of a Device are exposed in the network as Services of the Device - - - - - - - - - - A Service may be composed of smaller, independent (sub)Services, e.g. re-usable servicemodules - - - - - - - - - - A structured Variable can be composed of (sub-)Variables - - - - - - - - - - A Thing may have properties that can be described by Values - - - - - - - - - - A Thing may have relations to itself or to other Things (e-g. a Thing "Room" could have a relation "has_Door" with a Thing "Door") - - - - - - - - - - An InterworkedDevice constitutes a part of an AreaNetwork - - - - - - - - - - A Functionality of a Device can refer to a certain Aspect (a quality or kind) that is measured or controlled by that Functionality. -e.g. a temperature sensor would refer to the Aspect "Temperature" that it measures - - - - - - - - - - - - - - - This Data Property specifies the restrictions on the data type of the SimpleTypeVariable. -The Data Property "hasDataRestriction" shall always be sub-classed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This Data Property specifies the data type of the SimpleTypeVariable as text string - - - - - - - owl:rational - - - - owl:real - - - - rdf:PlainLiteral - - - - rdf:XMLLiteral - - - - xsd:NCName - - - - xsd:NMTOKEN - - - - xsd:Name - - - - xsd:anyURI - - - - xsd:base64Binary - - - - xsd:boolean - - - - xsd:byte - - - - xsd:dateTime - - - - xsd:dateTimeStamp - - - - xsd:decimal - - - - xsd:hexBinary - - - - xsd:int - - - - xsd:integer - - - - xsd:language - - - - xsd:long - - - - xsd:negativeInteger - - - - xsd:nonNegativeInteger - - - - xsd:nonPositiveInteger - - - - xsd:normalizedString - - - - xsd:positiveInteger - - - - xsd:short - - - - xsd:string - - - - xsd:token - - - - xsd:unsignedByte - - - - xsd:unsignedInt - - - - xsd:unsignedLong - - - - xsd:unsignedShort - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This data property contains the value of the Variable if that value is part of the semantic description and is not contained in a different resource (identified by the oneM2MTargetURI data property). Storing the value of a Variable in a semantic description (i.e. as part of the RDF description in the semanticDescriptor resource) is useful for values that are relatively static (e.g. the name of the manufacturer). - - Data properties "hasValue" and "oneM2MTargetURI" are mutually exclusive. Only one of the two shall be instantiated. - - - - - - - - - - Identification of a communication protocol (e.g. ZigBee_1_0) - - - - - - - - - - Identification of the physical properties of a Area Network technology (e.g. IEEE_802_15_4_2003_2_4GHz). - - - - - - - - - - Identification of a profile (e.g. ZigBee_HA) of a Area Network technology. - - - - - - - - - - This Data Property contains the name of the attribute of the oneM2M resource of type <flexContainer> or the the child resource of the oneM2M resource of type <container> that is referenced with the oneM2MTargetURI and that stores the value of the SimpleTypeVariable - - if the resource-type of the oneM2M resource that is referenced with the oneM2MTargetURI is <container> then this Data Property shall contain the text string "#latest" - - - - - - - - - - This data property contains a oneM2M CRUD Method through which the oneM2M instantiation of the value of the Variable can be manipulated by the communicating entity. - - It contains the string "RETRIEVE" for retrieving the variable when the oneM2M resource is of type <container> or <flexContainer>. This applies to sub-classes: OperationOutput, OutputDatapoint, ThingProperty and OperationState - - It contains the string "CREATE" for updating the variable when the oneM2M resource is of type <container>. This applies to sub-classes: OperationInput, InputDatapoint, ThingProperty - - It contains the string "UPDATE" for updationg the variable when the oneM2M resource is of type <flexContainer>. This applies to sub-classes: OperationInput, InputDatapoint, ThingProperty - - - - - - - - - - - - - - - - - oneM2MTargetURI (range data type: rdfs: Literal) -This data property contains the URI of a oneM2M resource (<container> or <flexContainer>) through which the oneM2M instantiation of the value of the Variable can be manipulated by the communicating entity. It can contain an absolute address or an address relative to the <semanticDescriptor> resource that holds the RDF description of the Variable. -That address could be e.g. - - The value of the parentID for the <container> or <flexContainer> of a Input- or OutputDataPoint which has child-resource of type <semanticDescriptor> that holds the RDF description of the DataPoint - - - - - - - - - - - - - - - - - - - - - - An AreaNetwork (Class: AreaNetwork) is a Network that provides data transport services between an Interworked Device and the oneM2M System. Different area Networks can use heterogeneous network technologies that may or may not support IP access - - - - - - - - An Aspect (Class: Aspect) describes the real-world aspect that a functionality relates to. Aspect is also used to describe the quality or kind OperationInput- or OperationOutput variables. -The Aspect could be a (physical or non-physical) entity or it could be a quality - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A Command (Class: Command) represents an action that can be performed to support the Functionality. A Command is the human understandable name of that action that is invoked in a device or is reported by the device. An Operation exposes a Command to the network. OperationInput and OperationOutput of the related Operation can parameterize the command. -e.g. the Functionality "dimming-functionality" of a light switch that remotely controls a light could have a Command "setLightIntensity", with a parameter that has values 0 - 100 %. - - Also InputDataPoints and OutputDataPoints expose Commands to the network. When a Device communicates in a RESTful way then changing (UPDATEing) an InputDataPoint triggers an action in the Device once the Device has read out the data from the InputDataPoint. - - Similarly, when a Device sets the data of an OutputDataPoint then it provides state information about the Device. -Note: In RESTful systems the names of Input- and OutputDataPoints are usually chosen in such a way that they express the Command, i.e. the human-understandable meaning (e.g. a binary InputDataPoint of a lightswitch could have a name "Set_Light_Status"). In such a case the Command coincides with the DataPoint. - - - - - - - - - A ControllingFunctionality (Class: ControllingFunctionality) represents a functionality that has impacts on the real world, but does not gather data. In general a ControllingFunctionality has Commands (and/or Operations of its related Services) that receives Input data -E.g. a thermostat would have "temperature-adjustment" as a ControllingFunctionality - - - - - - - - - - - - - 1 - - - - - - - - - - - - - 1 - - - A Device (Class: Device) is a object designed to accomplish a particular task. A Device contains some logic and is producer and/or consumer of data that are exchanged via its Services with other oneM2M entities (Devices, Things) in the network. A Device may be a physical or non-physical entity. -In the context of oneM2M a Device is always assumed to be capable of communicating electronically via a network. - - In order to accomplish its task, the device performs one or more functionalities - - These functionalities are exposed in the network as Services of the Device. - - A Device can be composed of several (sub-) Devices - - Each Device (including sub-Devices) needs to be individually addressable in the network. - - - - - - - - A Functionality (Class: Functionality) represents the functionality necessary to accomplish the task for which a Device is designed. A device can be designed to perform more than one functionality. -The functionality exhibits the – human understandable – meaning what the device "does". -A Functionality refers to (e.g. observes or influences) some real-world aspect(s), that can be modelled as a Class: Aspect. -E.g. considering a "light switch" then a related Functionality could be "Controlling_ON_OFF" or "Controlling Brightness". These functionalities would refer to an Aspect "light-control". - -A Functionality of a Device can be influenced / observed by a human user through the Commands that this Functionality has and that are offered to the user - - - - - - - - - InputDataPoint (Class: InputDataPoint) is a Variable of a Service that is accessed by a RESTful Device in its environment and that the Device reads out autonomously (e.g. at periodic times). -To enable a third party to instruct the device to retrieve (out of schedule) the current value of a InputputDataPoint devices often also offer a GET_InputDataPoint Operation to trigger the device to retrieve the data from the InputDataPoint - - - - - - - - - An InterworkedDevice (Class: InterworkedDevice) is a Device – e.g. in an Area Network – that does not support oneM2M interfaces and can only be accessed from the oneM2M System by communicating with a "proxied" (virtual) device that has been created by an Interworking Proxy Entity - - - - - - - - - A MeasuringFunctionality (Class: MeasuringFunctionality) represents a functionality that has no impacts on the real world, but only gathers data. In general a MeasuringFunctionality has Commands (and/or Operations of its related Services) that generate Output data -E.g. a temperature sensor would have "temperature-sensing" as a MeasuringFunctionality - - - - - - - - MetaData (Class: MetaData) contain data (like units, precision-ranges …) about a Variable or about an Aspect. -E.g. the indoor temperature could have meta data: "Degrees Celsius" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - An Operation (Class: Operation) is the means of a Service to communicate in a procedure-type manner over the network (i.e. transmit data to/from other devices). It is the –machine interpretable- exposure of a –human understandable- Command to a network. -An Operation is transient. I.e. an Operation can be invoked, possibly produces output and is finished. - - A non-oneM2M Device or a oneM2M entity (e.g. an AE) can invoke an Operation of the Device (oneM2M Device or InterworkedDevice) and that invocation can trigger some action in the Device. If an Operation has input data it may receive input data from - - InputDataPoints (persistent resources) and/or - - OperationInput (transient resources, that are deleted when the Operation finished) -and potentially produce output data into - - OutputDataPoints (persistent resources) and/or - - OperationOutput (transient resources, that are deleted when the Operation finished) -An Operation correlates the output data of the Operation to the input data that were used at Operation invokation. - - - - - - - - - OperationInput (Class: OperationInput) describes an input of an Operation of a Service. OperationInput also describes the input of an Command. - - - - - - - - - OperationOutput (Class: OperationOutput) describes an output of an Operation. OperationOutput also describes the output of a Command. - - An Operation/Command may have multiple OperationInputs and/or OperationOutputs - - - - - - - - - - - - - - data_received_by_application - - - - data_transmitted_to_interworked_device - - - - operation_ended - - - - operation_failed - - - - - - - - 1 - - - - - - - 1 - - - - describes the current state during the lifetime of an Operation. The OperationState class represents all possible values for that state (enumerated individuals). The OperationState is set during the progress of the operation by the entity invoking the operation, the entity that is the target of the operation, e.g. a device (or for interworked devices by the IPE) and the CSE. It takes values like -"data_received_by_application", "operation_ended", "operation_failed", "data_transmitted_to_interworked_device". - - - - - - - - - OutputDataPoint (Class: OutputDataPoint) is a Variable of a Service that is set by a RESTful Device in its environment and that the Device updates autonomously (e.g. at periodic times). To enable a third party to instruct the device to update (out of schedule) the current value of a OutputputDataPoint devices often also offer a SET_OutputDataPoint Operation to trigger the device to update the data of the OutputDataPoint - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A Service (Class: Service) is a electronic representation of a Functionality in a network. The Service exposes the Functionality to the network and makes it discoverable, registerable and remotely controllable in the network. -A Service is offered by a device that wants (a certain set of) its Functionalities to be discoverable, registerable, remotely controllable by other devices in the network. -A Service can expose one or more Functionalities and a Functionality can be exposed by one or more Services. -The Input- and Output DataPoints and Operations of a Service may have the same names as for a different Service, however the Service to which they belong differentiates how they are addressed in the Device (e.g. via a port specific to the Service). -NOTE: While a Functionality describes the – human understandable – meaning of a Service of the device the Service is used to describe how such functionality is represented in a communication network and can be accessed by electronic means. The Service and its Operations is therefore dependent on the technology of the network, hard- and software of the device. - - - - - - - - - - - - 1 - - - - SimpleTypeVariable (Class: SimpleTypeVariable) is a sub-class of class:Variable that only consists of Variables of simple xml types like xsd:integer, xsd:string…, potentially including restrictions - -The simple datatypes and –restrictions contained in "OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)" are supported. (see http://www.w3.org/TR/owl2-syntax/) - - - - - - - - - - - - - - A Thing in oneM2M (Class: Thing) is an entity that can be identified in the oneM2M System. -A Thing that is not a Device is not able to conmmunicate electronically with its environment. However, the sub-class of Thing that is able to interact electronically is called a "Device". -A Thing may have ThingProperties (Object Property: hasThingProperty). A Thing can have relations to other things (Object Property: hasThingRelation). -Since a Thing that is not a Device is not able to conmmunicate electronically it cannot influence the value of its ThingProperties or being influenced by it. Similarly a Thing cannot document its - real-world - relationships (via hasThingRelation) to other Things. - -E.g. A room that is modelled in oneM2M would be a Thing that could have a room-temperature as a ThingProperty and could have a relationship "isAdjacentTo" to another room - - - - - - - - - A Value (Class: Value) denotes a property of a Thing. A Value can e.g. be observed or influenced by devices, or it constitutes static data about a Thing. -E.g. the indoor temperature of the room could be a Value of a Thing "room". -A Value of a thing can concern a certain Aspect, e.g. the indoor temperature concerns the Aspect "Temperature" that could be measured by a temperature sensor. -A Value of a Thing can have meta data - - - - - - - - A Variable (Class: Variable) constitutes a super class to the following classes: ThingProperty, OperationInput, OperationOutput, OperationState, InputDataPoint, OutputDataPoint, SimpleTypeVariable. Its members are entities that store some data (e.g. integers, text, or structured data) that can change over time. -These data of the Variable usually describe some real-world Aspects (e.g. a temperature) and can have MetaData (e.g. units, precision..) - - - - - - -