Learning. This BCI Ontology was a product of that research project. The project took a "bottom-up" approach; the SCCN team developed two sets of metadata vocabulary: the EEG Study Schema (ESS) [2] and the Hierarchical Event Descriptor (HED) [3] to describe the settings of the neuro-physiological recording and the specification of the neuro-physiological events respectively. Collectively, they were referred to as the BCI metadata. As the teams began to expand these metadata to cover more BCI experiments, the need to develop an ontological structure became obvious not only to accommodate future expansion of the vocabulary but also to specify the semantic relations among these concepts. Most notably, the syntax of HED 2 started to resemble the RDF format. Subsequent development of the BCI Ontology (BCI-O), the semantic data repository and the federated SPARQL search all took place in NCTU with the results fed back to UCSD and ARL.

In order to employ BCI-O to accomplish the two goals mentioned above, the neurophysiological signals/data sets collected from the experiments need to be processed for feature extraction and preliminary classification using existing ML algorithms. In the task of gathering data sets for Transfer Learning, inference rules shall be in place to specify the criteria of selecting data sets classified by existing algorithms for the learning process. In the task of deducing the correlated interpersonal features, the relations among the extracted features from different individuals shall be discovered through semantic search. Since BCI is a type of sensor-actuator system, it is only proper to align BCI-O with the W3C Semantic Sensor Network (SSN) and Sensor, Observation, Sample, and Actuator (SOSA) [4] frameworks. Because many BCI devices are connected to the Internet, BCI-O should also be aligned with the ontology for the Internet-of-Things (IoT-O) [5].

An important contribution we made was the introduction of the concepts of context and contextual relations into BCI-O. The characteristics of biological and neurophysiological signals are known to be highly situation or context dependent. User's physical conditions, time of day, environmental conditions can also affect the signals. In order to include these factors in the search for the correlated interpersonal features and the relevant data sets for Transfer Learning, we incorporated the core concepts of the UNITY world model for game development into BCI-O. We followed the human-environment interaction model in Human-Computer Interaction (HCI) [6] to integrate the concepts of context with those of sense and actuation.

In the rest of this paper, the BCI metadata for context, multi-modal data, and event annotations were first depicted. The structure, design principle, engineering and applications were then explained in subsequent sections. Lastly, the main contribution and future work were summarized in the conclusion.

Real-world multimodal BCI [7] may be decomposed into the following modeling artifacts: wearing a set of sensors (bci:Device) and/or through actuators (bci:Actuator), human beings (bci:Subject) interact with an environment (bci:Context) while performing (bci:Session) real-world activities (bci:Activity), where stimuli (bci:StimulusEvent) triggered by contextual events (bci:Context.Event), are observed, recorded (bci:Record) and marked (bci:Marker) in the sensed multimodal (bci:Modality) BCI data (bci:RecordedData). At its core, BCI-O defines the conceptual components in any BCI through a bidirectional subject-context interaction model (a BCI session with sensors/actuators): a Sense Model (context to subject) and an Actuation Model (subject to context), as depicted in Fig. 1. The design principle underlying this interaction model is described in section 4. However, its structure can be summarized in the following way: the Sense Model is based on the Stimulus-Sensor-Observation (SSO) Ontology Design Pattern (ODP) [8] and aligned to the SOSA/SSN upper ontologies [4], whilst the Actuation Model is based on the Actuation-Actuator-Effect (AAE) ODP [5] Two distinct conceptual domains are found in this model: BCI domain (observations, actuations, and interactions) and context domain (surroundings). The context domain concepts are based on the gaming architectural modeling of the Unity framework [11]. The BCI domain concepts were taken from the following semi-structured standard vocabularies and formats:

