The Inferal Data Classification Ontology defines RDF terms for classifying addressable data elements with data categories, operational sensitivity, detection provenance, confidence, workflow status, policy hooks, and auditable classification rules.

The ontology models general data classification. Its general dcls:dataCategory and dcls:candidateDataCategory properties classify non-personal, operational, and reference data as well as personal data. Personal-data classification is a specialization: dcls:personalDataCategory and dcls:candidatePersonalDataCategory refine the general properties for privacy use cases without narrowing the scope of the module to personal data.

This is an unofficial 0.1 Editor's Draft maintained in the Inferal ontology repository.

Feedback should be sent to contact@inferal.com.

Namespace

https://ontology.inferal.com/modules/data-classification/

The suggested prefix is dcls. This module references [[DPV]], [[DPV-PD]], and [[PROV-O]]. DPV, DPV-PD, and PROV-O are imported by owl:imports. Repository catalog mappings resolve these imports to local Turtle files during validation.

Classification Model

A dcls:DataElement is an addressable place where data occurs. Examples include a database column, JSON path, RDF predicate, event attribute, table field, file region, or dataset attribute. The data element is the resource that should be classified, not usually the literal value contained in the element.

A dcls:DataClassification is a classification record about a data element. It can represent a confirmed assertion, an unconfirmed candidate, a rejection, or a stale record. It MUST identify exactly one dcls:DataElement with dcls:classifiesElement and MUST identify at least one asserted or candidate data category.

Confirmed classifications use asserted category properties: dcls:dataCategory or dcls:personalDataCategory. Candidate and rejected classifications use non-asserting category properties: dcls:candidateDataCategory or dcls:candidatePersonalDataCategory.

dcls:dataCategory is a subproperty of dpv:hasData. dcls:personalDataCategory is a subproperty of both dcls:dataCategory and dpv:hasPersonalData. The candidate properties are deliberately not DPV subproperties, so a rejected or unconfirmed detection does not entail dpv:hasData or dpv:hasPersonalData. Consumers can use DPV and DPV-PD categories such as pd:EmailAddress, pd:IPAddress, pd:OfficialID, or dpv:SpecialCategoryPersonalData without this module redefining those taxonomies.

Illustrative Patterns

The following patterns are non-normative, but they show how the module is intended to be used in data catalogs, privacy scans, schema registries, and RDF-native datasets.

Scanner Candidate

A scanner should create a classification record using candidate category properties when the result has not been accepted by a trusted reviewer or policy process. The candidate remains queryable and auditable, but it does not assert a DPV personal-data fact.

Human Confirmation

A confirmed record uses asserted category properties. Because dcls:personalDataCategory is a subproperty of dpv:hasPersonalData, RDFS consumers can use the record as a local assertion that the classified element has personal data of the referenced category.

Rejected Detection

Rejected detections should remain explicit classification records when they are useful for audit, scanner tuning, or suppressing repeated false positives. They still use candidate category properties because the record states what was proposed, not what is accepted.

RDF Predicate Classification

RDF-native datasets can classify a predicate as the data-bearing element. The classified element is the predicate occurrence pattern, not a specific literal value. This supports catalogs and policy controls over graphs without requiring every value triple to be reified.

Policy Materialization

Policy engines can consume classifications directly, or local SPARQL rules can materialize operational hooks. For example, a local profile can require encryption and review for restricted classifications.

Term Reference

Classification Records

A classification record is intentionally separate from the data element and from the DPV category. This allows a scanner, reviewer, or lineage process to make a qualified statement about a field without changing the identity of the field or the category. The record carries evidence, workflow state, and local policy consequences.

Term Kind Expected use
dcls:DataClassification Class Node that groups the category, confidence, status, provenance, sensitivity, and policy hooks for one data element.
dcls:classifiesElement Object property Exactly one link from the classification record to the classified dcls:DataElement.
dcls:hasClassificationStatus Object property Optional workflow state. The local shapes allow at most one status per classification record.
dcls:confidence Datatype property Deprecated legacy scalar projection from 0 to 1. New classifications use dcls:confidenceAssessment.
dcls:confidenceAssessment Object property Optional link to a scale-aware conf:ConfidenceAssessment for the classification record.
dcls:requiresReview Datatype property Boolean operational hook. Candidate and restricted classifications are expected to set this to true.

