Summary
Our local SynBioHub 3 instance stores public data in the Virtuoso triplestore under two different named graphs that differ only by URI scheme:
https://synbiohub.org/public — 5.24M triples, ~50,891 ComponentDefinitions
http://synbiohub.org/public — 3.31M triples, ~40,273 ComponentDefinitions
The application is configured with databasePrefix = https://synbiohub.org/ and defaultGraph = https://synbiohub.org/public. As a result, all search queries only ever reference the https:// graph, and everything stored under the http:// graph is effectively invisible to search.
Why the data is (mostly) unreachable
When a user searches, the backend sends the SPARQL query to Virtuoso with default-graph-uri = https://synbiohub.org/public (and, for logged-in users, FROM https://synbiohub.org/public FROM https://synbiohub.org/user/...). The http://synbiohub.org/public graph is never named in any query, so its contents are excluded — regardless of whether SBOLExplorer is enabled or not. This is a data/namespace-configuration problem at the triplestore level, not a search-engine bug.
How much is affected / is it just duplicate data?
I compared the two graphs by taking each http:// subject, swapping the scheme to https://, and checking whether that "twin" exists in the https:// graph:
~31,813 (79%) of the http:// ComponentDefinitions also exist in the https:// graph → these are redundant legacy copies.
~8,460 (21%) exist only under http:// → these are genuinely orphaned; they are not in the https:// graph and are currently unreachable by any search.
So the http:// graph is partly a redundant duplicate of the https:// data and partly unique data that would be lost if the graph were simply dropped.
Likely root cause
The http://synbiohub.org/public graph appears to be legacy data imported under an older URI namespace (SynBioHub historically used http://, and the instance later moved to https://). A namespace/prefix change (or a data migration/restore) left two parallel public graphs instead of migrating the old one into the new namespace. New submissions (e.g. my own user graph) correctly use https://, which is why recent data is searchable but the older http:// data is not.
Secondary, related issue (separate from the above)
When SBOLExplorer is enabled, its Elasticsearch index stores a graph field per part and filters search hits by exact-matching that field against the requested graph URI. The index shows the same split (109,651 docs under https://…/public vs 85,018 under http://…/public), so it reproduces the same mismatch. Additionally, the index was last fully rebuilt on 2026-06-30, so parts submitted after that (including private user data) are missing until an incremental re-index runs (GitHub issue #159). This is a distinct problem from the namespace split, but both must be resolved for search to be complete.
Question
Should we migrate the http://synbiohub.org/public graph into https://synbiohub.org/public (rewriting both the graph URI and all subject URIs from http:// to https://, letting the ~31.8k duplicates merge and preserving the ~8.5k unique parts), then rebuild the SBOLExplorer index? Or is there a reason the older http:// namespace was kept separate that we should account for before migrating?
Summary
Our local SynBioHub 3 instance stores public data in the Virtuoso triplestore under two different named graphs that differ only by URI scheme:
https://synbiohub.org/public — 5.24M triples, ~50,891 ComponentDefinitions
http://synbiohub.org/public — 3.31M triples, ~40,273 ComponentDefinitions
The application is configured with databasePrefix = https://synbiohub.org/ and defaultGraph = https://synbiohub.org/public. As a result, all search queries only ever reference the https:// graph, and everything stored under the http:// graph is effectively invisible to search.
Why the data is (mostly) unreachable
When a user searches, the backend sends the SPARQL query to Virtuoso with default-graph-uri = https://synbiohub.org/public (and, for logged-in users, FROM https://synbiohub.org/public FROM https://synbiohub.org/user/...). The http://synbiohub.org/public graph is never named in any query, so its contents are excluded — regardless of whether SBOLExplorer is enabled or not. This is a data/namespace-configuration problem at the triplestore level, not a search-engine bug.
How much is affected / is it just duplicate data?
I compared the two graphs by taking each http:// subject, swapping the scheme to https://, and checking whether that "twin" exists in the https:// graph:
~31,813 (79%) of the http:// ComponentDefinitions also exist in the https:// graph → these are redundant legacy copies.
~8,460 (21%) exist only under http:// → these are genuinely orphaned; they are not in the https:// graph and are currently unreachable by any search.
So the http:// graph is partly a redundant duplicate of the https:// data and partly unique data that would be lost if the graph were simply dropped.
Likely root cause
The http://synbiohub.org/public graph appears to be legacy data imported under an older URI namespace (SynBioHub historically used http://, and the instance later moved to https://). A namespace/prefix change (or a data migration/restore) left two parallel public graphs instead of migrating the old one into the new namespace. New submissions (e.g. my own user graph) correctly use https://, which is why recent data is searchable but the older http:// data is not.
Secondary, related issue (separate from the above)
When SBOLExplorer is enabled, its Elasticsearch index stores a graph field per part and filters search hits by exact-matching that field against the requested graph URI. The index shows the same split (109,651 docs under https://…/public vs 85,018 under http://…/public), so it reproduces the same mismatch. Additionally, the index was last fully rebuilt on 2026-06-30, so parts submitted after that (including private user data) are missing until an incremental re-index runs (GitHub issue #159). This is a distinct problem from the namespace split, but both must be resolved for search to be complete.
Question
Should we migrate the http://synbiohub.org/public graph into https://synbiohub.org/public (rewriting both the graph URI and all subject URIs from http:// to https://, letting the ~31.8k duplicates merge and preserving the ~8.5k unique parts), then rebuild the SBOLExplorer index? Or is there a reason the older http:// namespace was kept separate that we should account for before migrating?