1. Extensible Data Format (XDF) [12]: a general-purpose container format for multichannel time series data with extensive associated meta-information stored as XML, called "XDF Metadata Schemes". XDF is tailored towards bio-signal data (multimodal data capture) but can easily hold data with high sampling rate (like audio) or high numbers of channels (like fMRI or raw video), as well. 2. EEG Study Schema (ESS) [2]: an XML-based specification that holds a metadata hierarchy for describing and documenting electrophysiological studies and their raw recorded data, in a format that is both machine and human readable.

(HED) [3]: defines a hierarchy of standard and extended descriptors for EEG experimental events that provides a uniform human-and machine-readable interface that facilitates the use of an underlying event-description ontology during EEG data acquisition, analysis, and sharing. HED tags may be used to mark and annotate all known events in an experimental session. As a classification system, HED is a folksonomy due that can be used collaboratively to create and manage tags for annotating and categorizing EEG-related events content. ESS is the companion specification of HED.

In the BCI domain, after collecting multimodal data from a bci:Subject, systems proceed to "annotate" the data with descriptive and predictive parameters. The descriptive features explain the "interaction model settings" of the data (see Fig. 2); whereas the predictive features, based on the data contextual event tagging, provide important input to classification models (data analytics) for adaptive BCI [13] (see Fig. 3). In the BCI domain, bci:Context correspond to the same concept as in HCI literature. Due to its orientation on real-world BCI, the ontology main design objectives are: 2 . Each module represents a key topic that gives a consistent explanation of its correspondent functional aspect in the mentioned BCI interaction model. Following, are presented a brief description of the modules and their core concepts.

 Subject: defines a human being (bci:Subject) engaging in an bci:Activity and its associate state (bci:SubjectState). bci:Subject defines a person with certain attributes, equivalent to Patient in the HL7 standard.  Context: captures the architectural description of a physical/virtual environment. Its modeling is based on [11]. A bci:Context is a sequence of bci:Scene, each one of which depicts a collection of spatial-located entities (bci:Context.Object) interplaying (behavior: bci:Context.Method) with one another (temporality-based sequence of bci:Context.Event: change of state) in a specific way (see Fig. 6). These conceptual components able the structural, functional, and temporal complexity definitions of any environment. Under the bci:Context.Event classification, BCI-O defines three key concepts that bind the contextual integration with its Sense and Actuation Models: bci:StimulusEvent (a stimulus to the bci:Subject), bci:Action (issued by a bci:Subject while performing a bci:Activity), and bci:ActuationEvent (an effectchange of state-in the bci:Context as the result of an bci:Actuation).  Session: represents the interaction between a bci:Subject and a bci:Context while performing (bci:Session) a single bci:Activity, under specific settings and conditions (the descriptive data features). A bci:Session groups both observations (multimodal measurement records: bci:Record) and actuations (bci:Actuation). Fig. 2 depicts the core modeling for bci:Session.  Sense Model: describes the contextual input data and events to the subject [5].

