The NORIA Ontology
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
Lionel Tailhardat (https://orcid.org/0000-0001-5887-899X)
Raphaël Troncy (https://orcid.org/0000-0003-0457-1436)
Changes in v0.3: - Changed the ontology architecture from micro-architecture to single file. - Removed owl:imports for NORIA foundations. 2024-03-15: - Changed bibo:status
ManagedElement
Top abstract class of NORIA Cyber/Physical concepts for describing, managing and analyzing ICT systems.
Property
An abstract representation of qualifiable, quantifiable, observable or operable qualities of some Element.
elementProperty
An abstract representation of a relationship between some Element instance and some Property instance.
elementDistinguishedName
The Distinguished Name of the Element Instance (i.e. unique identifier).
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)).
StructuralElement
Abstract class for physical/logical ICT systems's assets and relations (a.k.a. *Structural facet*).
router xxx, virtual machine yyy, link zzz entities; is_a, connected_to or part_of properties
StructuralObservable
An abstract class for ICT systems's properties that should be defined as classes for extended description capability.
Time context of the observable value
structuralElementObservable
An abstract representation of a relationship between some StructuralElement instance and some StructuralObservable instance.
structuralObservableOf
Relates some `StructuralObservable` instance to some `StructuralElement` instance.
structuralElementObservableData
An abstract representation of a relationship between some StructuralElement instance and some literal data.
structuralElementDistinguishedName
The Distinguished Name of the Structural Element Instance (i.e. unique identifier).
FunctionalElement
Abstract class for services and broadcasting zones above the *Structural* facet (a.k.a. *Functional facet*).
functionalElementDistinguishedName
The Distinguished Name of the Functional Element Instance (i.e. unique identifier).
DynamicElement
Abstract class for time-related entities and their potential chaining (a.k.a. *Dynamic facet*).
An alarm with happens_on or followed_by properties
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.
ProceduralElement
Abstract class for (predeﬁned/computed) operational process (a.k.a. *Procedural facet*).
Incident diagnosis procedure, cyber attack scenario, network route fail-over algorithm
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.
The Working Hours for reaching the Agent (Team, Employee, etc.).
8:00 am - 12:00 am / 1:00 pm - 5:30 pm (Mon --> Fri)
8H-12H/13H-17H30 (lun --> ven)
Change in v0.2: - rdfs:domain moved from noria:Employee to foaf:Agent. - name and label moved from teamWorkingHours to agentWorkingHours.
The preferred contact method to reach the Agent (Team, Group, Employee).
Phone, e-mail
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.
Instructions for involving the Agent (Team, Group, Employee).
Use the Ticketing system + hotline phone number for national L2 and L3 issues.
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.
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.
Application model code.
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.
The type of the Application.
The importance of the Application from the business impact perspective for risk assessment analysis and incident management prioritization.
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
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 child/parent relationship between a specific and managed instance of an Application (i.e. an Application Module) and the Application.
The name of the Application module.
CONCAT( Application().applicationModelIdentifier(), "_", ApplicationModule().applicationModuleIdentifier() )
applicationModuleIdentifier
Application module code.
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.
Administration team.
Entité exploitante.
Changes in v0.2: - rdfs:range org:OrganizationalUnit in place of noria:Team.
Administration leader.
Responsable de l'entité exploitante.
Changes in v0.2: - rdfs:range foaf:Agent in place of noria:Employee.
Level 2 Support Team.
Entité support : Soutien Applicatif Technique (SAT) - Exploitant N2.
Support leader.
Responsable de l'entité support.
Level 1 support team.
Entité support: Point d'Entrée Interface Technique (PEIT) - Exploitant N1.
Hotline team.
Equipe d'astreinte applicative.
SLA level.
Niveau de service.
SLA Level date, the date at which the SLA Level has been set or updated.
Date du Niveau de service.
Hotline enabled for issues on a given ApplicationModule.
Possibilité d'appel de l'astreinte applicative.
Status of the Application Module.
Etat de service du Module Applicatif.
In Production
En Production
Service
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).
End-to-end data path for some specific customer
Changes in v0.2: - Further definition, notably with rdfs:seeAlso relationships. - Adding owl:equivalentClass devopsprod:ServiceInstance.
The type of the Service.
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 TroubleTicket 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.
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.
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.
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>
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 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 ticket type.
Failure, Long period assistance, Assistance, Installation, Maintenance, Parametrization, etc.
troubleTicketCriticity
The ticket criticity from the customer impact perspective.
Interrupted service, Corrupted service, Working backup, etc.
troubleTicketPriority
The trouble management priority.
The person or group family at the origin of the creation of the Trouble Ticket.
Customer, Supervision, Internal, Carrier, User, Partners
The EventRecord at the origin of the creation of the Trouble Ticket.
The priority level of the incident.
Immediate Intervention, Deferred Intervention, (State of) Emergency, No intervention, etc.
Supervision tool which detected the problem.
troubleTicketCategory
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.
Isolated customer site, Total breakdown, Working backup, Downgrading equipment, Inaccessible destination, etc.
problemCategory
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.
troubleTicketCause
The cause(s) defined for the trouble, in plain text.
SSH authentication failure due to loss of sync to NTP server and internal clock drift.
problemResponsibility
The *final* area of responsibility identified for the incident.
Customer, Managed access equipment on customer's premises, Managed backbone networks, Managed specific networks, Contract application-hosting services, Ill-defined, etc.
The date on which the trouble was discovered.
The Customer initial restoration date Estimated Time to Restore (ETR).
Confirmed to customer planned restoration date Actual Time to Restore (ATR).
The Customer Commitment Deadline Date (calculated on product information).
The *enable* or *disable* external notification on trouble ticket events.
The current activity status of the trouble ticket.
Initialised, InProgress, Frozen, Restored, Resolved, Closed
The related party(ies) that are associated to the ticket.
troubleTicketPartyIntervention
The history of groups activation and responsibility transfer.
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 Resource entity on which the trouble ticket has been created.
troubleTicketImpacts
A list of resources or services (applications) impacted by the trouble.
TroubleTicket.troubleTicketImpacts({Application [*], Resource [*]})
A list of Characteristics of the ticket (TroubleTicketCharacteristic [*]). The Trouble ticket specific characteristics
troubleTicketFreezeItem
The ticket freeze period history.
A list of `noria:EventRecord` specifically describing the freeze periods for the given `noria:TroubleTicket`.
The comment provenance type and/or disclosure rules family.
Customer, Group, Internal, System, etc.
Inward customer comments, Local customer call back, Tests and measurements, Diagnosis, 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.
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.
Date and time on which the Change Request implementation has started. It is displayed only after the Change Request implementation has started actually.
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.
Nature of the Change Request
Internal intervention, Third party intervention, Customer intervention, Change requested by customer
The type of the request describes the a priori impact and risk level of the Change Request.
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)
Expected duration of the outage, if any involved by the Change Request type.
The current status of the Change Request.
An item of the standard operation plan catalog for recurring activities.
The agent initiating the Change Request.
The pilot of the Change Request.
The actor of the Change Request.
If *true*, the Change Request is subject to special regulations.
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 class representing a formal set of operations to be carried out in a standardized/controlled way.
A system upgrade procedure, a network traffic fail-over activation, the control method for qualifying some system fault.
Changes in v0.2: - Adding rdfs:subClassOf folio:ControlMethod.
The Operation Plan (procedure) guiding the execution of the given Action.
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
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'.
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 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.
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.
Server room 314
SALLE STOCKAGE RESEAU 314
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.
Ligne:L, Colonne:6, en Salle:SALLE STOCKAGE RESEAU 314.
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.
A unique identifier of a Site.
Change in v0.2: rdfs:range moved from noria:Site to bot:Site.
The type of a Site.
Street address of a Site.
Postal Code for a Site. Alignment: - *GeoNames*: *ADM2*, *ADM3* or *ADM4* annotations may correspond to this property, depending on the considered country.
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`.
Street for a Site.
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`.
- 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>.
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.
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.
A named Resource, Application, Security Alarm Detector, etc.
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.
The Management System that receives, processes and forwards the Log record.
A named instance of Network Management System (NMS), Security Information and Event Monitoring system (SIEM), etc.
Changes in v0.2: - Adding rdfs:subPropertyOf dcterms:creator. - Adding rdfs:subPropertyOf prov:wasAttributedTo. - Adding rdfs:subPropertyOf noria:eventRelatedElement.
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.
A employee or maintenance bot that carried-out a change or corrective maintenance action. A service user that carried-out SQL Injection.
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.
Textual information describing the logged event.
Changes in v0.3: - Removed rdfs:subPropertyOf dcterms:title (useless and Widoco rendering issue).
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.
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).
Critical, Major, Minor, Warning.
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.
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.
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.
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 operational status of the Virtual Server.
The administrative status of the Network Interface.
The operational status of the Network Interface.
The metric value associated to the Network Interface for some routing protocol.
The emitted optical power measure of the Network Interface, in dBm.
The received optical power measure of the Network Interface, in dBm.
The average received optical power of the Network Interface, in dBm.
The high received power notification threshold.
The low received power notification threshold.
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`.
ICT resource.
Elément structurant informatique et télécoms.
Changes in v0.2: - Adding rdfs:subClassOf bot:Element. - Adding rdfs:subClassOf observable:Device. - Adding rdfs:subClassOf log:Host.
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.
The Product Model of some Resource as per the Manufacturer's naming.
The Support team or Owner of the Network Element (IT Resource).
- Resource("DNS server").resourceManagedBy("DNS admin team") - NetworkLink("WAN Paris-Papeete").resourceManagedBy("International backbone support team")
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.
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 logistic UID of the Resource (a.k.a. asset tag).
The hostname (nodename) of the Resource.
Changes in v0.2: - Adding rdfs:subPropertyOf log:host. - Adding rdfs:subPropertyOf observable:hostname.
The product model of the Resource.
The type of the Network Element Resource.
The serial number of the Resource.
The production state of the Resource.
The installation date of the Resource.
The Application this Resource is contributing to, whatever the Application type.
Corporate Internet access Infrastructure, Clock synchronization Service
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`.
Line: L, Column:6, in Room:Server room 314.
Changes in v0.2: - Adding rdfs:range noria:Locus. - Adding rdfs:subPropertyOf observable:location.
Specifies the IP address for remote management of the Resource, if relevant.
Relates a Resource that is part of a cluster with the cluster controller.
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.
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 type of the Network Interface.
physical, subinterface, virtual
The Resource the Network Interface is part-of.
The Network Link the Network Interface is attached-to.
The UID of the NetworkLink.
Link termination Resource, the Resource at some end fo the Network Link.
Link termination Resource, the Resource at the origin of a Network Link for a unidirectional link.
Link termination Resource, the Resource at the destination of a Network Link for a unidirectional link.
The installation date of the NetworkLink.
A description of the type of the Network Link.