Lionel Tailhardat (https://orcid.org/0000-0001-5887-899X)
Raphaël Troncy (https://orcid.org/0000-0003-0457-1436)
The NORIA-O project is a data model for IT networks, events and operations information. The ontology is developed using web technologies (e.g. RDF, OWL, SKOS) and is intended as a structure for realizing an IT Service Management (ITSM) Knowledge Graph (KG) for Anomaly Detection (AD) and Risk Management applications. The model has been developed in collaboration with operational teams, and in connection with third parties linked vocabularies. Alignment with third parties vocabularies is implemented on a per class or per property basis when relevant (e.g. with `rdfs:subClassOf`, `owl:equivalentClass`). Directions for direct instanciation of these vocabularies are provided for cases where implementing a class/property alignment is redundant. Alignment holds for the following vocabulary releases: - [BBO](https://hal.archives-ouvertes.fr/hal-02365012/) 1.0.0 - [BOT](https://w3id.org/bot/) 0.3.2 - [DevOps-Infra](https://oeg-upm.github.io/devops-infra/) 1.0.0 - [FOLIO](https://github.com/IBCNServices/Folio-Ontology) 1.0.0 - [ORG](https://www.w3.org/TR/vocab-org/) 0.8 - [PEP](https://w3id.org/pep/) 1.1 - [SEAS](https://w3id.org/seas/) 1.1 - [SLOGERT](https://sepses.ifs.tuwien.ac.at/ns/log/index-en.html) 1.1.0 - [UCO](https://github.com/ucoProject/uco) Release-0.8.0
The NORIA Ontology
The Operation Plan (procedure) guiding the execution of the given Action.
The Network Element (IT Resource) the Agent is responsible of (supervises). Alignment: - *FOAF*: A team may be interested into following the state of some resources, hence this property is semantically akin to `foaf:topic_interest`.
Change in v0.2: - rdfs:domain moved from noria:Employee to foaf:Agent. - name and label moved from teamManagesResource to agentManagesResource. - Removing rdfs:range noria:Resource for noria:Resource and noria:NetworkLink compatibility.
The preferred contact method to reach the Agent (Team, Group, Employee).
Change in v0.2: - rdfs:domain moved from noria:Employee to foaf:Agent. - name and label moved from employeePreferredContactMethod to agentPreferredContactMethod. - adding rdfs:subPropertyOf observable:contactNote.
Phone, e-mail
The ProcedureExecutionContainer (i.e. the set of Procedure Execution(s)) that led to clear the alarm and/or solve the issue. This allows, for example, the timely reporting of changing conditions prevalent at the time of the alarm.
ProcedureExecutionContainer(x) .ldp:member EventRecord(y) .hasCommand='ip address 10.1.5.1 255.255.255.0' .hasResult='SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36)'
The Monitored attributes parameter, when present, defines one or more attributes of the managed object and their corresponding values at the time of the alarm. Managed object definers may specify the set of attributes which are of interest, if any. This allows, for example, the timely reporting of changing conditions prevalent at the time of the alarm.
This parameter, when present, is used if the cause is known and the system being managed can suggest one or more solutions. This parameter is a set of possibilities specified by the object class definer.
Switch to standby equipment, retry to connect, replace media, etc.
Indication of how it is perceived that the capability of the managed object has been affected, or how serious are the service affecting conditions (including for security alarms).
Changes in v0.2: - Changed owl:hasValue restriction to <Notification/Severity/PerceivedSeverity> in place of <Notification/PerceivedSeverity>. - Adding rdfs:subPropertyOf dcterms:type. - Adding rdfs:subPropertyOf folio:hasCriticality. - Merging the noria:securityAlarmSeverity.
Critical, Major, Minor, Warning.
The importance of the Application from the business impact perspective for risk assessment analysis and incident management prioritization.
Administration leader.
Responsable de l'entité exploitante.
Changes in v0.2: - rdfs:range foaf:Agent in place of noria:Employee.
Administration team.
Entité exploitante.
Changes in v0.2: - rdfs:range org:OrganizationalUnit in place of noria:Team.
Equipe d'astreinte applicative.
Hotline team.
A child/parent relationship between a specific and managed instance of an Application (i.e. an Application Module) and the Application.
Generic property for linking a party playing a role in the management of the Application Module.
Changes in v0.2: - Adding rdfs:subPropertyOf noria:elementManagedBy.
Niveau de service.
SLA level.
Etat de service du Module Applicatif.
Status of the Application Module.
En Production
In Production
Entité support: Point d'Entrée Interface Technique (PEIT) - Exploitant N1.
Level 1 support team.
Responsable de l'entité support.
Support leader.
Entité support : Soutien Applicatif Technique (SAT) - Exploitant N2.
Level 2 Support Team.
The type of the Application.
The actor of the Change Request.
Nature of the Change Request
Internal intervention, Third party intervention, Customer intervention, Change requested by customer
Cause of (reason for) the Change Request.
Configuration, Preventative maintenance, Software upgrade, Network extension, etc.
Set of physical/logical entities on which the Change Request is carried-out.
Resource(s), Application(s), Service(s)
The agent initiating the Change Request.
The pilot of the Change Request.
An item of the standard operation plan catalog for recurring activities.
The current status of the Change Request.
The type of the request describes the a priori impact and risk level of the Change Request.
Relates a Resource that is part of a cluster with the cluster controller.
The status change history of the document as recorded by the system's logging feature.
EventRecord .loggingTime("2019-01-23T11:58:00Z") .logOriginatingManagementSystem(</object/APP_MyOSS>) .references(</document/TT_2019-01-23_Resource1>) .title("InProgress") .type </kos/Notification/EventType/stateChange>
The Agent or Owner of the Managed Element. Alignment: - *ORG*: the *elementManagedBy* property can range an `org:Organization` or `org:OrganizationalUnit` entity as the ORG data model defines these class as subClassOf `foaf:Agent` (see [org:Organization](https://www.w3.org/TR/vocab-org/#org:Organization)).
An abstract representation of a relationship between some Element instance and some Property instance.
elementProperty
The structural or functional element instance some event or time-dependant entity is related with.
Party playing a role (stakeholders) in the life cycle of a given event instance or time-dependant entity.
A uniquely identified space of the Resource within a given Room. Alignment: - *UCO*: This property enables linking a concrete `Resource` instance to some location, hence it relates to `observable:location`. - *BOT*: This property is akin to the inverse of `bot:hasElement`.
Changes in v0.2: - Adding rdfs:range noria:Locus. - Adding rdfs:subPropertyOf observable:location.
Ligne:L, Colonne:6, en Salle:SALLE STOCKAGE RESEAU 314.
Line: L, Column:6, in Room:Server room 314.
The Agent at the origin of the Log record whenever it represents some action carried out on the ICT system. This includes information about the service user associated with the service request that caused a security alarm.
Changes in v0.2: - rdfs:range foaf:Agent in place of rdfs:range noria:Employee. - Adding rdfs:subPropertyOf dcterms:creator. - Adding rdfs:subPropertyOf prov:wasAttributedTo. - Merging the noria:alarmServiceUser.
A employee or maintenance bot that carried-out a change or corrective maintenance action. A service user that carried-out SQL Injection.
The Managed Object entity at the origin of the Log record. This includes information about the service provider associated with the service request that caused a security alarm.
Changes in v0.2: - Adding rdfs:subPropertyOf dcterms:creator. - Adding rdfs:subPropertyOf prov:wasAttributedTo. - Adding rdfs:subPropertyOf folio:happenedAt. - Adding rdfs:subPropertyOf log:hasSourceHost. - Adding reference to ITU-T X721 SecurityAlarmDetector. - Adding reference to ITU-T X721 serviceProvider. - Merging the noria:serviceProvider.
A named Resource, Application, Security Alarm Detector, etc.
The Management System that receives, processes and forwards the Log record.
Changes in v0.2: - Adding rdfs:subPropertyOf dcterms:creator. - Adding rdfs:subPropertyOf prov:wasAttributedTo. - Adding rdfs:subPropertyOf noria:eventRelatedElement.
A named instance of Network Management System (NMS), Security Information and Event Monitoring system (SIEM), etc.
The administrative status of the Network Interface.
The Network Link the Network Interface is attached-to.
The Resource the Network Interface is part-of.
The operational status of the Network Interface.
The type of the Network Interface.
physical, subinterface, virtual
Link termination Resource, the Resource at some end fo the Network Link.
The ActionPostCondition to check/that would be observed whenever the OperationPlan is carried out. Alignment: - *PEP*: OperationPlan (Procedures) may be linked to some description of the output, hence `operationPlanPostCondition` is a kind of `pep:hasOutput`. - *BBO*: From the BPMN perspective, the `operationPlanPostCondition` is the description of what should be observed to after the realization of a given Task, hence it is a kind of `BBO:has_completionCondition`.
Change in v0.2: - Adding pep:hasOutput. - Adding rdfs:subPropertyOf BBO::has_completionCondition.
The ActionPreCondition to check/that would be checked whenever the OperationPlan will be executed/is executed. Alignment: - *PEP*: OperationPlan (Procedures) may be linked to some description of the input, hence `operationPlanPreCondition` is a kind of `pep:hasInput`. - *BBO*: From the BPMN perspective, the `operationPlanPreCondition` is the description of what may activate the realization of a given Task, hence it is a kind of `BBO:has_activationCondition`.
Change in v0.2: - Adding pep:hasInput. - Adding rdfs:subPropertyOf BBO::has_activationCondition.
The *final* nature (for product ticket class) or technical impact (for resource ticket class) of the incident category of any Trouble Ticket or Incident Ticket.
problemCategory
Isolated customer site, Total breakdown, Working backup, Downgrading equipment, Inaccessible destination, etc.
The *final* area of responsibility identified for the incident.
problemResponsibility
Customer, Managed access equipment on customer's premises, Managed backbone networks, Managed specific networks, Contract application-hosting services, Ill-defined, etc.
The Manufacturer of the Product Model.
Change in v0.2: - property name and label changed from noria:manufacturedBy to noria:productManufacturedBy. - rdfs:range moved from noria:Manufacturer to org:Organization.
The Application this Resource is contributing to, whatever the Application type.
Corporate Internet access Infrastructure, Clock synchronization Service
The Support team or Owner of the Network Element (IT Resource).
Change in v0.2: - rdfs:range moved from noria:Team and noria:Organization to foaf:Agent. - Removing rdfs:range foaf:Agent as it is already defined by noria:elementManagedBy. - Removing rdfs:domain noria:Resource for noria:Resource and noria:NetworkLink compatibility.
- Resource("DNS server").resourceManagedBy("DNS admin team") - NetworkLink("WAN Paris-Papeete").resourceManagedBy("International backbone support team")
Specifies the IP address for remote management of the Resource, if relevant.
The product model of the Resource.
The type of the Network Element Resource.
The production state of the Resource.
The type of the Service.
An abstract representation of a relationship between some StructuralElement instance and some StructuralObservable instance.
structuralElementObservable
Relates some `StructuralObservable` instance to some `StructuralElement` instance.
structuralObservableOf
The *initial* nature (for product ticket class) or technical impact (for resource ticket class) of the incident category of any Trouble Ticket or Incident Ticket.
troubleTicketCategory
A list of Characteristics of the ticket (TroubleTicketCharacteristic [*]). The Trouble ticket specific characteristics
The ticket criticity from the customer impact perspective.
troubleTicketCriticity
Interrupted service, Corrupted service, Working backup, etc.
The ticket freeze period history.
troubleTicketFreezeItem
A list of `noria:EventRecord` specifically describing the freeze periods for the given `noria:TroubleTicket`.
A list of resources or services (applications) impacted by the trouble.
troubleTicketImpacts
TroubleTicket.troubleTicketImpacts({Application [*], Resource [*]})
The comment provenance type and/or disclosure rules family.
Customer, Group, Internal, System, etc.
The correlated *ProcedureExecutionContainer* corresponding to the corrective maintenance actions depicted in the Trouble Ticket Note (i.e. the set of `EventRecord` about interactions with the system and as notified by the system). From a practical perspective, relating a `noria:TroubleTicketNote` to a `pep:ProcedureExecutionContainer` is akin to show off the materialization of a corrective maintenance action from the technical perspective. Note that for actions undoubtedly related to a given trouble ticket note (i.e. that can be asserted without mining for execution context candidates), one can avoid using `troubleTicketNoteCorrelatedExecution` by directly relating the note to `EventRecord` with `ldp:member` as `TroubleTicket` and `TroubleTicketNote` are themselves subclasses of `pep:ProcedureExecutionContainer`.
Changes in v0.2: - Adding the troubleTicketNoteCorrelatedExecution property.
Inward customer comments, Local customer call back, Tests and measurements, Diagnosis, etc.
The person or group family at the origin of the creation of the Trouble Ticket.
Customer, Supervision, Internal, Carrier, User, Partners
The history of groups activation and responsibility transfer.
troubleTicketPartyIntervention
The trouble management priority.
troubleTicketPriority
The related party(ies) that are associated to the ticket.
The Resource entity on which the trouble ticket has been created.
The *Application* or *Service* entity on which trouble ticket has been created.
- TroubleTicket.troubleTicketImpacts("syslog-ng") Application("syslog-ng").applicationType(<kos/application/type/service-platform>) - TroubleTicket.troubleTicketImpacts("Corporate Internet access Infrastructure") Application("Corporate Internet access Infrastructure").applicationType(<kos/application/type/infrastructure>)
The criticity of the incident. The classification (severity) of the Incident may be defined in accordance with Service Level Agreement (SLA) requirements. The thresholds of Incident resolution depend on standards defined per service type. When the thresholds are exceeded, specific process of escalation may be activated.
Minor, Major, Blocking, etc.
The current activity status of the trouble ticket.
Initialised, InProgress, Frozen, Restored, Resolved, Closed
The ticket type.
Failure, Long period assistance, Assistance, Installation, Maintenance, Parametrization, etc.
The priority level of the incident.
Immediate Intervention, Deferred Intervention, (State of) Emergency, No intervention, etc.
The operational status of the Virtual Server.
Instructions for involving the Agent (Team, Group, Employee).
Change in v0.2: - rdfs:domain moved from noria:Employee to foaf:Agent. - name and label moved from teamInstructions to agentInstructions. - adding rdfs:subPropertyOf observable:contactNote.
Use the Ticketing system + hotline phone number for national L2 and L3 issues.
The Working Hours for reaching the Agent (Team, Employee, etc.).
Change in v0.2: - rdfs:domain moved from noria:Employee to foaf:Agent. - name and label moved from teamWorkingHours to agentWorkingHours.
8:00 am - 12:00 am / 1:00 pm - 5:30 pm (Mon --> Fri)
8H-12H/13H-17H30 (lun --> ven)
The functional domain of the Application for describing the organization’s activities from a system point of view. Alignment: - *tmforum*: the `noria:applicationFunctionalDomain` is equivalent to the *Domain* concept of the ODA Functional Framework.
- Market and Customer Relationship Management domain - Service Development, Management and Operations - Resource Development, Management and Operations
The functional sub-domain of the Application for describing the organization’s activities from a system point of view. Alignment: - *tmforum*: the `noria:applicationFunctionalSubDomain` is equivalent to *Aggregate Business Entities* (ABEs) and *Business Entities* (BEs) of the ODA Functional Framework.
- Human Resource Management - Offer and Product Operational Analysis - Resource Repository Management
Application model code.
Hotline enabled for issues on a given ApplicationModule.
Possibilité d'appel de l'astreinte applicative.
Application module code.
applicationModuleIdentifier
The name of the Application module.
CONCAT( Application().applicationModelIdentifier(), "_", ApplicationModule().applicationModuleIdentifier() )
Date du Niveau de service.
SLA Level date, the date at which the SLA Level has been set or updated.
Application numerical identifier, the numerical identifier of the Application within the Information System.
Application short identifier, a short string identifier of Application within the Information System.
Date and time on which the Change Request implementation has been completed. It is displayed only after the Change Request implementation has been completed actually.
Date and time on which the Change Request implementation has started. It is displayed only after the Change Request implementation has started actually.
If *true*, the Change Request is subject to special regulations.
Expected duration of the outage, if any involved by the Change Request type.
Date and time on which is planned the end of the implementation of the Change Request. It is displayed only before the Change Request implementation is completed.
ID given by the requestor to facilitate the relationship set up and searches afterwards.
Customer reference, Identifier coming from an external system, etc.
Hyperlink to the TroubleTicket or ChangeRequest entity in the originating information system.
The Distinguished Name of the Element Instance (i.e. unique identifier).
elementDistinguishedName
The Distinguished Name of the Functional Element Instance (i.e. unique identifier).
functionalElementDistinguishedName
The line identifier in a `noria:Room` for a Locus defined by Cartesian coordinates.
Line:L, in Room:Server room 314.
The row identifier in a `noria:Room` for a Locus defined by Cartesian coordinates.
Column:6, in Room:Server room 314.
Textual information describing the logged event.
Changes in v0.2: - Adding rdfs:subPropertyOf dcterms:title. - Adding rdfs:subPropertyOf pep:hasSimpleResult. - Adding rdfs:subPropertyOf log:msg.
The Date on which the log record was created in the system.
Changes in v0.2: - Adding rdfs:subPropertyOf dcterms:created. - Adding rdfs:subPropertyOf log:time.
A human-readable/editable text that describes the network interface. The information included in the description depends on the capabilities of the Resource's operating system.
The high received power notification threshold.
The low received power notification threshold.
The received optical power measure of the Network Interface, in dBm.
The average received optical power of the Network Interface, in dBm.
The emitted optical power measure of the Network Interface, in dBm.
The metric value associated to the Network Interface for some routing protocol.
The UID of the NetworkLink.
The installation date of the NetworkLink.
A description of the type of the Network Link.
The hostname (nodename) of the Resource.
Changes in v0.2: - Adding rdfs:subPropertyOf log:host. - Adding rdfs:subPropertyOf observable:hostname.
The installation date of the Resource.
The logistic UID of the Resource (a.k.a. asset tag).
The serial number of the Resource.
A unique identifier of a Site.
Change in v0.2: rdfs:range moved from noria:Site to bot:Site.
Street address of a Site.
City Name for a Site. Alignment: - *GeoNames*: a `P` class `gn:Feature` (city, village, etc.) may correspond to this property.
Country name or code for a Site. Alignment: - *GeoNames*: - a `A` class `gn:Feature` (country, state, region, etc.) may correspond to this property. - prefer ISO 3166 values for easier matching with `gn:countryCode`.
Postal Code for a Site. Alignment: - *GeoNames*: *ADM2*, *ADM3* or *ADM4* annotations may correspond to this property, depending on the considered country.
Street for a Site.
The type of a Site.
The Distinguished Name of the Structural Element Instance (i.e. unique identifier).
structuralElementDistinguishedName
The cause(s) defined for the trouble, in plain text.
troubleTicketCause
SSH authentication failure due to loss of sync to NTP server and internal clock drift.
The Customer Commitment Deadline Date (calculated on product information).
The date on which the trouble was discovered.
The *enable* or *disable* external notification on trouble ticket events.
Confirmed to customer planned restoration date ATR (Actual Time to Restore (ATR)).
Supervision tool which detected the problem.
The Customer initial restoration date Estimated Time to Restore (ETR).
Set of Post Conditions or Potential outcomes that the execution of some OperationPlan may satisfy/lead to/confirm/solve. From the *ChangeRequest* perspective this enables to declare what to observe in order to confirm that the Procedure reached its goal; from the *TroubleTicket* perspective this enables to capitalize on expectations and outcomes for a given Procedure.
In an Incident Management context, the materialization to expect, such as: - 'service restored', - 'traffic down', - 'Customer or a probe with that traffic coming up after some CLI command'.
Set of Pre Conditions or Hypothesis enabling/leading to the potential execution of some OperationPlan.
In an Incident Management context: when in situation X, shut link may help
An abstract class for grouping observables and events that, when satisfied by the existence of some instance/value, represents the occurrence of a (complex) fault/failure mode.
Changes in v0.2: - Renamed AnomalyPattern from AnomalyMode. - Adding rdfs:subClassOf folio:FailureMode.
An abstract system based on data processing and presentation.
- RLOGS: Centralization of real time logs. - DMZ VoIP: shared management zone / platform for Voice over IP services.
A specific and managed instance of an Application.
- Development instance of the RLOGS (Centralization of real time logs) Application. - B2B instance of the DMZ VoIP (shared management zone / platform for Voice over IP services) Application.
A Change Request represents a record used for reporting and managing change activities on services and resources. It is a key artefact to the Change Management process. Change Management process is to respond to the customer’s changing business requirements while maximizing value and reducing incidents, disruption and network. Alignment: - *DCMI*: from the DCMI Abstract Model perspective, a ChangeRequest is a described resource, hence DC terms apply: - changeRequestId <=> http://purl.org/dc/terms/identifier : Identifier of the ChangeRequest. - changeRequestCreationDateTime <=> http://purl.org/dc/terms/created : The Date and time on which the ChangeRequest was created in the system. - changeRequestLastUpdate <=> http://purl.org/dc/terms/modified : The date and time on which the ChangeRequest was last updated. - changeRequestDescription <=> http://purl.org/dc/terms/description : Extended description of the change to be made. - changeRequestNote <=> http://purl.org/dc/terms/hasPart : A list of customer or internal comments. - changeRequestAttachment <=> http://purl.org/dc/terms/hasPart : DocumentAttachment(s) that are associated to the ChangeRequest. - changeRequestDuration <=> http://purl.org/dc/terms/extent (optional) - changeRequestRelatedParty <=> http://purl.org/dc/terms/contributor : Party playing a role in the ChangeRequest, whether it be an unqualified role (i.e. direct usage of dcterms:contributor) or a qualified role (i.e. sub-properties such as noria:changeRequestInitiatorParty). - changeRequestCorrelatedNotifications <=> http://purl.org/dc/terms/relation : EventRecord(s) instances or identifiers that are considered to be correlated to this ChangeRequest. - *PEP*: a ChangeRequest is a context for (potentially) many *ChangeAction* to occur; hence it relates to a `pep:ProcedureExecutionContainer`. - *BBO*: a ChangeRequest is a DocumentResource in the sense that it is the result of the Change Management process and can be used as an input for another activity. From the BPMN 2.0 perspective, a ChangeRequest is a DataObject.
The Corporate User Identifier (CUid) is the unique identifier of a Person as a member of Organization (i.e. an Employee). It is also the main account of this Person for connecting to the organization's IT resources, including to its personal computer (PC). Alignment: - *FOAF*: - The `foaf:accountName` allows for asserting the login identifier of an instance of this class. - The `foaf:holdsAccount` property allows for relating an employee entity to an instance of this class. - *UCO*: - A CUid is equivalent to a `observable:UserAccount`. - The `observable:accountLogin` and `observable:accountIdentifier` can be used in parallel to `foaf:accountName` for asserting the the login identifier. - The Person (`foaf:Agent`) holding this CUid is also a `observable:Contact`.
Change in v0.2: - alignment with foaf of the previously available noria:employeeId property.
A file attachment. Alignment: - *DCMI*: from the DCMI Abstract Model perspective, a DocumentAttachment is a described resource, hence DC terms apply: - troubleTicketAttachmentForTicket <=> http://purl.org/dc/terms/isPartOf : The TroubleTicket this file is part of. - changeRequestAttachment <=> http://purl.org/dc/terms/isPartOf : The TroubleTicket this file is part of. - *BBO*: a DocumentAttachment is a DocumentResource in the sense that it is the result of the Incident Management Process (IMP) or Change Management Process (CMP) and can be used as an input for another activity. From the BPMN 2.0 perspective, a DocumentAttachment is a DataObject.
Picture of broken device, scanning of a bill or charge, network diagram, operation plan, location map.
Abstract class for time-related entities and their potential chaining (a.k.a. *Dynamic facet*).
DynamicElement
An alarm with happens_on or followed_by properties
This managed object represents the information stored in the log as a result of receiving notifications or incoming event reports. In that sense it is an abstract object with basic properties (e.g. event type, logging time, provenance system, message) to interpret in the context of its properties and relationships. For example, an *EventRecord* instance `log1` originating from the managed resource `R1` and describing a network interface state change on the Resource is fetched from a syslog-ng platform `Mon1` (i.e. the originating management system). A related *EventRecord* instance `alarm1` with `noria:alarmSeverity = Critical` and originating managed resource `R1` is triggered by a Network Monitoring System `NMS1` (i.e. the originating management system) for presentation to the Technical Support Center. Considering possible combinations of properties' objects and values, a `noria:EventRecord` allows for describing: - both informational and alarm notifications (this rely on `skos:ConceptScheme` over the `dcterms:type` of the `noria:EventRecord`), - notifications that affect both the network infrastructure (e.g. network interface down), network applications/services (e.g. timeout, k-out-of-n) and the Operation Support System (OSS) itself (e.g. updating a `noria:TroubleTicketNote`), - notifications originating from both onboard signaling (e.g. [SNMP Trap](https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol)), probes (e.g. [NIDS](https://en.wikipedia.org/wiki/Intrusion_detection_system)), the monitoring system (e.g. threshold overrun, business rules) and inference engines (e.g. NORIA-AD). Alignment: - *DCMI*: from the DCMI Abstract Model perspective, a EventRecord is a described resource, hence DC terms apply: - *logRecordId* <=> http://purl.org/dc/terms/identifier : Identifier of notification or log record, as defined by <https://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/x721.html#-logRecordId>. - *logInformation* <=> http://purl.org/dc/terms/description : Additional information describing the logged event, as defined by <https://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/x721.html#-additionalInformation>. - *logType* <=> http://purl.org/dc/terms/type : The Type of the Event (e.g. General Operation Alarm, State Change, etc.), as defined by the NORIA `kos/Notification/EventType` concept scheme. - *alarmCorrelatedNotifications* <=> http://purl.org/dc/terms/relation : EventRecord instances or identifiers that are considered to be correlated to this EventRecord, as defined by <https://www.itu.int/ITU-T/formal-language/itu-t/x/x721/1992/x721.html#-correlatedNotifications>. - *alarmOwner* <=> http://purl.org/dc/terms/mediator : The Support team member who acknowledged an Alarm Event Record. - *alarmProbableCause* <=> http://purl.org/dc/terms/conformsTo : The asserted or inferred cause of the Alarm Event Record, as defined by the NORIA `kos/Notification/ProbableCause` and `kos/Notification/SecurityAlarmCause` concept schemes. Asserting the Alarm cause is equivalent to directly connecting the Alarm, as a fault (issue, incident) artefact, to some phenomenon interpretation. Inferring the Alarm cause is equivalent to guessing the phenomenon origin through Root Cause Analysis (RCA) or some probabilistic approach. - *BBO*: an EventRecord is a `BBO:DocumentResource` in the sense that it is the result of the Event Management process and can be used as an input for another activity. From the BPMN 2.0 perspective, an EventRecord is a `DataObject`. - *PEP*: an EventRecord is an artefact of the realization of a `pep:Procedure`, hence it is a specialization of a `pep:ProcedureExecution` for the NORIA context. - *SLOGERT*: an EventRecord is equivalent to a `log:Event`.
Changes in v0.2: - EventRecord introduced, replacing noria:EventLog. - Removing many related properties to the benefit of direct instanciation with dcterms properties. - Adding rdfs:subClassOf BBO:DocumentResource. - Adding rdfs:subClassOf pep:ProcedureExecution. - Adding rdfs:subClassOf log:Event.
- A network router event with loggingTime=`2022-01-01T17:12:00,259Z` and logText=`LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0/1, changed state to up`. - A configuration change event on network router with pep:hasCommand='no shutdown' and logText='SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36)' and logOriginatingManagedObject=<object/NE_R1>.
Abstract class for services and broadcasting zones above the *Structural* facet (a.k.a. *Functional facet*).
FunctionalElement
A uniquely identified space for Resources within a given Room. Alignment: - *BOT*: - The relationship to the Locus of a Room is available with the `bot:containsZone` property. - Approximating the geographical coordinates of a Locus is feasible through transitive inference over the `bot:hasZeroPoint` of the parent `bot:Site` (considering the GeoNames database this would to a `(bot:Site)=[bot:hasZeroPoint]=>(gn:Feature)` path towards `wgs84_pos:lat` or `wgs84_pos:long` values). - *ORG*: Note that, at instanciation time, `bot:Site` entities may also be `org:Site` (see https://www.w3.org/TR/vocab-org/#org:Site) in order to allow for an Organization (including teams, persons, manufacturers) to be localized (e.g. see `org:basedAt`), and hence allow for intervention distance/time calculus or threat calculus with respect to a given Locus.
Line:L, Column:6, in Room:Server room 314.
Top abstract class of NORIA Cyber/Physical concepts for describing, managing and analyzing ICT systems.
ManagedElement
A Network Interface of some Resource (e.g. server, router, virtual routing and forwarding (VRF) instance), and of some type (e.g. physical, virtual). Usage notes: - The name of the Network Interface (aka. networkInterfaceName, such as `ge-0/0/0.3013` or `ae52.3028`) can be set with the `rdfs:label` property.
Changes in v0.2: - Adding rdfs:subClassOf observable:NetworkInterface.
A physical or logical Link between Resources. Usage notes: - The organizational unit in charge of the Network Link (i.e. the Support team or Owner of the Network Link) can be set with the `noria:resourceManagedBy` property.
Optical fiber, L2TP connection, etc.
An abstract class representing a formal set of operations to be carried out in a standardized/controlled way.
Changes in v0.2: - Adding rdfs:subClassOf folio:ControlMethod.
A system upgrade procedure, a network traffic fail-over activation, the control method for qualifying some system fault.
Abstract class for (predeﬁned/computed) operational process (a.k.a. *Procedural facet*).
ProceduralElement
Incident diagnosis procedure, cyber attack scenario, network route fail-over algorithm
The Product Model of some Resource as per the Manufacturer's naming.
An abstract representation of qualifiable, quantifiable, observable or operable qualities of some Element.
Property
General resource record of the Communication Device kind from the logistics park. It is a managed entity that can be either Physical or Virtual. Alignment: - *SEAS*: Whenever a Resource individual is an assembly of other resources (e.g. a server rack) or is part of an assembly (e.g. a server blade), the Resource individual can also be declared as a `seas:System` in order to benefit of the `seas:subSystemOf` relation. For example, Resources may be grouped in some `noria:Service` class for providing both an end-to-end analysis of the data path (i.e. Communication Devices + Connections) and an abstract object linked to some end user (e.g. Customer). - *BOT*: A `noria:Resource` is a sub-class of `bot:Element` for setting instances in the context of a physical environment (e.g. in a building). - *SLOGERT*: A `noria:Resource` is equivalent to a `log:Host`. - *UCO*: A `noria:Resource` is equivalent to an UCO's observable `Device`.
Elément structurant informatique et télécoms.
ICT resource.
Changes in v0.2: - Adding rdfs:subClassOf bot:Element. - Adding rdfs:subClassOf observable:Device. - Adding rdfs:subClassOf log:Host.
A part of the physical world or a virtual world whose 3D spatial extent is bounded actually or theoretically, and provides for certain functions within the zone it is contained in. Alignment: - *BOT*: A Room is a specialization of a `bot:Space` for common sense understanding.
SALLE STOCKAGE RESEAU 314
Server room 314
Service is an abstract base class for defining the Service hierarchy, i.e. the composition of assets (a.k.a. asset chain, service function chain) for providing a end-to-end data path or processing for some specific Customer or purpose. Usage notes: - The `noria:Service` is loosely defined as per the way to group underpinning assets. The typical usage is to assert `noria:ApplicationModule` entities as `seas:subSystemOf` a given `noria:Service`. - The network topology related to a given `noria:Service` is inferred from the set of resources, network interfaces and network links included in each Application that is part of the Service. We remark here that, although deterministic, the data path granularity calculus for some communication session (e.g. a time-bounded IP/http query with its response) depends on the specificity of the resources included in `ApplicationModule` instances. For example, the resulting granularity for a "national IP backbone infrastructure" application instance will correspond to the [routing domain](https://en.wikipedia.org/wiki/Routing_domain). Alignment: - *SEAS*: A `noria:Service` allows for grouping components, hence it is a subclass of `seas:System`. - *DevOps-Infra*: - The `noria:Service` is a concrete instance of a set of deployment models, hence it relates to `devopsprod:ServiceInstance`. - A `noria:Service.serviceType(<kos/service/type/CustomerFacingService>)` relates to the `devopsprod:BusinessProductInstance` concept. - *tmforum*: - The `noria:Service` is equivalent to the `Service` object from the *[TMF 638 - Service Inventory](https://github.com/tmforum-apis/TMF638_ServiceInventory)* API. - Using the `noria:serviceType` relates to asserting the `CustomerFacingService` or `ResourceFacingService` Service subclasses notions of the *TMF 638 - Service Inventory* API (i.e. as either being possibly visible and usable by a Customer or not). - *IETF*: Assuming a group *Service Functions* (SFs), the `noria:Service` concept relates to the *Service Function Chain (SFC)* definition from the [RFC 7665: SFC Architecture](https://www.rfc-editor.org/rfc/rfc7665) (see also [ITU-T X.1045](https://handle.itu.int/11.1002/1000/14043) for complementary SFC definition).
Service
Changes in v0.2: - Further definition, notably with rdfs:seeAlso relationships. - Adding owl:equivalentClass devopsprod:ServiceInstance.
End-to-end data path for some specific customer
Abstract class for physical/logical ICT systems's assets and relations (a.k.a. *Structural facet*).
StructuralElement
router xxx, virtual machine yyy, link zzz entities; is_a, connected_to or part_of properties
An abstract class for ICT systems's properties that should be defined as classes for extended description capability.
StructuralObservable
Time context of the observable value
A trouble ticket represents a record used for reporting and managing the resolution of resource problems. Main trouble ticket attributes are its description, severity, type, priority, related dates (created, target resolution, resolution, etc.), state and related information (change reason, change date), related parties (originator, owner, pilot), notes, trouble causes and impacts. Alignment: - *DCMI*: from the DCMI Abstract Model perspective, a TroubleTicket is a described resource, hence DC terms apply: - troubleTicketId <=> http://purl.org/dc/terms/identifier : Identifier of the trouble ticket. - troubleTicketCreationDateTime <=> http://purl.org/dc/terms/created : The Date on which the TroubleTicket was created in the ticketing system. - troubleTicketLastUpdate <=> http://purl.org/dc/terms/modified : The date and time that the TroubleTicket was last updated. - troubleTicketName <=> http://purl.org/dc/terms/title : Name of the TroubleTicket, typically a short description provided by the user that create the ticket or complementary data - troubleTicketDescription <=> http://purl.org/dc/terms/description : Extended description of the trouble or issue. - troubleTicketNote <=> http://purl.org/dc/terms/hasPart : The TroubleTicketNote(s) that are associated to the TroubleTicket. - troubleTicketAttachment <=> http://purl.org/dc/terms/hasPart : The DocumentAttachment(s) that are associated to the TroubleTicket. - troubleTicketRelationshipParentOf <=> http://purl.org/dc/terms/hasPart : The TroubleTicket(s) this ticket is parent of (TicketRelationship). - troubleTicketRelationshipChildOf <=> http://purl.org/dc/terms/isPartOf : The TroubleTicket this ticket is the child of (TicketRelationship). - troubleTicketDuration <=> http://purl.org/dc/terms/extent (optional) : The overall duration of the incident management process, typically in ISO 8601 duration format. Can be useful for computing Mean Time To Repair (MTTR) values for a given `problemCategory`. - troubleTicketCorrelatedNotifications <=> http://purl.org/dc/terms/relation : EventRecord(s) instances or identifiers that are considered to be correlated to this TroubleTicket/TroubleTicketNote. - *BBO*: a TroubleTicket is a DocumentResource in the sense that it is the result of the Incident Management process and can be used as an input for another activity. From the BPMN 2.0 perspective, a TroubleTicket is a DataObject. - *PEP*: a TroubleTicketNote is a context for (potentially) many *CorrectiveMaintenanceAction* to occur; hence it relates to a `pep:ProcedureExecutionContainer`, which in turns enable to track the corresponding `EventRecord` through the `ldp:member` property.
A trouble ticket note represents a record used for reporting and information sharing during the incident management process for a given Trouble Ticket. Alignment: - *DCMI*: from the DCMI Abstract Model perspective, a TroubleTicketNote is a described resource, hence DC terms apply: - troubleTicketNoteDate <=> http://purl.org/dc/terms/created : The recording date of the TroubleTicketNote. - troubleTicketNoteAuthor <=> http://purl.org/dc/terms/creator : The Author of the TroubleTicketNote. - troubleTicketNoteText <=> http://purl.org/dc/terms/description : The content of the TroubleTicketNote. - troubleTicketNoteForTicket <=> http://purl.org/dc/terms/isPartOf : The TroubleTicket this note is part of. - troubleTicketNoteCorrelatedNotifications <=> http://purl.org/dc/terms/relation : EventRecord(s) instances or identifiers that are considered to be correlated to this TroubleTicketNote. - *BBO*: a TroubleTicketNote is a DocumentResource in the sense that it is the result of the Incident Management process and can be used as an input for another activity. From the BPMN 2.0 perspective, a TroubleTicketNote is a DataObject. - *PEP*: a TroubleTicketNote is a context for (potentially) many *CorrectiveMaintenanceAction* to occur; hence it relates to a `pep:ProcedureExecutionContainer`, which in turns enable to track the corresponding `EventRecord` through the `ldp:member` property.
We shut interface ge-0-0-1 of Router1 in order to force route on Router2. 2.6Gb traffic measured at 10:28. Customer has confirmed that the service is restored.
The Document Ontology defines the TroubleTicket and ChangeRequest objects. These are data resource (i.e. the result of a process) for efficient Incident Management and Change Management.
The NORIA Notification Ontology
An abstract representation of a relationship between some StructuralElement instance and some literal data.
structuralElementObservableData
The EventRecord at the origin of the creation of the Trouble Ticket.