Category Properties

Category properties are split into asserted properties and candidate properties. This is the main truth-status boundary in the ontology. Use asserted properties when the classification is accepted as a local fact. Use candidate properties when the category is proposed by a detector, imported as unreviewed evidence, rejected, or otherwise not accepted.

Term Entailment Use for
dcls:dataCategory Subproperty of dpv:hasData Confirmed non-personal or general DPV-compatible data categories.
dcls:personalDataCategory Subproperty of dcls:dataCategory and dpv:hasPersonalData Confirmed DPV-PD or DPV-compatible personal-data categories.
dcls:candidateDataCategory No DPV subproperty entailment Unconfirmed or rejected general data-category proposals.
dcls:candidatePersonalDataCategory Subproperty of dcls:candidateDataCategory; no DPV hasPersonalData entailment Unconfirmed or rejected personal-data-category proposals.

Status Values

Status values are local workflow states. They do not by themselves create or remove category triples; SHACL constraints define which category properties are acceptable for each state in this profile.

Status Meaning Category property expectation
dcls:Candidate Unconfirmed detection or import. Use candidate category properties and require review.
dcls:Confirmed Accepted by a trusted process, reviewer, or source. Use asserted category properties.
dcls:Rejected Detection considered incorrect or not applicable. Use candidate category properties so the rejected record remains auditable without asserting the category.
dcls:Stale Previously accepted classification that should be re-evaluated. May preserve asserted categories while requiring downstream review policy.

Data Elements

A data element MAY point to a containing asset using dcls:sourceAsset. It MAY provide a string address using dcls:path. RDF-native elements MAY point to the RDF predicate carrying the data with dcls:dataPredicate.

dcls:sourceAsset identifies the containing dataset, table, stream, file, message type, graph, or document. dcls:path is intentionally a string because different source systems use different address syntaxes, such as SQL column names, dotted object paths, JSONPath, XPath, or source-code spans. dcls:dataPredicate is for RDF-native datasets where the classified value occurs as the object of a predicate.

A classification MAY identify its local evaluation context with dcls:hasClassificationContext. The value is a dcls:ClassificationContext, such as a jurisdiction, processing context, policy scope, controller context, system, or operational environment.

Context is deliberately modeled as a resource rather than a literal. Downstream profiles can specialize dcls:ClassificationContext for jurisdictions, tenants, product areas, data controllers, processing purposes, contractual scopes, or deployment environments.

Sensitivity

dcls:SensitivityLevel is a local operational specialization of dpv:SensitivityLevel. The predefined levels are dcls:LowSensitivity, dcls:ModerateSensitivity, dcls:HighSensitivity, and dcls:RestrictedSensitivity. A classification uses dcls:hasSensitivityLevel to reference one of these levels or an extension-defined level. The property is a subproperty of dpv:hasSensitivityLevel.

Sensitivity is intentionally separate from DPV category semantics. For example, the same DPV-PD category can require different local controls depending on jurisdiction, processing purpose, data subject population, retention, form, or exposure path.

Level Typical interpretation Typical policy consequence
dcls:LowSensitivity Low expected privacy or operational impact in the stated context. Ordinary stewardship controls.
dcls:ModerateSensitivity Privacy-relevant data requiring routine access and handling controls. Access control, purpose review, or ordinary retention checks.
dcls:HighSensitivity Exposure can create substantial privacy, compliance, or operational risk. Stronger access, logging, minimization, and transfer controls.
dcls:RestrictedSensitivity Data requiring explicit approval and strong controls before use, sharing, or broad access. Review required and at least one required measure in this profile.

Detection Provenance

A dcls:DetectionActivity is a subclass of prov:Activity. A classification points to the producing or importing activity with dcls:wasClassifiedBy. Detection-specific provenance can use dcls:detectedBy as a specialization of the producing classification activity. Review provenance uses dcls:reviewedBy. Review activities influence a classification but are not modeled as a second prov:wasGeneratedBy activity for the same entity. The activity identifies its dcls:hasDetectionMethod.

