SPARQL integration and semantic query results linked to IFC elements

[unifiBIM]

I would like to discuss the possibility of adding an optional SPARQL integration to IFClite.

The motivation is to support workflows where an IFC model is connected to external RDF/knowledge-graph data, such as documents, sensors, inspections, maintenance information, cultural-heritage information, or other domain-specific semantic data.

The proposed feature would not replace IFClite's existing IFC query capabilities. Instead, it would provide an additional semantic-query layer that can connect the viewer to an external SPARQL endpoint.

Proposed workflow

IFC model
    │
    ▼
 IFClite viewer
    │
    ├───────────────┐
    │               │
    ▼               ▼
IFC query       SPARQL query
                    │
                    ▼
             SPARQL endpoint
                    │
                    ▼
              query results
                    │
                    ▼
             IFC entity mapping
                    │
                    ▼
           existing selection /
              highlighting

Proposed UI

A new optional panel could contain:

• SPARQL endpoint configuration
• SPARQL query editor
• Run query button
• query results table
• selection/highlighting controls

For example:

┌──────────────────────────────────────────────┐
│ SPARQL endpoint                              │
│ https://example.org/sparql                   │
│                                              │
│ SELECT ?element ?label                       │
│ WHERE {                                      │
│   ?element ex:ifcGlobalId ?id ;              │
│            rdfs:label ?label .               │
│ }                                            │
│                                              │
│ [ Run query ]                                │
├──────────────────────────────────────────────┤
│ Results                                      │
│                                              │
│ Element       Label                          │
│ 3hK2...       Wall A                         │
│ 8Hd7...       Wall B                         │
│ 91Ks...       Wall C                         │
└──────────────────────────────────────────────┘

Selecting a result should resolve the semantic resource to the corresponding IFC entity and use the existing IFClite selection/highlighting mechanism to highlight it in the 3D scene.

IFC ↔ RDF mapping

I think the important architectural point is to keep the SPARQL layer independent from the IFC parser.

Rather than making SPARQL a dependency of the IFC data model, an abstraction such as a semantic entity resolver could map RDF resources or identifiers to IFC entities:

interface SemanticEntityResolver {
    resolve(
        semanticIdentifier: string
    ): Promise<IfcEntityReference | null>;
}

where an IfcEntityReference could contain the model identifier and IFC expressId.

The first implementation could support IFC GlobalId-based mappings, while leaving room for other identifier/mapping strategies.

Bidirectional interaction

A useful long-term workflow would be both:

SPARQL → IFC

SPARQL query
     ↓
results
     ↓
IFC identifiers
     ↓
3D selection/highlighting

and:

IFC → SPARQL

select IFC element
     ↓
resolve semantic identifier
     ↓
query related RDF resources
     ↓
display semantic information

This could make IFClite useful as a lightweight interface between IFC models and external knowledge graphs.

Reuse of existing functionality

I would prefer to reuse the existing IFClite query, selection and highlighting mechanisms rather than introducing a separate highlighting implementation.

In particular, SPARQL results could ultimately be converted into the same type of entity selection used by the viewer.

Scope

A possible first version could be deliberately small:

1. configurable SPARQL endpoint;
2. SPARQL SELECT query execution;
3. SPARQL JSON result rendering;
4. configurable mapping from SPARQL result bindings to IFC GlobalIds;
5. selection/highlighting of the corresponding IFC entities.

More advanced functionality such as CONSTRUCT queries, RDF graph editing, ontology management, federated queries, authentication mechanisms, or automatic IFC/RDF mappings could remain outside the initial implementation.

[louistrue]

I’ve opened a full implementation charter here: #6643.

The charter keeps the generic SPARQL layer independent of IFC parsing and makes DBL/DPP profiles optional. Arbitrary SELECT results must work without requiring a particular ontology or an id/type/label record shape. Mapping and selection reuse IFClite’s existing model-scoped mechanisms.

It defines six delivery milestones:

1. Review and promote the tested pilot baseline.
2. Establish a reusable semantic core, providers, RDF-term fidelity and arbitrary SELECT results.
3. Complete bidirectional IFC ↔ semantic interaction, persistent workspaces and revision-aware mappings.
4. Add bounded graph retrieval, extensible profiles, generated Schema/JSON-LD/RDFS/SHACL, and dictionary/bSDD adapters.
5. Generalize explicit IFC property projections with provenance, conflict handling and grouped undo/redo.
6. Deliver authenticated provider modes, shared-core headless integration, documented resource budgets and release evidence.

A local pilot already demonstrates JSON/SPARQL loading, two IFC revisions with reused GlobalIds, shared batch and item passports, retained inspection/replacement links, validation findings, and an undoable FireRating projection that survives IFC export/reimport. Its 10 integration tests pass, including actual SPARQL execution, mounted panel interaction and real WASM geometry; 302 SDK tests also passed, with 6 skips.

The pilot has not yet been pushed, merged or released. The charter requires a full browser demonstration, a real authoring-tool IFC fixture, independent validation, and final integrated CI evidence before completion. It also makes partial-query validation scope and ambiguous mappings explicit, preserves relationships that cannot be represented in IFC, and does not require OWL or claim standards conformity for the demonstration profile.

The issue contains the detailed scope, phase acceptance criteria and stopping condition so this can progress through reviewable implementation PRs.

[louistrue]

The complete charter #6643 implementation is in delivery PR #6645. Five upper component PRs (#6648, #6649, #6650, #6651, #6652) were reviewed and consolidated normally into the delivery branch; delivery PR #6645 is now merged to main as 09745f0f3bb99ac07802ae061f13df92e865683f. The maintainer authorized submitter self-review and discretionary admin merge while reviewers are out of quota. No independent approval is claimed, and all required source gates passed and the final audit found no unresolved review feedback.

The viewer and headless CLI share one semantic core. Generic SELECT/CONSTRUCT and Turtle/N-Quads/inline JSON-LD preserve RDF terms, arbitrary columns and named graphs. A technology-neutral optional profile generates JSON Schema, JSON-LD context, RDFS, a bounded SHACL Core subset and neutral dictionary assets from one definition. OWL is not required. bSDD definition import is separate from manufacturer instance values. External building/logbook/passport/inspection relationships remain in the semantic graph and portable workspace while IFC receives only explicitly previewed mapped values and provenance. Resource identifiers remain distinct from revision-scoped IFC identity; a DID-shaped identifier does not establish resolution or trust.

Implemented workflows include both query/selection directions, candidate review, explicit revision association, credential-safe workspace restore, worker validation, authenticated direct/relay HTTPS, typed Door/Wall projections, unit conversion, conflict handling and grouped Undo/Redo. Real public ArchiCAD model runs, actual HTTPS/SPARQL operations, independent JSON Schema/pySHACL checks, and behavioral regressions support the acceptance evidence: #6643 (comment).

Final self-review and all eleven freshly posted consolidated-review threads are addressed, with regressions for room reconstruction/export integrity, atomic local validation, stale metadata, linear RDF projection and portable Unicode validation. Current head 7eb9157 has passed root typecheck/lint, semantic 70/70, CLI 1,242 passed/15 explicit skips, and six focused viewer test files including the non-skipped public authoring-tool fixture. Final source CI passed 22 jobs with six expected path skips: https://github.com/LTplus-AG/ifc-lite/actions/runs/36984815053. Source review evidence: #6643 (comment).

The implementation uses original example.org reference data and identified public IFC models. It makes no EN/ISO conformity certification claim and publishes no confidential working-group material.

Post-merge main Test passed: https://github.com/LTplus-AG/ifc-lite/actions/runs/36987094090. CI-only draft #6654 was closed without merging.

