hasActivity
type: ObjectProperty
type: FunctionalProperty
domain: Session
range: Activity
part: Session
still image: Session.png
modified: $ 02:10 AM 2016-06-28 $
change note: %STATUS_STABLE%
definition: Connects a Session with its associated Activity.
preferred label: has activity
scope note: Connecting a Session individual with its associated Activity.
describedby: hasActivity.POWDER

hasMQTT.ID
type: FunctionalProperty
type: DatatypeProperty
comment: hasMQTT.ID.POWDER
domain: AccessMethod.MQTT
range: Literal
part: SSN-Skeleton
still image: RecordedData.png
conforms to: %DATATYPE%
conforms to: A Client Identifier (or ClientId) conforms to the following definition in the latest OASIS MQTT specification: MQTT Version 3.1.1 Plus Errata 01 (OASIS Standard Incorporating Approved Errata 01 10 December 2015) – 3. MQTT Control Packets / 3.1. CONNECT / 3.1.3. Payload – (3.1.3.1. Client Identifier).
format: The Client Identifier MUST be a UTF-8 encoded string as defined in Section 1.5.3 of the latest OASIS MQTT specification: MQTT Version 3.1.1 Plus Errata 01 (OASIS Standard Incorporating Approved Errata 01 10 December 2015) – 1. Introduction – (1.5 Data representations).
modified: $ 04:35 AM 2016-07-05 $
deprecated: true
deprecated: «This ontology should be agnostic to the data access» $ 04:35 AM 2016-07-05 $
change note: %STATUS_STABLE%
definition: Describes the Client Identifier (ClientId) parameter in an AccessMethod.MQTT connection. This parameter identifies the Client to the MQTT Server.
preferred label: has MQTT ID

Context.ObjectComponent.Event
type: Class
subclass of: Event
subclass of: Context.ObjectComponent
subclass of: Restriction
  min qualified cardinality: 0
  on class: Action
  on property: causes
subclass of: Restriction
  min qualified cardinality: 1
  on class: PlayoutInstant.ContextEvent
  on property: hasPlayoutInstant
part: Context
still image: Activity.png
still image: Context.ObjectComponent.png
modified: $ 11:45 PM 2016-05-18 $
source: [Unity]
change note: %STATUS_STABLE%
definition: Captures an Event that triggers a change on the Context.ObjectComponent's state.
example: Some event types from the Gaming domain are: PointerEnter PointerExit PointerDown PointerUp PointerClick Drag Drop Scroll UpdateSelected Select Deselect Move InitializePotentialDrag BeginDrag EndDrag Submit Cancel
preferred label: context object component event
scope note: %CLASS_HIERARCHY% any Context.ObjectComponent.Event entities. This class hierarchy includes the subclass StimulusEvent.
describedby: Context.ObjectComponent.Event.POWDER

observedModality
type: FunctionalProperty
type: ObjectProperty
domain: Record
range: Modality
sub property of: observedProperty
part: SSN-Skeleton
still image: Record.png
modified: $ 05:10 AM 2016-07-21 $
source: [SSN], [ESS]
change note: %STATUS_STABLE%
definition: Connects a Record with its correspondent Modality. This can be read, as follow: "A Record observes a Modality". This object property is a subproperty of ssn:observedProperty: [ssn:Observation] ––– (ssn:observedProperty) –––> [ssn:Property] [Record] ––––––– (observedModality) –––––> [Modality]
history note: [ESS 1.0]: A record (bci:Record) has a specific (single) defined modality (bci:Modality). [ESS 2.0]: A record (bci:Session) has a specific defined RecordedParameterSet, which groups various (multiple) RecordedModality (Modality-ies). Therefore, a record (bci:Session) can be associated with multiple RecordedModality (bci:Modality) definitions.
preferred label: observed modality
scope note: Connecting a Record individual with its correspondent Modality
describedby: observedModality.POWDER

hasMQTT.Broker
type: FunctionalProperty
type: DatatypeProperty
comment: hasMQTT.Broker.POWDER
domain: AccessMethod.MQTT
range: Literal
part: SSN-Skeleton
still image: RecordedData.png
conforms to: %DATATYPE%
conforms to: A broker (or MQTT Server) conforms to the following definition in the latest OASIS MQTT specification: MQTT Version 3.1.1 Plus Errata 01 (OASIS Standard Incorporating Approved Errata 01 10 December 2015) – 1.2 Terminology – (Server).
format: As defined in: MQTT Version 3.1.1 Plus Errata 01 (OASIS Standard Incorporating Approved Errata 01 10 December 2015) – 1. Introduction – (1.5 Data representations).
modified: $ 04:35 AM 2016-07-05 $
deprecated: «This ontology should be agnostic to the data access» $ 04:35 AM 2016-07-05 $
deprecated: true
change note: %STATUS_STABLE%
definition: Describes the broker (a MQTT Server) parameter in an AccessMethod.MQTT connection.
preferred label: has MQTT broker

hasLocator
type: FunctionalProperty
type: DatatypeProperty
comment: hasLocator.POWDER
domain: Class
  union of: AccessMethod
  union of: Descriptor
range: anyURI
part: Descriptor,SSN-Skeleton
still image: RecordedData.png
conforms to: %DATATYPE%
modified: $ 07:42 PM 2016-06-02 $
change note: %STATUS_STABLE%
definition: An IRI locator to access a Web resource.
editorial note: A http-schemed IRI has the ability for content-type negotiation; and thus, it can process the media type of the Web resource.
preferred label: has locator (IRI)
scope note: AccessMethod: access to the Web resource that represents the Data File that storages the Record. Descriptor: external Web resource IRI.

CognitiveAspect
type: Class
subclass of: Aspect
part: SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 12:53 AM 2016-05-24 $
change note: %STATUS_STABLE%
definition: Describes the classification of CognitiveAspects. One application for this Aspect is Learning.
preferred label: cognitive aspect
scope note: %CLASS_HIERARCHY% the CognitiveAspects of the Records.
describedby: CognitiveAspect.POWDER

hasObjectComponent
type: ObjectProperty
domain: Class
  union of: Context.Object
  union of: Context.ObjectComponent
range: Context.ObjectComponent
part: Context
still image: Context.ObjectComponent.png
modified: $ 10:53 PM 2016-05-16 $
source: [Unity]
change note: %STATUS_STABLE%
definition: Connects a (Context.Object or Context.ObjectComponent) with the set of Context.ObjectComponents that comprises its internal structure.
preferred label: has object component
scope note: Connecting a (Context.Object or Context.ObjectComponent) with its Context.ObjectComponents
describedby: hasObjectComponent.POWDER

hasState
type: FunctionalProperty
type: DatatypeProperty
comment: hasState.POWDER
domain: ResponseTag
range: Literal
part: AnnotationTag
still image: Marker.png
conforms to: %DATATYPE%
modified: $ 09:23 PM 2016-05-22 $
change note: %STATUS_STABLE%
definition: Captures the alphabet symbol of the ResponseTag, representating its "State". BCI domain applications can define their own specific symbolic scheme to represent its relevant States.
example: An alphabet-based symbolic scheme, could be: "A B C D E...". Thus, a specific State, would be: {"B"}
preferred label: has state

Context.Scene
type: Class
subclass of: Restriction
  min qualified cardinality: 0
  on class: Context.Scene
  on property: hasPrevious
subclass of: Restriction
  min qualified cardinality: 1
  on class: Context.Object
  on property: hasObject
subclass of: Restriction
  min qualified cardinality: 0
  on class: Context.Scene
  on property: hasScene
subclass of: Restriction
  min qualified cardinality: 0
  on class: Context.Scene
  on property: hasNext
subclass of: Restriction
  max cardinality: 1
  on property: hasTitle
part: Context
still image: Context.Scene.png
modified: $ 03:24 AM 2016-09-29 $
source: [Unity]
change note: %STATUS_STABLE%
definition: It is the architectural description of a specific part of a Context, based on the dimension of time (temporality). A Context is compose of a non-empty sequence (see the editorial note) of Context.Scenes. A Context.Scene is related to other Context.Scene based on its temporality: occurrence in its sequence. A Context.Scene object can be composed of multiple Context.Scenes. A Context.Scene corresponds to the notion of World or Level on a Gaming platform.
editorial note: "In mathematics, a sequence is an ordered collection of objects in which repetitions are allowed. (...) Unlike a set, order matters, and exactly the same elements can appear multiple times at different positions in the sequence". Reference: [Wikipedia: Sequence]
example: On a Simulation: [driving a car in not-busy day on a freeway]; [driving a car in rush hour on a main city road]. On a Video Game: World 3; Level 3-2.
preferred label: context scene
describedby: Context.Scene.POWDER

hasStimulusEvent
type: ObjectProperty
type: FunctionalProperty
domain: StimulusTag
range: StimulusEvent
part: AnnotationTag
still image: Marker.png
modified: $ 06:51 PM 2016-05-22 $
inverse of: isStimulusEventOf
change note: %STATUS_STABLE%
definition: A StimulusTag is associated with (has) a StimulusEvent.
preferred label: has stimulus event
scope note: Connecting a StimulusTag with its correspondent StimulusEvent.
describedby: hasStimulusEvent.POWDER

DeviceChannelingSpec
type: Class
subclass of: ChannelingSpec
subclass of: Restriction
  on class: ChannelingSpec
  on property: extendsChannelingSpec
  qualified cardinality: 1
subclass of: Restriction
  on data range: positiveInteger
  on property: hasNumberOfChannels
  qualified cardinality: 1
subclass of: Restriction
  on property: hasChannelData
  some values from: Channel
part: Descriptor,SSN-Device
still image: Descriptor.png
still image: Aspect-and-Modality.png
still image: Device.png
modified: $ 11:13 PM 2016-08-08 $
change note: %STATUS_STABLE%
definition: Each Device supports a specific channeling schema information: all the supported logical components (Channels) and their extended metadata that describe a "more concrete" subset of its Modality's data structure model and template, based on the Device's own physical spec of its operational features and functionalities. A DeviceChannelingSpec captures two information sets for a specific Device: Its complete channeling schema description, in a form of an external document specification (outside the metadata repository): a specialized Descriptor. Relevant metadata attributes regarding the specific characteristics of the Device's channeling schema: a set of related Channels. The structure described in a DeviceChannelingSpec (first information set mentioned above) is a functional subset of the ChannelingSpec defined for the Modality that the Device supports, following the [SSN] data model. Hence, for practical reasons, a DeviceChannelingSpec is defined as a subclass of ChannelingSpec.
editorial note: Theoretically, a DeviceChannelingSpec could be defined as a specialized DeviceSpec concept. However, for practical reasons, this ontology aligns the definition of its first information set with ChannelingSpec.
preferred label: device channeling schema spec
scope note: %CLASS_HIERARCHY% any relevant type of a DeviceChannelingSpec to capture the external information that defines the channeling schema information of a Device.
describedby: DeviceChannelingSpec.POWDER

hasDataFormat
type: ObjectProperty
type: FunctionalProperty
domain: RecordedData
range: DataFormat
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 01:24 AM 2016-06-01 $
change note: %STATUS_STABLE%
definition: Connects a RecordedData with its corresponding DataFormat that describes the representation of the data observed by a Device.
preferred label: has BCI data format
scope note: Connecting a RecordedData with its corresponding DataFormat
describedby: hasDataFormat.POWDER

observedByEegDevice
type: ObjectProperty
type: FunctionalProperty
domain: EegRecord
range: EegDevice
sub property of: observedByDevice
part: EEG
still image: EegRecord.png
modified: $ 02:47 AM 2016-07-22 $
deprecated: true
deprecated: «Concerning EEG, this ontology only defines its related classes. It does not extend or define any specific properties for EEG.» $ 04:27 AM 2016-07-29 $
inverse of: madeEegRecord
change note: %STATUS_STABLE%
definition: Connects an EegRecord with its correspondent EegDevice. This can be read, as follow: "An EegRecord is observed by an EegDevice". This object property is a subproperty of observedByDevice: [Record] –––––– (observedByDevice) ––––––> [Device] [EegRecord] ––– (observedByEegDevice) –––> [EegDevice]
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: observed by EEG device
scope note: Connecting an EegRecord individual with its correspondent EegDevice
describedby: observedByEegDevice.POWDER

observationResult
type: ObjectProperty
type: InverseFunctionalProperty
domain: Record
range: RecordedData
sub property of: observationResult
part: SSN-Skeleton
still image: Record.png
still image: RecordedData.png
modified: $ 03:30 AM 2016-07-22 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a Record with its correspondent RecordedData set. This can be read, as follow: "A Record has as its observation result a RecordedData set". This object property is a subproperty of ssn:observationResult: [ssn:Observation] ––– (ssn:observationResult) –––> [ssn:SensorOutput] [Record] ––––––– (observationResult) –––––> [RecordedData]
preferred label: observation result (of a BCI record)
scope note: Connecting a Record individual with its correspondent RecordedData set
describedby: observationResult.POWDER

isSubjectOf
type: ObjectProperty
domain: Subject
range: Interaction
part: Subject
still image: Subject.png
modified: $ 01:55 AM 2016-06-23 $
change note: %STATUS_STABLE%
definition: Connects a Subject with a set of Interactions where he/she participates in.
preferred label: is subject of (participates in)
scope note: Connecting a Subject with a set of Interactions where he/she participates in.
describedby: isSubjectOf.POWDER

hasEegNonChannelData
type: ObjectProperty
domain: EegDevice
range: EegNonChannel
sub property of: hasNonChannelData
part: EEG
still image: MeasurementCapability.png
modified: $ 06:48 AM 2016-08-10 $
source: [SSN]
deprecated: «Concerning EEG, this ontology only defines its related classes. It does not extend or define any specific properties for EEG.» $ 04:27 AM 2016-07-29 $
deprecated: true
change note: %STATUS_STABLE%
definition: [SSN] Relation from a EegDevice to its EegNonChannel describing the non-channeling measurement capabilities (a set of measurement properties) of the EEG BCI device.
editorial note: This ontology leaves open to BCI applications the way how they should describe properly basic non-channeling measurement capabilities for its relevant set of different classes of sensors (Device class hierarchy) used in BCI activities, following the description of the ssn:MeasurementCapability concept. Based on their system requirements, BCI applications may define a set of restrictions and specialized connections (subproperties) on the property hasNonChannelData (subproperty of ssn:hasMeasurementCapability) for each particular subclass of Device (subclass of ssn:Sensor), which describes sensors for specific types.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: has non-channeling EEG data (other EEG measurement capability)
describedby: hasEegNonChannelData.POWDER

DeviceSpec
type: Class
subclass of: SensorDataSheet
subclass of: Descriptor
subclass of: Restriction
  min qualified cardinality: 0
  on class: DeviceSpec
  on property: hasDeviceSpec
part: Descriptor,SSN-Device
still image: Descriptor.png
still image: Device.png
description: ** HIDDEN CONTENT ** ============================================================================== ** scopeNote ** Manufacturer (source [XDF], [ESS]): manufacturer of the sensor (device). { History note } [ESS 1.0] Corresponds to the (/study/summary/recordedModalities/modality/recordingDevice) node definition: name or type of recording device used to acquire data (manufacturer name). [ESS 2.0] Corresponds to the (/study/recordingParameterSets/recordingParameterSet/channelType/modality/name) node definition: the name (brand) of the sensor device. For example: BioSemi, OptiTrack, SMI, etc. ==============================================================================
modified: $ 12:21 AM 2016-06-29 $
source: [SSN], [XDF], [ESS]
change note: %STATUS_STABLE%
definition: [SSN], [XDF] A DeviceSpec is a ssn:SensorDataSheet (information object) that records (describes) specific properties (such as: hardware specs, power used, types of connectors, etc.) of a Device. It has been modeled as a composite object so that it can be composed as a set of DeviceSpecs to describe specific parts of a Device. In this way, a DeviceSpec is considered as a bag of descriptive properties about the Device. A DeviceSpec is a specialized Descriptor. The relevant set of a Device's properties are recorded directly (with hasChannelData and hasNonChannelData), but the DeviceSpecs can be used to record any other descriptive information related to the physical device, such as: to record the manufacturers specifications verses observed capabilites, or if more is known than the manufacturer specifies, etc.
editorial note: The channeling schema that supports a Device is defined as an independent component from the DeviceSpec. A Device's channeling schema (DeviceChannelingSchema) is a subset of the generic ChannelingSchema defined for its correspondent Modality. This ontology does not define any information object in particular of a DeviceSpec.
example: Some BCI applications based on [XDF], find important to keep information regarding the hardware specifications of its Devices. Hence, a BCI application could define a classification for different type of specifications, such as: Hardware specs: Manufacturer (source [XDF], [ESS]): manufacturer of the sensor (device). Material (source [XDF]): conductive material of the sensor (e.g. Ag-AgCl, Foam, Plastic, Rubber). Model (source [XDF]): model of the sensor. Serial number (source [XDF]): serial number of the device. Its generalization was taken from the description of the "Gaze meta data". Ownership specs: Name / Label: a logical human-readable name or label of the device. Organization: organization name that owns the device.
preferred label: device specification
scope note: %CLASS_HIERARCHY% specific types of DeviceSpec.
describedby: DeviceSpec.POWDER

hasSubject
type: ObjectProperty
domain: Interaction
range: Subject
part: Session,Subject
still image: Subject.png
modified: $ 01:55 AM 2016-06-23 $
inverse of: isSubjectOf
change note: %STATUS_STABLE%
definition: Connects an Interaction with its set of Subjects.
preferred label: has subject (participant)
scope note: Connecting an Interaction with its set of Subjects
describedby: hasSubject.POWDER

NeurologicalAspect
type: Class
subclass of: Aspect
part: SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 12:47 AM 2016-05-24 $
change note: %STATUS_STABLE%
definition: Describes the classification of NeurologicalAspects. One application for this Aspect is glaucoma monitoring.
preferred label: neurological aspect
scope note: %CLASS_HIERARCHY% the NeurologicalAspects of the Records.
describedby: NeurologicalAspect.POWDER

hasAccessMethod
type: ObjectProperty
domain: RecordedData
range: AccessMethod
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 01:18 AM 2016-06-01 $
change note: %STATUS_STABLE%
definition: Connects a RecordedData with a set of AccessMethods that describes how the data is being accessed by the BCI application.
preferred label: has BCI data access method
scope note: Connecting a RecordedData with its associated AccessMethods
describedby: hasAccessMethod.POWDER

