Copied from Slack
Adam Graefe [4:28 PM]
Hello everyone, we want to work towards a generalisable local LLM pipeline based on ontogpt and a local hpo-embedding space to extract HPO terms from structured discharge letters that contain real patient data (therefore everything must be run locally). The background is that we have servers running wiht 8 GPUS that have access to hundreds of thousands of discharge letters in both Cologne and Berlin. I was wondering whether anyone has some ideas on how to generate the linkml template schemas for the different kind of discharge letters? Would it be feasable to use linkml-schema automator, eventually combined with some kind of LLM/agentic approach? Does anyone work on this already or something similar? We would like to modularise and generalise the entire existing pipeline and I assume there could be useful things to use from the linkml packages and/or community. Happy to hear any feedback! Thank you! (edited)
noelmcloughlin [5:21 PM]
I have been doing some conversions. I used schema automator in the past but found it lossy, so I now generally use LLM to create conversion scripts, rdf-to-linkml.py, ttl-to-linkml.py (which in theory could be generic converters, contributed back, or merged into schema automater - but I had no time), and other domain/project specific scripts 'xxx-to-linkml.py' (not worth contributing back).
These scripts usually work off local copy in ./upstream-sources/xxx/ which can be refreshed manually.
This works for me but creates new common requirements, namely 'how can i repeatedly replay semantics?' .. overlays for semantics i added since last refresh.
For mappings, my convention is to store these under /src/my-awesome-schema/mappings/*.sssom.tsv and replay using overlay-sssom.py script which definitely could be reusable.
But i had another use case where i wanted to overlay 'normatative text' (licensed, non-distributable text from say ISO) so was thinking this could be common requirement.
Finally, I felt some of these patterns (examples + scripts) should be part of linkml-project-copier.
Adam Graefe [3:11 PM]
Hi @noelmcloughlin, thank you for your thorough reply and sorry for getting back late. The "replay semantics" framing is exactly our wall: we've got hand-curated prompt/schema refinements on a base template, and generalising across letter types keeps breaking on how to preserve that curation when the base regenerates. Base + replayable overlays makes it tractable.
One check: our base artifacts are SPIRES extraction templates (prompt-bearing LinkML for OntoGPT), not RDF/TTL→LinkML conversions; so is it your converters that transfer, or mainly the overlay + SSSOM layer? The SSSOM bit especially: currently we hardcoded verified synonym mappings into a postprocess script, and *.sssom.tsv + overlay-sssom.py looks much cleaner. Would you share it? And since generalizing this is our goal anyway, happy to help turn it into something reusable if you've had no time. (edited)
Copied from Slack
Adam Graefe [4:28 PM]
Hello everyone, we want to work towards a generalisable local LLM pipeline based on ontogpt and a local hpo-embedding space to extract HPO terms from structured discharge letters that contain real patient data (therefore everything must be run locally). The background is that we have servers running wiht 8 GPUS that have access to hundreds of thousands of discharge letters in both Cologne and Berlin. I was wondering whether anyone has some ideas on how to generate the linkml template schemas for the different kind of discharge letters? Would it be feasable to use linkml-schema automator, eventually combined with some kind of LLM/agentic approach? Does anyone work on this already or something similar? We would like to modularise and generalise the entire existing pipeline and I assume there could be useful things to use from the linkml packages and/or community. Happy to hear any feedback! Thank you! (edited)
noelmcloughlin [5:21 PM]
I have been doing some conversions. I used schema automator in the past but found it lossy, so I now generally use LLM to create conversion scripts, rdf-to-linkml.py, ttl-to-linkml.py (which in theory could be generic converters, contributed back, or merged into schema automater - but I had no time), and other domain/project specific scripts 'xxx-to-linkml.py' (not worth contributing back).
These scripts usually work off local copy in ./upstream-sources/xxx/ which can be refreshed manually.
This works for me but creates new common requirements, namely 'how can i repeatedly replay semantics?' .. overlays for semantics i added since last refresh.
For mappings, my convention is to store these under /src/my-awesome-schema/mappings/*.sssom.tsv and replay using overlay-sssom.py script which definitely could be reusable.
But i had another use case where i wanted to overlay 'normatative text' (licensed, non-distributable text from say ISO) so was thinking this could be common requirement.
Finally, I felt some of these patterns (examples + scripts) should be part of linkml-project-copier.
Adam Graefe [3:11 PM]
Hi @noelmcloughlin, thank you for your thorough reply and sorry for getting back late. The "replay semantics" framing is exactly our wall: we've got hand-curated prompt/schema refinements on a base template, and generalising across letter types keeps breaking on how to preserve that curation when the base regenerates. Base + replayable overlays makes it tractable.
One check: our base artifacts are SPIRES extraction templates (prompt-bearing LinkML for OntoGPT), not RDF/TTL→LinkML conversions; so is it your converters that transfer, or mainly the overlay + SSSOM layer? The SSSOM bit especially: currently we hardcoded verified synonym mappings into a postprocess script, and *.sssom.tsv + overlay-sssom.py looks much cleaner. Would you share it? And since generalizing this is our goal anyway, happy to help turn it into something reusable if you've had no time. (edited)