Meeting minutes
RDF Lists
jim: Opened an issue in OWL API: https://
… Getting pessimistic about it.
… Small ont w two properties, one a sub-prop of the other. And some axiom annotations, using rdf:first as the annotatedProperty. You're not realy supposed ot do this, but you would if you're using a prop in a list.
… But one of the annotations gets put onto the wrong node.
… When it goes through the parsing, it has pending annotations, and it takes whatever is in the pending annotations instaed of matching u what should be there.
… Hoping to get some engagement on it, but IDK now likely. Parsing algo ... the rdfs:comment should be in the unparsed things at the end of the algo.
dbooth: Who wrote the code?
jim: Probably Matt Horridge originally.
eric: Any out of band way to get Matthew's interest? Like ping him on twitter?
jim: He's protege author also.
… Is our RDF List decision entirely contingent on making OWL API work on it?
eric: I think it should be a desiderata. I'd accept the RDF list approach if we can get this working. I think that would motivate other vendors.
eric: Ultimately it's a flaw in OWL.
gaurav: Another way to get OWL API dev interested: find valid OWL that triggers this bug.
… A bug that puts an annotation on an unrelated triple is really bad.
jim: It is also triggered if I change rdf:first to rdf:somethingelse .
dbooth: This is a barrier to using RDF lists with FHIR.
… You should tell them that.
Concept IRIs
gaurav: Grahame pointed me to synthia, which generates fake healthcare records. It generates them in JSON. For most codes, it draws on SNOMED and LOINC. But it also uses a bunch of other HL7 terminologies, incl passpport numbers, driver license numbers, etc. Trying to figure out where in the source code it is generated. Or we could gen a lot of fake patient records. 28GB of fake data already generated. Downside: Not in the wild, and because it
was created by software it w be well curated.
eric: One place to look ... UMLS ... or bioportal.
… Minimal mission is to handle codes that we observe now, and give not-too-unpleasant codes to SNOMED non-ccompositional code. But if we're trying to meet ont requirements, we might want to look at bioportal.
gaurav: A bunch of synthia codes are URLs. Should add that to examples.
gaurav: Grahame suggested checking system/code pairs from Synthea, which is available as software code (https://
eric: If we offer to 2 algorithms, conservative and liberal, then it would do the job.
dbooth: This investigation is to determine whether we should offer 2 algorithms.
dbooth: Should we offer 2 algo?
gopi: Offer two algo.
eric: Offer two algo.
gaurav: Grahame just adds a hash and then appends the code.
gaurav: Offer two algo.
brad: Two algo.
dbooth: I have some concerns about over engineering, but I'm okay w offering two algo.
… Friendly amendment: name the algorithm, and allow more than two.
eric: Should use different IRI stems for different algorithms.
dbooth: Sounds like someone could define multiple entries for the same code system.
eric: Suggest using another column. One for flatIRISTem, one for hierarchicalIRISTem.
… That embeds the algo name into the name of the column.
dbooth: But if a third algo is added, that means added another column to the table.
dbooth: That would allow multiple URIs for the same thing, which is not desirable.
eric: I like multiple columns because it is easier to police what gets written into the naming system than goes than to police their code.
dbooth: having one column for each algo rubs me the wrong way.
gaurav: Translator project is currently looking into qualifiers when making statements, like "ebola causes chem x to increase" You can add qualifiers, but orig statement must remain true.
dbooth: One column per algorithm vs a single column for algo name?
gaurav: pref one column pe r algo, but writing it up might shed light.
eric: I like gaurav's approach.
ADJOURNED