isProxyFor
type: ObjectProperty
domain: StimulusEvent
range: Modality
sub property of: isProxyFor
part: SSN-Skeleton
still image: StimulusEvent.png
modified: $ 03:35 AM 2016-07-28 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a StimulusEvent with its associated Modality-ies. This can be read, as follow: "A StimulusEvent is proxy for a Modality". This object property is a subproperty of ssn:isProxyFor: [ssn:Stimulus] ––– (ssn:isProxyFor) –––> [ssn:Property] [StimulusEvent] ––– (isProxyFor) –––––> [Modality]
editorial note: The following descriptions capture the definition of this relation (4.2.13 Stimuli-Centered, 5.3.1.2.1 Stimuli) adjusted to this ontology: The role of StimulusEvents as a proxy between the Device and the object of sensing (Context.Object). A StimulusEvent may only be usable as proxy for a specific region of an observed Modality.
preferred label: is proxy for
scope note: Connecting a StimulusEvent with its associated Modality(ies).
describedby: isProxyFor.POWDER

Context
type: Class
subclass of: Restriction
  max cardinality: 1
  on property: hasTitle
subclass of: Restriction
  min qualified cardinality: 1
  on class: Session
  on property: hasSession
subclass of: Restriction
  on property: hasLocation
  some values from: Thing
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  min qualified cardinality: 1
  on class: Playout
  on property: hasPlayout
subclass of: Restriction
  min qualified cardinality: 1
  on class: Context.Scene
  on property: hasScene
part: Context
still image: Context.png
modified: $ 01:45 2016-04-14 $
source: [Shafer2001], [Unity]
change note: %STATUS_STABLE%
definition: In [Shafer2001] we find the following definition of Context: Dey et al. define context as "any information that can be used to characterize the situation of entities (i.e., whether a person, place, or object) that are considered relevant to the interaction between a user and an application" (p. 106). Thus, context awareness implies two attributes of a system: the ability to obtain context and the ability to utilize contextual information. For the purpose of this ontology, a Context is the architectural description of the environment (external settings, components and procedures) on which a Subject interacts with it, during a Session.
editorial note: A classification (class hierarchy) for Context has been not yet defined.
example: Physical descriptions of any environment. Simulations. Video Games. Virtual Reality environments.
preferred label: context
describedby: Context.POWDER

hasDescriptor
type: ObjectProperty
domain: Class
  union of: Activity
  union of: Channel
  union of: Collection
  union of: Context
  union of: DataFormat
  union of: DataSegment
  union of: Descriptor
  union of: Interaction
  union of: Modality
  union of: Model
  union of: Playout
  union of: Session
  union of: Subject
range: Descriptor
part: AnnotationTag,Context,Descriptor,Session,SSN-MeasurementCapability,SSN-Skeleton,Subject
still image: Descriptor.png
modified: $ 01:43 AM 2016-06-30 $
change note: %STATUS_STABLE%
definition: Connects an entity with a set of Descriptors.
preferred label: has external resource (descriptor)
scope note: Connecting an entity with a set of Descriptors.
describedby: hasDescriptor.POWDER

isChannelDataOf
type: ObjectProperty
domain: Channel
range: DeviceChannelingSpec
part: SSN-MeasurementCapability
still image: MeasurementCapability.png
modified: $ 05:28 AM 2016-08-14 $
source: [XDF]
inverse of: hasChannelData
change note: %STATUS_STABLE%
definition: Connects a Channel with its associated DeviceChannelingSpec.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: is channel (logical component) data of
scope note: Connecting a Channel with its associated DeviceChannelingSpec definition.
describedby: isChannelDataOf.POWDER

hasPrevious
type: FunctionalProperty
type: ObjectProperty
domain: Class
  union of: Context.Scene
  union of: DataBlock
  union of: Record
  union of: RecordedData
range: Class
  union of: Context.Scene
  union of: DataBlock
  union of: Record
  union of: RecordedData
part: Context,SSN-Data,SSN-Skeleton
still image: DataBlock.png
still image: Context.Scene.png
modified: $ 02:50 AM 2016-07-07 $
change note: %STATUS_STABLE%
definition: Connects a (Context.Scene or Record or RecordedData or DataBlock) with its previous (Context.Scene or Record or RecordedData or DataBlock) of the sequence.
example: [Context.Scene] On a Video Game: (Level 3-2) hasPrevious (Level 3-1). [Record]: an observation is linked to its previous observation. Their difference could be on their channeling settings. [RecordedData]: links to the previous data version of the current data set. [DataBlock]: points to the previous data unit value from the current one along the sequence.
preferred label: has previous (before)
scope note: Connecting a (Context.Scene or Record or RecordedData or DataBlock) with its previous (Context.Scene or Record or RecordedData or DataBlock).
describedby: hasPrevious.POWDER

hasRole
type: ObjectProperty
domain: Context.Object
range: Context.Role
part: Context
still image: Context.Role.png
modified: $ 10:23 PM 2016-05-16 $
source: [Unity]
change note: %STATUS_STABLE%
definition: Connects a Context.Object with its Context.Role.
preferred label: has role
describedby: hasRole.POWDER

Action
type: Class
subclass of: Event
subclass of: Restriction
  min qualified cardinality: 1
  on class: PlayoutInstant.SubjectAction
  on property: hasPlayoutInstant
part: Session,Subject
still image: Activity.png
modified: $ 06:32 PM 2016-06-24 $
change note: %STATUS_STABLE%
definition: Describes any Event issued by a Subject while performing a specific Activity. Actions are considered to be structural components of an Activity, which are performed by the Subject while interacting with the Context. As an interaction event, an Action can register many PlayoutInstant.SubjectActions in a Playout.
preferred label: action
scope note: %CLASS_HIERARCHY% any relevant Action classification that Subjects can do, while performing an Activity.
describedby: Action.POWDER

hasLocation
type: ObjectProperty
domain: Context
range: Thing
sub property of: hasLocation
part: Context
modified: $ 06:22 AM 2016-08-14 $
deprecated: true
deprecated: «This ontology will not define a "location" concept of a Context. BCI applications may extend its own ontology to include this definition if necessary.» $ 06:26 AM 2016-08-14 $
change note: %STATUS_STABLE%
definition: Connects a Context with an entity that represents or describes its location.
preferred label: has location
scope note: Connecting a Context with an entity that represents or describes its location.
describedby: hasLocation.POWDER

EmotionalAspect
type: Class
subclass of: Aspect
part: SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 12:56 AM 2016-05-24 $
change note: %STATUS_STABLE%
definition: Describes the classification of EmotionalAspects.
preferred label: emotional aspect
scope note: %CLASS_HIERARCHY% the EmotionalAspects of the Records.
describedby: EmotionalAspect.POWDER

EegNonChannel
type: Class
subclass of: NonChannel
part: EEG
still image: MeasurementCapability.png
modified: $ 06:03 AM 2016-08-10 $
change note: %STATUS_STABLE%
definition: The NonChannel of a specific EegDevice.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: non-channeling EEG data component (other EEG measurement capability)
scope note: %CLASS_HIERARCHY% any relevant NonChannels specific for an EegDevice.
describedby: EegNonChannel.POWDER

Aspect
type: Class
subclass of: FeatureOfInterest
subclass of: Restriction
  on property: hasModality
  some values from: Modality
subclass of: Restriction
  max qualified cardinality: 1
  on data range: positiveInteger
  on property: hasIntensityLevel
part: SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 05:19 AM 2016-08-20 $
source: [SSN], [Compton2009]
change note: %STATUS_STABLE%
definition: [SSN] It's the classification of ssn:FeatureOfInterest for BCI Activities. This concept captures the view or interpretation for the Records.
editorial note: %GENERAL_COMMENT%@ASPECT-and-MODALITY
editorial note: The following descriptions capture the definition of this concept ([SSN: FeatureOfInterest] and [Compton2009]) adjusted to this ontology: An Aspect is an abstraction of BCI activities performed by humans, from the human body's state perspective. Devices observe physiological signals (Modality-ies) of Aspects: for example, the EEG signals (Modality) of an emotion (Aspect). Aspects are human body's states that are the target of sensing.
preferred label: aspect
scope note: %CLASS_HIERARCHY% the Aspects of the Records. Three main Aspects are defined in this ontology.
describedby: Aspect.POWDER

isObservationResultOf
type: FunctionalProperty
type: ObjectProperty
domain: RecordedData
range: Record
part: SSN-Skeleton
still image: Record.png
still image: RecordedData.png
modified: $ 03:30 AM 2016-07-22 $
inverse of: observationResult
change note: %STATUS_STABLE%
definition: Connects a RecordedData set with its correspondent Record.
preferred label: is observation result of (a BCI Record)
scope note: Connecting a RecordedData set with its correspondent Record
describedby: isObservationResultOf.POWDER

SubjectState
type: Class
subclass of: Descriptor
part: Descriptor,Session,Subject
still image: Session.png
still image: Descriptor.png
modified: $ 05:00 AM 2016-06-29 $
source: [ESS], [HED]
change note: %STATUS_STABLE%
definition: Describes the state of the Subject during the Session, throughout a collection of external specifications which capture extended metadata of the Subject's overall state. A state can be further classified properly to document more accurately the nature of the metadata (such as physiological state, cognitive state or emotional state). The nature of this concept is "transient" and depends directly on the Session: it is considered as an extended collection of metadata related to the Session that captures the overall state of the Subject during the data recording. A SubjectState is, itself, a specialized Descriptor that may have multiple Descriptors associated with, which describe extended metadata sets such as the HL7 Record.
example: Some examples of SubjectState may include descriptions regarding: Physiological state: [ESS] Age: Subject's age (in years) at the time of the Session. [ESS] Height: Subject's height in centimeters (at the moment of the Session). [ESS] Weight: Subject's weight in kilograms (at the moment of the Session). [ESS] Hearing: Subject's hearing (e.g. "CorrectedToNormal", "Impaired", "Normal"). [ESS] Vision: Subject's vision (e.g. "CorrectedToNormal", "Impaired", "Normal"). [ESS] Caffeine: number of hours since last caffeine intake, if less than 12 hours. [ESS] Alcohol: whether the Subject has consumed alcohol within 24 hours before the Session (a logical value). [ESS] Medication: specification of the medication intake based on different parameters (time, chemical compounds, etc.). Drowsiness: identified in [HED 1.31] as "awake". Stress level. [HED 1.31] Emotional state: Alertness. Some additional metadata related to this concept used for research purposes could be: A set of attributes to label the identity of the Subject in the Session. Example: [ESS] A Lab. ID as a de-personalized Subject identifier in the research lab. [ESS] A sequential ID to identify the Subject in a collection of Sessions. (Case: "InSessionNumber" attribute in [ESS 2.0]). [ESS] An attribute to identify the group type that the Subject belongs to based on the research nature of the Sessions. Example: a Session Group to identify the Subject's group (e.g. "Autistic", "Normal", "Control", etc.).
preferred label: Subject's state during a specific session
scope note: %CLASS_HIERARCHY% the different types of SubjectStates that can be found in a Session.
describedby: SubjectState.POWDER

madeEegRecord
type: InverseFunctionalProperty
type: ObjectProperty
domain: EegDevice
range: EegRecord
sub property of: madeRecord
part: EEG
still image: EegRecord.png
modified: $ 02:47 AM 2016-07-22 $
deprecated: «Concerning EEG, this ontology only defines its related classes. It does not extend or define any specific properties for EEG.» $ 04:27 AM 2016-07-29 $
deprecated: true
change note: %STATUS_STABLE%
definition: Connects an EegDevice with its correspondent EegRecords. This can be read, as follow: "An EegDevice made EegRecords". This object property is a subproperty of madeRecord: [Device] –––––– (madeRecord) ––––––> [Record] [EegDevice] ––– (madeEegRecord) –––> [EegRecord]
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: made EEG record
scope note: Connecting an EegDevice individual with its correspondent EegRecord
describedby: madeEegRecord.POWDER

isPlayoutOf
type: ObjectProperty
type: FunctionalProperty
domain: Playout
range: Class
  union of: Context
  union of: Session
part: Context
still image: Playout.png
modified: $ 02:17 AM 2016-06-23 $
change note: %STATUS_STABLE%
definition: Connects a set of Playouts with its corresponding (Context or Session).
preferred label: is playout record of
scope note: Connecting an individual with exactly one (Context or Session)
describedby: isPlayoutOf.POWDER

hasScene
type: ObjectProperty
domain: Class
  union of: Context
  union of: Context.Scene
range: Context.Scene
part: Context
still image: Context.Scene.png
modified: $ 01:06 2016-04-14 $
change note: %STATUS_STABLE%
definition: Connects a (Context or Context.Scene) with its Context.Scenes.
preferred label: has scene
scope note: Connecting a (Context or Context.Scene) with its Context.Scenes
describedby: hasScene.POWDER

XdfDataFormat
type: Class
subclass of: DataFormat
part: SSN-Skeleton
still image: RecordedData.png
conforms to: The XDF DataFormat.
modified: $ 02:16 AM 2016-06-03 $
source: [XDF]
change note: %STATUS_STABLE%
definition: Represents a XDF DataFormat. XDF is a general-purpose container format for multi-channel time series data with extensive associated meta-information. XDF is tailored towards biosignal data such as EEG, EMG, EOG, ECG, GSR, MEG, etc.
preferred label: XDF EEG data format
describedby: XdfDataFormat.POWDER

hasEegChannelData
type: ObjectProperty
domain: DeviceChannelingSpec
range: EegChannel
sub property of: hasChannelData
part: EEG
still image: MeasurementCapability.png
modified: $ 05:39 AM 2016-08-14 $
source: [XDF]
deprecated: «Concerning EEG, this ontology only defines its related classes. It does not extend or define any specific properties for EEG.» $ 04:27 AM 2016-07-29 $
deprecated: true
change note: %STATUS_STABLE%
definition: Connects an EegDeviceChannelingSpec with the set of EegChannels that comprises its internal structure.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: has EEG channel data
scope note: Connecting an EegDeviceChannelingSpec with its EegChannel set.
describedby: hasEegChannelData.POWDER

hasStartTime
type: DatatypeProperty
type: FunctionalProperty
comment: hasStartTime.POWDER
domain: Class
  union of: Playout
  union of: Record
  union of: Session
range: dateTime
part: Context,Session,SSN-Skeleton
still image: TimeInterval.png
conforms to: %DATATYPE%
modified: $ 02:44 AM 2016-06-30 $
source: [OWL-Time]
change note: %STATUS_STABLE%
definition: XSD dateTime associated to an entity, that indicates the starting-point of a time interval. BCI applications should, at least, measure these time values in seconds.
editorial note: For simplicity, this ontology does not define explicitly a TimeInterval concept.
preferred label: has start (initial) date time

hasAction
type: ObjectProperty
domain: Activity
range: Action
part: Session,Subject
still image: Activity.png
modified: $ 06:38 PM 2016-06-24 $
change note: %STATUS_STABLE%
definition: Connects an Activity with its correspondent Action set.
preferred label: has action
scope note: Connecting an Activity individual with its correspondent Action set.
describedby: hasAction.POWDER

AccessMethod.CoAP
type: Class
subclass of: AccessMethod
subclass of: Restriction
  has value: File
  on property: hasType
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 04:35 AM 2016-07-05 $
deprecated: true
deprecated: «This ontology should be agnostic to the data access» $ 04:35 AM 2016-07-05 $
change note: %STATUS_STABLE%
definition: Represents a CoAP AccessMethod. Similarly as HTTP, this software protocol supports IRI and content-type negotiation.
preferred label: CoAP access method
describedby: AccessMethod.CoAP.POWDER

isEegChannelDataOf
type: ObjectProperty
domain: EegChannel
range: DeviceChannelingSpec
sub property of: isChannelDataOf
part: EEG
still image: MeasurementCapability.png
modified: $ 05:45 AM 2016-08-14 $
source: [XDF]
deprecated: true
deprecated: «Concerning EEG, this ontology only defines its related classes. It does not extend or define any specific properties for EEG.» $ 04:27 AM 2016-07-29 $
inverse of: hasEegChannelData
change note: %STATUS_STABLE%
definition: Connects an EegChannel with its associated EegDeviceChannelingSpec.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: is EEG channel data of
scope note: Connecting an EegChannel with its associated EegDeviceChannelingSpec definition.
describedby: isEegChannelDataOf.POWDER

hasDeviceChannelingSpec
type: FunctionalProperty
type: ObjectProperty
domain: Device
range: DeviceChannelingSpec
sub property of: hasDescriptor
part: SSN-Device
still image: Device.png
modified: $ 04:33 AM 2016-07-19 $
change note: %STATUS_STABLE%
definition: Connects a Device with its related DeviceChannelingSpec.
preferred label: has device channeling schema spec
scope note: A sub property of hasDescriptor for connecting a Device with its related DeviceChannelingSpec.
describedby: hasDeviceChannelingSpec.POWDER

isSituationOf
type: ObjectProperty
domain: Class
  union of: Interaction
  union of: Session
range: Collection
part: Session,Subject
modified: $ 04:46 AM 2016-06-28 $
change note: %STATUS_STABLE%
definition: Connects a (Session set and/or an Interaction set) that are associated with a Collection.
preferred label: is situation of
scope note: Connecting a (Session set and/or an Interaction set) with its related Collection.
describedby: isSituationOf.POWDER

Model
type: Class
subclass of: Restriction
  on class: Aspect
  on property: analizes
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 1
  on class: ResponseTag
  on property: isModelOf
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  on data range: anyURI
  on property: hasModelIRI
  qualified cardinality: 1
subclass of: Restriction
  max cardinality: 1
  on property: hasTitle
part: AnnotationTag
still image: Model.png
modified: $ 11:48 PM 2016-05-22 $
change note: %STATUS_STABLE%
definition: Describes a Machine Learning Model that "detects something" in a DataSegment. A common name given for a Model is Classifier.
editorial note: In the BCI domain, all the Machine Learning processes can generate many different results. These results are called "Features". A feature is a transient information object, i.e., it has an expiration date. This concept is not defined in this ontology.
editorial note: Right after a set of DataSegments is created, two consecutive tasks occur: A set of editing processes is run on the recordings, which classify the data sets based on different Models. A set of ResponseTags ;is created, which capture the information related to "what is so special about" a particular DataSegment.
preferred label: model
describedby: Model.POWDER

Context.Role
type: Class
part: Context
still image: Context.Role.png
modified: $ 12:50 AM 2016-08-22 $
source: [Unity]
change note: %STATUS_STABLE%
definition: Specifies how a Context.Object participates (its "Role") in the Context.Scene. A Context.Object only has one Context.Role.
editorial note: This ontology does not define any specific Context.Role subclasses.
example: Character: The Context.Object participates as a character in the Context.Scene. That is, as an autonomous animated entity that interacts directly (in the foreground) with the Subject. For some BCI applications, this role describes all the Context.Objects that forms a "Protocol" or "Procedure"; that is, the ones that the Subject needs to pay attention to. Property: The Context.Object participates as a property in the Context.Scene. That is, as a co-dependant entity that can influence the configuration of any entity in a Context.Scene. Scenery: The Context.Object participates as part of the scenery in the Context.Scene. That is, as an (autonomous) animated entity that interacts indirectly (in the background) with the Subject. Some BCI applications implement simple Contexts, based solely on two structural roles for Context.Objects: Background. Foreground: where the "Protocol" or "Procedure" is implemented. Hence, the classification described above can be mapped with this terminology in the following way: Background is equivalent to the scenery role. Foreground is equivalent to the character role.
preferred label: context object role
scope note: The classification of how a Context.Object participates in a Context.Scene.
scope note: %CLASS_HIERARCHY% the different ways ("Roles") in that Context.Objects can participate in a Context.Scene.
describedby: Context.Role.POWDER

Activity
type: Class
subclass of: Restriction
  min qualified cardinality: 1
  on class: Action
  on property: hasAction
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
part: Session,Subject
still image: Activity.png
modified: $ 01:42 AM 2016-06-28 $
change note: %STATUS_STABLE%
definition: Activity is the Subject's physical state while interacting with the Context during a specific Session. This concept descirbes an Activity performed by the Subject on a specific Session while interacting with a specific Context. BCI applications monitor the Subject's physical state during the Sessions. This concept identifies the type of Activity that the Subject is performing while recording the data in a Session. Hence, each Session associates a single Subject interactions with a single Context while performing a single Activity. An Activity can be break down as a set of Actions, performed by the Subject while interacting with the Context.
editorial note: Relationship between Activity and Aspect: BCI applications are designed to analyze how an Activity influences an Aspect: it's part of the research scheme and purpose of a BCI application. From the perspective of a BCI application, an Activity has a "main" Aspect to analyze. A SPARQL triple pattern matching that connects Activity(ies) to Aspects would be: ?Session hasActivity ?Activity ?Session hasRecord ?Record ?Record bci:aspectOfInterest ?Aspect
editorial note: The concept of Activity is agnostic regarding the number of Subjects engaging in an individual Activity. The ontology clearly defines that the connection between Subjects and Activity(ies) is through Sessions: one Session associates one Subject performing one Activity while interacting with one Context. BCI applications can use this concept as a way to annotate/mark (Marker) the Records (DataSegments).
example: Some subclasses of this concept could be: Glaucoma Tracking: This Activity type is a common example for "pre-screening" of Subjects. Learning: BCI applications can apply different Stimuli (StimulusEvent) to the Subjects. This Activity type is a common example for "interactive" observations. Sleeping: BCI applications don't apply any kind of Stimuli to the Subjects (there are no StimulusEvent). This Activity type is a common example for "running" observations: continuous observations.
preferred label: activity
scope note: %CLASS_HIERARCHY% any relevant Activity classification that Subjects can engage on in Sessions.
describedby: Activity.POWDER

Playout
type: Class
subclass of: Restriction
  on data range: dateTime
  on property: hasEndTime
  qualified cardinality: 1
subclass of: Restriction
  on class: Context
  on property: isPlayoutOf
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  on data range: dateTime
  on property: hasStartTime
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 1
  on class: PlayoutInstant
  on property: hasPlayoutInstant
part: Context
still image: Playout.png
modified: $ 02:32 AM 2016-09-29 $
change note: %STATUS_STABLE%
definition: Describes the data logging (recording) of the dynamic state of the Context: the "play out" of the happenings. A Playout consist of many PlayoutInstant(ces).
preferred label: playout record
describedby: Playout.POWDER

Context.ObjectComponent
type: Class
subclass of: Object
subclass of: Restriction
  min qualified cardinality: 0
  on class: Context.ObjectComponent
  on property: hasObjectComponent
subclass of: Restriction
  max cardinality: 1
  on property: hasTitle
part: Context
still image: Context.ObjectComponent.png
modified: $ 01:35 AM 2016-08-22 $
source: [Unity]
change note: %STATUS_STABLE%
definition: Captures the architectural description of a stand-alone entity ("logical" or "physical") that structurally forms part of a Context.Object. A Context.ObjectComponent can be compose of Context.ObjectComponents.
example: Audio: A Context.ObjectComponent with audio capabilities. Camera: A Context.ObjectComponent that defines a specific visual perspective for the Subject. Effects: A Context.ObjectComponent that can define specific visual effects. Layout: A Context.ObjectComponent that can define specific layout configurations. Physics: A Context.ObjectComponent that can define specific behaviour based on Physics models. Transform: A Context.ObjectComponent that defines the logic of how an entity can move. Protocol or Procedure: some BCI applications may need to define a set of Context.Objects that the Subject needs to pay attention to. A specific type of a Transform could be defined to represent the logical behaviour or movement of an entity based on an algorithm. Video: A Context.ObjectComponent with video recording capabilities.
preferred label: context object component
scope note: %CLASS_HIERARCHY% the entities that can form any Context.Object.
describedby: Context.ObjectComponent.POWDER

Context.Object
type: Class
subclass of: Object
subclass of: Restriction
  min qualified cardinality: 1
  on class: Context.ObjectComponent
  on property: hasObjectComponent
subclass of: Restriction
  max cardinality: 1
  on property: hasTitle
subclass of: Restriction
  on class: Context.Role
  on property: hasRole
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 0
  on class: Context.Object
  on property: hasObject
part: Context
still image: Context.Object.png
modified: $ 11:10 PM 2016-05-25 $
source: [Unity]
change note: %STATUS_STABLE%
definition: Captures the architectural description of a stand-alone entity ("logical" or "physical") that participates in a Context.Scene. A Context.Object can be compose of Context.Objects. A Context.Object is compose of a non-empty set of Context.ObjectComponent.
preferred label: context object
scope note: %CLASS_HIERARCHY% the entities that participate in any Context.Scene.
scope note: Describing entities in any Context.Scene.
describedby: Context.Object.POWDER

AccessMethod.RESTful-JSON
type: Class
subclass of: AccessMethod
subclass of: Restriction
  has value: File
  on property: hasType
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 04:35 AM 2016-07-05 $
deprecated: true
deprecated: «This ontology should be agnostic to the data access» $ 04:35 AM 2016-07-05 $
change note: %STATUS_STABLE%
definition: Represents a RESTful AccessMethod, where the data is exchanged in JSON format.
preferred label: RESTful-JSON access method
describedby: AccessMethod.RESTful-JSON.POWDER

forModality
type: ObjectProperty
domain: Channel
range: Modality
sub property of: forProperty
part: SSN-MeasurementCapability
still image: Aspect-and-Modality.png
modified: $ 06:31 AM 2016-08-10 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a Channel to the supported Modality is described for. This can be read, as follow: "A Channel is described for (supports) Modality". This object property is a subproperty of ssn:forProperty: [ssn:MeasurementCapability] ––– (ssn:forProperty) –––> [ssn:Property] [Channel] –––––––––– (forModality) –––––> [Modality] [SSN] A relation from a ssn:MeasurementCapability to the ssn:Property the capability is described for. (Used in conjunction with ssn:ofFeature).
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: for modality
scope note: Connecting a Channel to the supported Modality is described for.
describedby: forModality.POWDER

hasSampleCount
type: FunctionalProperty
type: DatatypeProperty
comment: hasSampleCount.POWDER
domain: Record
range: positiveInteger
part: SSN-Skeleton
still image: Record.png
conforms to: %DATATYPE%
modified: $ 02:55 AM 2016-07-19 $
source: [XDF]
change note: %STATUS_STABLE%
definition: Counts the number of samples of the Record.
editorial note: [XDF] It is defined in the StreamFooter chunk as <sample_count>.
preferred label: has sample count

hasDateTime
type: DatatypeProperty
type: FunctionalProperty
comment: hasDateTime.POWDER
domain: Descriptor
range: dateTime
part: Descriptor
still image: Descriptor.png
conforms to: %DATATYPE%
modified: $ 12:35 AM 2016-06-29 $
source: [OWL-Time]
change note: %STATUS_STABLE%
definition: XSD dateTime associated to an entity. BCI applications should, at least, measure these time values in minutes.
preferred label: has date time

isModalityOf
type: ObjectProperty
domain: Modality
range: Aspect
sub property of: isPropertyOf
part: SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 12:28 AM 2016-07-26 $
source: [SSN]
inverse of: hasModality
change note: %STATUS_STABLE%
definition: Connects a Modality with its correspondent Aspect. This can be read, as follow: "A Modality is modality of Aspect". This object property is a subproperty of ssn:isPropertyOf: [ssn:Property] ––– (ssn:isPropertyOf) –––> [ssn:FeatureOfInterest] [Modality] ––––– (isModalityOf) ––––––––––> [Aspect]
preferred label: is modality of
scope note: Connecting a Modality with its correspondent Aspect.
describedby: isModalityOf.POWDER

Marker
type: Class
subclass of: Restriction
  max cardinality: 1
  on property: hasLabel
subclass of: Restriction
  on data range: dateTimeStamp
  on property: hasTimeStamp
  qualified cardinality: 1
subclass of: Restriction
  on class: DataSegment
  on property: pointsTo
  qualified cardinality: 1
part: AnnotationTag
still image: Marker.png
modified: $ 11:10 PM 2016-05-25 $
change note: %STATUS_STABLE%
definition: Corresponds to the "entry points" of the semantic annotations (event tags) related to a specific DataSegment. This concept captures the annotation tags of the data.
preferred label: annotation tag (or data segment pointer)
scope note: %CLASS_HIERARCHY% the type of Markers (or Annotation Tags) that define "entry points" in DataSegments. This ontology defines two types of Markers: the ResponseTag and the StimulusTag.
describedby: Marker.POWDER

hasDataBlock
type: ObjectProperty
domain: DataSegment
range: DataBlock
part: AnnotationTag
still image: DataSegment.png
modified: $ 11:39 PM 2016-06-12 $
change note: %STATUS_STABLE%
definition: Connects a DataSegment with its correspondent DataBlock set.
preferred label: has data block set
scope note: Connecting a DataSegment individual with its correspondent DataBlock set.
describedby: hasDataBlock.POWDER

NonChannel
type: Class
subclass of: MeasurementCapability
part: SSN-MeasurementCapability
still image: MeasurementCapability.png
description: ** HIDDEN CONTENT ** ============================================================================== ** editorialNote ** The BCI ontology defines this modeling structure for EEG Devices: see the definition of the Object Property hasEegNonChannelData. ==============================================================================
modified: $ 02:34 AM 2016-08-22 $
source: [SSN]
change note: %STATUS_STABLE%
definition: [SSN] The NonChannel of any Device describes a set of measurement properties (ssn:MeasurementProperty) of a sensor (ssn:Sensor) in specific conditions, as explained in SSN MeasuringCapability module, that are not related directly to any DeviceChannelingSpec. Note that the measurement properties describe in this concept are of a sensor (Device subclass of ssn:Sensor), not of a specific observed measurement (Record subclass of ssn:Observation).
editorial note: %GENERAL_COMMENT%@UNITS-OF-MEASUREMENT
editorial note: This ontology leaves open to BCI applications the way how they should describe properly basic non-channeling measurement capabilities for its relevant set of different classes of sensors (Device class hierarchy) used in BCI activities, following the description of the ssn:MeasurementCapability concept found at: (5.3.5 MeasuringCapability » 5.3.5.2 How to describe capabilities of a sensor?), (5.4.2 Smart product example » 5.4.2.3 Measurement capabilities). The sensor ontology does not restrict the way in which specific measurement properties (ssn:MeasurementProperty) are described. Thus, specialized applications may defined their own RDF properties (data or object properties) to define values of measurement properties (ssn:MeasurementProperty). If necessary, BCI applications should (but are not require to) define a set of restrictions and specialized connections (subproperties) on the property hasNonChannelData (subproperty of ssn:hasMeasurementCapability) for each particular subclass of Device (subclass of ssn:Sensor), which describes sensors for specific types. A relevant non-channeling measurement property (ssn:MeasurementProperty) related to a Device is sampling rate. Based on the modeling of the ssn:MeasurementCapability and ssn:MeasurementProperty concepts and the guidelines found in (5.4.2 Smart product example » 5.4.2.2 Sensor), this ontology defines the SamplingRate concept.
preferred label: non-channeling data component (other BCI measurement capability)
scope note: %CLASS_HIERARCHY% a set of relevant non-channeling measurement capabilities for each type of Device.
describedby: NonChannel.POWDER

ChannelingSpec
type: Class
subclass of: Descriptor
part: Descriptor,SSN-Skeleton
still image: Aspect-and-Modality.png
still image: Descriptor.png
modified: $ 11:54 PM 2016-08-08 $
change note: %STATUS_STABLE%
definition: Each Modality defines its own specific channeling schema information: a complete, generic and descriptive set of all possible Channels and their extended metadata attributes that defines the data structure model and template of the Modality. A ChannelingSpec captures the complete description of the channeling schema information, in a form of an external document specification (outside the metadata repository). Similar to the DeviceSpec concept, a ChannelingSpec is a specialized Descriptor.
example: A channeling schema information related to all kind of EegRecords would define around 32 fields (i.e., EegChannels) to describe a complete data structure regarding EEG data. The full specification for this channeling schema information would be associated with the generic EegModality concept. A proper name for this spec would be EegChannelingSpec.
preferred label: channeling schema spec
scope note: %CLASS_HIERARCHY% any relevant type of a ChannelingSpec to capture the external information that defines the complete channeling schema information of a Modality.
describedby: ChannelingSpec.POWDER

ofAspect
type: ObjectProperty
domain: Channel
range: Aspect
sub property of: ofFeature
part: SSN-MeasurementCapability
still image: Aspect-and-Modality.png
modified: $ 06:34 AM 2016-08-10 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a Channel to the Aspect is described for. This can be read, as follow: "A Channel is use to describe a property of an Aspect". This object property is a subproperty of ssn:ofFeature: [ssn:MeasurementCapability] ––– (ssn:ofFeature) –––> [ssn:FeatureOfInterest] [Channel] ––––––––––– (ofAspect) ––––––––––> [Aspect] [SSN] A relation from a ssn:MeasurementCapability to the ssn:FeatureOfInterest the capability is described for. (Used in conjunction with ssn:forProperty).
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: of aspect
scope note: Connecting a Channel to the Aspect is described for.
describedby: ofAspect.POWDER

PlayoutInstant
type: Class
subclass of: Restriction
  on data range: dateTimeStamp
  on property: hasTimeStamp
  qualified cardinality: 1
part: Context
still image: PlayoutInstant.png
modified: $ 11:03 PM 2016-05-18 $
change note: %STATUS_STABLE%
definition: Captures any relevant entry log in a Playout. Two specific type of instances are defined: PlayoutInstant.SubjectAction. PlayoutInstant.ContextEvent.
preferred label: playout instant
scope note: Describing entities that form any log entry in a Playout.
scope note: %CLASS_HIERARCHY% the types of log entries in a Playout. Two important types of log entries are defined in this ontology.
describedby: PlayoutInstant.POWDER

Device
type: Class
subclass of: SensingDevice
subclass of: Restriction
  min qualified cardinality: 0
  on class: NonChannel
  on property: hasNonChannelData
subclass of: Restriction
  min qualified cardinality: 1
  on class: Record
  on property: madeRecord
subclass of: Restriction
  on class: Modality
  on property: observes
  qualified cardinality: 1
subclass of: Restriction
  on class: DeviceChannelingSpec
  on property: hasDeviceChannelingSpec
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 1
  on class: DeviceSpec
  on property: hasDeviceSpec
subclass of: Restriction
  on property: detects
  some values from: StimulusEvent
