Detlef: Out next week.
https: //github.com/w3c/hcls-fhir-rdf/issues/132
gaurav: Grahame disagrees with the proposed change. Wait and see.
... On vac the next 4 weeks.
... Back 5 wks from now.
erich: Spoke to Lawrence Tarbucks (sp?) who is also in WG20 (DICOM)
... That's the group that is running conjointly w the FHIR imaging group.
... This is a long-standing friendly relationship. He made multiple suggestions for getting DICOM to take this on.
... DICOM likes things done in certain ways. Suggested presenting to WG20, though it might move to another group after.
... i.e., the strategic WG.
... They aren't keen on receiving a complete solution, but want to be involve in the process.
... Get their buy-in sooner.
... Wants me to do something before Nov 11, to speak about it.
... I'll contact the secretary for WG20. Their minutes are not up to date.
dbooth: Sounds like a great development. Suggest preparing only one slide, to start the conversation.
erich: I think my dept is a member. Want to make a good first impression, but very short notice and busy the next few days.
... Want to get a critical mass on it.
dbooth: If not Nov 11, when would be next opportunity?
erich: Prob after the holidays. ALso want to do more recon in advance.
... I know Larry already.
... He's co-chair for WG23, which is AI group
detlef: What would convince them to adopt RDF?
erich: I've been hearing that end users spend a lot of time homogenizing and ETL-ing data before they can use the data. There's an effort for common vocabs. This is a use case for RDF.
... You want to connect the information to clinical info. how? Allow the data to connect.
detlef: If you want to build out a KG you'll need a lot of converters.
... RDF would help that.
... In my case, linking ICD10 codes
erich: Also, when people publish anything, how do you find the value? Look at citations. Want to include the publication data.
... To link it all together, there's so much effort in connecting it.
... In RDF you can bring that data together a lot faster.
detlef: Also, their data is hierarchical, which doesn't fit well with relational.
... And you can link directly from one doc to another.
... RDF is much better choice than JSON, for example.
erich: Gen vast amounts of data from deep learning pipelines. You can try to put that in JSON in MongoDB, but it's tricky to deal with at that scale.
... Want to pull out features at this scale, and search it. That's my argument for geosparql.
... Good like w trying to do this w MongoDB!
... THrowing it all in a triplestore is hard at scale.
... YOu end up with n log n speed problem.
... I split it apart into independently indexed files. But RDF allows me to link it back together quickly.
... Wouldn't try to attempt this w a relational DB.
... I'm implementing it.
... When DICOM added polygon features, but the left out spacial indexing.
... A POC is not enough. Need to handle it at scale.
... This is why DICOM should use RDF: allows all the pieces to be brought together.
https: //github.com/w3c/hcls-fhir-rdf/issues/149
erich: I think geospatial is the way to go.
... There's "grid spacing", but no clear guidance on what the grid is
... Sometimes the x and y spacing differs.
... They're proposing an RDF way to specify a spacing. I want to be sure that x and y spacing can differ.
... E.g. 0.43 microns per pixel.
... Still trying to figure out how to do that.
... Virtuoso is still at geosparql 1.0, and Jena is also.
https: //github.com/w3c/hcls-fhir-rdf/issues/127
dbooth: Discussed w ITS group yesterday, and they agreed to say "don't put the prefix in the code", but pushed back on also saying "but accept the prefix if it's in there".
... So I took out the part about "but accept the prefix if it's in there".
... The ITS group voted to accept the amended proposal.
https: //jira.hl7.org/browse/FHIR-48787
ADJOURNED