─ Observations: specific concepts aligned to the SOSA/SSN axioms for modeling Observations (the initial alignment was to the Skeleton of [14]). These are related to bci:Record (a single observation), bci:Modality types ("mode of the data"), interpretation aspects (bci:Aspect), channeling schema information (bci:ChannelingSpec), bci:RecordedData as sensor output streams (with a bci:Da-taFormat and a bci:AccessMethod), and bci:StimulusEvent. ─ Sensors: specific concepts aligned to the SOSA/SSN axioms for modeling Sensors -under Observations-(the initial alignment was to the Device Module of [14]). These are related to bci:Device, their channeling schema (bci:DeviceChannelingSpec), and their bci:DeviceSpec. ─ System Capabilities: specific concepts aligned to the SSN horizontal segmentation module for System Capabilities (the initial alignment was to the Measure-ment Capability Module of [14]). They are about bci:Channel (logical components of a channeling schema spec's data structure model) and other measurement properties. ─ Results: specific concepts aligned to the SOSA axioms for modeling Results (the initial alignment was to the Data Module of [14]). They are bci:DataBlock and bci:RecordedData. bci:ActuationResult is also included in this module.  Actuation Model (Actuation): unified concepts aligned to the SOSA and SAN axioms for modeling Actuations. This module depicts how the bci:Subject can interact with the bci:Context [5]. Its main concepts are bci:Actuation and bci:Actuator.  Annotation Tag: bci:StimulusTag (event markers based on context stimulibci:StimulusEvent-) and bci:ResponseTag (response markers based on machine learning bci:Model) for annotations on specific bci:DataSegment (data tagging). These define the predictive data features (see Fig. 3), while the previously modules explain the descriptive data features.  Descriptor: a bci:Descriptor defines an external resource set that extends and/or complements the description associated with relevant entities defined in BCI-O.  EEG: concepts for EEG applications. Due to the common nature of EEG data, these subclasses represent EEG subtypes for channel, device, modality and record.

Semantic Sensor Network (SSN) [14,15,4], along with its self-contained core ontology SOSA (Sensor, Observation, Sample, and Actuator) [4], is a standard framework ontology that BCI-O furtherly extends for the BCI domain. SOSA/SSN gives BCI-O the conceptual template and structure for both its Sense and Actuation Models, describing functional aspects of any BCI data capture activity.

Sense Model: SOSA/SSN Ontologies & SSO Design Pattern Besides of SSN general benefits [15], BCI-O's Sense Model leverages from it in the following ways:

 BCI systems can be considered as specialized sensor networks [13]; SOSA/SSN helps to improve their semantic interoperability and integration.  As a Linked Sensor Data standard, SSN helps to connect the IoT and the Internet of Services layers [15], which is of special interest to BCI in M2M environments.  SOSA/SSN supports different views related to BCI systems architecture, which can be centered around sensors (capabilities), observations (what was observed and how), and features and properties (how to observe them).  SSN gives a foundation for describing sensor networks as Web apps: real-time data processing from Web-of-Things sensors; which is a characteristic of BCI systems.

SSN Skeleton module describes the Stimulus-Sensor-Observation (SSO) ontology design pattern [8] [16], which forms the top-level of SSN [15]. BCI-O's Sense Model key concepts were first built aligned to SSO (following closely [15]), and later on, remapped to [4]. Not only SSO is suitable for event/situation based data logging but due to its generic and reusable structure, this pattern is intended for observation-related ontologies and for observation-based data on the Semantic Web [8]. Thus, it conforms a natural design structure for the BCI-O's Sense Model.

Design Approach: Ontology Alignments BCI-O's basic design principle can be depicted as a three-layered architecture of an ontology library [18], with the following structure: the foundational layer (DUL), the core layer (SOSA/SSN + SAN), and the domain layer (BCI-O). Thus, as an example, the participation foundational design pattern [16] fits in the following way: Based on the SSO ODP, the domain level concepts of the Sense Model were specialized initially from the SSN Skeleton module, following a similar alignment scheme that this one had with DUL, as explained in [15]. Due to its alignment with the initial SSN version, BCI-O was documented as part of the analysis on the usage of SSN [20], as one of the ontologies (concept producers) that reuse SSN. Subsequently, BCI-O's Sense Model was re-aligned to the Dolce-Ultralite (DUL) Alignment Module of the SOSA/SSN Vertical Segmentation5 . SSO-based core alignments are:

 Stimulus: A detectable change in the environment that triggers the sensors to perform observations. BCI-O defines bci:StimulusEvent aligned to ssn:Stimulus.  Sensor: An object that performs observations to measure certain observable properties. SSO defines sensors as the composite abstraction of sensing devices. BCI-O defines bci:Device aligned to sosa:Sensor.  Observation: A multi-dimensional event that captures information about the stimulus, sensor, its output and the spatial-temporal specification of the sensing activity. Due to its constraints, BCI-O defines bci:Record aligned to sosa:Observation.

Based on the AAE ODP, the domain level concepts of the Actuation Model were aligned initially to SOSA/SSN. Afterwards, they were integrated with proper alignments to SAN (IoT-O), following closely their axiomatization satisfiability (see Fig. 4 and Fig. 5). BCI-O's AAE-based core alignments are:

 Actuation: Carries out a procedure to change the state of the context using an actuator. BCI-O defines bci:Actuation aligned to both sosa:Actuation and san:Actuation.  Actuator: A device that is used by, or implements, an actuation that changes the state of the context. BCI-O defines bci:Actuator aligned to both sosa:Actuator and san:Actuator.

 Effect: Any kind of physical modification (an effect on the context) induced by an actuator (a characteristic of its nature, as an agent that has an effect on the context). BCI-O defines bci:ActuationEvent aligned to san:Effect.

Direct alignments to DUL were considered carefully evaluating the scope and intent for each concept, which led to properly define class hierarchies and disjoint axioms.

Context Model: Unity's Gaming High-Level Modeling Architecture BCI-O's Context Model (Fig. 6) was built based on relevant abstractions curated from the gaming architectural modeling of the Unity framework [11]. Unity models the architectural description of any kind of environment based on the organization of its entities and their relationships from three complementary perspectives: structural (the entities composition), behavioral (the entities operation), and temporal (the entities causality). These conceptual components able the structural, functional, and temporal complexity definitions of any environment with a certain level of abstraction (relevant to its purpose). This is the main reason why Unity's core concepts were chosen as the basis for the Context Model. Besides being one of the most popular game engines worldwide, also its modeling artifacts are easy to understand and use. In order to be consistent in the BCI-O's overall structure and intention, the Context Model core concepts were properly aligned to DUL.

As part of a pervasive online BCI system developed under the CaN-CTA Program of the U.S. ARL [13] [7], a proto-ontology was initially designed based on the project specs and incremental Software Engineering tasks. Later, it was generalized and expanded through a modeling process [21] described below.

Two fundamental and general representational aspects were considered for the domain modeling: BCI and physical/virtual environments (contexts). The contextual aspect was focused on explain the relevant component architecture of any environment for BCI (context-awareness), by abstracting the high-level concepts and relations found in [11]. The BCI aspect focused on categorizing the entities in any interaction through structured metadata. BCI interaction model complexity was addressed as follows: (a) major players flows were clearly identified based on HCI notions; (b) their characterizations were formalized following open BCI vocabularies; and, (c) additional/complementary design considerations, taken from [22] and especially from [23], were incorporated in a top-down approach to model the Annotation Tag module and related concepts. Common concepts, such as time intervals, were defined as datatype properties, in order to ease the modeling to BCI systems. However, if required, BCI-O applications could add more semantic expressiveness for the representation of time stamps and intervals, using directly W3C OWL-Time ontology.

The modeling and its spec were assessed several times until they reached a stable status. Below, are presented important aspects of the followed construction process:  Proto-ontology's project: specification (requirements), conceptualization and formalization (analysis & design), and implementation (dev. & deployment).  A hybrid modeling style was used: verbal/semi-structured (BCI vocabularies), logicbased (upper ontologies), and structural -object-(Unity framework [11]).  Level of detail for BCI-O: conceptual and logical model. Ontology authoring and quality were carefully looked during the overall process of building the BCI-O spec. Many best practices found in the SSN and IoT-O specs were taken as proper guidelines for its structure and documentation. The construction rules applied in the BCI-O development were:

1. Identify relevant BCI metadata terms to be included. They should have major "impact" to BCI activity/data annotation and machine-launched semantic search. 2. Determine domain and scope of concepts, keeping the model simple and stable. 3. Define class hierarchies and design rules, following closely BCI vocabularies. 4. Find prominent ontologies from which we could apply ontology design patterns [16] to directly align the term definitions: SOSA/SSN and SAN (IoT-O). 5. If necessary, establish equivalence relations with other related terms of interest.

During the ontology development, some terms from popular vocabularies were included to enrich the BCI-O concepts metadata as annotation properties, such as Dublin Core Metadata Terms (DC and DCMIType), SKOS (Simple Knowledge Organization System), VANN (a vocabulary for annotating vocabulary descriptions), and Open.vocab.org. Besides of their minimal semantic commitment, these annotations are wellknown Web-oriented representations that aim to reuse and share ontological concepts and their descriptions. Guidelines6 were carefully followed while incorporating the annotations into the BCI-O spec. SKOS lexical labels (prefLabel) and Notes documentation properties 7 (such as definition, scope note, editorial note and change note) were included into the spec to distinct and structure properly the different content nature for each BCI-O concept.

Axioms' Satisfiability BCI-O's satisfiability was checked in different validation points immediately after including and modifying various axioms, such as disjoint concepts, and DUL/SAN alignments. The reasoner HermiT v1.3.8 was used. As part of the ontology engineering process, a detailed log was kept with all the results and durations of each satisfiability checkpoint.

Publishing the Spec: Versions, Linked Data Engine and Modeling Tools

The spec was developed in three versions, each with related XML documents. First, the Base Version, an (OWL 2) RDF/XML document with the complete modeling structure and content, plus embedded HTML formatting and text-handling rules. Second, the HTML Version, a set of XSL 3 documents with XPath 3 functions and a companion XML configuration document to handle the base-to-HTML transformation. And third, the (OWL 2) RDF/XML Version, an XSL 3 document strips off from the base-version the HTML formatting, to generate a clean and proper machine-readable document.

A simple linked data engine was developed to handle some specialized linked data services for the spec, including serving (dispatching and generation) the proper HTML and RDF/XML versions and URI entry-points to different user agents. A w3id.org identifier was registered as its namespace URI definition. A basic content negotiation server-side script was developed to serve properly the different versions of the spec. The BCI-O spec was published in the LOV registry on 2016-11-08. The modeling and ontology tools used were: Astah Community Modeling Tool, IHMC CmapTools [24], and Protégé v5.2.0 [25].

As mentioned, BCI-O proto-ontology was developed in a joint project between NCTU (PET Lab) and UCSD (SCCN), with the U.S. ARL Translational Neuroscience Branch (CaN-CTA Program) [13] [7]. As an application for a proof of concept system, the proto-ontology was used in order to make sure that big data sets were semantically searchable for high-level processing via BCI metadata definitions. The proto-ontology was successfully used further in heterogeneous BCI datasets coming from different applications 8 , such as stress and fatigue neuroimaging [7], car driving tests, and multimodal mobile brain imaging. Another application is described in the paper on the Neuromonitoring VR/AR Goggle [26].

The BCI-O spec's HTML version presents two early applications (including their correspondent RDF graph model): the CerebraTek ® νPod Ontology 9 , applied to glaucoma diagnostics using mfSSVEP, and the ESS+HED Standards Ontology for BCI-O 10 , as an ontological overlay for the ESS v2.0 and HED v2.0 EEG data sharing tools work from U.S. ARL CaN-CTA Program). These tools have been built as a multi-iterative process infrastructure (with many layers) to train and personalized ML models using semi-structured and non-interoperable metadata formats. BCI-O's axiomatizations of relevant BCI metadata can greatly enhance these software pipelines.

Following, we describe a use case where BCI-O aids applications in TL operations. A semantic query is used for a TL operation of data sets and segments between two ML models, based on categorized observations. An application for "Early Glaucoma Detection" that uses the νPod Ontology aims to select data sets/segments, which have been previously classified via a simple Convolutional Neural Network (CNN), as the input to a more sophisticated CNN model. The glaucoma patients' datasets consist of EEG recordings collected from 100 subjects as part of an experiment performed by a UCSD research team. Each subject has one session with two EEG records (one for each eye). An EEG recording (eye's vision) is classified as either "Normal", "G. Early", or "G. Late" (categories of glaucoma detection stages). These annotations define the categorization of the observations. Each recorded data that has been analyzed has a sequence of data segments with related attributes that define a probability and a correlation: highcorrelated segments signifies relevant epochs to the source model that classify the eye's vision. Only high-correlated segments are relevant to the target model. The application only annotates both, the probability and correlation, for high-correlated segments of the source model. The analyzed EEG recordings have a related EEGNet model (used as a high-level selector and as the TL source model). EEGNet is a simple 4-layer CNN model for glaucoma classification. RevNet+I is a complex 24-layer CNN model, used as a more sophisticated tool to analyze features of the collected EEG signals (the TL target model). The purpose of the semantic query is to select the analyzed raw data and data segments that have been annotated with high-correlation of their segments' probabilities as the input to RevNet+I. For this use case, the semantic query has four important sections. First, the Semantic Matching: defines the relationship between the relevant metadata concepts for the BCI application based on the νPod Ontology and its alignment to BCI-O. Second, the Query Restriction, which is attribute-based restrictions of the categories on sessions, subjects, and records (these filters categorize the observations). Third, the Model Selector for the Data, comprised of the annotated data segments (with probabilities and correlations) and classified recordings with the TL source model. Fourth, the Query Projection: the raw data sets and their data segments for the TL target model. In general, BCI-O offers two main applications to BCI systems: the modeling of subject-independent features (orthogonal conceptual dimensionality for subjects), and relevant data sets to personalized calibration of models with some level of confidence.