part: SSN-Device
still image: Device.png
description: ** HIDDEN CONTENT ** ============================================================================== ** scopeNote ** %CLASS_HIERARCHY% any relevant type of BCI devices to measure specific Modality(ies) for BCI activities, such as: EEG (Electroencephalogram) device. ECG (Electrocardiogram) device. MoCap (Motion Capture) device. Example: LeapMotion (MoCap) Tracker. Eye-Gaze device (for gaze or eye-tracking). Example: EyeTribe. Audio device. Video device. Hand-Gesture device. Keyboard device. Mouse device. Visual BCI device. This ontology does not define all the BCI devices listed above. ==============================================================================
modified: $ 01:32 AM 2016-08-11 $
source: [XDF], [SSN], [Compton2009]
change note: %STATUS_STABLE%
definition: [SSN] A Device is a physical piece of technology (a system in a box) that implements a sensing method (therefore a ssn:SensingDevice) and, thus, observe some Modality (a ssn:Property) of an Aspect (a ssn:FeatureOfInterest). In the BCI domain, a Device is a physical BCI device (or sensor) that is used to measure BCI activities. A Device, of course, collects data (represented by RecordedData) in an ssn:Observation (a Record).
editorial note: [SSN] Based on the guidelines explained in the following examples: (5.3.12 Device), (5.4.1 University deployment example » 5.4.1.3 Sensor), (5.4.2 Smart product example » 5.4.2.2 Sensor), (5.4.3 Wind sensor (WM30) » 5.4.3.2 Wind Sensor system), and (5.4.4 Agriculture Meteorology Sensor Network » 5.4.4.1.3 Sensor view), Some of the core restrictions modeled for ssn:SensingDevice (Device) are: For ssn:MeasurementCapability, two distinct kinds of measurement capabilities are identified and defined: Those used for defining the Channeling Spec: a set of Channels. These are associated indirectly via the DeviceChannelingSpec concept. Other measurement capabilities not related to any channel definition: NonChannels. These are associated directly via a ssn:hasMeasurementCapability sub property, as follow: ssn:hasMeasurementCapability (hasNonChannelData) only ssn:MeasurementCapability (NonChannel): multiple instances. ssn:observes (observes) only ssn:Property (Modality): for BCI, it's implied that it only has one instance. ssn:detects (detects) only ssn:Stimulus (StimulusEvent): multiple instances; details (what made) the ssn:Sensor input. Additionally, it's important to highlight the following concepts: All physical sensor devices are represented by the class ssn:SensingDevice in the SSN ontology. Instances of this class possess all properties of the classes ssn:Sensor and ssn:Device.
editorial note: [Compton2009] According to the Sensor Ontology, a sensor has a set of independent cluster of concepts: Domain: FeatureOfInterest and PhysicalQuality. Abstract properties: OperationModel that defines a ResponseModel. Concrete properties: SensorGrounding. A Device in this ontology corresponds to the concepts for Abstract properties (#2).
preferred label: BCI device
scope note: %CLASS_HIERARCHY% any relevant type of BCI devices to measure specific Modality(ies) for BCI activities.
describedby: Device.POWDER

StimulusEvent
type: Class
subclass of: Stimulus
subclass of: Context.ObjectComponent.Event
subclass of: Restriction
  min qualified cardinality: 1
  on class: StimulusTag
  on property: isStimulusEventOf
subclass of: Restriction
  on property: isProxyFor
  some values from: Modality
part: Context,SSN-Skeleton
still image: StimulusEvent.png
description: ** HIDDEN CONTENT ** ============================================================================== ** HED class in EXAMPLE SPEC ** <owl:Class rdf:about="&bci;HED.Stimulus"> <rdfs:subClassOf rdf:resource="&bci;StimulusEvent"/> <skos:scopeNote rdf:datatype="&rdfs;Literal">%CLASS_HIERARCHY% any XXX</skos:scopeNote> <skos:example rdf:datatype="&rdfs;Literal"> HED.Auditory HED.Pain HED.Smell HED.TMS HED.Tactile HED.Taste HED.Visual </skos:example> <skos:definition rdf:datatype="&rdfs;Literal">Defines a general Stimuli HED.</skos:definition> <skos:prefLabel rdf:datatype="&rdfs;Literal">HED.Stimulus</skos:prefLabel> <DCMIType:StillImage rdf:datatype="&rdfs;Literal">HED.Stimulus_Visual.png</DCMIType:StillImage> <dct:source rdf:datatype="&rdfs;Literal">[HED]</dct:source> </owl:Class> ** HED attribute for the HED class in EXAMPLE SPEC ** <owl:DatatypeProperty rdf:about="&bci;hasHEDtag"> <skos:definition rdf:datatype="&rdfs;Literal"> Event code tag, based on "Hierarchical Event Descriptor (HED) Tags for Analysis of Event-Related EEG Studies" document, (if available, otherwise leave blank).</skos:definition> <rdfs:range rdf:resource="&rdfs;Literal"/> </owl:DatatypeProperty> ==============================================================================
modified: $ 03:08 AM 2016-07-28 $
source: [SSN]
change note: %STATUS_STABLE%
definition: A StimulusEvent describes an event that triggers a stimulus to the Subject during a Session. By its own nature, it may affect the Subject's performance of the Activity (and, therefore, a set of Actions related to the Activity). A StimulusEvent is an external happening on a specific Context that generates the input for the sensors ([SSN] concepts). Thus, these events can be generated (issued) by a set of Context.Objects (architecturally speaking by Context.ObjectComponent.Events). In [SSN], this concept is a subclass of ssn:Stimulus and, therefore, a ssn:SensorInput, which describes the (data) input for the ssn:Sensors. In the BCI domain, this concept is simply called an "Event": the stimuli or trigger that causes the relevant measurement to be, in fact, processed or analyzed.
editorial note: The following descriptions capture the definition of this concept ([SSN: Stimulus], 5.3.1.2.1 Stimuli) adjusted to this ontology: StimulusEvents are detectable changes in the environment (Context), i.e., in the physical or a virtual world. A StimulusEvent is an event in the real (or virtual) world that "triggers" the Device. StimulusEvents can either be directly or indirectly related to observable Modality-ies and, therefore, to Aspects. The same types of StimulusEvents can trigger different kinds of Devices and be used to reason about different Modality-ies. The Modality-ies associated to the StimulusEvent may be different to eventual observed (Record) Modality. It is the StimulusEvent, not the Context.Object that triggers the Device. A StimulusEvent may only be usable as proxy for a specific region of an observed Modality.
example: A StimulusEvent describes a specific component of the Context that "generates" an annotation tag (StimulusTag). Some examples of a StimulusEvent are: Red light for 15 seconds at a 66 Hz. frequency. Green light for 10 seconds at a 74 Hz. frequency.
preferred label: stimulus event
scope note: %CLASS_HIERARCHY% any relevant contextual event that describes the stimuli or trigger that causes a relevant BCI measurement.
describedby: StimulusEvent.POWDER

hasModel
type: ObjectProperty
type: FunctionalProperty
domain: ResponseTag
range: Model
part: AnnotationTag
still image: Model.png
modified: $ 02:32 AM 2016-05-23 $
inverse of: isModelOf
change note: %STATUS_STABLE%
definition: A ResponseTag is associated with (has) a Model.
preferred label: has model
scope note: Connecting a ResponseTag with its correspondent Model.
describedby: hasModel.POWDER

StimulusTag
type: Class
subclass of: Marker
subclass of: Restriction
  on class: StimulusEvent
  on property: hasStimulusEvent
  qualified cardinality: 1
part: AnnotationTag
still image: Marker.png
modified: $ 06:48 PM 2016-05-20 $
change note: %STATUS_STABLE%
definition: Information object that captures a Marker issued by a StimulusEvent. While doing the data recording, the system automatically creates a Marker (StimulusTag) for the ssn:SensorInput based on the Context (issued by a Context.ObjectComponent.Event, specifically a StimulusEvent) of the Session.
editorial note: This is one of the most important concepts in this ontology.
preferred label: stimulus tag
describedby: StimulusTag.POWDER

RecordSpec
type: Class
subclass of: Descriptor
subclass of: Restriction
  min qualified cardinality: 0
  on class: RecordSpec
  on property: hasRecordSpec
part: Descriptor,SSN-Skeleton
still image: Descriptor.png
still image: Record.png
modified: $ 03:23 AM 2016-07-19 $
source: [XDF], [ESS]
change note: %STATUS_STABLE%
definition: A RecordSpec is an information object that records (describes) specific properties (such as: specs of assistant materials, ambience settings, tools, etc.) regarding how a Record was made. Similarly to DeviceSpec, the structure of RecordSpec has been modeled as a composite object so that it can be composed as a set of RecordSpecs to describe specific parts on how a Record was made. In this way, a RecordSpec is considered as a bag of general, extended and descriptive properties about the Record settings. A RecordSpec is a specialized Descriptor. RecordSpecs can be used to record any other descriptive and extended information related to any settings or conditions on how the Record was made.
editorial note: The channeling schema of a Record is defined as an independent component from the RecordSpec. A Record's channeling schema (RecordChannelingSchema) is a subset of the DeviceChannelingSchema defined for its correspondent Device. This ontology does not define any information object in particular of a RecordSpec.
example: Some BCI applications based on [XDF], find important to keep information regarding what assistant materials (hardware) and how they were used when the Record was made. Hence, a BCI application could define a classification for different type of specifications, such as: Hardware specs for EegRecords: Coupling (source [XDF]): type of coupling used (e.g. Capacitive, Dry, Gel, Saline). Surface (source [XDF]): type of the contact surface (e.g. Bristle, Pad, Pins, Plate).
preferred label: record specification
scope note: %CLASS_HIERARCHY% specific types of RecordSpec.
describedby: RecordSpec.POWDER

hasNumberOfChannels
type: FunctionalProperty
type: DatatypeProperty
comment: hasNumberOfChannels.POWDER
domain: Class
  union of: DeviceChannelingSpec
  union of: RecordChannelingSpec
range: positiveInteger
part: SSN-Device,SSN-Skeleton
still image: Descriptor.png
still image: Record.png
conforms to: %DATATYPE%
description: ** HIDDEN CONTENT ** ============================================================================== EEG 10/20 system channeling schema. ==============================================================================
modified: $ 01:57 AM 2016-10-12 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: Captures the number of channels used in a Record or supported by a Device. Its value is expected to be a positive integer.
editorial note: [XDF]: <channel_count> is a non-negative integer that encodes the number of channels in the stream. [ESS 1.0]: number of (used) data channels.
example: Instead of using this generic datatype property, some BCI applications could define the following specific attributes, according to the recording setup, DeviceChannelingSpec and Record's Modality: Number of used LEDs. Number of used cameras.
preferred label: has number of channels

aspectOfInterest
type: ObjectProperty
type: FunctionalProperty
domain: Record
range: Aspect
sub property of: featureOfInterest
part: SSN-Skeleton
still image: Record.png
modified: $ 01:19 AM 2016-07-21 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a Record with its correspondent Aspect. This can be read, as follow: "A Record is generated by capturing an Aspect (of interest)". This object property is a subproperty of ssn:featureOfInterest: [ssn:Observation] ––– (ssn:featureOfInterest) –––> [ssn:FeatureOfInterest] [Record] ––––––– (aspectOfInterest) ––––––––––> [Aspect]
preferred label: aspect of interest
scope note: Connecting a Record individual with its correspondent Aspect
describedby: aspectOfInterest.POWDER

isValueOf
type: FunctionalProperty
type: ObjectProperty
domain: DataBlock
range: RecordedData
part: SSN-Data
modified: $ 11:19 PM 2016-06-12 $
inverse of: hasValue
change note: %STATUS_STABLE%
definition: Connects a DataBlock set with its correspondent RecordedData.
preferred label: is value of (recorded data)
scope note: Connecting a DataBlock individual with its correspondent RecordedData
describedby: isValueOf.POWDER

hasNonChannelData
type: ObjectProperty
domain: Device
range: NonChannel
sub property of: hasMeasurementCapability
part: SSN-Device
still image: MeasurementCapability.png
modified: $ 06:44 AM 2016-08-10 $
source: [SSN]
change note: %STATUS_STABLE%
definition: [SSN] Relation from a Device to a NonChannel describing the non-channeling measurement capabilities (a set of measurement properties) of the BCI device.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
editorial note: This ontology leaves open to BCI applications the way how they should describe properly basic non-channeling measurement capabilities for its relevant set of different classes of sensors (Device class hierarchy) used in BCI activities, following the description of the ssn:MeasurementCapability concept. Based on their system requirements, BCI applications may define a set of restrictions and specialized connections (subproperties) on the property hasNonChannelData (subproperty of ssn:hasMeasurementCapability) for each particular subclass of Device (subclass of ssn:Sensor), which describes sensors for specific types.
preferred label: has non-channeling data (other BCI measurement capability)
describedby: hasNonChannelData.POWDER

observes
type: ObjectProperty
domain: Device
range: Modality
sub property of: observes
part: SSN-Device
still image: MeasurementCapability.png
still image: Record.png
still image: Device.png
modified: $ 07:02 AM 2016-08-10 $
source: [SSN], [Compton2009]
property chain axiom: madeRecord
property chain axiom: observedModality
property chain axiom: hasDeviceChannelingSpec
property chain axiom: hasChannelData
property chain axiom: forModality
change note: %STATUS_STABLE%
definition: [SSN] Relation between a Device (ssn:Sensor) and a Modality (ssn:Property) that the sensor supports (can observe). The object property composition (owl:propertyChainAxiom) ensures that if a Record (ssn:Observation) is made of a particular Modality (ssn:Property), then one can infer that the Device (ssn:Sensor) supports (observes) that Modality (quality). This object property composition defines a "theoretical attribute" that describes its supported functionality: Device.madeRecord ∘ Record.observedModality ⟹ Device.observes ≔ Modality. Device.hasDeviceChannelingSpec ∘ DeviceChannelingSpec.hasChannelData ∘ Channel.forModality ⟹ Device.observes ≔ Modality.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
scope note: Connecting a Device individual with its correspondent supported Modality individual.
describedby: observes.POWDER

hasChannelingSpec
type: FunctionalProperty
type: ObjectProperty
domain: Modality
range: ChannelingSpec
sub property of: hasDescriptor
part: SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 01:43 AM 2016-06-30 $
change note: %STATUS_STABLE%
definition: Connects a Modality with its related ChannelingSpec.
preferred label: has channeling schema spec
scope note: A hasDescriptor sub property for connecting a Modality with its related ChannelingSpec.
describedby: hasChannelingSpec.POWDER

hasSamplingRate
type: DatatypeProperty
type: FunctionalProperty
comment: hasSamplingRate.POWDER
domain: Record
range: float
part: SSN-Skeleton
still image: Record.png
conforms to: %DATATYPE%
modified: $ 02:49 AM 2016-08-22 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: Sampling rate of the recording (Record). Its measurement unit is Hz.
editorial note: Related concept for a Device: SamplingRate.
editorial note: [ESS 2.0] Sampling rate of the modality (in Hz). In some file formats, e.g. XDF, each modality may be recorded at a different sampling rate.
preferred label: (a record) has sampling rate

hasPlayoutInstant
type: ObjectProperty
type: InverseFunctionalProperty
domain: Class
  union of: Action
  union of: Context.ObjectComponent.Event
  union of: Playout
range: PlayoutInstant
part: Context,Session
still image: Activity.png
still image: PlayoutInstant.png
modified: $ 02:39 AM 2016-06-23 $
change note: %STATUS_STABLE%
definition: Connects a (Playout or Context.ObjectComponent.Event or Action) with its correspondent PlayoutInstant(ces) log entries.
preferred label: has playout instant
scope note: Connecting a (Playout or Context.ObjectComponent.Event or Action) individual with its correspondent PlayoutInstant(ces)
describedby: hasPlayoutInstant.POWDER

EegRecord
type: Class
subclass of: Record
subclass of: Restriction
  on class: EegDevice
  on property: observedByEegDevice
  qualified cardinality: 1
part: EEG
still image: Record.png
modified: $ 04:09 AM 2016-08-05 $
change note: %STATUS_STABLE%
definition: Defines a broader type of an EEG Record, which represents the class of observations for EEG (Electroencephalography) data.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: EEG record
scope note: %CLASS_HIERARCHY% any relevant EegRecords, based on specialized EegModality(ies), that BCI applications may require.
describedby: EegRecord.POWDER

hasDeviceSpec
type: ObjectProperty
domain: Class
  union of: Device
  union of: DeviceSpec
range: DeviceSpec
sub property of: hasDescriptor
part: SSN-Device
still image: Device.png
modified: $ 01:43 AM 2016-06-30 $
source: [XDF], [ESS]
change note: %STATUS_STABLE%
definition: Connects a (Device or DeviceSpec) with its set of related DeviceSpecs.
preferred label: has device spec
scope note: A hasDescriptor sub property for connecting a (Device or DeviceSpec) with its set of DeviceSpecs.
describedby: hasDeviceSpec.POWDER

EegChannel
type: Class
subclass of: Channel
part: EEG
still image: MeasurementCapability.png
modified: $ 08:25 AM 2016-08-14 $
source: [XDF], [ESS]
change note: %STATUS_STABLE%
definition: Defines a broader type of an EEG Channel (channeling scheme information component), used in BCI applications to collect EEG (Electroencephalography) data. This concept relates directly to the notion of an electrode capturing brainwave activity.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
example: BCI applications based on [ESS] and [XDF], could define the following channeling metadata attributes for an EegModality spec: Label: [ESS 2.0]: a comma separated list of labels corresponding channels. This node is required for EEG Modality. [XDF]: EEG channel label, according to the labeling scheme. For EEG, the preferred labeling scheme is 10-20 (or the finer-grained 10-5). Placement: [ESS 2.0]: location of the reference channel or channels used during EEG or ECG recording. Should only be provided if the ModalitySignalType (Modality) is EEG or ECG. For EEG, the preferred location convention is presented below. Choose between the following values (or provide a new value if the reference is not any of these options): { "Right Mastoid", "Left Mastoid", "Mastoids", "Linked Mastoids" [for electrically linked mastoids], "Cz" [top of the head], "CMS" [e.g. in BIOSEMI], "Left Ear", "Right Ear", "Ears", "Average", "Nasion", "Nose" }. For Wilson Central Terminal ECG reference use "WCT". [XDF]: { LocationX, LocationY, LocationZ }: 3D position (measured location) of the electrode on the head's surface based on a coordinate system (frame of reference). Each value is described as: { LocationX }: coordinate axis pointing from the center of the head to the right, in millimeters. { LocationY }: coordinate axis pointing from the center of the head to the front, in millimeters. { LocationZ }: coordinate axis pointing from the center of the head to the top, in millimeters. XDF states that if the used coordinate system is arbitrary, the application should then include well-known fiducials (landmarks) for co-registration. LocationType = { 10-10, 10-20, 10-5, Custom, EGI }: channel location type/standard used. [XDF] ChannelFormat = { double64, float32, int16, int32, int64, int8, string }: corresponds to the <channel_format> field of the StreamHeader chunk section. It's one of the 3 required fields in the XDF header. [XDF] Signal Referencing Scheme: isCommonAverage: (boolean data type); "…
preferred label: EEG channel
scope note: %CLASS_HIERARCHY% any relevant EegChannels, based on specialized EegModality(ies), that BCI applications may require.
describedby: EegChannel.POWDER

Record
type: Class
subclass of: Observation
subclass of: Restriction
  min qualified cardinality: 1
  on class: RecordSpec
  on property: hasRecordSpec
subclass of: Restriction
  on property: includesEvent
  some values from: StimulusEvent
subclass of: Restriction
  on class: Subject
  on property: isRecordOf
  qualified cardinality: 1
subclass of: Restriction
  on data range: positiveInteger
  on property: hasSampleCount
  qualified cardinality: 1
subclass of: Restriction
  on data range: dateTime
  on property: hasStartTime
  qualified cardinality: 1
subclass of: Restriction
  on class: RecordChannelingSpec
  on property: hasRecordChannelingSpec
  qualified cardinality: 1
subclass of: Restriction
  on data range: float
  on property: hasSamplingRate
  qualified cardinality: 1
subclass of: Restriction
  on data range: dateTime
  on property: hasEndTime
  qualified cardinality: 1
subclass of: Restriction
  on class: Modality
  on property: observedModality
  qualified cardinality: 1
subclass of: Restriction
  max qualified cardinality: 1
  on class: Record
  on property: hasPrevious
subclass of: Restriction
  min qualified cardinality: 1
  on class: RecordedData
  on property: observationResult
subclass of: Restriction
  on class: Aspect
  on property: aspectOfInterest
  qualified cardinality: 1
subclass of: Restriction
  on class: Session
  on property: isRecordOf
  qualified cardinality: 1
subclass of: Restriction
  max qualified cardinality: 1
  on class: Record
  on property: hasNext
subclass of: Restriction
  on class: Device
  on property: observedByDevice
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 0
  on class: MeasurementProperty
  on property: hasMeasurementProperty
part: SSN-Skeleton
still image: Record.png
description: ** HIDDEN CONTENT ** ============================================================================== ** scopeNote ** %CLASS_HIERARCHY% any relevant type of BCI records generated by BCI devices for BCI activities, such as: EEG (Electroencephalogram) record. ECG (Electrocardiogram) record. MoCap (Motion Capture) record. Eye-Gaze record (for gaze or eye-tracking): A BCI Record that stores the coordinates of user's eye gaze captured by eye trackers. Audio record. Video record. Hand-Gesture record: A BCI Record that stores the coordinates and velocities of user's hands and fingers captured by trackers such as LeapMotion. Keyboard-Hit (keystroke) record: A BCI Record that stores the subject's hits on different keyboard keys. Mouse-Click record: A BCI Record that stores the position coordinates of a subject's clicks with different mouse buttons. Visual BCI record. This ontology does not define all the BCI records listed above. ==============================================================================
modified: $ 01:26 AM 2016-08-23 $
source: [SSN], [ESS]
change note: %STATUS_STABLE%
definition: A Record is a type of ssn:Observation with the following characteristics: A single ssn:Observation for a specific unimodal BCI data capture task (with its own purpose). [SSN] A Sensing Method is used to estimate or calculate a value of a specific ssn:Property (Modality) based on a specific ssn:FeatureOfInterest (Aspect). A single Device is used to observe the unimodal BCI data (RecordedData). [SSN]: Record, along with its related concepts, defines an appropiate structure based on the following description: "An observation (Record) is a situation that describes an observed feature (Aspect), an observed property (Modality), a sensor (Device) and method of sensing used and a value (RecordedData) observed for the property: that is, an observation (Record) describes a single value (RecordedData) attributed to a single property (Modality) by a particular sensor (Device)". In the BCI domain, it's common that some related observations occur immediately after an observation has ended, by changing some of its initial channeling or Device settings (parameters or conditions). Hence, it is desirable to keep a temporal tracking of the previous and following related observations. This is achieved via the hasPrevious and hasNext object properties. The logical data structure template of a Record is defined in its associated RecordChannelingSpec information object. Additional relevant metadata can be extended via the object property hasMeasurementProperty.
editorial note: [SSN] States that "an Observation is a description of the context, the Situation, in which the observation was made". In this ontology, the Context is directly related through the Session, which is a Situation where the Observation (Record) was made.
editorial note: [SSN] Following the structure presented in this example, the Record concept has been modeled to describe BCI observations, including the following object properties: SSN object property BCI object subproperty Between (from)... ... and (to) ssn:featureOfInterest aspectOfInterest ssn:Observation (Record) ssn:FeatureOfInterest (Aspect) ssn:observedProperty observedModality ssn:Observation (Record) ssn:Property (Modality) ssn:observedBy observedByDevice ssn:Observation (Record) ssn:Sensor («sub subclass» Device) DUL:includesEvent includesEvent ssn:Observation (Record) ssn:Stimulus (StimulusEvent) ssn:observationResult observationResult ssn:Observation (Record) ssn:SensorOutput (RecordedData) ssn:isProducedBy isProducedByDevice ssn:SensorOutput (RecordedData) ssn:Sensor («sub subclass» Device) ssn:hasValue hasValue ssn:SensorOutput (RecordedData) ssn:ObservationValue (DataBlock) Proper restrictions have been designed accordingly for each object property.
editorial note: [SSN] Following the guidelines explained in (5.3.6 Observation) and (5.4.2 Smart product example » 5.4.2.4 Observation), the main restrictions modeled for ssn:Observation (Record) are: Exactly 1 ssn:FeatureOfInterest (Aspect): details what was sensed. Exactly 1 ssn:Property (Modality): details what was sensed. Exactly 1 ssn:Sensor («sub subclass» Device): describes what made the Observation. Some ssn:Stimulus (StimulusEvent): details (what made) the ssn:Sensor input. Other restrictions are: Exactly 1 ssn:Sensing (describes how the Observation was made): not adjusted for BCI activities.
history note: In [ESS 1.0]: Corresponds to the "eegRecordings" node: a specific collection of raw BCI data collected from a subject in a specific session. In [ESS 2.0]: Corresponds to the "dataRecordings" node: information about EEG (or other data modality) recordings.
preferred label: BCI record (measurement record)
scope note: %CLASS_HIERARCHY% any relevant type of BCI records generated by BCI devices for BCI activities.
describedby: Record.POWDER

hasPlayout
type: InverseFunctionalProperty
type: ObjectProperty
domain: Class
  union of: Context
  union of: Session
range: Playout
part: Context,Session
still image: Playout.png
modified: $ 07:16 PM 2016-05-18 $
inverse of: isPlayoutOf
change note: %STATUS_STABLE%
definition: Connects a (Context or Session) with its set of Playouts.
preferred label: has playout record
scope note: Connecting a (Context or Session) with its Playouts.
describedby: hasPlayout.POWDER

ResponseTag
type: Class
subclass of: Marker
subclass of: Restriction
  on data range: float
  on property: hasConfidence
  qualified cardinality: 1
subclass of: Restriction
  on class: Model
  on property: hasModel
  qualified cardinality: 1
subclass of: Restriction
  cardinality: 1
  on property: hasState
part: AnnotationTag
still image: Marker.png
modified: $ 07:01 PM 2016-05-22 $
change note: %STATUS_STABLE%
definition: Information object that captures a Marker issued by a Model. In the BCI domain, a natural (physiological or neurological) change in the Subject's state while doing an Activity, is simply called a State. A ResponseTag could not be directly linked to a change in the Context (issued by a Context.ObjectComponent.Event, specifically a StimulusEvent) in a Session. A ResponseTag represents "something" detected by a Machine Learning Model (Model).
editorial note: Right after a set of DataSegments is created, two consecutive tasks occur: A set of editing processes is run on the recordings, which classify the data sets based on different Models. A set of ResponseTags ;is created, which capture the information related to "what is so special about" a particular DataSegment.
editorial note: This is one of the most important concepts in this ontology.
example: In a common M2M semantic search query, the following input parameters may be used to retrieve a set of ResponseTags related to its DataSegments: Activity: for example, driving. Aspect: for example, vigilance and alert. Modality: for example, EEG, EOG. Subject: filtered by gender, age, etc.
preferred label: state (response tag)
describedby: ResponseTag.POWDER

extendsChannelingSpec
type: FunctionalProperty
type: ObjectProperty
domain: DeviceChannelingSpec
range: ChannelingSpec
sub property of: hasDescriptor
part: Descriptor,SSN-Device
still image: Aspect-and-Modality.png
modified: $ 03:18 AM 2016-07-29 $
change note: %STATUS_STABLE%
definition: Connects a DeviceChannelingSpec with its related ChannelingSpec. This relation states that a DeviceChannelingSpec individual extends its related ChannelingSpec from which was derivated.
preferred label: extends its modality channeling schema spec
scope note: A hasDescriptor sub property that connects a DeviceChannelingSpec with its related ChannelingSpec.
describedby: extendsChannelingSpec.POWDER

hasType
type: FunctionalProperty
type: DatatypeProperty
comment: hasType.POWDER
domain: AccessMethod
range: Datatype
  one of: File
  one of: Stream
part: SSN-Skeleton
still image: RecordedData.png
conforms to: %DATATYPE%
modified: $ 01:55 AM 2016-06-01 $
change note: %STATUS_STABLE%
definition: Indicates the AccessMethod's type: the nature of how the RecordedData can be accessed. This ontology only defines the two following Access Method Type: "File": archived access method. "Stream": real-time access method.
preferred label: has access method type (nature)

RecordChannelingSpec
type: Class
subclass of: DeviceChannelingSpec
subclass of: Restriction
  on data range: nonNegativeInteger
  on property: hasEndChannel
  qualified cardinality: 1
subclass of: Restriction
  on class: ChannelingSpec
  on property: extends
  qualified cardinality: 1
subclass of: Restriction
  on class: DeviceChannelingSpec
  on property: extendsDeviceChannelingSpec
  qualified cardinality: 1
subclass of: Restriction
  on data range: positiveInteger
  on property: hasNumberOfChannels
  qualified cardinality: 1
subclass of: Restriction
  on data range: nonNegativeInteger
  on property: hasStartChannel
  qualified cardinality: 1
part: Descriptor,SSN-Skeleton
still image: Aspect-and-Modality.png
still image: Record.png
still image: Descriptor.png
modified: $ 11:15 PM 2016-08-08 $
change note: %STATUS_STABLE%
definition: Based on the adjusted settings of the DeviceChannelingSpec made for the observation, a Record has its own specific channeling schema information: that is, the logical components (Channels) and their extended generic metadata set that describe the Record's own logical data structure (specific to the observation and the Subject), according to the recording setup. A RecordChannelingSpec captures two information sets for a specific Record: Its complete channeling schema description, in a form of an external document specification (outside the metadata repository). Relevant metadata attributes regarding the general characteristics of the channeling schema: a set of related Channels. The structure described in a RecordChannelingSpec (first information set mentioned above) is based on a concrete subset of the DeviceChannelingSpec that the Device supports. Hence, for practical reasons, a RecordChannelingSpec is defined as a subclass of DeviceChannelingSpec.
editorial note: The channeling schema information objects are structured in the following way: The Channeling Schema of a... Modality (ChannelingSpec): it's the complete theoretical spec; the generic template for a specific ssn:Property. ––––> Device (DeviceChannelingSpec): it's a functional subset of the ChannelingSpec; ––––> defines the logical subset of the complete spec for the specific functionality of a ssn:SensingDevice. ––––––––> Record (RecordChannelingSpec): it's the concrete subset of the DeviceChannelingSpec for a specific ssn:Observation. ––––––––> This information object is user specific according to recording setup.
example: A RecordChannelingSpec for an EegRecord would define the values of the positions for specific EegChannels used by the EegDevice, when the observation is made. A proper name for this spec would be EegRecordChannelingSpec. For "Precision" Records, BCI applications may find important to keep the information regarding the Channel's positions (coordinates).
preferred label: record channeling schema spec
scope note: %CLASS_HIERARCHY% any relevant type of a RecordChannelingSpec to capture the external information that defines the channeling schema information of a Record.
describedby: RecordChannelingSpec.POWDER

hasIntensityLevel
type: FunctionalProperty
type: DatatypeProperty
comment: hasIntensityLevel.POWDER
domain: Aspect
range: positiveInteger
part: SSN-Skeleton
still image: Aspect-and-Modality.png
conforms to: %DATATYPE% Its Domain value is all the positive integers: { 1, 2, 3, ... }
modified: $ 12:21 AM 2016-05-24 $
change note: %STATUS_STABLE%
definition: Indicates the level of intensity related to its concept.
editorial note: Aspect: the measurement of the intensity depends on the nature of the Aspect and purpose of the BCI application.
preferred label: has intensity level

hasStartChannel
type: DatatypeProperty
type: FunctionalProperty
comment: hasStartChannel.POWDER
domain: RecordChannelingSpec
range: nonNegativeInteger
part: SSN-Skeleton
still image: Descriptor.png
still image: Record.png
conforms to: %DATATYPE%
modified: $ 01:59 AM 2016-07-19 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: The channel number in the recording where the modality block starts.
preferred label: has start channel

hasModality
type: ObjectProperty
domain: Aspect
range: Modality
sub property of: hasProperty
part: SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 12:21 AM 2016-07-26 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects an Aspect with its correspondent Modality set. This can be read, as follow: "An Aspect has Modality(ies)". This object property is a subproperty of ssn:hasProperty: [ssn:FeatureOfInterest] ––– (ssn:hasProperty) –––> [ssn:Property] [Aspect] –––––––––– (hasModality) –––––> [Modality]
preferred label: has modality
scope note: Connecting an Aspect with its correspondent Modality set.
describedby: hasModality.POWDER

hasRecord
type: ObjectProperty
type: InverseFunctionalProperty
domain: Class
  union of: Session
  union of: Subject
range: Record
part: Session,Subject
still image: Record.png
modified: $ 12:07 AM 2016-06-24 $
change note: %STATUS_STABLE%
definition: Connects a (Subject or Session) with a set of Records that are associated with it.
preferred label: has BCI record
scope note: Connecting a (Subject or Session) with its related set of Records
describedby: hasRecord.POWDER

hasEndTime
type: FunctionalProperty
type: DatatypeProperty
comment: hasEndTime.POWDER
domain: Class
  union of: Playout
  union of: Record
  union of: Session
range: dateTime
part: Context,Session,SSN-Skeleton
still image: TimeInterval.png
conforms to: %DATATYPE%
modified: $ 02:44 AM 2016-06-30 $
source: [OWL-Time]
change note: %STATUS_STABLE%
definition: XSD dateTime associated to an entity, that indicates the ending-point of a time interval. BCI applications should, at least, measure these time values in seconds.
editorial note: For simplicity, this ontology does not define explicitly a TimeInterval concept.
preferred label: has end (final) date time

extends
type: FunctionalProperty
type: ObjectProperty
domain: RecordChannelingSpec
range: ChannelingSpec
sub property of: hasDescriptor
part: Descriptor,SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 03:41 AM 2016-07-29 $
property chain axiom: extendsDeviceChannelingSpec
property chain axiom: extendsChannelingSpec
change note: %STATUS_STABLE%
definition: Relation between a RecordChannelingSpec and a ChannelingSpec that the observation extends through the associated DeviceChannelingSpec. The object property composition (owl:propertyChainAxiom) ensures that if a DeviceChannelingSpec extends a particular ChannelingSpec, then one can infer that the RecordChannelingSpec also extends that ChannelingSpec. This object property composition describes the extended spec of the channeling schema information object: RecordChannelingSpec.extendsDeviceChannelingSpec ∘ DeviceChannelingSpec.extendsChannelingSpec ⟹ RecordChannelingSpec.extends ≔ ChannelingSpec.
preferred label: extends its related modality channeling schema spec
scope note: A hasDescriptor sub property that connects a RecordChannelingSpec with its related ChannelingSpec.
describedby: extends.POWDER

Modality
type: Class
subclass of: Property
subclass of: Restriction
  on class: ChannelingSpec
  on property: hasChannelingSpec
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  on property: isModalityOf
  some values from: Aspect
part: SSN-Skeleton
still image: Aspect-and-Modality.png
description: ** HIDDEN CONTENT ** ============================================================================== ** scopeNote ** %CLASS_HIERARCHY% any relevant type of human signals (Modality Signal Type —nature of the data—) analyzed by BCI applications, such as: EEG (Electroencephalogram). ECG (Electrocardiogram). MoCap (Motion Capture). Eye-Gaze (for gaze or eye-tracking). Audio. Video. Hand-Gesture. Keyboard-Hit. Mouse-Click. This ontology does not define all the modalities listed above. ==============================================================================
modified: $ 05:19 AM 2016-08-20 $
source: [SSN], [Compton2009]
change note: %STATUS_STABLE%
definition: [SSN]: A Modality is a kind of an "Observable Quality", i. e., an aspect (the human signals) of an entity (the human body) that is intrinsic to and cannot exist without the entity and is observable by a sensor (Device). In the BCI domain, the Modality defines a certain type of measurement (classification) related to a specific kind of data due to its nature. Literally, Modality means the "Mode of the data". The Modality defines, in an intrinsic manner, the operational functionality of any Device based on its related ChannelingSpec information. That is, a specific type of Device operates for a specific type of Modality: the nature of the data sensed. Each Modality must have its own complete and generic ChannelingSpec information.
editorial note: %GENERAL_COMMENT%@ASPECT-and-MODALITY
editorial note: The following descriptions capture the definition of this concept ([SSN: Property] and [Compton2009]) adjusted to this ontology: An observable Quality of human physiological signals. That is, a characteristic of an Aspect (human body's state) that is intrinsic to and cannot exist without the Aspect and is observable by a Device. Devices observe physiological signals (Modality-ies) of Aspects: for example, the EEG signals (Modality) of an emotion (Aspect).
editorial note: A Modality has its own specific: Measurement procedures, Applications (each one with relevant attributes), and Stimuli.
history note: [ESS 1.0]: This data object describes the name of the different type of modalities recorded in a study. Corresponds to the (/study/summary/recordedModalities/modality/name) node definition. [ESS 2.0]: It contains information about one or more set of recording data parameters (which can apply to multiple Records). Corresponds to the (/study/recordingParameterSets/recordingParameterSet) node definition. Most studies have only a single parameter set, i. e., the same types of data (EEG, Mocap, etc.) are recorded in the same channel ranges, with the same device types and with the same sampling rates. This "recordings parameter set" is associated with Records nodes (which represent the "dataRecording" nodes).
preferred label: recorded modality
scope note: %CLASS_HIERARCHY% any relevant type of human signals (Modality Signal Type —nature of the data—) analyzed by BCI applications.
describedby: Modality.POWDER

hasTitle
type: DatatypeProperty
type: FunctionalProperty
comment: hasTitle.POWDER
domain: Class
  union of: Collection
  union of: Context
  union of: Context.Object
  union of: Context.ObjectComponent
  union of: Context.ObjectComponent.Event
  union of: Context.Scene
  union of: Descriptor
  union of: Interaction
  union of: Session
range: Literal
part: Context,Descriptor,Session
conforms to: %DATATYPE%
modified: $ 03:24 AM 2016-09-29 $
change note: %STATUS_STABLE%
definition: The given title or logical name of an entity. It is used to associate a human-readable label to entities.
preferred label: has title

AccessMethod.MQTT
type: Class
subclass of: AccessMethod
subclass of: Restriction
  has value: Stream
  on property: hasType
subclass of: Restriction
  cardinality: 1
  on property: hasMQTT.ID
subclass of: Restriction
  min cardinality: 1
  on property: hasMQTT.Topic
subclass of: Restriction
  cardinality: 1
  on property: hasMQTT.Broker
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 04:35 AM 2016-07-05 $
deprecated: «This ontology should be agnostic to the data access» $ 04:35 AM 2016-07-05 $
deprecated: true
change note: %STATUS_STABLE%
definition: Represents a MQTT AccessMethod, which is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. MQTT was designed as an extremely lightweight publish/subscribe messaging transport. This concept describes the corresponding definition of access parameters needed for a suitable MQTT connection.
preferred label: MQTT Access Method
describedby: AccessMethod.MQTT.POWDER

extendsDeviceChannelingSpec
type: ObjectProperty
type: FunctionalProperty
domain: RecordChannelingSpec
range: DeviceChannelingSpec
sub property of: hasDescriptor
part: Descriptor,SSN-Skeleton
still image: Aspect-and-Modality.png
modified: $ 02:21 AM 2016-07-29 $
change note: %STATUS_STABLE%
definition: Connects a RecordChannelingSpec with its related DeviceChannelingSpec. This relation states that a RecordChannelingSpec individual extends its related DeviceChannelingSpec from which was derivated.
preferred label: extends its device channeling schema spec
scope note: A hasDescriptor sub property that connects a RecordChannelingSpec with its related DeviceChannelingSpec.
describedby: extendsDeviceChannelingSpec.POWDER

hasValue
type: ObjectProperty
type: InverseFunctionalProperty
domain: RecordedData
range: DataBlock
sub property of: hasValue
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 11:11 PM 2016-06-12 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a RecordedData with its correspondent DataBlock set. This object property is a subproperty of ssn:hasValue: [ssn:SensorOutput] ––– (ssn:hasValue) –––> [ssn:ObservationValue] [RecordedData] ––––– (hasValue) –––––––> [DataBlock]
editorial note: A SPARQL triple pattern matching to find the DataBlocks of a Record via this object property would be: ?Record bci:observationResult ?RecordedData ?RecordedData bci:hasValue ?DataBlock ( Based on the following relationships: [Record] –––– (observationResult) –––> [RecordedData] [RecordedData] ––––– (hasValue) –––––––> [DataBlock] )
preferred label: has value (data blocks)
scope note: Connecting a RecordedData individual with its correspondent DataBlocks
describedby: hasValue.POWDER

madeRecord
type: ObjectProperty
type: InverseFunctionalProperty
domain: Device
range: Record
sub property of: madeObservation
part: SSN-Device
still image: Record.png
modified: $ 02:47 AM 2016-07-22 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a Device with its correspondent Records. This can be read, as follow: "A Device made Records". This object property is a subproperty of ssn:madeObservation: [ssn:Sensor] ––– (ssn:madeObservation) –––> [ssn:Observation] [Device] ––––––––– (madeRecord) –––––––––> [Record]
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: made BCI record
scope note: Connecting a Device individual with its correspondent Record
describedby: madeRecord.POWDER

EegDevice
type: Class
subclass of: Device
subclass of: Restriction
  min qualified cardinality: 1
  on class: EegRecord
  on property: madeEegRecord
subclass of: Restriction
  min qualified cardinality: 0
  on class: EegNonChannel
  on property: hasEegNonChannelData
part: EEG
still image: Device.png
modified: $ 03:51 AM 2016-08-05 $
change note: %STATUS_STABLE%
definition: Defines a broader type of an EEG Device, used in BCI applications to collect EEG (Electroencephalography) data.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: EEG device
scope note: %CLASS_HIERARCHY% any relevant EegDevices, based on specialized EegModality(ies), that BCI applications may require.
describedby: EegDevice.POWDER

detects
type: ObjectProperty
domain: Device
range: StimulusEvent
sub property of: detects
part: SSN-Device
still image: StimulusEvent.png
modified: $ 02:02 AM 2016-07-25 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a Device with its correspondent StimulusEvent set. This can be read, as follow: "A Device detects StimulusEvent". This object property is a subproperty of ssn:detects: [ssn:Sensor] ––– (ssn:detects) –––> [ssn:Stimulus] [Device] ––––– (detects) –––> [StimulusEvent] [SSN] A relation from a ssn:Sensor to the ssn:Stimulus that the ssn:Sensor can detect.
scope note: Connecting a Device individual with its correspondent StimulusEvent set.
describedby: detects.POWDER

isPlayoutInstantOf
type: ObjectProperty
type: FunctionalProperty
domain: PlayoutInstant
range: Class
  union of: Action
  union of: Context.ObjectComponent.Event
  union of: Playout
part: Context
modified: $ 02:41 AM 2016-06-23 $
inverse of: hasPlayoutInstant
change note: %STATUS_STABLE%
definition: Connects a PlayoutInstant log entry with its correspondent individual (Playout or Context.ObjectComponent.Event orAction) that issued its creation.
preferred label: is the playout instant of
scope note: Connecting a PlayoutInstant with its correspondent (Playout or Context.ObjectComponent.Event or Action) individual.
describedby: isPlayoutInstantOf.POWDER

isSessionOf
type: FunctionalProperty
type: ObjectProperty
domain: Session
range: Class
  union of: Context
  union of: Interaction
  union of: Subject
part: Session
still image: Session.png
modified: $ 10:13 PM 2016-06-23 $
change note: %STATUS_STABLE%
definition: Connects a Session with its associated (Context or Interaction or Subject).
preferred label: is session of
scope note: Connecting a Session with its related (Context or Interaction or Subject).
describedby: isSessionOf.POWDER

AccessMethod
type: Class
subclass of: Restriction
  on data range: anyURI
  on property: hasLocator
  qualified cardinality: 1
subclass of: Restriction
  cardinality: 1
  on property: hasType
part: SSN-Skeleton
still image: RecordedData.png
description: ** HIDDEN CONTENT ** ============================================================================== ** definition ** "(a network communication protocol and its parameters)" The identity scheme of the data access. The security scheme of the protocol. ** scopeNote ** %CLASS_HIERARCHY% the network communication protocols that BCI applications can use to access and retrieve the RecordedData. This ontology defines some of the aforementioned network communication protocols, commonly used by BCI applications. ** editorialNote ** This ontology does not define in any specific way the components regarding the identity and security schemes of an AccessMethod. This information could be extended, for example, through a set of undefined-general-purpose datatype properties to capture the following corresponding definitions: For the identity scheme of the data access: hasIdentity. For the security scheme of the protocol: hasSecurity and hasQoS. ==============================================================================
modified: $ 04:34 AM 2016-07-06 $
change note: %STATUS_STABLE%
definition: This concept captures any computer network mechanism (network communication protocol) through which the RecordedData can be accessed. An AccessMethod represents any specific standard communication protocol, such as: MQTT, MQTT-SN, HTTP, CoAP, FTP, etc. For the purpose of this ontology, an AccessMethod captures only the following components: Nature of the data access: file or stream. The locator (address) of the data.
editorial note: The publish/subscribe mechanism is one of the preferred implementations for BCI applications.
editorial note: The concept will be merged into the generic abstraction of <container> under the oneM2M spec, and made compatible with its emerging semantic extension. A <container> represents a "data collection" and, therefore, it's directly related to the RecordedData concept.
preferred label: BCI data access method
describedby: AccessMethod.POWDER

EegModality
type: Class
subclass of: Modality
part: EEG
still image: Aspect-and-Modality.png
modified: $ 01:30 AM 2016-10-12 $
change note: %STATUS_STABLE%
definition: A specific type of Modality for EEG (Electroencephalography). This modality can be further classified depending on different measurement procedures, applications and set of stimuli.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: EEG modality
scope note: %CLASS_HIERARCHY% any relevant EEG modalities. Following, we present a possible classification for this type: ERP (Event Related Potential -voltage-): related to a stimuli. VEP: Video. SSVEP: Steady-State. Caused by Flickering Visual Stimuli (2 different stimuli). Applications: Migraine (SSVE MSE - Complexity) and Glaucoma (mfVEP - Vision Field Sensitivity). TVEP: Transient. AEP: Aural "Free Run".
describedby: EegModality.POWDER

hasEndChannel
type: DatatypeProperty
type: FunctionalProperty
comment: hasEndChannel.POWDER
domain: RecordChannelingSpec
range: nonNegativeInteger
part: SSN-Skeleton
still image: Descriptor.png
still image: Record.png
conforms to: %DATATYPE%
modified: $ 01:59 AM 2016-07-19 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: The channel number in the recording where the modality block ends.
preferred label: has end channel

hasLabel
type: FunctionalProperty
type: DatatypeProperty
comment: hasLabel.POWDER
domain: Class
  union of: Channel
  union of: Marker
range: Literal
part: AnnotationTag,SSN-MeasurementCapability
conforms to: %DATATYPE%
modified: $ 03:19 AM 2016-08-14 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: A human-readable and descriptive label for general identification purposes associated to an instance.
editorial note: If necessary, BCI applications may extend the definition of this attribute to specify the preferred notation scheme, using the semantic annotation skos:notation.
history note: Related to Channel, this concept has the following definitions: [ESS 2.0]: a comma separated list of labels of the corresponding referenced channel or channels. This node is required for EEG Modality and it's used during EEG or ECG recording. For example, if using 10-20 system and numerical average of both mastoids, use "A1, A2" for {referenceLabel} and "Mastoids" for {referenceLocation}. Note that there could be multiple labels. [XDF] Signal referencing scheme: name of the dedicated reference channel(s), if part of the measured channels (repeated if multiple). For an EEG channel label, its value is based on the labeling scheme. For EEG, the preferred labeling scheme is 10-20 (or the finer-grained 10-5).
preferred label: has label
scope note: In a Channel: this attribute is used for codification (reference) and search (access) purposes, according to a preferred labeling scheme (see the editorial note). In a Marker: this attribute indicates a marker type. For example: "110" = "Red light being flashed".

Interaction
type: Class
subclass of: Situation
subclass of: Restriction
  max cardinality: 1
  on property: hasTitle
subclass of: Restriction
  min qualified cardinality: 2
  on class: Subject
  on property: hasSubject
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  min qualified cardinality: 0
  on class: Collection
  on property: isSituationOf
subclass of: Restriction
  min qualified cardinality: 2
  on class: Session
  on property: hasSession
part: Session,Subject
still image: Subject.png
modified: $ 01:05 AM 2016-06-23 $
change note: %STATUS_STABLE%
definition: A situation where multiple (more than one) Subjects interact with each other, while each is performing a single Activity. Commonly, it's expected that all the Subjects in an Interaction engage in the same Activity, but it's not required. Due that an Interaction group a set of Sessions (potentially many for each Subject), BCI applications can make correlations among these Sessions.
editorial note: This concept defines a Cluster of Sessions: a cross-sectional collection of multiple related Sessions that occur at the same time.
preferred label: Interaction of multiple subjects
describedby: Interaction.POWDER

hasRecordSpec
type: ObjectProperty
domain: Class
  union of: Record
  union of: RecordSpec
range: RecordSpec
sub property of: hasDescriptor
part: SSN-Skeleton
still image: Record.png
modified: $ 03:01 AM 2016-07-18 $
source: [XDF], [ESS]
change note: %STATUS_STABLE%
definition: Connects a (Record or RecordSpec) with its set of related RecordSpecs.
preferred label: has record spec
scope note: A hasDescriptor sub property for connecting a (Record or RecordSpec) with its set of RecordSpecs.
describedby: hasRecordSpec.POWDER

hasRecordChannelingSpec
type: ObjectProperty
type: FunctionalProperty
domain: Record
range: RecordChannelingSpec
sub property of: hasDescriptor
part: SSN-Skeleton
still image: Record.png
modified: $ 03:24 AM 2016-07-18 $
change note: %STATUS_STABLE%
definition: Connects a Record with its related RecordChannelingSpec.
preferred label: has record channeling schema spec
scope note: A hasDescriptor sub property for connecting a Record with its related RecordChannelingSpec.
describedby: hasRecordChannelingSpec.POWDER

hasObject
type: ObjectProperty
domain: Class
  union of: Context.Object
  union of: Context.Scene
range: Context.Object
part: Context
still image: Context.Object.png
modified: $ 09:27 PM 2016-05-16 $
source: [Unity]
change note: %STATUS_STABLE%
definition: Connects a (Context.Scene or Context.Object) with the set of Context.Objects that comprises its internal structure.
preferred label: has object
scope note: Connecting a (Context.Scene or Context.Object) with its Context.Objects
describedby: hasObject.POWDER

hasModelIRI
type: DatatypeProperty
type: FunctionalProperty
comment: hasModelIRI.POWDER
domain: Model
range: anyURI
part: AnnotationTag
still image: Marker.png
conforms to: %DATATYPE%
modified: $ 02:03 AM 2016-05-23 $
change note: %STATUS_STABLE%
definition: It's the IRI of the resource that describes or represents the Model or classifier. A Model can be described in any language or format, such as PMML.
preferred label: has model IRI

RecordedData
type: Class
subclass of: SensorOutput
subclass of: Restriction
  on class: DataFormat
  on property: hasDataFormat
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 1
  on class: DataBlock
  on property: hasValue
subclass of: Restriction
  max qualified cardinality: 1
  on class: RecordedData
  on property: hasPrevious
subclass of: Restriction
  min qualified cardinality: 0
  on class: RecordedData
  on property: hasNext
subclass of: Restriction
  min qualified cardinality: 1
  on class: AccessMethod
  on property: hasAccessMethod
subclass of: Restriction
  on class: Device
  on property: isProducedByDevice
  qualified cardinality: 1
subclass of: Restriction
  on class: Record
  on property: isObservationResultOf
  qualified cardinality: 1
part: SSN-Skeleton
still image: RecordedData.png
still image: Record.png
modified: $ 11:43 PM 2016-08-17 $
source: [SSN]
change note: %STATUS_STABLE%
definition: [SSN] It is a specific type of a ssn:SensorOutput (a piece of information outputted by a Device in an ssn:Observation: an observed value) for BCI activities. The value itself is being represented by a specific type of an ssn:ObservationValue (a sequence of DataBlocks). This concept abstracts a raw data set (independent of its representation and access method) outputted by a Device for a specific Modality. In this way, a RecordedData has: A single data representation, a DataFormat, and multiple AccessMethods (either archived or in real-time). In the BCI domain, it's common that the data "evolves" over time. That is, there are changes on the data structure: from its "initial" state (ever since it's collected from a Device: raw data) to "following" states (when applying specialized algorithms to recognizes patterns throughout Models: transformed data). For example, for EEG data its evolution over time resembles a tree structure. Hence, it is desirable for BCI applications to keep a temporal tracking of the previous and following versions of the data: a derived data tree throughout keeping links between data versions. This is achieved via the hasPrevious and hasNext object properties.
editorial note: From the perspective of the data (RecordedData): Its physical structure is defined through the DataFormat. Its logical structure is defined through the associated RecordChannelingSpec of its Record (the defined collection of Channels).
preferred label: recorded BCI data
describedby: RecordedData.POWDER

Collection
type: Class
subclass of: Restriction
  on property: hasDescriptor
  some values from: Descriptor
subclass of: Restriction
  min qualified cardinality: 1
  on class: Session
  on property: hasSituation
subclass of: Restriction
  cardinality: 1
  on property: hasTitle
subclass of: Restriction
  min qualified cardinality: 0
  on class: Interaction
  on property: hasSituation
part: Session
still image: Session.png
modified: $ 04:57 AM 2016-06-28 $
source: [ESS]
change note: %STATUS_STABLE%
definition: Groups a collection of related Sessions and/or Interactions, which may be associated with different Activity(ies).
editorial note: Collection generalizes the concept of Study as defined in [ESS]: a set of data collection efforts to answer one or few related scientific questions. This concept defines a longitudinal (temporal) collection of Sessions.
preferred label: collection
describedby: Collection.POWDER

pointsTo
type: ObjectProperty
type: FunctionalProperty
domain: Marker
range: DataSegment
part: AnnotationTag
still image: DataSegment.png
modified: $ 12:07 AM 2016-06-13 $
change note: %STATUS_STABLE%
definition: Connects a Marker with a DataSegment.
preferred label: points to
scope note: Connecting a Marker individual with a DataSegment.
describedby: pointsTo.POWDER

hasOffset
type: DatatypeProperty
type: FunctionalProperty
comment: hasOffset.POWDER
domain: DataBlock
range: long
part: SSN-Data
still image: DataBlock.png
conforms to: %DATATYPE%
modified: $ 04:17 AM 2016-06-12 $
change note: %STATUS_STABLE%
definition: Indicates the offset (start time) of the DataBlock. Its measurement unit (dimensional) is in milliseconds.
preferred label: has offset

DataSegment
type: Class
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  min qualified cardinality: 0
  on class: Marker
  on property: isReferencedBy
subclass of: Restriction
  min qualified cardinality: 1
  on class: DataBlock
  on property: hasDataBlock
part: AnnotationTag
still image: DataSegment.png
modified: $ 10:05 PM 2016-06-12 $
change note: %STATUS_STABLE%
definition: It is a logical data entity that group a set of sequentially linked DataBlocks, and thus, identifies a proper subset of a RecordedData. A time interval is implicitly found between the first DataBlock (startTime) and the last DataBlock (endTime) of the DataSegment. In the BCI domain: A DataSegment conforms the basic data unit for "tagging" purposes, i. e., to associate semantic annotations (event tags or Markers) to the data (DataBlock sets). A DataSegment is a collection of DataBlocks that expands a certain time interval. A DataSegment is considered a logical data entity (whereas a DataBlock is considered a physical data entity).
editorial note: Right after a set of DataSegments is created, two consecutive tasks occur: A set of editing processes is run on the recordings, which classify the data sets based on different Models. A set of ResponseTags is created, which capture the information related to "what is so special about" a particular DataSegment.
preferred label: data segment
describedby: DataSegment.POWDER

isModelOf
type: InverseFunctionalProperty
type: ObjectProperty
domain: Model
range: ResponseTag
part: AnnotationTag
still image: Model.png
modified: $ 01:55 AM 2016-06-23 $
change note: %STATUS_STABLE%
definition: A Model has associated a set of ResponseTags.
preferred label: is model of
scope note: Connecting a Model with its correspondent set of ResponseTags.
describedby: isModelOf.POWDER

isProducedByDevice
type: ObjectProperty
type: FunctionalProperty
domain: RecordedData
range: Device
sub property of: isProducedBy
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 05:11 AM 2016-07-22 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a RecordedData with its correspondent Device that produced it. This can be read, as follow: "A RecordedData is produced by a Device". This object property is a subproperty of ssn:isProducedBy: [ssn:SensorOutput] ––– (ssn:isProducedBy) –––> [ssn:Sensor] [RecordedData] ––– (isProducedByDevice) –––> [Device]
preferred label: is produced by device
scope note: Connecting a RecordedData with its correspondent Device that produced it.
describedby: isProducedByDevice.POWDER

causes
type: ObjectProperty
domain: Context.ObjectComponent.Event
range: Action
part: Context
still image: Activity.png
modified: $ 12:44 AM 2016-06-28 $
change note: %STATUS_STABLE%
definition: A Context.ObjectComponent.Event may influence an Activity, by causing (triggering) a set of Actions.
editorial note: The relationship between an Activity and a Context is throughout a Session, which connects also the Subject (who performs the Activity while interacting with the Context).
scope note: Connecting a Context.ObjectComponent.Event individual with a correspondent Action set.
describedby: causes.POWDER

Subject
type: Class
subclass of: Person
subclass of: NaturalPerson
subclass of: Restriction
  min qualified cardinality: 0
  on class: Interaction
  on property: isSubjectOf
subclass of: Restriction
  min qualified cardinality: 1
  on class: Session
  on property: hasSession
subclass of: Restriction
  min qualified cardinality: 1
  on class: Record
  on property: hasRecord
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
part: Subject
still image: Subject.png
modified: $ 10:49 PM 2016-06-23 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: A specific person (probably anonymous but possessing unique identity) with certain attributes on which the Sessions are recorded (from which the data is observed: Record). The concept is based on the notion of Patient, specifically from a standarized Electronic Patient/Medical Record, such as the HL7 Record. An information object of this class, describes the Medical and Physiological "Condition" of a Subject. Therefore, it may have multiple Descriptors associated (such as HL7 Records or specific XML vocabularies from the industry). This ontology does not define any specific set of attributes associated to a Subject. BCI applications con extend this concept according to their information needs and system requirements.
editorial note: The Subject is the point of reference (focus) of the data monitoring and data analysis, from which BCI applications collect Measurement Recordings. Hence, the name Subject instead of Person.
example: [ESS] and [XDF] define some useful data type properties (attributes) associated to a Subject. Some examples of these attributes are: Gender: Defined as an enumerated value = { Female, Male, ... }. It can be derived as a subproperty extended from the (dbp:Person).sex property definition. Year of birth (YOB): Defined as a positive integer greater or equal than 1900. It can be derived as a subproperty extended from the dbp:Person definition. Handedness: Defined as an enumerated value = { Ambidextrous, Left, N/A, Right }. Subject's dominantly used hand. Related to medical record. Hearing: Defined as an enumerated value = { CorrectedToNormal, Impaired, Normal }. Subject's hearing condition. Related to medical record. Vision: Defined as an enumerated value = { CorrectedToNormal, Impaired, Normal }. Subject's vision condition. Related to medical record.
preferred label: subject (or person)
describedby: Subject.POWDER

hasSubjectState
type: ObjectProperty
domain: Session
range: SubjectState
sub property of: hasDescriptor
part: Session
still image: Session.png
modified: $ 01:43 AM 2016-06-30 $
change note: %STATUS_STABLE%
definition: Connects a Session with a set of SubjectStates which describe the overall state of the Subject during the Session.
preferred label: has subject state
scope note: A hasDescriptor sub property for connecting a Session with a set of SubjectStates
describedby: hasSubjectState.POWDER

hasMeasurementProperty
type: ObjectProperty
domain: Record
range: MeasurementProperty
part: SSN-Skeleton
still image: Record.png
modified: $ 01:26 AM 2016-08-23 $
change note: %STATUS_STABLE%
definition: Connects a Record with a set of ssn:MeasurementProperty-ies. Through this relationship, BCI applications may extend the relevant metadata set related to the Record concept.
preferred label: has SSN measurement property
scope note: Connecting a Record with a ssn:MeasurementProperty set.
describedby: hasMeasurementProperty.POWDER

PlayoutInstant.SubjectAction
type: Class
subclass of: PlayoutInstant
part: Context
still image: PlayoutInstant.png
modified: $ 05:27 PM 2016-05-19 $
change note: %STATUS_STABLE%
definition: Captures a relevant entry log in a Playout of a Subject's Event issued by an Action instance during a Session.
preferred label: playout instant: subject action type
scope note: Events (Actions) issued by a Subject during a Session.
describedby: PlayoutInstant.SubjectAction.POWDER

ProtocolBuffersDataFormat
type: Class
subclass of: DataFormat
part: SSN-Skeleton
still image: RecordedData.png
conforms to: Google Protocol Buffers DataFormat
modified: $ 02:25 AM 2016-06-03 $
change note: %STATUS_STABLE%
definition: Represents a Protocol Buffers DataFormat, which is a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols and data storage.
preferred label: protocol buffers BCI data format
describedby: ProtocolBuffersDataFormat.POWDER

Channel
type: Class
subclass of: MeasurementCapability
subclass of: Restriction
  on property: forModality
  some values from: Modality
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  cardinality: 1
  on property: hasLabel
subclass of: Restriction
  on property: ofAspect
  some values from: Aspect
subclass of: Restriction
  on property: isChannelDataOf
  some values from: DeviceChannelingSpec
part: SSN-MeasurementCapability
still image: MeasurementCapability.png
modified: $ 04:30 AM 2016-08-20 $
source: [SSN], [XDF], [ESS]
change note: %STATUS_STABLE%
definition: A Channel is a relevant metadata set that defines a logical component schema of a DeviceChannelingSpec's data structure model. A Channel is defined as a specialized ssn:MeasurementCapability type that describes a compounded set of measurement properties (ssn:MeasurementProperty-ies), as explained in SSN MeasuringCapability module. A Channel is associated to a DeviceChannelingSpec definition and, hence, to a RecordChannelingSpec. As part of a channeling spec, a Channel definition can be extended to incorporate contextual metadata semantics (i.e., properties to describe dimensional characteristics regarding what, when, how —including mathematical formulas for calculations—, where, why, etc.), depending on the DataFormat used for the data files. This information can be associated to a channel definition via a Descriptor set.
editorial note: BCI systems naturally collects and transmits data from a sender (transmitter machine) to a receiver (receiving machine). In a general and abstract way, a channel is used to convey an information signal, for example a digital bit stream, from one or several senders (or transmitters) to one or several receivers. The concept of channel defined in this ontology aims to capture a relevant metadata set that describes the measurement properties for any type of channel.
editorial note: A simplistic notion regarding the relationship and difference between the concepts of Channel and DataFormat, is depicted in the following example: If the used DataFormat were "CSV", then the channeling schema (DeviceChannelingSpec) would define the data's logical structure: [Channeling Schema] = { Col1: ID, Col2: Date, Col3: Name, ... }, where each column represents a specific Channel definition. Note that each column has its own related metadata and attributes; also, it follows its proper structure, format or notation scheme, etc.
editorial note: %GENERAL_COMMENT%@UNITS-OF-MEASUREMENT
editorial note: Channels are the logical components of Records. Their structural relationship resembles a matrix, in the following way: [rows] Channels are different data rows. ⇉ ⇉ ⇉ ⇉ [columns] Data samples are different data columns. They correspond to specific time instances. ⇊ ⇊ ⇊ ⇊ ⇊ Hence, Channels can point to specific parts of a Record.
editorial note: Channel Structure: The channel structure is composed of different related metadata and attributes. It varies widely depending on the following: the related/associated Modality. the functional "role" that plays in a Device's data model, and, the way how it's used in a specific Record settings. Due that a channeling spec is directly associated with a Device and a Record, in theory, a channel defines a specific (or proper) logical data structure component for a Device and/or a Record. The most common metadata and attributes of a channel structure, regardless of its nature, are: Label: defined as hasLabel. Type: defined as the channel class type (class hierarchy). Placement (or Location): refers to the attribute set that define its placement on a Subject. The placement's attribute structure varies widely depending on the channel's nature.
example: [XDF] Eye-Gaze Channel: channeling metadata for an Eye-Gaze Record. CoordinateSystem = { World-Space, Object-Space, Camera-Space, or Image-Space }: coordinate system of the respective parameter. RefersTo = { Left, Right, or Both }: which eye the channel is referring to. Type: Type of data in this channel. It can be any of the following values: { ScreenX, ScreenY }: screen coordinates of the gaze cursor (can also refer to a scene image); usually in pixels. { DirectionX, DirectionY, DirectionZ }: 3D gaze vector in some coordinate system. { PositionX, PositionY, PositionZ }: 3D position of the eye center in some coordinate system. { IntersectionX, IntersectionY, IntersectionZ }: 2D or 3D position of the intersection point with a plane (in some coordinate system). { HeadX, HeadY, HeadZ }: 3D location of the head center in some coordinate system. { PupilX, PupilY, PupilZ }: 2D or 3D location of the pupil center in some coordinate system. { ReflexX, ReflexY, ReflexZ }: 2D or 3D location of the illuminator's reflection point in some coordinate system. { Radius or Diameter }: the overall pupil radius or diameter (usually in mm or pixels). { RadiusX, RadiusY }: horizontal and vertical pupil radius. { DiameterX, DiameterY }: horizontal and vertical pupil diameter. { Confidence }: for confidence information (preferred unit: normalized). { FrameNumber }: frame number that the parameters were calculated from. { PlaneNumber or ObjectId }: number or identifier of the object that was intersected by the gaze vector. Keyboard-Hit Channel: channeling metadata for a Keyboard-Hit Record. [XDF] Hand-Gesture Channel: channeling metadata for a Hand-Gesture Record. Type = { Confidence, OrientationH, OrientationP, OrientationR, PositionX, PositionY, PositionZ }: type of data. [following types from GazeMetaData & "LeapMotion_xml_output" definitions.] Mouse-Click Channel: channeling metadata for a Mouse-Click Record. Type = { PositionX, PositionY }. Button = { Left, Other, Right, Wheel }.
preferred label: channeling data (logical component)
scope note: %CLASS_HIERARCHY% specialized channel definitions related to specific Modality types.
describedby: Channel.POWDER

analizes
type: ObjectProperty
type: FunctionalProperty
domain: Model
range: Aspect
part: AnnotationTag
still image: Model.png
modified: $ 01:55 AM 2016-06-28 $
change note: %STATUS_STABLE%
definition: Indicates that an Aspect is analized by a Model (throughout its States): analyzing looking for specific kind of Markers. A Model is specific to the purpose of its BCI application, such as: stress level measurement or fatigue detection.
scope note: Connecting a Model with an Aspect.
describedby: analizes.POWDER

hasChannelData
type: ObjectProperty
domain: DeviceChannelingSpec
range: Channel
part: SSN-Device
still image: MeasurementCapability.png
modified: $ 05:19 AM 2016-08-14 $
source: [XDF]
change note: %STATUS_STABLE%
definition: Connects a DeviceChannelingSpec with the set of Channels that comprises its internal structure.
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: has channel data (logical component)
scope note: Connecting a DeviceChannelingSpec with its Channel set.
describedby: hasChannelData.POWDER

isRecordOf
type: ObjectProperty
type: FunctionalProperty
domain: Record
range: Class
  union of: Session
  union of: Subject
part: SSN-Skeleton
still image: Record.png
modified: $ 12:16 AM 2016-06-24 $
inverse of: hasRecord
change note: %STATUS_STABLE%
definition: Connects a Record with its associated (Subject or Session).
preferred label: is BCI record of
scope note: Connecting a Record with its related (Subject or Session).
describedby: isRecordOf.POWDER

hasConfidence
type: FunctionalProperty
type: DatatypeProperty
comment: hasConfidence.POWDER
domain: ResponseTag
range: float
part: AnnotationTag
still image: Marker.png
conforms to: %DATATYPE% Its Domain value consists of approximated arbitrary real numbers in the close range of [0..1].
modified: $ 09:23 PM 2016-05-22 $
change note: %STATUS_STABLE%
definition: Captures the accuracy (statistical level of confidence) of the ResponseTag.
example: Example: 0.75
preferred label: has confidence

Session
type: Class
subclass of: Situation
subclass of: Restriction
  min qualified cardinality: 1
  on class: Record
  on property: hasRecord
subclass of: Restriction
  on data range: dateTime
  on property: hasStartTime
  qualified cardinality: 1
subclass of: Restriction
  on class: Playout
  on property: hasPlayout
  qualified cardinality: 1
subclass of: Restriction
  on class: Subject
  on property: isSessionOf
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 0
  on class: Collection
  on property: isSituationOf
subclass of: Restriction
  max cardinality: 1
  on property: hasTitle
subclass of: Restriction
  on data range: dateTime
  on property: hasEndTime
  qualified cardinality: 1
subclass of: Restriction
  on class: Context
  on property: isSessionOf
  qualified cardinality: 1
subclass of: Restriction
  on class: Activity
  on property: hasActivity
  qualified cardinality: 1
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  max qualified cardinality: 1
  on class: Interaction
  on property: isSessionOf
subclass of: Restriction
  min qualified cardinality: 0
  on class: SubjectState
  on property: hasSubjectState
part: Session
still image: Session.png
modified: $ 03:03 AM 2016-07-01 $
source: [ESS], [SSN]
change note: %STATUS_STABLE%
definition: A Session is a DUL:Situation that monitors how one Subject interacts with one Context while performing one Activity, throughout collecting a nonempty set of multimodal biomedical ssn:Observations (Records). A Session has the following characteristics and restrictions: Comprises a collection of multimodal BCI data capture tasks (each one with its own specific measurement purpose: Aspect). Monitors exactly one Subject. Monitors exactly one Activity (performed by the Subject). Monitors exactly one Context (while the Subject interacts with it). Comprises exactly one Playout collected from the associated Context. Groups different and multiple Records (multimodal data) that are observed (collected) simultaneously from the Subject. [SSN]: The concept of Session defines an appropiate structure to group multiple Records (multimodal data), based on the following description: "Observations (Records) of multiple features (Aspects) or multiple properties (Modality-ies) of the one feature should be represented as either compound properties, features and values or as multiple observations, grouped in some appropriate structure". In the BCI research domain, a Session can have multipurpose extended metadata sets to describe broader concepts and definitions regarding the nature and purpose of this information object. These external metadata sets can be associated with Descriptors.
example: External descriptions that complement and extend the information about a Session, can be added through Descriptors. BCI applications based on [ESS 1.0] could define Descriptors to include information, such as: Lab. ID. – identifier of the session used in the original lab notes (if available, otherwise insert 'NA'). Task Label. – indicates which task is being performed in the session (e.g. A, B, C,...). Only use this node if there are different tasks. Otherwise leave the node blank. For Session entities: If different tasks occur in the same session repeat the session node with a different "taskLabel", and other information that may be different, such as the "eegRecording" node. For EventCode entities: Use this only if there are multiple tasks in the study and they use the same event codes, otherwise leave blank.
history note: In [ESS 2.0], a Session is related to the RecordedParameterSet concept, found in the following XML element: (../recordingParameterSet/recordingParameterSetLabel). The "recordingParameterSet" node groups the information of multiple Modality-ies and, also, DeviceSpecs. Hence, it implies that a Session (a Record set) is associated (used) with multiple Devices, due of the "dataRecording" node definition in ESS (multiple RecordedData).
preferred label: BCI session
describedby: Session.POWDER

DataFormat
type: Class
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
part: SSN-Skeleton
still image: RecordedData.png
modified: $ 11:58 PM 2016-08-17 $
change note: %STATUS_STABLE%
definition: This concept describes any Data Format that BCI applications use to represent and store the RecordedData. A DataFormat represents any specific standard data format used in one of the following ways: Signal (electrical engineering). File format. Content format.
editorial note: A DataFormat should properly define its encoding scheme.
preferred label: BCI data format
scope note: %CLASS_HIERARCHY% the data formats that BCI applications can use to represent and store the RecordedData. This ontology defines some common data formats used in the BCI domain.
describedby: DataFormat.POWDER

hasOrdinalPosition
type: FunctionalProperty
type: DatatypeProperty
comment: hasOrdinalPosition.POWDER
domain: DataBlock
range: positiveInteger
part: SSN-Data
still image: DataBlock.png
conforms to: %DATATYPE%
modified: $ 03:44 AM 2016-06-12 $
change note: %STATUS_STABLE%
definition: Indicates the ordinal position of the DataBlock.
preferred label: has (ordinal) position

hasTimeStamp
type: FunctionalProperty
type: DatatypeProperty
comment: hasTimeStamp.POWDER
domain: Class
  union of: Channel
  union of: DataBlock
  union of: Marker
  union of: PlayoutInstant
range: dateTimeStamp
part: AnnotationTag,Context,SSN-Data,SSN-MeasurementCapability
still image: Marker.png
still image: PlayoutInstant.png
conforms to: %DATATYPE%
modified: $ 12:34 AM 2016-06-29 $
source: [OWL-Time]
change note: %STATUS_STABLE%
definition: XSD dateTimeStamp of a specific time instant. BCI applications are recommended to measure the time with high precision, in order to keep a proper granularity for this measurement unit. BCI applications should, at least, measure the time instants in milliseconds.
preferred label: has time stamp

observedByDevice
type: ObjectProperty
type: FunctionalProperty
domain: Record
range: Device
sub property of: observedBy
part: SSN-Skeleton
still image: Record.png
modified: $ 02:47 AM 2016-07-22 $
source: [SSN]
inverse of: madeRecord
change note: %STATUS_STABLE%
definition: Connects a Record with its correspondent Device. This can be read, as follow: "A Record is observed by a Device". This object property is a subproperty of ssn:observedBy: [ssn:Observation] ––– (ssn:observedBy) –––> [ssn:Sensor] [Record] –––– (observedByDevice) ––––> [Device]
editorial note: %GENERAL_COMMENT%@EEG-CONCEPTS
preferred label: observed by device
scope note: Connecting a Record individual with its correspondent Device
describedby: observedByDevice.POWDER

Brain Computing Interface (BCI) Ontology
type: Ontology
comment: This ontology describes the framework of core concepts to capture the specialized metadata vocabulary set for multimodal "Brain Computing Interface" (BCI) data capture activities. This ontology is developed by the "Pervasive Embedded Technologies" Laboratory (PET Lab) at the Computer Science Department of the National Chiao Tung University (NCTU), Taiwan (Republic of China, R.O.C). The concepts and structure of the ontology depict a foundational metadata model for BCI data capture activities, that BCI applications can extend and use in their implementations. Any feedback is welcome. Please mail it to srodriguez@pet.cs.nctu.edu.tw
license: https://creativecommons.org/licenses/by-sa/4.0/
still image: <preview alt="(3) — Visual Notation (VOWL) of the Ontology">03-webvowl-preview.png</preview> <show> </show>
still image: <preview alt="(4) — OWLGrEd Model of the Ontology">04-OWLGrEd-preview.png</preview> <show> </show>
still image: <preview alt="(2) — Complete UML diagram of the BCI Ontology">02-complete-UML-diagram.png</preview> <show />
still image: <preview alt="(1) — Core structure and modules of the BCI Ontology">01-core-structure.png</preview> <show />
abstract: The BCI ontology specifies a foundational metadata model set for real-world multimodal Brain Computing Interface (BCI) data capture activities. Its structure depicts a conceptual framework that BCI applications can extend and use in their implementations, to define core concepts that capture a relevant and interoperable metadata vocabulary. The ontology is aligned to the Semantic Sensor Network Ontology (SSN): a domain-independent and end-to-end model for sensing applications. Hence, its structure has been normalized to assist its use in conjunction with other ontologies or linked data resources to specify any particular definitions (such as, units of measurement, time and time series, and location and mobility), that specialized applications in the BCI domain might need. Also, this spec provides general alignment data modeling guidelines for core concepts, to help BCI applications in their design.
created: 2014-03-27
creator: Sergio José Rodríguez Méndez. Pervasive Embedded Technologies Laboratory (PET Lab), Computer Science Department, NCTU, Taiwan. John K. Zao. Pervasive Embedded Technologies Laboratory (PET Lab), Computer Science Department, NCTU, Taiwan and CerebraTek, Taiwan.
description: The BCI ontology provides a high level semantic structure specialized metadata vocabulary set for real-world multimodal BCI data capture activities. The ontology defines a minimalist and simple abstract metadata foundational model for real-world BCI applications that monitors human activity in any scenario. BCI multimodal domain applications are encouraged to extend and use this ontology in their implementations. This ontology was developed following W3C Semantic Web ontology standards and guidelines, so that BCI applications can express reusable, interoperable and extendable machine-readable BCI metadata models, especially in pervasive M2M environments. For this purpose, its design was aligned to the Semantic Sensor Network Ontology (SSN), following closely its Stimulus-Sensor-Observation Ontology Design Pattern. The core and generic set of relevant metadata definitions for real-world BCI activities depicted on this ontology, were taken from different proposed vocabularies and formats in the BCI domain, such as: XDF, ESS and HED. The BCI ontology concepts are logically grouped in 10 modules. Each module represents a central topic of the ontology structure where the related concepts give a consistent explanation about its functional data model. The modules are: Subject: concepts related to the depiction of a human being (or human subject) engaging in an activity and its associate state. Context: captures the architectural description of an environment (or context). A human being interacts with a context. Session: represents the interaction between a subject and a context while performing a single activity, under specific settings and conditions. SSN-Skeleton: specific related concepts for BCI activities aligned to the Skeleton of SSN. Metadata related to records, modality types (such as EEG), channeling information, output streams (file formats and access) and stimulus events, are found in this module. SSN-Device: specific related concepts for BCI activities aligned…
issued: 2014-03-27
modified: $ 11:26 PM 2016-10-13 $
references: [Compton2009] Compton, M.; Neuhaus, H.; Taylor K. and Tran, K. Reasoning about Sensors and Compositions. In Proceedings of the 2nd International Workshop on Semantic Sensor Networks (SSN 09) at ISWC 2009, pp. 33-48, 2009. URL=http://ceur-ws.org/Vol-522/p7.pdf. [ESS] SCCN, "EEG Study Schema (ESS)". Resources: [ESS@SCCN], [ESS v2.0]. [HED] N. Bigdely-Shamlo, K. Kreutz-Delgado, M. Miyakoshi, M. Westerfield, T. Bel-Bahar, C. Kothe and K. Robbins, "Hierarchical event descriptor (HED) tags for analysis of event-related EEG studies". Resources: [HED@SCCN], [HED v2.0]. [OWL-Time] W3C, "Time Ontology in OWL", https://www.w3.org/TR/owl-time/ [Shafer2001] Shafer, Steven A. N.; Brumitt, Barry; Cadiz, J. J. Interaction Issues in Context-aware Intelligent Environments. Human-Computer Interaction. Volumen 16, Issue 2 (December 2001), Pp. 363-378. DOI=http://dx.doi.org/10.1207/S15327051HCI16234_16. URL=http://dl.acm.org/citation.cfm?id=1463124. [SSN] W3C, "Semantic Sensor Network (SSN) Ontology", http://www.w3.org/2005/Incubator/ssn/ssnx/ssn.html. W3C Semantic Sensor Network Incubator Group, "Semantic Sensor Network XG Final Report", http://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/. [Unity] Unity Gaming Platform (http://unity3d.com/), Unity's Gaming Modeling Architecture Manual http://docs.unity3d.com/Manual/index.html [XDF] C. Kothe and C. Brunner, "XDF (Extensible Data Format)", https://code.google.com/p/xdf/
rights: Copyright 2014 - 2016 PET Lab, Computer Science Department, NCTU, Taiwan.
table of contents: (visualise the BCI-ontology with LODE)
preferred namespace prefix: bci
preferred namespace uri: https://w3id.org/BCI-ontology#
imports: ontology
imports: DUL.owl
imports: ssn
prior version: 0.9.9,0.9.5,0.9.1
version info: 1.0.0
editorial note: Regarding the treatment of measurement units This ontology leaves open to BCI applications, the way how they should handle the semantic expressiveness level of measurement units. In general, there are two possible ways (based on their data requirements): For data-centric applications: defining relevant measurement properties (ssn:MeasurementProperty) as basic data type properties (with its previously-known units of measurements), implies that it's not necessary to incorporate into their ontology's definition a semantic structure to describe properly units of measurement. For semantic-centric applications: it's necessary to incorporate into their ontology's definition a structure to describe properly units of measurement, depending on their required semantic level of expressiveness. The vast majority of BCI applications are heavily data-centric. Well-known measurement units for a wide range of metadata attributes are used in different specs (such as [XDF] and [ESS]), e.g., pixels, mm, degrees and microvolts. For them, defining a relevant data type property set without specifying measurement units is suffice. For BCI applications that require a proper semantic expressiveness level of measurement units, this ontology provides the following guideline: The BCI concepts that are subject to be extended are those related to Device and Record (including the channeling spec definitions). From the perspective of the BCI ontology alignment to the Stimulus-Sensor-Observation Ontology Design Pattern, the core SSN concepts that "map" to quantities (and, therefore, to units of measurement) are ssn:MeasurementCapability and ssn:MeasurementProperty. Thus, BCI applications should pay special attention to extend the semantic structure of the concepts: Channel, and NonChannel. BCI applications should extend the BCI ontology based on the [SSN] guidelines, explained in: (5.3.10 Data » 5.3.10.2 How to attach a data value to a property?), (5.3.13 Energy » 5.3.13.3 How to represent a WSN nod…
editorial note: Regarding Aspect and Modality The importance and relationship between the concepts ssn:FeatureOfInterest (superclass of Aspect) and ssn:Property (superclass of Modality) are shown and explained in: (5.4.4 Agriculture Meteorology Sensor Network » 5.4.4.1.1 Sensor selection), (5.4.4 Agriculture Meteorology Sensor Network » 5.4.4.2.2 CF (Climate and Forecast) ontologies), (5.4.3 Wind sensor (WM30) » 5.4.3.6 Wind Feature and properties), (Wind Sensor example » Wind Sensor example: Feature of interest). As a SSN domain application ontology, these concepts are defined and adjusted properly for describing the nature of BCI applications.
editorial note: Regarding EEG concepts This ontology does not define any specific relationships (object properties) among the core EEG concepts: EegModality. EegNonChannel. EegDevice. EegRecord. EegChannel. If necessary, BCI applications may define a set of restrictions and specialized connections (subproperties) for the relations among the EEG concepts.
preferred label: BCI Ontology

hasNext
type: ObjectProperty
type: FunctionalProperty
domain: Class
  union of: Context.Scene
  union of: DataBlock
  union of: Record
  union of: RecordedData
range: Class
  union of: Context.Scene
  union of: DataBlock
  union of: Record
  union of: RecordedData
part: Context,SSN-Data,SSN-Skeleton
still image: Context.Scene.png
still image: DataBlock.png
modified: $ 02:50 AM 2016-07-07 $
change note: %STATUS_STABLE%
definition: Connects a (Context.Scene or Record or RecordedData or DataBlock) with its following (next) (Context.Scene or Record or RecordedData or DataBlock) of the sequence.
example: [Context.Scene] On a Video Game: (Level 3-2) hasNext (Level 3-3). [Record]: an observation is linked to its following observation. Their difference could be on their channeling settings. [RecordedData]: links to the following data version of the current data set. [DataBlock]: points to the following data unit value from the current one along the sequence.
preferred label: has next (following)
scope note: Connecting a (Context.Scene or Record or RecordedData or DataBlock) with its next correspondent (Context.Scene or Record or RecordedData or DataBlock).
describedby: hasNext.POWDER

isStimulusEventOf
type: InverseFunctionalProperty
type: ObjectProperty
domain: StimulusEvent
range: StimulusTag
part: Context,SSN-Skeleton
still image: Marker.png
modified: $ 01:55 AM 2016-06-23 $
change note: %STATUS_STABLE%
definition: A StimulusEvent generates a set of StimulusTags.
preferred label: is stimulus event of (generates)
scope note: Connecting a StimulusEvent with its set of StimulusTags.
describedby: isStimulusEventOf.POWDER

SamplingRate
type: Class
subclass of: Frequency
part: SSN-MeasurementCapability
still image: SamplingRate.png
modified: $ 02:52 AM 2016-08-22 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: Sampling rate of the Device. Its measurement unit is Hz. As a relevant non-channeling measurement property (ssn:MeasurementProperty) related to a Device its modeling is based on: the ssn:MeasurementCapability and ssn:MeasurementProperty concepts, and the guidelines found in (5.4.2 Smart product example » 5.4.2.2 Sensor).
editorial note: %GENERAL_COMMENT%@UNITS-OF-MEASUREMENT
editorial note: Related concept for a Record: hasSamplingRate.
preferred label: sampling rate of a device
describedby: SamplingRate.POWDER

includesEvent
type: ObjectProperty
domain: Record
range: StimulusEvent
sub property of: includesEvent
part: SSN-Skeleton
still image: StimulusEvent.png
modified: $ 12:44 AM 2016-07-25 $
source: [SSN]
change note: %STATUS_STABLE%
definition: Connects a Record with its correspondent StimulusEvent set. This can be read, as follow: "A Record includes events StimulusEvent". This object property is a subproperty of DUL:includesEvent: [ssn:Observation] ––– (DUL:includesEvent) –––> [ssn:Stimulus] [Record] –––––– (includesEvent) –––> [StimulusEvent] [SSN] A ssn:Observation has a DUL:includesEvent property who may be a ssn:Stimulus.
preferred label: includes stimulus event
scope note: Connecting a Record individual with its correspondent StimulusEvent set.
describedby: includesEvent.POWDER

PlayoutInstant.ContextEvent
type: Class
subclass of: PlayoutInstant
part: Context
still image: PlayoutInstant.png
modified: $ 05:27 PM 2016-05-19 $
change note: %STATUS_STABLE%
definition: Captures a relevant entry log in a Playout of a Context Event issued by a Context.ObjectComponent.Event instance during a Session.
preferred label: playout instant: context event type
scope note: Events (Context.ObjectComponent.Event) issued in a Context during a Session.
describedby: PlayoutInstant.ContextEvent.POWDER

Descriptor
type: Class
subclass of: InformationObject
subclass of: Restriction
  on data range: anyURI
  on property: hasLocator
  qualified cardinality: 1
subclass of: Restriction
  cardinality: 1
  on property: hasTitle
subclass of: Restriction
  min qualified cardinality: 0
  on class: Descriptor
  on property: hasDescriptor
subclass of: Restriction
  on data range: dateTime
  on property: hasDateTime
  qualified cardinality: 1
part: Descriptor
still image: Descriptor.png
modified: $ 01:30 AM 2016-06-30 $
source: [ESS], [XDF]
change note: %STATUS_STABLE%
definition: Describes an external Web resource that complements the information related to a specific entity found in this ontology. In a general sense, represents a class of information objects that describes complementary external resources of the metadata. Each individual of this class refers to an external file/document with extensive information to the associated metadata object. A Descriptor can have a related Descriptor set. This concept is defined as a subclass of DUL:InformationObject.
example: [XDF] and [ESS] BCI applications may extend this concept based on its purpose as an information object (practical usage of the Web resource). Thus, some subclasses of this concept could be: Annotation. Channel locations. Descriptive metadata. Event instance. Experiment note. Specification.
preferred label: descriptor of an external resource
scope note: %CLASS_HIERARCHY% any relevant type of Descriptors to capture specific external information that complements a metadata object.
describedby: Descriptor.POWDER

hasSituation
type: ObjectProperty
domain: Collection
range: Class
  union of: Interaction
  union of: Session
part: Session
still image: Session.png
modified: $ 04:43 AM 2016-06-28 $
inverse of: isSituationOf
change note: %STATUS_STABLE%
definition: Connects a Collection with a Session set and/or an Interaction set that are associated with it.
preferred label: has situation
scope note: Connecting a Collection with its related Session set and/or Interaction set.
describedby: hasSituation.POWDER

hasMQTT.Topic
type: FunctionalProperty
type: DatatypeProperty
comment: hasMQTT.Topic.POWDER
domain: AccessMethod.MQTT
range: Literal
part: SSN-Skeleton
still image: RecordedData.png
conforms to: %DATATYPE%
conforms to: A Topic conforms to the following definitions in the latest OASIS MQTT specification: MQTT Version 3.1.1 Plus Errata 01 (OASIS Standard Incorporating Approved Errata 01 10 December 2015) – 3. MQTT Control Packets / 3.3 PUBLISH – Publish message – (3.3.2.1. Topic Name). 3. MQTT Control Packets / 3.8 SUBSCRIBE – Subscribe to topics – (3.8.3 Payload).
format: The Topic MUST be a UTF-8 encoded string as defined in Section 1.5.3 of the latest OASIS MQTT specification: MQTT Version 3.1.1 Plus Errata 01 (OASIS Standard Incorporating Approved Errata 01 10 December 2015) – 1. Introduction – (1.5 Data representations).
modified: $ 04:35 AM 2016-07-05 $
deprecated: «This ontology should be agnostic to the data access» $ 04:35 AM 2016-07-05 $
deprecated: true
change note: %STATUS_STABLE%
definition: Describes the Topic (name or filter) parameter in an AccessMethod.MQTT connection. This parameter identifies either: The Topic Name (for the PUBLISH message), which identifies the information channel to which payload data is published. The Topic Filter (for the SUBSCRIBE message), which corresponds to the Client’s interest in one or more Topics (each subscription registers a Client’s interest in a Server). The payload of a SUBSCRIBE packet contains at least one Topic Filter.
preferred label: has MQTT topic
scope note: The usage of this parameter (for either publishing data –Topic Name– or subscribe to specific topics) depends on the purpose and implementation of the BCI application.

DataBlock
type: Class
subclass of: ObservationValue
subclass of: Restriction
  on data range: positiveInteger
  on property: hasOrdinalPosition
  qualified cardinality: 1
subclass of: Restriction
  on data range: long
  on property: hasOffset
  qualified cardinality: 1
subclass of: Restriction
  on class: RecordedData
  on property: isValueOf
  qualified cardinality: 1
subclass of: Restriction
  max qualified cardinality: 1
  on class: DataBlock
  on property: hasNext
subclass of: Restriction
  on data range: dateTimeStamp
  on property: hasTimeStamp
  qualified cardinality: 1
subclass of: Restriction
  max qualified cardinality: 1
  on class: DataBlock
  on property: hasPrevious
part: SSN-Data
still image: DataBlock.png
modified: $ 01:30 AM 2016-10-12 $
source: [SSN]
change note: %STATUS_STABLE%
definition: A DataBlock represents the basic/atomic physical data unit value of a RecordedData. Hence and following the alignment with [SSN], a RecordedData [has as for Value] a non-empty sequence (with not allowed repetitions) of DataBlocks. In the BCI domain: A RecordedData is compose of a non-empty sequence (with not allowed repetitions) of DataBlocks. A DataBlock is considered a physical data entity (whereas a DataSegment is considered a logical data entity). A DataBlock is related to another DataBlock based on its temporality: occurrence in its sequence. Therefore, a DataBlock may be sequentially linked to a following and a previous DataBlocks. All the sequentially linked DataBlocks compose the value of a RecordedData. The mechanism to access a DataBlock is the following: First, one retrieves the locators of the AccessMethods associated to desired RecordedData. With this, one can have the access to the "data file". Then, one can derived the correspondent DataBlocks locators, using the positional attributes: ordinal position, offset or timestamp.
editorial note: Depending on its implementation nature, a BCI application may choose to use any (or both) of the positional attributes: hasTimeStamp. hasOffset.
editorial note: "In mathematics, a sequence is an ordered collection of objects in which repetitions are allowed. (...) Unlike a set, order matters, and exactly the same elements can appear multiple times at different positions in the sequence". Reference: [Wikipedia: Sequence] For this specific concept, a sequence of DataBlocks does not allow repetitions.
preferred label: BCI data block
describedby: DataBlock.POWDER

hasSession
type: InverseFunctionalProperty
type: ObjectProperty
domain: Class
  union of: Context
  union of: Interaction
  union of: Subject
range: Session
part: Context,Session,Subject
still image: Session.png
modified: $ 10:08 PM 2016-06-23 $
inverse of: isSessionOf
change note: %STATUS_STABLE%
definition: Connects a (Context or Interaction or Subject) with a set of Sessions that are associated with it.
preferred label: has session
scope note: Connecting a (Context or Interaction or Subject) with its related set of Sessions
describedby: hasSession.POWDER

isReferencedBy
type: InverseFunctionalProperty
type: ObjectProperty
domain: DataSegment
range: Marker
part: AnnotationTag
still image: DataSegment.png
modified: $ 12:16 AM 2016-06-13 $
inverse of: pointsTo
change note: %STATUS_STABLE%
definition: Connects a DataSegment with a set of Markers.
preferred label: is referenced by
scope note: Connecting a DataSegment individual with a set of Markers.
describedby: isReferencedBy.POWDER