# Industry–Function Mapping (IFM) — core ontology # # The graph exists so that ecosystem use cases and real implementation flows can # be classified and composed. Three concerns are kept apart, and the separation # is the load-bearing decision in this file: # # CLASSIFICATION where does this use case belong? # ifm:Sector, ifm:BusinessFunction, ifm:ValueStream, # ifm:ValueStreamStage # # INTERFACE what can connect to it? # ifm:Condition, ifm:Requirement, ifm:Provision, # ifm:requires, ifm:provides # # REALISATION how is it implemented? # ifm:Flow, ifm:CredentialType, ifm:Participation, # ifm:TrustRole, protocol profile, governance reference # # Two rules follow from the separation and are worth stating before anything # else, because breaking either collapses the model back into a taxonomy: # # A classification relationship never implies composability. Two use cases # under the same function, in the same sector, at the same value-stream stage # do not thereby connect. They connect when one provides a condition the # other requires. # # A credential identifier is never the mechanism of composition. A use case # provides a condition; a credential can substantiate that condition; another # use case requires the condition, not the credential. That is what lets a # second credential, issuer or evidence mechanism serve the same business # interface without touching the classification. # # SPDX-License-Identifier: CC-BY-4.0 @prefix ifm: . @prefix owl: . @prefix rdfs: . @prefix skos: . @prefix dct: . @prefix xsd: . a owl:Ontology ; dct:title "Industry–Function Mapping ontology"@en ; dct:description """Vocabulary for classifying reusable business use cases against an industry sector taxonomy, a business function taxonomy and a value stream position; for describing each one's machine-readable interface of required and provided conditions; and for recording the real implementation flows and credential types that realise them. The purpose is that a new ecosystem flow or a new credential type can find a stable place in the classification and connect to what is already there, instead of forcing the classification itself to grow."""@en ; dct:creator "Daniel Saeuberli" ; dct:license ; owl:versionInfo "0.3.0" . ################################################################ # Composition — the abstract interface # # A use case pattern, a value stream stage and a value stream itself all expose # the same shape: a set of required conditions and a set of provided ones. One # abstract class carries that shape so the composition rules are written once # and every kind of element can feed every other kind. ################################################################ ifm:ComposableElement a owl:Class ; rdfs:label "Composable element"@en ; rdfs:comment """Anything with an interface of required and provided conditions: a use case pattern, a value stream stage, or a whole value stream. Introduced because the composition rules are identical for all three, so a use case can feed a value stream and a value stream can feed a use case without a second set of properties."""@en . ifm:Requirement a owl:Class ; rdfs:label "Requirement"@en ; rdfs:comment """One thing that must be true before a composable element can run. Reified rather than a bare link to a condition, so it can also name the actor the condition is about, a specific evidence type where the requirement genuinely turns on one, and contextual constraints. Only the condition is mandatory. An interface stays as loose as its author left it: a requirement that names no subject role, no evidence type and no context is met by anything that provides a compatible condition."""@en . ifm:Provision a owl:Class ; rdfs:label "Provision"@en ; rdfs:comment """One thing that is true once a composable element has run. Reified for the same reasons as ifm:Requirement. Exactly one provision of a use case pattern is its principal outcome; the rest are additional outputs."""@en . ifm:requires a owl:ObjectProperty ; rdfs:label "requires"@en ; rdfs:domain ifm:ComposableElement ; rdfs:range ifm:Requirement ; rdfs:comment "An element with no requirement can start unaided."@en . ifm:provides a owl:ObjectProperty ; rdfs:label "provides"@en ; rdfs:domain ifm:ComposableElement ; rdfs:range ifm:Provision ; rdfs:comment "Every use case pattern must provide at least one thing, or nothing can follow it."@en . ifm:condition a owl:ObjectProperty ; rdfs:label "condition"@en ; rdfs:range ifm:Condition ; rdfs:comment "The condition a requirement asks for or a provision establishes. The one mandatory part of an interface point."@en . ifm:subjectRole a owl:ObjectProperty ; rdfs:label "subject role"@en ; rdfs:range ifm:SubjectRole ; rdfs:comment """Which party the condition is about, where a use case involves more than one it could apply to. A requirement about an organisation is not met by a provision about a natural person. Omitted where the subject is obvious."""@en . ifm:evidenceType a owl:ObjectProperty ; rdfs:label "evidence type"@en ; rdfs:range ifm:CredentialType ; rdfs:comment """A specific credential, recorded only where the interface point genuinely turns on one. On a requirement it narrows what is acceptable; on a provision it records what this element actually issues. Most interface points should leave it empty, because naming a credential in an interface is what stops a second credential from serving the same business need."""@en . ifm:contextConstraint a owl:DatatypeProperty ; rdfs:label "context constraint"@en ; rdfs:comment """Contextual constraints on an interface point, as `key=value` clauses: jurisdiction, sector, actor type, governing authority, required assurance, governance regime. Composition means a compatible interface AND compatible context. The vocabulary is deliberately small for now; the shape is here so it can grow without the interface model changing."""@en . ifm:principalOutcome a owl:DatatypeProperty ; rdfs:label "principal outcome"@en ; rdfs:range xsd:boolean ; rdfs:comment """True on the one provision that is the use case's reason for existing. Exactly one per use case pattern. Additional provisions are legitimate outputs; they are not what the use case is for."""@en . ifm:satisfies a owl:ObjectProperty ; rdfs:label "satisfies"@en ; rdfs:domain ifm:Provision ; rdfs:range ifm:Requirement ; rdfs:comment """Derived: this provision meets that requirement. True when the provided condition is the required one or narrower than it, the subject roles agree where both are stated, any named evidence type is met, and the context constraints are compatible. Never entered by hand."""@en . ifm:enables a owl:ObjectProperty ; rdfs:label "enables"@en ; rdfs:domain ifm:ComposableElement ; rdfs:range ifm:ComposableElement ; rdfs:comment """Derived: something this element provides satisfies a requirement of the other. Computed from the interfaces through the condition subsumption lattice, so an element providing something narrower than what a downstream element asks for is still recognised as feeding it."""@en . ################################################################ # Conditions — what interfaces are written in # # Conditions form a subsumption lattice through skos:broader. That is what lets # an interface be written at the level of generality it actually needs: a use # case asking for "education qualification evidence" is fed by one providing an # upper-secondary qualification, without either naming the other. ################################################################ ifm:Condition a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Condition"@en ; rdfs:comment """Something that is true, or that a party holds, before or after a composable element runs. Conditions are deliberately coarse, because their purpose is to be shared: a condition used by one use case connects nothing. A narrower condition satisfies a requirement for a broader one, never the reverse. skos:broader carries that relation."""@en . ifm:EvidenceCondition a owl:Class ; rdfs:subClassOf ifm:Condition ; rdfs:label "Evidence condition"@en ; rdfs:comment """Evidence is available: a party holds something it can present and another can check. Says nothing about whether anyone has checked it or acted on it, which is the distinction the rest of these subclasses exist to keep."""@en . ifm:FactCondition a owl:Class ; rdfs:subClassOf ifm:Condition ; rdfs:label "Fact condition"@en ; rdfs:comment """A relying party has established a fact by checking evidence: an identity verified, an age threshold proven, a qualification confirmed. Holding evidence is not this."""@en . ifm:OutcomeCondition a owl:Class ; rdfs:subClassOf ifm:Condition ; rdfs:label "Outcome condition"@en ; rdfs:comment "A business decision has been taken on established facts - a supplier accepted, a record bound to a person."@en . ifm:RelationshipCondition a owl:Class ; rdfs:subClassOf ifm:Condition ; rdfs:label "Relationship condition"@en ; rdfs:comment "An ongoing relationship, entitlement or access exists and persists after the interaction that created it."@en . ifm:SubjectRole a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Subject role"@en ; rdfs:comment "Which party an interface point's condition is about."@en . ################################################################ # Classification — where a use case belongs ################################################################ ifm:Sector a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Sector"@en ; rdfs:comment """An economic activity class. Sectors are not defined here: they are a local SKOS rendering of ISIC Rev. 5 (sections, divisions, classes). skos:notation carries the official ISIC code. Sector is context, not identity. Two flows doing the same work in different sectors realise one use case pattern; they do not become two patterns. Identifiers for divisions and classes deliberately omit the section letter. Letters move between revisions - finance went K to L, education P to Q and human health Q to R between Rev. 4 and Rev. 5 - while the division and class numbers hold."""@en . ifm:naceRev21Code a owl:DatatypeProperty ; rdfs:label "NACE Rev. 2.1 code"@en ; rdfs:domain ifm:Sector ; rdfs:range xsd:string ; rdfs:comment """NACE Rev. 2.1 is the European classification derived from ISIC Rev. 5, and its sections and divisions are reported to be identical to ISIC's. The code is therefore recorded at those two levels only, and not at class level where NACE subdivides ISIC. See ../README.md § "Provenance" for how far that relationship has been verified from primary sources."""@en . ifm:BusinessFunction a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Business function"@en ; rdfs:comment """A reusable category of work performed by an organisation, defined independently of the sector performing it. "Identity proofing" is the same function in banking and in healthcare; only its regulatory context differs. A business function must not denote an industry, a department, an actor, a technology, a legal obligation or a desired outcome. An entry that cannot be stated without naming one of those belongs in another layer. The scheme is IFM's own; the relation to CBF and the APQC PCF is carried as SKOS mapping relations, so an external classification can be corrected or replaced without touching a use case."""@en . ifm:ValueStream a owl:Class ; rdfs:subClassOf ifm:ComposableElement, skos:Concept ; rdfs:label "Value stream"@en ; rdfs:comment """An ordered sequence of stages delivering an outcome - procure to pay, order to cash. The concept follows ArchiMate's Value Stream element. A value stream is a composition template, not just a list of functions: each stage carries its own interface, and the stream as a whole exposes start requirements and end outcomes through the same ifm:requires and ifm:provides as a use case. That is what lets a use case feed a stream and a stream feed a use case. Each catalogue entry here is one modelled decomposition, not the universal sequence for that stream."""@en . ifm:ValueStreamStage a owl:Class ; rdfs:subClassOf ifm:ComposableElement ; rdfs:label "Value stream stage"@en ; rdfs:comment """One step of a modelled value stream: a position, a label, the function it exercises, and its own interface of required and provided conditions. Several use case patterns may realise the same stage."""@en . ifm:hasStage a owl:ObjectProperty ; rdfs:label "has stage"@en ; rdfs:domain ifm:ValueStream ; rdfs:range ifm:ValueStreamStage . ifm:inValueStream a owl:ObjectProperty ; rdfs:label "in value stream"@en ; owl:inverseOf ifm:hasStage . ifm:position a owl:DatatypeProperty ; rdfs:label "position"@en ; rdfs:domain ifm:ValueStreamStage ; rdfs:range xsd:integer ; rdfs:comment """Where the stage sits in the reading order of the modelled sequence. An ordering and presentation hint only. It does not assert temporal exclusivity, that the stage is mandatory, that it causally depends on the preceding one, or any process-control semantics. What actually orders the work is the stages' interfaces."""@en . ifm:stageFunction a owl:ObjectProperty ; rdfs:label "stage function"@en ; rdfs:domain ifm:ValueStreamStage ; rdfs:range ifm:BusinessFunction . ifm:realisesStage a owl:ObjectProperty ; rdfs:label "realises stage"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:ValueStreamStage ; rdfs:comment """This use case pattern is one way of performing that stage. Several patterns may realise one stage, and one pattern may realise stages in several streams - which is the point of separating the two."""@en . ################################################################ # Use case patterns — the canonical unit ################################################################ ifm:UseCasePattern a owl:Class ; rdfs:subClassOf ifm:ComposableElement ; rdfs:label "Use case pattern"@en ; rdfs:comment """A reusable unit of business activity with one primary business function, a defined set of required conditions and one principal business outcome. It may expose additional outputs, but it must represent one coherent transformation: required conditions -> use case -> provided conditions Atomicity. If a candidate performs several independent transformations that could be reused on their own, it is not one pattern: split it, and model the larger process as a flow or a value stream composing the parts. "Employee onboarding" containing identity proofing, qualification verification, contract signing and access provisioning is four reusable patterns and one flow, not one pattern. A pattern is a definition, not an occurrence, and not an implementation. It is deliberately not a schema:Action, and the concrete implementations of it are ifm:Flow instances."""@en . ifm:appliesToSector a owl:ObjectProperty ; rdfs:label "applies to sector"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:Sector ; rdfs:comment """Where the pattern is applicable, which is broader than where it has been implemented. Applicability is editorial; the sectors flows actually run in are recorded on the flows."""@en . ifm:executesFunction a owl:ObjectProperty ; rdfs:label "executes function"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:BusinessFunction ; rdfs:comment """A supporting function. Useful for discovery and context; it must not determine a use case's identity or its composition, which run on the primary function and the interface."""@en . ifm:primaryFunction a owl:ObjectProperty ; rdfs:subPropertyOf ifm:executesFunction ; rdfs:label "primary function"@en ; rdfs:comment "The one function the use case exists to perform. Exactly one per pattern."@en . ifm:sectorHasUseCase a owl:ObjectProperty ; rdfs:label "sector has use case"@en ; owl:inverseOf ifm:appliesToSector . ifm:functionHasUseCase a owl:ObjectProperty ; rdfs:label "function has use case"@en ; owl:inverseOf ifm:executesFunction . ifm:requiresUseCase a owl:ObjectProperty ; rdfs:label "requires use case"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:UseCasePattern ; rdfs:comment """A named dependency on another specific use case. Exceptional by design, and empty in this repository. Prefer the interface. "Tertiary admission requires verified qualification evidence" composes with any upstream flow that can establish it; "tertiary admission requires the Maturitätszeugnis issuance use case" composes with exactly one and silently excludes every alternative route. Use this property only for a dependency that genuinely cannot be stated as a condition."""@en . ################################################################ # Realisation — how a use case is actually implemented ################################################################ ifm:Flow a owl:Class ; rdfs:label "Flow"@en ; rdfs:comment """A real implementation: an actual trust flow, in an actual sector and jurisdiction, naming the credential types it uses, the parties and roles that take part, the protocols and governance it runs under, and where it is documented. A flow realises one or more use case patterns, in order. Keeping flows out of the taxonomy is the point of the distinction: an ecosystem adds implementations continuously, and each new one should find a place among the existing patterns rather than becoming another canonical node. Several flows realising one pattern is the normal case, not an exception."""@en . ifm:realisesUseCase a owl:ObjectProperty ; rdfs:label "realises use case"@en ; rdfs:domain ifm:Flow ; rdfs:range ifm:UseCasePattern ; rdfs:comment "A canonical pattern this flow implements. A flow that composes several patterns records each, with its step."@en . ifm:realisedBy a owl:ObjectProperty ; rdfs:label "realised by"@en ; owl:inverseOf ifm:realisesUseCase . ifm:realisationStep a owl:DatatypeProperty ; rdfs:label "realisation step"@en ; rdfs:range xsd:integer ; rdfs:comment "Where a realised pattern sits in the flow's sequence."@en . ifm:sectorContext a owl:ObjectProperty ; rdfs:label "sector context"@en ; rdfs:domain ifm:Flow ; rdfs:range ifm:Sector ; rdfs:comment """The sector this implementation actually runs in. Omitted for infrastructure flows that belong to no one sector."""@en . ifm:jurisdiction a owl:DatatypeProperty ; rdfs:label "jurisdiction"@en ; rdfs:domain ifm:Flow ; rdfs:comment "The legal jurisdiction the implementation runs under, as an ISO 3166 alpha-2 code."@en . ifm:governanceReference a owl:DatatypeProperty ; rdfs:label "governance reference"@en ; rdfs:domain ifm:Flow ; rdfs:comment "The statute, framework or scheme rules the implementation operates under, where one has been established."@en . ifm:CredentialType a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Credential type"@en ; rdfs:comment """A kind of verifiable credential, not an instance of one, and not a claim, a derived attribute or a business conclusion. Recorded only where something is actually issued as a separate artefact. A credential is evidence, not a socket. It substantiates a condition; it is not what two use cases plug into each other with. Several credential types can substantiate the same condition, which is what lets a new credential enter the ecosystem without any canonical use case changing."""@en . ifm:substantiates a owl:ObjectProperty ; rdfs:label "substantiates"@en ; rdfs:domain ifm:CredentialType ; rdfs:range ifm:Condition ; rdfs:comment """This credential type is evidence that may support the condition. Not equivalence, and not exclusivity: possession is not verification, verification is not acceptance, several credentials may substantiate one condition, and one credential may substantiate several."""@en . ifm:substantiatedBy a owl:ObjectProperty ; rdfs:label "substantiated by"@en ; rdfs:domain ifm:Condition ; rdfs:range ifm:CredentialType ; owl:inverseOf ifm:substantiates ; rdfs:comment """Which credential types are acceptable evidence for this condition. Several is the normal case, and the reason a new credential can enter the ecosystem without any use case changing."""@en . ifm:credentialFormat a owl:DatatypeProperty ; rdfs:label "credential format"@en ; rdfs:domain ifm:CredentialType ; rdfs:comment "The wire format or representation: SD-JWT VC, W3C VCDM. A version only where the ecosystem states one."@en . ifm:semanticModel a owl:DatatypeProperty ; rdfs:label "semantic model"@en ; rdfs:domain ifm:CredentialType ; rdfs:comment "The schema family that gives the claims their meaning. Distinct from the wire format and from the trust framework."@en . ifm:trustFramework a owl:DatatypeProperty ; rdfs:label "trust framework"@en ; rdfs:domain ifm:CredentialType ; rdfs:comment "The governance framework under which issuers are authorised. Omitted where none has been chosen."@en . ifm:protocolProfile a owl:DatatypeProperty ; rdfs:label "protocol profile"@en ; rdfs:domain ifm:CredentialType ; rdfs:comment "The issuance and presentation profile the credential is exchanged under, where an ecosystem names one."@en . ifm:TrustRole a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Trust role"@en ; rdfs:comment """The role a party plays in a credential exchange: issuer, holder, verifier, relying party or trust anchor. Verifier and relying party are distinct roles that frequently belong to the same organisation; where one organisation plays several roles in one flow, each is its own participation."""@en . ifm:Participation a owl:Class ; rdfs:label "Participation"@en ; rdfs:comment """One party playing one role in one flow. A property of the implementation, not of the canonical use case: who does the work, at whose cost, is exactly what differs between two implementations of one pattern. Reified so it can carry who pays, who benefits and which credentials that party handles. A flow may hold several participations with the same trust role, so a participation is identified within its flow rather than by its role."""@en . ifm:participation a owl:ObjectProperty ; rdfs:label "participation"@en ; rdfs:domain ifm:Flow ; rdfs:range ifm:Participation . ifm:inFlow a owl:ObjectProperty ; rdfs:label "in flow"@en ; owl:inverseOf ifm:participation . ifm:trustRole a owl:ObjectProperty ; rdfs:label "trust role"@en ; rdfs:domain ifm:Participation ; rdfs:range ifm:TrustRole . ifm:party a owl:DatatypeProperty ; rdfs:label "party"@en ; rdfs:domain ifm:Participation ; rdfs:comment "The kind of organisation or person playing the role, not a named one."@en . ifm:issuesCredential a owl:ObjectProperty ; rdfs:label "issues credential"@en ; rdfs:domain ifm:Participation ; rdfs:range ifm:CredentialType ; rdfs:comment "Recorded only on a participation whose trust role is issuer."@en . ifm:holdsCredential a owl:ObjectProperty ; rdfs:label "holds credential"@en ; rdfs:domain ifm:Participation ; rdfs:range ifm:CredentialType ; rdfs:comment "Recorded only on a holder participation, and only in the flow where possession begins."@en . ifm:presentsCredential a owl:ObjectProperty ; rdfs:label "presents credential"@en ; rdfs:domain ifm:Participation ; rdfs:range ifm:CredentialType ; rdfs:comment "Recorded only on a participation whose trust role is holder."@en . ifm:verifiesCredential a owl:ObjectProperty ; rdfs:label "verifies credential"@en ; rdfs:domain ifm:Participation ; rdfs:range ifm:CredentialType ; rdfs:comment "Recorded only on a participation whose trust role is verifier."@en . ################################################################ # Decision-support metadata # # Useful for prioritising work. Deliberately secondary: none of it takes part # in classification or in composition, and nothing below should be read as # having the standing of the interface model above. ################################################################ ifm:ValueDriver a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Value driver"@en ; rdfs:comment "What applying a verifiable credential to a use case reduces, removes or makes possible. An IFM editorial vocabulary."@en . ifm:valueDriver a owl:ObjectProperty ; rdfs:label "value driver"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:ValueDriver . ifm:TransformationMode a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Transformation mode"@en ; rdfs:comment "How far the process is reorganised. Exactly one per pattern. An IFM editorial classification, not an external standard."@en . ifm:transformationMode a owl:ObjectProperty ; rdfs:label "transformation mode"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:TransformationMode . ifm:ChangeMode a owl:Class ; rdfs:label "Change mode"@en ; rdfs:comment "An IFM editorial two-way split over the transformation modes. Derived, never typed in."@en . ifm:Run a ifm:ChangeMode ; rdfs:label "Run"@en . ifm:Change a ifm:ChangeMode ; rdfs:label "Change"@en . ifm:changeMode a owl:ObjectProperty ; rdfs:label "change mode"@en ; rdfs:range ifm:ChangeMode ; rdfs:comment "Run or change. Derived from the transformation mode, never typed in."@en . ifm:bearsCost a owl:DatatypeProperty ; rdfs:label "bears cost"@en ; rdfs:domain ifm:Participation ; rdfs:range xsd:boolean ; rdfs:comment "Whether this party carries material cost to make the flow work, as a yes or no. No magnitude, no time profile."@en . ifm:gainsValue a owl:DatatypeProperty ; rdfs:label "gains value"@en ; rdfs:domain ifm:Participation ; rdfs:comment "direct, indirect or none. An editorial judgement."@en . ifm:costValueAsymmetry a owl:DatatypeProperty ; rdfs:label "cost/value asymmetry"@en ; rdfs:domain ifm:Flow ; rdfs:range xsd:boolean ; rdfs:comment """True when at least one participation in the flow records bearing cost without direct value. An editorial heuristic for locating where funding or coordination may be needed, not an economic result: it aggregates two yes/no judgements, weighs nothing, and supports no inference about whether an implementation will be adopted."""@en . ifm:PriorEvidenceMechanism a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "Prior evidence mechanism"@en ; rdfs:comment "How the same assurance is obtained today without a verifiable credential. A description of the current mechanism, not a judgement on it."@en . ifm:reducesRelianceOn a owl:ObjectProperty ; rdfs:label "reduces reliance on"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:PriorEvidenceMechanism ; rdfs:comment """The use case reduces how far the parties must lean on this mechanism for the same assurance. It does not assert that the mechanism leaves the architecture: a register queried less often is still a register."""@en . ifm:Maturity a owl:Class ; rdfs:label "Maturity"@en ; rdfs:comment "How far a real implementation has been worked out. A property of a flow, not of a canonical pattern."@en . ifm:Exploratory a ifm:Maturity ; rdfs:label "Exploratory"@en ; rdfs:comment "Identified and scoped; no worked flow is linked."@en . ifm:Modelled a ifm:Maturity ; rdfs:label "Modelled"@en ; rdfs:comment "A worked flow or equivalent detailed specification is linked through ifm:documentedBy."@en . ifm:Live a ifm:Maturity ; rdfs:label "Live"@en ; rdfs:comment "Documented as operational in at least one production deployment, with evidence linked through ifm:deploymentEvidence."@en . ifm:maturity a owl:ObjectProperty ; rdfs:label "maturity"@en ; rdfs:domain ifm:Flow ; rdfs:range ifm:Maturity . ifm:documentedBy a owl:ObjectProperty ; rdfs:label "documented by"@en ; rdfs:domain ifm:Flow ; rdfs:comment "The worked flow or detailed specification for this implementation, wherever it is published."@en . ifm:deploymentEvidence a owl:ObjectProperty ; rdfs:label "deployment evidence"@en ; rdfs:domain ifm:Flow ; rdfs:comment "Evidence that the implementation is operational in production. Required for ifm:Live."@en . ################################################################ # Derived classification scope ################################################################ ifm:Scope a owl:Class ; rdfs:label "Classification scope"@en ; rdfs:comment """How widely a use case reaches across one level of the sector classification. Derived at each of the three ISIC levels separately, because they answer different questions and a single binary conflates them: banking and insurance are different industries inside one ISIC section."""@en . ifm:CrossSection a ifm:Scope ; rdfs:label "Cross-section"@en . ifm:SingleSection a ifm:Scope ; rdfs:label "Single-section"@en . ifm:CrossDivision a ifm:Scope ; rdfs:label "Cross-division"@en . ifm:SingleDivision a ifm:Scope ; rdfs:label "Single-division"@en . ifm:CrossClass a ifm:Scope ; rdfs:label "Cross-class"@en . ifm:SingleClass a ifm:Scope ; rdfs:label "Single-class"@en . ifm:sectionScope a owl:ObjectProperty ; rdfs:label "section scope"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:Scope ; rdfs:comment "A statement about the classification, not about industries in ordinary usage."@en . ifm:divisionScope a owl:ObjectProperty ; rdfs:label "division scope"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:Scope . ifm:classScope a owl:ObjectProperty ; rdfs:label "class scope"@en ; rdfs:domain ifm:UseCasePattern ; rdfs:range ifm:Scope . ################################################################ # Provenance of the taxonomy data itself ################################################################ ifm:codeStatus a owl:DatatypeProperty ; rdfs:label "code status"@en ; rdfs:range xsd:string ; rdfs:comment """How far the notation and label of a concept have been checked against the official publication of the source classification: "verified" or "provisional". It describes the concept alone; the confidence of a mapping onto it is carried separately by ifm:mappingStatus."""@en . ifm:mappingStatus a owl:DatatypeProperty ; rdfs:label "mapping status"@en ; rdfs:range xsd:string ; rdfs:comment """How a SKOS mapping onto an external concept was arrived at: "editorial" or "verified". Independent of the external concept's own ifm:codeStatus."""@en . ifm:schemeVersion a owl:DatatypeProperty ; rdfs:label "scheme version"@en ; rdfs:range xsd:string ; rdfs:comment "The edition of an external classification the concepts here follow, where one is known."@en .