From: <cod...@go...> - 2008-11-28 17:43:24
|
Comment #50 on issue 42 by dcreasy: Issues with the CV http://code.google.com/p/psi-pi/issues/detail?id=42 Um. I can't find the relevant minutes that describe why we aren't importing the MS CV... I recollect that part of the discussion was along the lines that the structure would be different between the two and this could become a logistical nightmare. Also, that the mzML CV is not yet stable and trying to get the two to work together in a timely manner wasn't considered to be feasible. I'm no expert with CV, so am probably not the best person to answer this. Guess we (both groups) may have to defend this decision. btw, there's no constraint for nativeID being unique in the mzML schema so I assumed it didn't have to be unique. I think this is starting to get a little beyond the scope of analysisXML. 'All' we want is to be able to say which spectrum a result relates to, and we can realistically only report back whatever is fed into the search engine. Is the following 'good enough' for all cases (even if we aren't 100% happy with it?): The spectrumID attribute in analysisXML instance documents must be unique. spectrumID: for mzML files must be the <spectrum id> and is enforced as unique in mzML schema for mzData files, <spectrum id> value, should be unique, but not enforced in mzData schema for mzXML scan attribute, should be unique, but not enforced in mzXML schema? Other files, any unique value, possibly generated by the search engine. Add the following optional CV terms: scan time (maxOccurs="unbounded" for merged spectra) nativeID (maxOccurs="unbounded" for merged spectra) mgf title mgf scans mgf rawscans So MyriMatch would presumably report the nativeID. Does this sound reasonable? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |