Dear David and Greg, thanks for your answers. I still don't see the sense in having the "base_name" constraint, though. The basic question for me is, what would break without the constraint? Because as far as I can tell now, it just prevents a sensible use case - searching the same mzXML file with different tools, and aggregating the results in one pepXML file.
> dshteynb...@systemsbiology.org> wrote: > > The idea is that different searches > > of the same data would happen in separate directories and the > > base_name (full path to the data file) would identify one search of an > > mzXML file representing one msms_run, and more than one search would > > never happen in one directory on the same file. I understand that you might keep the results from different search engines in different directories, but surely you wouldn't copy (or link, if you're smart) an mzXML file to three different directories to search it with Mascot, Sequest and X!Tandem, would you? > > In the iProphet tool (which combines results from > > multiple searches of the same data), I don't look at either base_name > > but rather the spectrum names themselves, with the combination of > > experiment_label, which is a user specified parameter that identifies > > data from the same experiment. The idea is that the combination of > > experiment_label and spectrum name will uniquely identify a spectrum > > searched. This is exactly the problem that I have: Wouldn't it be far easier to use the "base_name" attribute to make the connection to the mzXML file, rather an a custom label? I think it would be - only you couldn't do it with the current schema because of that strange uniqueness constraint. I'm working with iProphet results and I have to do quite some post- processing to find out which results belong to which mzXML file, so that I can annotate features derived from the mzXML with peptide sequences. (To be fair, the main reason is that only for X!Tandem "base_name" really contains the path to the original mzXML...) >From the perspective of a third-party developer, I woud much have rather see a clean-up of the existing pepXML than the addition of new elements. Hendrik -- You received this message because you are subscribed to the Google Groups "spctools-discuss" group. To post to this group, send email to spctools-disc...@googlegroups.com. To unsubscribe from this group, send email to spctools-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/spctools-discuss?hl=.
