Took a quick look, three things I'd do first:
- Use Synapse IDs directly in the instance IRIs. Rather than minting a parallel w3id identifier (
.../cckp-portal/data/Dataset/syn77073588), point at the canonical one: <https://www.synapse.org/Synapse:syn77073588> a cckp:Dataset. These entities already have stable identity in Synapse and a second identifier just means two things to keep in sync.
- Dual-type with Biolink so we can query everything more easily.
<instance_uri> a cckp:Dataset, biolink:Dataset. Once Neptune supports reasoning we can drop the additional materialization and just have a subclass axiom.
- Emit
manifest.ttl as part of the build; it doesn't need much, just have a prov statement about the graph build. Tom's auto-loader uses that file as its trigger.
Took a quick look, three things I'd do first:
.../cckp-portal/data/Dataset/syn77073588), point at the canonical one:<https://www.synapse.org/Synapse:syn77073588> a cckp:Dataset. These entities already have stable identity in Synapse and a second identifier just means two things to keep in sync.<instance_uri> a cckp:Dataset, biolink:Dataset. Once Neptune supports reasoning we can drop the additional materialization and just have a subclass axiom.manifest.ttlas part of the build; it doesn't need much, just have aprovstatement about the graph build. Tom's auto-loader uses that file as its trigger.