Release-verification follow-up #6682 merged as ea2bfce4750aa42dbd0454a9f2691cc14762375d after the maintainer-requested 30-minute merge hold and successful queue validation for #6670/#6671. Its corrected source CI passed 21 applicable jobs/seven expected skips: https://github.com/LTplus-AG/ifc-lite/actions/runs/36990537459. All four required contexts passed, final feedback audit found zero review threads, and 52 release behavioral tests passed. Default/fail-open detection and real publication verification remain intact; only proven introductions with pending changesets are deferred. Post-merge Test passed all 19 applicable jobs, including all eight viewer shards, with zero failures: https://github.com/LTplus-AG/ifc-lite/actions/runs/36994802184. Post-merge Release passed: https://github.com/LTplus-AG/ifc-lite/actions/runs/36994802299. Server Binaries and the revert-oracle selfcheck also passed. The merged tree 4f7caf61999699b3ccdf40e128d51feefcb0ee2f exactly matches the precomputed combination with main 605bdcb146c8df166044aeeb85e241c03d11f41a. Charter #6643 is closed. No npm publication or production-viewer deployment is claimed. Documentation deployment for the semantic delivery passed.

[louistrue]

here we go: #6643

[louistrue]

thx for the nudge @unifiBIM

[unifiBIM]

