<matthias_samwald> i volunteer for scribing.

<michel> thanks

<matthias_samwald> scribenick: matthias_samwald

joanne: in the last telecon, chime summarized some of his work.
... the information did not have enough detail to tell us which mapping would be right, because there was not enough information.

<ericP> 1 person with 3 bodies?

joanne: a sample from the same age/date/gender from a different location. we imagined a situation where supplies are short. we decided we did not have the authority to decide about identity.
... the patient data is ambiguous.
... the different options should be presented in the paper to the readers.

<michel> ericP is this a model problem, or a data input problem?

joanne: question: "when it happens, what are the possible causes?"

scott: a question when you are trying to map is, are you starting with the correct term -- as a recommendation, there should be disambiguation built into the interface. if a clinican is labeling a clinical report, they should be offered many choices to help them disambiguate.

joanne: another issue is when the categories are too narrow.
... if the annotator has to record something that has not been seen before, it will not be recorded/annotated.
... you have to expect that unusual / unexpected things will need to be captured.

<michel> http://esw.w3.org/HCLSIG/PharmaOntology/Data/MappingDataToSNOMED

michel: i have made a mapping to SNOMED terms on the wiki.

scott: alignment is a different process than data entry.
... but the underlying decisions that need to be made are probably similar.

michel: regarding the mapping table on the wiki -- what does our coverage look like?
... how many patient records do not have any matches, what are we proposing to do about it?

joanne: the table... is the data from all patients combined?

michel: don't know, chime gave me the link.

<Bob> Michel: Summary of last week's meeting?

<Bob> <Bob> Joanne: Went thru Chime's record, discussed what could not be matched

<Bob> <Bob> ... decided that it was important not to make inferences where they didn't exist

<Bob> <Bob> ... granularization didn't have enough detail

<Bob> <Bob> ... Second case was where inference was not warranted

<Bob> <Bob> ... influenza case had sample coming from same...but different parts of body

<Bob> <Bob> ... different modes of taking samples, but we didn't have authority to infer

<Bob> <Bob> Eric: Is this a modelling question?

<Bob> <Bob> Joanne: Data are ambiguous

<Bob> <Bob> ... this is what Chime was working on last week

<Bob> <Bob> ... answering Eric: these are the kinds of things that do come up

<Bob> <Bob> Eric: We get to resolve the ambiguities, port to Indivo, more modelling, bugs are in Indivo

<Bob> <Bob> ... yes there's value in disussing in the paper, since people will encounter this

<Bob> <Bob> ... but those are resolvable bugs in our model etc

<Bob> <Bob> ... Invdivo model carries these interpretations, gives a concrete example

<Bob> <Bob> ... prepares people for encountering these, point out to reader that these can be fixed

<Bob> <Bob> Scott: Disambiguation? There will always be cases where data themselves have not be disambiguating

<Bob> <Bob> ... need to have disambiguation built into the interface, at the clinician front end

<Bob> <Bob> Joanne: Two thumbs up!

<Bob> <Bob> Scott: If you've done that then minimizes noise later on

<Bob> <Bob> Joanne: If categories are too narrow, as in galaxies, people need to be able to record that things have not been seen before

<Bob> <Bob> ... want to make sure that unusual things can be noted

<Bob> <Bob> Scott: Yes, this also should be captured

<Bob> <Bob> Michel: Q about mapping of terms

<Bob> Joanne: We can look at coverage

<Bob> (above section was at beginning of call!)

oh, i was scribing here as well!

okay, you take over!

<Bob> (I was off on hlcs2!)

<Bob> Joanne: Map to more than one snomed category, but there weren't that many cases like this

<scribe> scribenick: Bob

Michel: Q is more tech, In patient data conversion we were keeping track of labels

Eric: Going Indivo to TMO?
... Will the Indivo xml carry these IDs? Yes
... this is place where tests are not carefully done yet
... rest of these tests have interesting modeling questions
... Indivo writes down a code w coding system, units, etc.
... combination of coding and ids gives you snomed
... But we want to start picking away at these, modeling w TMO
... too many, so we bring them in slowly, elevate some of them to our first-class way
... can start putting in further information
... goal here is to take bp, figure out mechanics
... problem is that some test results are not structured
... also have very structured tests, but some are just values
... ex: had to make up a genetic test, result

Michel: Share the structure?

Eric: This came up early b/c w SNPs
... genotyping SNPs

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

