Semantic profiles and dictionaries

The linked-records feature uses a versioned, technology-neutral ProfileDefinition as the source of its JSON Schema Draft 7, inline JSON-LD context, RDFS vocabulary, SHACL Core shapes and neutral dictionary. The reference DBL/DPP profile uses original demonstration terms under example.org; it does not claim compliance with unpublished CEN drafts.

Profile definitions

A definition contains an absolute id, a version, a vocabulary, named fields, and named resource types. Each field supplies a stable semantic iri and a kind: string, number, integer, boolean, iri or language. Type definitions list the fields they permit and each field's minCount and maxCount; omitted counts mean zero and one. Fields with maximum counts above one use JSON arrays. Resource id, type and label remain the common exchange envelope contract. Each type must explicitly require exactly one string label, keeping JSON and SHACL cardinalities equivalent. Unknown definition members are rejected instead of silently becoming exported configuration or ignored constraints.

Patterns permit at most one variable repetition (?, +, * or a bounded range); groups and backreferences are unsupported. Shorthand character classes (\d, \D, \w, \W, \s, \S) and property classes (\p, \P) are rejected, including inside character classes, because their alphabets differ between XPath/SPARQL and JavaScript. Use explicit ranges such as [0-9]; escaped literal backslashes remain supported. This bounded subset does not implement the full XPath regular-expression language. Fixed repetitions remain supported within the configured bounds. Multiple variable repetitions are rejected before JSON Schema or SHACL executes them, including patterns without groups. Profile field/type references must name declared members, and reserved JavaScript prototype names cannot define types.

Fields can supply multilingual labels, allowed-value enum, bounded pattern, inclusive minimum/maximum, a descriptive unit, and an IRI relation's targetType. external: true identifies references whose target need not appear in this submission. language values use JSON language maps such as {"en":"Door","de":"Tür"}; generated JSON-LD retains the language tags and SHACL checks one value per language. Raw RDF datasets independently preserve typed literals, repeated properties and blank nodes.

The narrow JSON profile's integer values, ranges and enumerations must remain within JavaScript's exact safe-integer range. Larger integer declarations stay available as lexical typed literals in generic RDF datasets; they are rejected by the numeric profile projection instead of producing an invalid or rounded RDF integer.

JSON Schema closes each resource to its declared fields. Structural import rejects unknown keys, unsupported primitive types and duplicate resource identifiers before JSON-LD conversion. Missing required values and semantic constraints appear as findings. Relation validation checks local target types in both complete and partial submissions; absent internal targets are findings only in complete submissions. A partial submission makes no assertion that absent linked records do not exist. Explicit graph validation evaluates the supplied graph under its chosen shapes; missing target classes can therefore yield graph findings even when a partial JSON exchange permits external retrieval.

Profile IDs identify immutable definitions: change the identifier when changing a published profile's constraints. Persist the complete definition alongside a dataset rather than relying on a mutable remote URL. Unit metadata identifies the supplied quantity; declaring a unit does not silently convert or infer values.

Generated artifacts and validation limits

String values, IRI field values and each multilingual label are limited to 65,536 Unicode codepoints in both JSON Schema and SHACL. The graph validator corrects the installed SHACL library's UTF-16 counting for this trusted built-in constraint; imported shapes cannot supply executable callbacks.

JSON Schema generation uses the constraints supported by the installed Ajv implementation. JSON-LD uses generated inline contexts; the converter rejects remote document/context retrieval. RDFS describes classes and properties, without importing ontologies or performing inference. OWL is not required by this implementation.