I tested the current semantic/Linked Records implementation with RDF generated by the latest IFC2LBD-Neo converter ( https://ifc2lbd-neo.pages.dev/ ), and I found a related identity-mapping use case that may be worth considering.

In the generated RDF, the IFC GlobalId is encoded directly in the resource URI:

<https://lbd.org/1SkQ09Gbf4fA3lKJzuqwyp> a bot:Space .
<https://lbd.org/0kMnQ1zpDATPDS5PHxCZAM> a bot:Storey .

Here, 1SkQ09Gbf4fA3lKJzuqwyp is the IFC GlobalId. There is no separate GlobalId property or SPARQL binding.

This means that a query such as:

SELECT ?resource ?type
WHERE {
  ?resource a ?type .
}

already returns the complete identifier needed to map the RDF resource to the IFC entity:

?resource
https://lbd.org/1SkQ09Gbf4fA3lKJzuqwyp
                    └───────────────┘
                         GlobalId

Would it make sense to support an additional identity mapping strategy such as:

Resource URI → IFC GlobalId

with a configurable URI pattern, for example:

https://lbd.org/{GlobalId}

or simply extraction of the last URI path segment?

This would allow existing RDF/Linked Building Data datasets to be consumed directly, without having to materialize an additional GlobalId property only for IFClite.

I think this is particularly relevant for the current generic SPARQL implementation, because the RDF resource URI is often the primary identifier of an entity.

A second related use case is local development. It would be useful to allow explicitly authorized loopback SPARQL endpoints such as:

http://localhost:7200/repositories/my-repository
http://127.0.0.1:8890/sparql

while retaining the HTTPS requirement for remote endpoints.

In other words:

Remote endpoint       → HTTPS
localhost/127.0.0.1  → HTTP allowed with explicit local grant

The goal would be to make IFClite usable directly with local GraphDB/Virtuoso/RDF stores and with RDF datasets whose IFC identity is encoded in the resource URI.

I think this could fit naturally as an additional mapping strategy rather than changing the existing GlobalId-field mapping.

[louistrue]

Both follow-ups are implemented and merged on main:

• IFC GlobalId in resource URIs: feat(semantic): map URI-encoded IFC GlobalIds (#6783) #6785. Select Resource URI contains IFC GlobalId, choose Full URI template, and apply https://lbd.org/{GlobalId} (or your dataset's equivalent). Map the resource binding to resource; no separate GlobalId column/property is required. Explicit last-path-segment matching is also available. Percent-encoded GlobalIds are supported while preserving the original RDF URI; model/revision ambiguity still requires explicit resolution.
• Local HTTP SPARQL endpoints: feat(semantic): explicitly authorize local HTTP endpoints #6786. Enter your literal localhost, 127.0.0.1, or [::1] endpoint and exact hostname, then check Allow local HTTP requests to the displayed origin/port. Authorization is session-only and is cleared on source changes or workspace restoration. The CLI provides semantic query --allow-loopback-http alongside the exact --host grant. Remote HTTP remains denied; browser CORS/local-network permissions still apply.

Verified together with an actual local HTTP endpoint running Oxigraph SPARQL: URI-only results selected the matching door in a real ArchiCAD IFC model. All 113 viewer semantic tests passed without skips, full PR and post-merge Test workflows passed, and all raised review feedback was resolved.

Usage: viewer guide and headless guide. These changes are merged; package publication and the production viewer deployment follow the normal release schedule.

[unifiBIM]

I tested the new SPARQL and bSDD-related functionality on my local instance of IFClite, and I have a couple of observations that may be useful for further UI improvements.

SPARQL result binding

The basic IFC entity mapping works correctly when the SPARQL result uses ?id as the binding:

SELECT ?id
WHERE {
    ?id a beo:Window .
}
LIMIT 10

The returned RDF resources are correctly mapped to the corresponding IFC entities, and clicking a result in the table also selects the corresponding entity in the IFC viewer.

For the basic use case, I think id should therefore be the only required/default result binding. The other bindings currently shown in the UI (type, label, GlobalID, modelRevision) seem more advanced and are not necessary for a simple RDF → IFC entity mapping.

Perhaps these could be optional fields or moved into an "Advanced" section, leaving the basic workflow as simple as:

SPARQL query → ?id → IFC entity selection

Similarly, "Associate revision with model" seems useful for more advanced multi-model/revision scenarios, but probably not necessary for the basic single-model use case.

Multiple selection from SPARQL results

Another feature that I think would be very useful is allowing multiple rows in the SPARQL result table to be selected at once.

For example:

SELECT ?id ?label
WHERE {
    ?id a beo:Window ;
        rdfs:label ?label .
}

The user could then select several rows (e.g. with checkboxes or Ctrl/Cmd selection) and have all corresponding IFC entities selected/highlighted in the viewer.

It could also be useful to have:

• Select all results
• Clear selection
• Possibly invert selection

This would make the SPARQL interface much more useful as a semantic selection tool, rather than only as a query/result viewer.

bSDD / Profile and Dictionary

I also tested the "Profile and Dictionary" functionality.

When entering the bSDD dictionary URI:

https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3

IFClite sends a request to:

https://api.bsdd.buildingsmart.org/api/Class/Search/v1?SearchText=...

I also tried simply:

IfcWindow

which produces the same type of request:

https://api.bsdd.buildingsmart.org/api/Class/Search/v1?SearchText=IfcWindow

In both cases Firefox reports:

Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at
https://api.bsdd.buildingsmart.org/api/Class/Search/v1?SearchText=...
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Status code: 200.

So the bSDD API appears to respond successfully with HTTP 200, but the browser prevents the IFClite frontend from reading the response because the required CORS header is missing.

This seems to be a browser/API CORS issue rather than an incorrect value entered in the IFClite UI.

It may therefore be worth considering one of the following approaches:

1. bSDD API enabling the appropriate CORS headers;
2. a small server-side proxy in IFClite for bSDD requests;
3. or another mechanism that avoids requiring the browser to directly perform the cross-origin request.

I think the bSDD integration is potentially very useful, especially for connecting IFC semantics with bSDD definitions, but the current browser CORS restriction prevents me from testing the functionality further in the normal frontend environment.

Overall, the new SPARQL functionality is already working very well for the basic RDF → IFC mapping. My main suggestion would be to simplify the basic UI around ?id and make the additional bindings/revision mapping advanced options, while adding multi-selection of IFC entities from the query result table.