Future Work

BCI-O models subject-context interactions while focusing on monitoring the brain dynamics. In a long-term, we would like to take BCI-O as the basis towards generalizing a semantic model to describe how any human body bio-signal (not only from the brain) can be monitored and made to interact with computing interfaces. Initially, this work would lead to BCI-O's generalization towards a "Bio-signal Computer-Interaction Ontology". This modeling task is planned to be one of the main development drivers in the future, for a set of ontological frameworks to capture the different bio-signal markers and technological interfaces for the entire human body: organs (brain, heart, liver, etc.) and systems (nervous, integumentary, endocrine, etc.). Additionally, there is an ongoing effort on proposing some extensions to the SOSA/SSN W3C Recommendation [27]. We are following closely the new proposed concepts and relationships and given our feedback from the BCI-O perspective in their ongoing discussions: special interest for issue #1028 regarding the "Homogeneity of an ObservationCollection" 11 . BCI-O will be updated accordingly following the structure/alignments of these extensions, after the proposal becomes stable. Last, some BCI applications keep part of their metadata store in standard relational database systems. As an aside project, we are planning to work on an OWL 2 QL profile [28] version of BCI-O, so that those relevant metadata sets can be queried through a restrictive version of BCI-O.

As a foundational model for real-world BCI, BCI-O will become an important tool to aid large-scale BCI data analytics models and processes, due primarily to its OWL 2 formal structure. Semantic reasoning based tasks of BCI-O's axiomatizations enable BCI systems to carry out two major jobs: first, to apply inference rules to aid ML techniques, such as feature-based TL (Adaptive DL), in online multimodal (EEG) classification [29]; and second, to perform Adaptive BCI (train and refine brain state prediction and classification models) [13], based on relevant data sets constructed through semantic data queries. Another key contribution of BCI-O is its novel Context Model. This one associates the context architectonic definition with the data recordings (SOSA/SSN-based observations), making BCI systems to be semantically context-aware for real/virtual-world situations. Thus, it gives a semantic foundation for augmented BCI, assisting ambient intelligence's settings in sensor systems for any kind of BCI. As a domain ontology for BCI sensors 12 and actuators 13 , BCI-O allows to semantically informed BCI analytics of sensor/actuator data patterns (unambiguous searchability, similarities, simulations, and predictions), as well as semantic interoperability (based on its alignments): easy integration, reusability, and extensibility into the Linked Data world for all kind of BCI. In general, its axiomatizations enable BCI systems to apply Semantic Web technologies for data analysis, as a form of a semantic middleware for BCI sensor/actuator networks.