The predefined detection methods are dcls:RegexDetection, dcls:NERDetection, dcls:SchemaNameDetection, dcls:SampleValueDetection, dcls:ManualReview, and dcls:LineageInheritedDetection.

Method Evidence represented
dcls:RegexDetection Pattern matches over names or sampled values.
dcls:NERDetection Named-entity recognition output over text values.
dcls:SchemaNameDetection Heuristics from column names, field names, predicate IRIs, or schema labels.
dcls:SampleValueDetection Inspection of sampled values from the data element.
dcls:ManualReview Human analyst or steward judgment.
dcls:LineageInheritedDetection Classification inherited through upstream/downstream lineage, mapping, or transformation.

Classification Rules

A dcls:ClassificationRuleSet is a versioned set of classification rules or heuristics. A dcls:ClassificationRule describes one rule in that set. Rule records are intended for audit, explanation, and provenance. They are not a complete executable rule language.

A rule set links to its rules with dcls:hasClassificationRule. A generated or reviewed classification can identify the rule that produced it with dcls:classifiedByRule. Rules can state what evidence they inspect using dcls:matchesFieldPart and the field-part individuals dcls:LocalNamePart, dcls:LabelPart, and dcls:CommentPart.

Lexical rule conditions are represented with dcls:matchesPattern and dcls:excludesPattern. Ordered rule sets can use dcls:ruleOrder. Human-readable explanation can use dcls:ruleRationale.

Rule output is described with dcls:assignsDataCategory, dcls:assignsPersonalDataCategory, dcls:assignsClassificationStatus, dcls:assignsSensitivityLevel, dcls:assignsConfidence, and dcls:assignsReviewRequirement. These describe what a rule assigns when it fires; they do not by themselves classify any data element.

Confidence And Status

dcls:confidence is a deprecated legacy scalar projection from 0 to 1 on a classification. It is retained so older data can still be read and range-checked, but new classifications must use dcls:confidenceAssessment.

dcls:confidenceAssessment links a classification to a structured confidence assessment in the Inferal Confidence Ontology. Use this link when the confidence value needs an explicit scale, uncertainty components, composition operator, conversion rule, or recorded derivation assumptions.

dcls:ClassificationStatus supports review workflows. The predefined statuses are dcls:Candidate, dcls:Confirmed, dcls:Rejected, and dcls:Stale. A classification uses dcls:hasClassificationStatus to reference one status.

dcls:requiresReview is a boolean hook for queueing review. Candidate classifications MUST explicitly require review. Restricted classifications MUST require review and at least one required measure.

Policy Hooks

This module does not define a complete policy language. It provides hooks from classifications into policy, compliance, or enforcement resources. A classification MAY use dcls:requiresMeasure, dcls:requiresLegalBasis, dcls:allowedProcessing, dcls:prohibitedProcessing, and dcls:triggersPolicy.

dcls:DataPolicy is a policy, rule, control set, or downstream decision resource. It can later be aligned to DPV Rules, ODRL, SPECIAL, or a local policy module.

dcls:MitigationMeasure is a local category of DPV technical measures for reducing exposure of classified data elements in downstream representations, exports, or processing contexts. Values of dcls:requiresMeasure are measure category IRIs. Producers MAY use a broad category when the implementation is not known, or a more specific subclass when a concrete technique is required. The predefined mitigation categories are semantic controls rather than algorithm names: dcls:IdentityLinkagePseudonymisation, dcls:AttributeGroupingObfuscation, dcls:ValueElision, and dcls:ElementElision.

Measure Intended use DPV alignment
dcls:IdentityLinkagePseudonymisation Replace a direct identifier with a stable pseudonymous value so records about the same person, account, device, or entity can still be linked. Subclass of dpv:DeterministicPseudonymisation.
dcls:AttributeGroupingObfuscation Replace an attribute value with an opaque grouping value so records sharing that attribute can be grouped without exposing the original value. Subclass of dpv:DataSanitisationTechnique.
dcls:ValueElision Withhold the original value while preserving the data element in the downstream representation, usually through a non-informative placeholder. Subclass of dpv:DataRedaction.
dcls:ElementElision Omit the data element from the downstream representation without implying deletion or erasure of the source data. Subclass of dpv:DataRedaction.

Validation Expectations

Examples