Graph validation accepts a bounded SHACL Core subset: direct IRI paths, class and explicit targets, closed shapes, counts, primitive datatypes, node kinds, class checks, enumeration/language lists, unique languages, patterns and inclusive numeric bounds. Nonrecursive property-shape composition remains supported. Local rdfs:subClassOf relationships in the data graph participate in SHACL class membership and class targets. This does not load ontologies or enable OWL inference. Iterative preflights reject cycles, paths over 64 levels and excessive DAG fan-out in both subclass relationships and property-shape references before invoking the validator. Implicit class shapes and subclass definitions in shapes are rejected; declare explicit targets and put local class relationships in the data graph. Custom shapes containing executable SPARQL, JavaScript, recursion, complex paths or other unsupported constraints fail with an actionable error instead of silently skipping them. Cyclic, malformed and oversized RDF lists are rejected.

Each graph and shape input is capped at 5 MiB and 50,000 quads, with at most 1,000 findings per engine and 1,000 serialized report findings. JSON and link validators stop accumulating findings at their budget, preventing large invalid submissions from allocating unbounded reports. Profiles support at most 100 types and 500 fields; exchanges support at most 5,000 resources. Client callers may reduce graph limits using positive integers within these bounds. Validation concerns the selected shapes' explicit focus nodes; a graph with no matching targets is rejected instead of reported as conforming. An explicit sh:targetNode selects its node even when that node has no triples in the supplied graph.

parseGraph accepts Turtle, N-Quads or JSON-LD with inline contexts and normalizes the input to N-Quads. It preserves named graphs, blank nodes, repeated predicates, literal datatypes and language tags. Nested remote contexts and context @import are rejected; no remote context or document is retrieved. Both input and converted output must remain within the configured limits.

createValidationReport supplies a versioned envelope containing the profile identifier and version, profile/graph scope, complete/partial submission mode, engines, limits and findings. Each finding carries its focus resource, path, message and severity. Missing severity defaults to Violation; SHACL warnings and informational findings keep their declared severity. Reports count all supplied findings and bound their serialized findings list, marking a reached limit as potentially truncated. Conformance requires no violation among supplied findings and a findings budget that was not reached; a truncated report cannot claim conformance.

Dictionary and bSDD integration

profileToDictionary and dictionaryToProfile roundtrip the supported neutral representation, including identifiers, labels, kinds, ranges, cardinalities and units. Unsupported relations remain in the returned raw dictionary with diagnostics; they are not projected into IFC relationships. This neutral representation is not the official bSDD upload format.

In the viewer, paste a neutral dictionary into the profile definition input and choose Use neutral dictionary. The active profile receives its supported definitions, and diagnostics identify unsupported relations. The source input remains unchanged; Export source definition unchanged saves the original dictionary including those relations. Export the source before closing the panel if you need to retain it: a generated profile or saved workspace contains the supported profile subset, rather than the original dictionary's unsupported relations.

profileFromBsdd accepts a provider structurally compatible with the existing SDK BsddNamespace.fetchClassByUri. The viewer uses the existing namespace for search and class retrieval, sharing its versioned API implementation and cache. The adapter maps supported String, Real, Number, Integer and Boolean properties, typed enumerations and a single declared unit. Unknown datatypes, conflicting terms, multiple units and parent-class metadata remain in the raw class response with diagnostics; required fields or inheritance are never inferred from missing information.

The adapter follows buildingSMART's official API guidance: use the versioned Class API rather than dereferencing identifier URIs for machine communication. bSDD supplies definitions, not manufacturer instance values, product passports or building identity authorities.

Patterns with variable repetitions require a start anchor and cannot contain alternation. Profile patterns use Unicode codepoint matching in both JSON Schema and SHACL; patterns invalid in Unicode mode are rejected when loading the definition. Generated shapes use standard SHACL regex parameters. The JavaScript validator adapter adds its Unicode flag only to a private runtime copy, keeping exported shapes portable. Imported SHACL pattern flags support i and s; multiline matching is rejected because it can restart a variable repetition at every line.

Imported SHACL count/length parameters must be non-negative safe xsd:integer values, booleans must use valid xsd:boolean terms, and patterns/flags must be xsd:string terms. These scalar parameters allow at most one value per shape. Boolean lexical forms 1 and 0 are normalized to true and false before the engine runs; malformed parameters fail before a conformance result can be produced.