Eric: these are tests w lots of structure

Discussion of what is deep in this representation...

<michel> http://www.ncbi.nlm.nih.gov/sites/entrez?db=snp&cmd=search&term=rs72547528

<michel> http://www.ncbi.nlm.nih.gov/projects/SNP/snp_ref.cgi?rs=72547528

Michel: See C/T, chromosome, position, etc
... This is analogous to term-mapping, in that there is no corresponding record in dbSNP
... needs to be formalization, but up to you whether to embed

Eric: Alan R. had raised Q, to what degree are we capturing all the information?
... there are laws re capturing data, etc, so we can't throw anything away

Michel: Next-gen seq, how to get back to raw data from annotation?

Scott: We can throw down challenge to Indivo re SNPs

Eric: Clinics have laws that say you have to do all this, but EHRs are not motivated to

Scott: Maybe a placeholder in our data to enable this capability
... going back to low level from high level, sort of a reverse use case

<michel> http://esw.w3.org/HCLSIG/PharmaOntology/Diagrams

Michel: Here is the diagram to represent elements in the first query
... describe visually the query and identify elements in our KB
... query is largely described in relation rather than in type
... could be domain and range restrictions, but we haven't done that
... we had discussion re specialization of relations
... Will RDF still have this structure?

Eric: Yes, roughly. If something better, then would use it
... would like to have the extra predicates so consumers don't have to constrain by type
... use where I can

Michel: We have in linked-data: specific predicates sitting in one namespace

Eric: We need some inference if we are over-specializing our predicates

Michel: Coarse relations, use them in different combinations
... we should create a mapping of relations

Eric: We can do this in specific use cases
... point out that there can be more general use cases, what can be queried w/o inference

Joanne: Use cases is what drives the TMO

Eric: Yes, this would be the prize if we can show

Michel: TMO isn't playing a big role if we don't really use predicate mappings

<michel> use case - query the dataset - use dataset specific types/relations

<michel> use case - query all datasets - use TMO types/relations

<michel> but requires mappings

Eric: Use case: get query across datasets, but can still ask intelligent questions

<michel> at the type and relation level

Eric: Do we get to ask readers for more general queries?
... maybe say that these are questions for the community, OK as an interest group

Michel: Contrast two different queries w different predicate formulations

Scott: Chime's queries were from wiki, not aligned w TMO?
... should we change queries or TMO or both, from last week's call

Michel: Some of this is just in patient data, not in TMO
... before: mapping at type-level, we could query the type but could not do it w relation
... Scott, we want to contrast sparql within-dataset, against TMO types and relations across all datasets that are aligned
... LODD we could query irrespective of which dataset, we did not have relation mapping
... objects, individuals call for relations, we want to query on these sorts of predicates

Eric: LODD certain amount of coding to make things similar, so queries get similar units, etc

Michel: One query for a union across datasets

Eric: How general can you get before there is no useful unified query
... Ex: BP need normalization
... what query can we get in this non-normalized form? (excellent point) "Head-scratching time."

Michel: Take the paper that we had, start adding in new work.

Eric: We can point out about EHR integration

Michel: Want to convey that linked-data play nicely in the whole business space

<Trish> agree, at least for now no need to include SNP data but point to source

Michel: Nobody is going to undertake the whole process to convert everything
... they can just take their own part. SNP is a good example.

<mscottm> hand of God?

<mscottm> ;)

<Trish> need to move to next call

<michel> yup

<mscottm> bye

<michel> bye

<matthias_samwald> (i need to leave, bye!)

<Trish> i can work on some MS items

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)

Found ScribeNick: matthias_samwald
Found ScribeNick: Bob
Inferring Scribes: matthias_samwald, Bob
Scribes: matthias_samwald, Bob
ScribeNicks: matthias_samwald, Bob

WARNING: No "Topic:" lines found.

Default Present: Bob_Powers, Joanne_Luciano, +46.4.63.3.aaaa, +1.317.655.aabb, +1.781.431.aacc, EricP, mscottm, +46.4.63.3.aadd, +1.302.598.aaee
Present: Bob_Powers Joanne_Luciano +46.4.63.3.aaaa +1.317.655.aabb +1.781.431.aacc EricP mscottm +46.4.63.3.aadd +1.302.598.aaee

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: 28 Oct 2010
Guessing minutes URL: http://www.w3.org/2010/10/28-hcls2-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report