W3C

- DRAFT -

SV_MEETING_TITLE

02 Dec 2010

See also: IRC log

Attendees

Present
Regrets
matthias
Chair
SV_MEETING_CHAIR
Scribe
Bob

Contents


<jluciano> what's eric talking about?

<jluciano> the children's hosp project?

<michel> i2b2

<michel> ericP: simple data structure, no complex relations

<michel> ... they're excited about adding semantics to describe concepts, ericP excited about adding semantics for the relations

<michel> ... patients have a portal into the clinical database

Michel: Open MRS had a demo, can't really do all things, like have to know patient's name
... but it is open w meet-ups etc, concept library like i2b2

<ericP> ericP: there's also MLHIM (Multi-level Health Information Modeling)

Michel: Are there other platforms where we can work on plumbing and concepts?

Eric: All these projects have a few coders on them
... don't now that i2b2 or Indivio offers serious advantage over others

<michel> requirements: interface, basic plumbing that can be customized, provide new content

<michel> attending: ericP, michel, scott, bob, joanne, elgar

<jluciano> TIm Lebo

patient data

Eric: Stuck a couple of claims in the paper, when forced to come up w model
... some bag of assertions that need not be elevated into ontology
... huge amount of info in SNPs, can be condensed into SNP variation for a person

<mscottm> Another system that I and Matthias looked at back in June: http://www.tolvenhealth.com/ It was being used by Collaborx

Eric: need a SNP expert, maybe join that with other things
... SNPs appear as XML, we need RDF. What would that look like in Indivo? Don't quite know
... what is true of all SNPs, don't need to code for individual patient.

Joanne: Are SNPs relevant for Alzheimer's?

Michel: Value of SNP is hiding in text: major allele, position, current allele
... info not quite structured in the way we need, but it is in there.

Eric: Micro-parsing is ahead of us.
... need to generically represent tests
... there is a whole lot of structure in the patient data about SNPs that are incomprehensible

Michel: RDF-ize dbSNP, would specify the structure

Eric: We can push this back to Indivo, make an informed plea

Joanne: Paper, still need to use TMO in queries

Eric: trans:, TMO, also strong desire to force units
... TMO is principled, wrote some OWL to map to units etc

Michel: trans: gets the RDF done, need a formal mapping trans: to schema relations
... more painful way is to formally analyze every transformation generates TMO

Eric: There is practical value to have another namespace, like trans:

Scott: Is trans: from bottom-up?

Eric: Yes, nothing special about it

<jluciano> that was Tim Lebo

Eric: trans: is a "to-do" namespace artifact
... Look at data, look at TMO, ask "How is this supposed to be expressed?"
... eveantually should not see any trans: in the XSLT
... XML data from EHR --> RDF version of Indivo

Tim: Generally good idea to push the ontology into the converter?

(good question!)

Eric: Logical structure for data, then that should be how the data are represented
... get rid of the trans as long as the queries do not become hopelessly erudite
... trans: represents questions people do ask plus what questions they might want to ask
... as long as questions are intuitive in TMO, then tweak the XSL
... there becomes less and less trans: in this process
... OWL file is a separate issue, to show fixed units
... tension between that, and TMO

Scott: We have discussed this a great deal.
... because we are using a language that is amenable to reasoning then we should use it

(that was Michel!)

Eric: At what level of tooling do you reduce choices?
... want data normalized *at input*, makes it easier downstream

Michel: Trivial to normalize units

Eric: Every standard reduces choices, the cost becomes exponentially harder
... generic federation problems appear after download

Michel: Once it's in RDF and sparql, well structured, then it't trivial to normalize
... that's what we're looking to do

Eric: Still have to examine each one and deal with it. Q is not whether but when.

Scott: "Standardizing" we require that people use certain units w. TMO. So how to specify that as a constraint?
... can't say from TMO that you need certain units?

Eric: Can do some enforcement in OWL
... Q is What is the space between the patient data and the TMO?

<jluciano> https://dvcs.w3.org/hg/TMO-Indivo/file/3334734509e9/syntheticPatients/AD_PCHR_1.xml

<mscottm> I lost all audio

<mscottm> got it back again (?)

<mscottm> .rdf files include some CPR - they were produced before using indivo

Eric has missed his lunch.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/12/02 18:00:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: Bob
Inferring Scribes: Bob

WARNING: No "Present: ... " found!
Possibly Present: Eric Joanne Joanne_Luciano Michel Scott Tim aaaa aabb attending epichler ericP https jluciano mscottm requirements
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Regrets: matthias

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 02 Dec 2010
Guessing minutes URL: http://www.w3.org/2010/12/02-hcls2-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]