psidev-pi-dev — General Development List for Proteomics Informatics

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Comment #12 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

In response to comment 11

I think this is correct, if no threshold has been specified, all should be  
set to
true i.e. everything is deemed to have passed the threshold.

Let's discuss on the call the cardinality of <threshold> and passThreshold.  
There is
an argument for making both mandatory, but having a CV term for "no  
threshold" - this
might annoy some implementers though...


--
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

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Updates:
	Labels: Milestone-Release1.0

Comment #11 on issue 49 by eisenachM: Issues / schema updates prior to  
version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

In the MPC example I set all passThreshold to true, although not having  
specified a
threshold; maybe this was a misunderstanding arising from the following  
schema
comment about passThreshold: "If no such threshold has been set, value of  
true should
be given for all results." (possibly a typo and should read "value of  
false"?

--
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

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Comment #10 on issue 49 by eisenachM: Issues / schema updates prior to  
version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

In response to Comment 3 and 8 (Threshold element):

I agree that it makes things clearer, but it seems to be mandatory at the  
moment, but
should be optional ("minOccurs=0") as Andy suggested in comment 3.

--
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

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[<cod...@go...>]

Comment #69 on issue 42 by eisenachM: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

need CV term under "Analysissoftware" and "Bruker  
Software": "ProteinExtractor" (an
algorithm for protein determination/assembly integrated into ProteinScape

--
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

[Psidev-pi-dev] Issue 50 in psi-pi: Taxonomy for each protein (DBSequence)

[<cod...@go...>]

Comment #2 on issue 50 by a.bertsch0815: Taxonomy for each protein  
(DBSequence)
http://code.google.com/p/psi-pi/issues/detail?id=50

MS:1001090 is obsolete now. The terms suggested by David are added to the  
CV. This
issue can be closed.

--
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

Re: [Psidev-pi-dev] mzIdentML schema questions

[Florian R. <fl...@eb...>]

Hi Andy,

to me the options 2 and 3 sound the best (although I am not quite sure what the exact difference 
would be in practice).

As I said, I am not a XML schema wizard, so I can't really see all the effects a schema change 
according to 2 or 3 would have.

As a Java developer and XML amateur, I can only say that I get quickly confused with different 
namespaces in one single instance document. Also if FuGE light is meant to be a sort of library for 
other related schemas, I would conceptually prefer to have that library consist of usable 
complexTypes rather than elements (which I would define in my schema), which I guess would be 
solution 3. However, I am not sure if that is possible or what percussions a rootless schema would 
have, also regarding the difference in the resulting instance documents...

Yes, I can attend next weeks telephone conference and maybe I can get a clearer picture then.

Thanks for your efforts,
Florian



Jones, Andy wrote:
> Hi Florian,
> Another quick follow up on this. I've tried adapting the mzIdentML schema so that it basically has only one possible root element (not uploaded yet). This is relatively simple and we can make this change without affecting too much in the instance docs. However, the FuGE-light schema is a bit more complicated because other projects are using it (I'm proposing to adapt GelML to use this schema), although nothing is fixed yet.
> 
> Can you give me some idea of how much difference there would be to implement the following scenarios:
> 
> 1) Current schema as is
> 2) Only one possible root element in mzIdentML, many possible root elements in FuGE light (i.e. this schema is unchanged)
> 	a) It is possible to use this system but create instances in mzIdentML where no FuGE elements can be imported i.e. instance docs would not have any elements with the pf: namespace - would this simplify implementation?
> 3) One root in mzIdentML, no possible roots in FuGE-light
> 4) Only one schema, no inheritance from FuGE-light
> 
> Are you able to join the conference call next week, Thurs 4pm UK time?
> Cheers
> Andy
> 
> 
>> -----Original Message-----
>> From: Jones, Andy [mailto:And...@li...]
>> Sent: 22 May 2009 09:43
>> To: 'psi...@li...'
>> Subject: Re: [Psidev-pi-dev] mzIdentML schema questions
>>
>> Hi Florian,
>>
>> Thanks for your input, this is an issue we discussed in the past:
>> http://code.google.com/p/psi-pi/issues/detail?id=27&can=1 but we didn't previously
>> get any feedback from implementers that the schema design made much
>> difference. For the schema development, we've focussed on getting instance
>> documents to look how we want and not worried too much about which design
>> paradigm we've followed for XSD creation.
>>
>> Since, it appears that the current design (which is slightly messy) will complicate
>> implementations, I'll look into how much work it would be to fix the design. I'll let
>> you know!
>> Cheers
>> Andy
>>
>>
>>
>>> -----Original Message-----
>>> From: Florian Reisinger [mailto:fl...@eb...]
>>> Sent: 21 May 2009 18:04
>>> To: psi...@li...
>>> Subject: [Psidev-pi-dev] mzIdentML schema questions
>>>
>>> Dear PSI-PI developers,
>>>
>>> I am member of the PRIDE team (EBI) and we are trying to implement a Java API
>>> for the mzIdentML
>>> schema similar to the jmzml API for mzML.
>>>
>>> However I am a little confused about this schema (probably because of my lack
>> of
>>> knowledge about XML
>>> schema, so I apologize if I ask stupid questions) and I would be very thankful for
>>> some help
>>> concerning some difficulties I have with understanding the schema.
>>>
>>>
>>> The first thing that I noticed is that complexTypes reference elements (defined
>> at
>>> the document root
>>> of mzIdentML or FuGElight) a lot instead of defining them with name and using a
>>> global custom type.
>>> Also there are quite a few anonymous complexTypes.
>>>
>>> Is there a special reason for this syntax?
>>>
>>> It generates a couple of issues:
>>> - the anonymous complexTypes result in inner classes when generating the Java
>>> object model (which is
>>> not very nice to work with).
>>> - the elements defined at the root level, allow the creation of very simple XML
>>> instance files which
>>> are valid against the schema, but have nothing to do with mzIdentML. For
>> example:
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <ns1:BooleanValue xmlns:ns1="http://psidev.info/fuge-light/1.0"
>>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>   xsi:schemaLocation="http://psidev.info/fuge-light/1.0 mzIdentML_working.xsd"
>>> value="false">
>>> </ns1:BooleanValue>
>>>
>>>
>>> Are there arguments against a sort of "Venetian Blind design", where all
>>> complexTypes are defined at
>>> the root level (globally) and (similar to mzML) only one root element is defined at
>>> the root level
>>> (so all valid instance documents have to start with that element)?
>>>
>>> In my opinion it would make the schema also a bit more readable, since all
>>> complexTypes could be
>>> seen instantly (and would be reusable) without having to search for anonymous
>>> local types.
>>>
>>> Since I am not very familiar with the full power and possibilities of XML schema, I
>>> tend to like
>>> simple schemas ;) and I may just not see the advantages of its current state.
>>>
>>> Please can someone help me understand it?
>>>
>>> Thank you very much!
>>>
>>> Best regards,
>>> Florian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>> is a gathering of tech-side developers & brand creativity professionals. Meet
>>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>>> _______________________________________________
>>> Psidev-pi-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> _______________________________________________
>> Psidev-pi-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] mzIdentML schema questions

[Jones, A. <And...@li...>]

Hi Florian,
Another quick follow up on this. I've tried adapting the mzIdentML schema so that it basically has only one possible root element (not uploaded yet). This is relatively simple and we can make this change without affecting too much in the instance docs. However, the FuGE-light schema is a bit more complicated because other projects are using it (I'm proposing to adapt GelML to use this schema), although nothing is fixed yet.

Can you give me some idea of how much difference there would be to implement the following scenarios:

1) Current schema as is
2) Only one possible root element in mzIdentML, many possible root elements in FuGE light (i.e. this schema is unchanged)
	a) It is possible to use this system but create instances in mzIdentML where no FuGE elements can be imported i.e. instance docs would not have any elements with the pf: namespace - would this simplify implementation?
3) One root in mzIdentML, no possible roots in FuGE-light
4) Only one schema, no inheritance from FuGE-light

Are you able to join the conference call next week, Thurs 4pm UK time?
Cheers
Andy


> -----Original Message-----
> From: Jones, Andy [mailto:And...@li...]
> Sent: 22 May 2009 09:43
> To: 'psi...@li...'
> Subject: Re: [Psidev-pi-dev] mzIdentML schema questions
> 
> Hi Florian,
> 
> Thanks for your input, this is an issue we discussed in the past:
> http://code.google.com/p/psi-pi/issues/detail?id=27&can=1 but we didn't previously
> get any feedback from implementers that the schema design made much
> difference. For the schema development, we've focussed on getting instance
> documents to look how we want and not worried too much about which design
> paradigm we've followed for XSD creation.
> 
> Since, it appears that the current design (which is slightly messy) will complicate
> implementations, I'll look into how much work it would be to fix the design. I'll let
> you know!
> Cheers
> Andy
> 
> 
> 
> > -----Original Message-----
> > From: Florian Reisinger [mailto:fl...@eb...]
> > Sent: 21 May 2009 18:04
> > To: psi...@li...
> > Subject: [Psidev-pi-dev] mzIdentML schema questions
> >
> > Dear PSI-PI developers,
> >
> > I am member of the PRIDE team (EBI) and we are trying to implement a Java API
> > for the mzIdentML
> > schema similar to the jmzml API for mzML.
> >
> > However I am a little confused about this schema (probably because of my lack
> of
> > knowledge about XML
> > schema, so I apologize if I ask stupid questions) and I would be very thankful for
> > some help
> > concerning some difficulties I have with understanding the schema.
> >
> >
> > The first thing that I noticed is that complexTypes reference elements (defined
> at
> > the document root
> > of mzIdentML or FuGElight) a lot instead of defining them with name and using a
> > global custom type.
> > Also there are quite a few anonymous complexTypes.
> >
> > Is there a special reason for this syntax?
> >
> > It generates a couple of issues:
> > - the anonymous complexTypes result in inner classes when generating the Java
> > object model (which is
> > not very nice to work with).
> > - the elements defined at the root level, allow the creation of very simple XML
> > instance files which
> > are valid against the schema, but have nothing to do with mzIdentML. For
> example:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <ns1:BooleanValue xmlns:ns1="http://psidev.info/fuge-light/1.0"
> >   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >   xsi:schemaLocation="http://psidev.info/fuge-light/1.0 mzIdentML_working.xsd"
> > value="false">
> > </ns1:BooleanValue>
> >
> >
> > Are there arguments against a sort of "Venetian Blind design", where all
> > complexTypes are defined at
> > the root level (globally) and (similar to mzML) only one root element is defined at
> > the root level
> > (so all valid instance documents have to start with that element)?
> >
> > In my opinion it would make the schema also a bit more readable, since all
> > complexTypes could be
> > seen instantly (and would be reusable) without having to search for anonymous
> > local types.
> >
> > Since I am not very familiar with the full power and possibilities of XML schema, I
> > tend to like
> > simple schemas ;) and I may just not see the advantages of its current state.
> >
> > Please can someone help me understand it?
> >
> > Thank you very much!
> >
> > Best regards,
> > Florian
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> > is a gathering of tech-side developers & brand creativity professionals. Meet
> > the minds behind Google Creative Lab, Visual Complexity, Processing, &
> > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> > Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> > _______________________________________________
> > Psidev-pi-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] mzIdentML schema questions

[Jones, A. <And...@li...>]

Hi Florian,

Thanks for your input, this is an issue we discussed in the past: http://code.google.com/p/psi-pi/issues/detail?id=27&can=1 but we didn't previously get any feedback from implementers that the schema design made much difference. For the schema development, we've focussed on getting instance documents to look how we want and not worried too much about which design paradigm we've followed for XSD creation. 

Since, it appears that the current design (which is slightly messy) will complicate implementations, I'll look into how much work it would be to fix the design. I'll let you know!
Cheers
Andy 



> -----Original Message-----
> From: Florian Reisinger [mailto:fl...@eb...]
> Sent: 21 May 2009 18:04
> To: psi...@li...
> Subject: [Psidev-pi-dev] mzIdentML schema questions
> 
> Dear PSI-PI developers,
> 
> I am member of the PRIDE team (EBI) and we are trying to implement a Java API
> for the mzIdentML
> schema similar to the jmzml API for mzML.
> 
> However I am a little confused about this schema (probably because of my lack of
> knowledge about XML
> schema, so I apologize if I ask stupid questions) and I would be very thankful for
> some help
> concerning some difficulties I have with understanding the schema.
> 
> 
> The first thing that I noticed is that complexTypes reference elements (defined at
> the document root
> of mzIdentML or FuGElight) a lot instead of defining them with name and using a
> global custom type.
> Also there are quite a few anonymous complexTypes.
> 
> Is there a special reason for this syntax?
> 
> It generates a couple of issues:
> - the anonymous complexTypes result in inner classes when generating the Java
> object model (which is
> not very nice to work with).
> - the elements defined at the root level, allow the creation of very simple XML
> instance files which
> are valid against the schema, but have nothing to do with mzIdentML. For example:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <ns1:BooleanValue xmlns:ns1="http://psidev.info/fuge-light/1.0"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://psidev.info/fuge-light/1.0 mzIdentML_working.xsd"
> value="false">
> </ns1:BooleanValue>
> 
> 
> Are there arguments against a sort of "Venetian Blind design", where all
> complexTypes are defined at
> the root level (globally) and (similar to mzML) only one root element is defined at
> the root level
> (so all valid instance documents have to start with that element)?
> 
> In my opinion it would make the schema also a bit more readable, since all
> complexTypes could be
> seen instantly (and would be reusable) without having to search for anonymous
> local types.
> 
> Since I am not very familiar with the full power and possibilities of XML schema, I
> tend to like
> simple schemas ;) and I may just not see the advantages of its current state.
> 
> Please can someone help me understand it?
> 
> Thank you very much!
> 
> Best regards,
> Florian
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

[Psidev-pi-dev] mzIdentML schema questions

[Florian R. <fl...@eb...>]

Dear PSI-PI developers,

I am member of the PRIDE team (EBI) and we are trying to implement a Java API for the mzIdentML 
schema similar to the jmzml API for mzML.

However I am a little confused about this schema (probably because of my lack of knowledge about XML 
schema, so I apologize if I ask stupid questions) and I would be very thankful for some help 
concerning some difficulties I have with understanding the schema.


The first thing that I noticed is that complexTypes reference elements (defined at the document root 
of mzIdentML or FuGElight) a lot instead of defining them with name and using a global custom type. 
Also there are quite a few anonymous complexTypes.

Is there a special reason for this syntax?

It generates a couple of issues:
- the anonymous complexTypes result in inner classes when generating the Java object model (which is 
not very nice to work with).
- the elements defined at the root level, allow the creation of very simple XML instance files which 
are valid against the schema, but have nothing to do with mzIdentML. For example:

<?xml version="1.0" encoding="UTF-8"?>
<ns1:BooleanValue xmlns:ns1="http://psidev.info/fuge-light/1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://psidev.info/fuge-light/1.0 mzIdentML_working.xsd" value="false">
</ns1:BooleanValue>


Are there arguments against a sort of "Venetian Blind design", where all complexTypes are defined at 
the root level (globally) and (similar to mzML) only one root element is defined at the root level 
(so all valid instance documents have to start with that element)?

In my opinion it would make the schema also a bit more readable, since all complexTypes could be 
seen instantly (and would be reusable) without having to search for anonymous local types.

Since I am not very familiar with the full power and possibilities of XML schema, I tend to like 
simple schemas ;) and I may just not see the advantages of its current state.

Please can someone help me understand it?

Thank you very much!

Best regards,
Florian

[Psidev-pi-dev] Minutes from Phone Conference (May 20)

[Juan A. V. <ju...@eb...>]

Hi all,

Minutes from yesterday's phone conference can be found here:

http://www.psidev.info/index.php?q=node/417

Cheers,

Juan Antonio


Juan Antonio Vizcaíno, Ph.D.
EMBL European Bioinformatics Institute
Proteomics Services Team, PANDA Group
Wellcome Trust Genome Campus
Hinxton, Cambridge, UK
CB10 1SD
Tel: +44 (0) 1223 492 686
Fax: +44 (0) 1223 494 468
Skype: javizca

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Comment #9 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Schema update:

Added SoftwareName --> Param to AnalysisSoftware

We need to add a mapping for these CV terms to the mapping file

--
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

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Comment #8 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Schema updates made:

Added Threshold to SIP and PDP

Altered SubstitutionModification - removed residues. Added documentation  
about
specifying original peptide sequence for SubMods

Changed data type for peptideSequence - should now check for upper case  
sequence of chars



--
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

[Psidev-pi-dev] FW: PSI-PI conference call 4pm UK today

[Jones, A. <And...@li...>]

> -----Original Message-----
> From: Andreas Bertsch [mailto:be...@in...]
> Sent: 20 May 2009 10:18
> To: Jones, Andy
> Subject: Re: [Psidev-pi-dev] PSI-PI conference call 4pm UK today
> 
> Hi Andy,
> 
> > There will be an mzIdentML working group conference call today
> > 4:00pm UK time:
> >
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?month=5&day=20&year=20
> 09&hour=16&min=0&sec=0&p1=136
> >
> > Agenda:
> >
> > - Review minutes from last call: http://www.psidev.info/index.php?q=node/415
> > - Outstanding issues with the CV:
> >
> >    http://code.google.com/p/psi-pi/source/browse/trunk/cv/psi-ms.obo
> >
> > - Outstanding schema issues - several minor issues identified:
> http://code.google.com/p/psi-pi/issues/detail?id=49
> > - Updates to the example instance docs – problems identified
> > - Other outstanding items on the issues list.
> >
> >
> > Please send me any further items for the agenda.
> 
> I have two points.
> - The mapping file is somewhat incomplete (see http://code.google.com/p/psi-
> pi/issues/detail?id=42
>   comment 66)
> - The CV is now officially merged with the ms and I will commit all
> changes to the cvs of the psi-ms group
> (http://psidev.cvs.sourceforge.net/viewvc/*checkout*/psidev/psi/psi-
> ms/mzML/controlledVocabulary/psi-ms.obo
> ). To avoid confusion I will remove it from our svn repository.
> 
> If I have time this afternoon, I will summarize the changes and
> decision to be done and add a comment to issue 42 (funny number for a
> never ending story, though ;)).
> 
> Cheers,
> A.
> 
> 
> --
> Div. for Simulation of Biological Systems, WSI, University of Tuebingen
> Room C322, Sand 14, 72076 Tuebingen, Germany
> phone: +49-7071-29-70461 fax: +49-7071-29-5152
> http://www-bs.informatik.uni-tuebingen.de
> 
> 
> 

[Psidev-pi-dev] Issue 44 in psi-pi: Issues with all instance docs

[<cod...@go...>]

Comment #12 on issue 44 by dcreasy: Issues with all instance docs
http://code.google.com/p/psi-pi/issues/detail?id=44

Regarding comment#8. Example now included in Mascot N15 example
Doesn't use the residues attribute.

--
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

[Psidev-pi-dev] Issue 44 in psi-pi: Issues with all instance docs

[<cod...@go...>]

Comment #11 on issue 44 by dcreasy: Issues with all instance docs
http://code.google.com/p/psi-pi/issues/detail?id=44

Regarding comment #6.
An example is now provided here:
http://code.google.com/p/psi-pi/source/browse/trunk/examples/Mascot_mzml_example.mzid
This is a search of small.pwiz.1.1.mzML which is referenced from here:
http://psidev.info/index.php?q=node/257

The example shows how the results can be tracked back to the raw data using  
the nativeID.

--
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

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

[<cod...@go...>]

Comment #68 on issue 42 by a.bertsch0815: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

TODOs
- cleanup software structure; which software terms needs to be added? (Mail  
Matt,
e.g. Waters Software)
- database and Taxonomy (see issue 50); MIRIAM and Co., Mapping and CV
- where to put the term "unknown modification"
- where to put role type
- other cleanups?

Mapping rules missing (no terms allowed at the moment):
/mzIdentML/DataCollection/AnalysisData/SpectrumIdentificationList/SpectrumIdentificationResult/SpectrumIdentificationItem/PeptideEvidence/
/mzIdentML/DataCollection/AnalysisData/ProteinDetectionList/ProteinAmbiguityGroup/


Things already done:
- Mapping for checksums for databases and input (source) files
- Obsoleted some term which were duplicates of MS terms
- Regex of cleavage agents are now in the cleavage agent subtree
- ...


--
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

[Psidev-pi-dev] Issue 44 in psi-pi: Issues with all instance docs

[<cod...@go...>]

Comment #10 on issue 44 by dcreasy: Issues with all instance docs
http://code.google.com/p/psi-pi/issues/detail?id=44

Regarding Comment #9:
The Mascot_N15_example.mzid search was against all "Arabidopsis" excluding
"Arabidopsis neglecta":

<DatabaseFilters>
   <Filter>
     <FilterType>
       <pf:cvParam accession="MS:1001020" name="DB filter taxonomy"  
cvRef="PSI-MS" />
     </FilterType>
     <Include>
       <pf:cvParam accession="NCBI:3701" name="Arabidopsis"  
cvRef="NCBI-TAXONOMY" />
     </Include>
     <Exclude>
       <pf:cvParam accession="NCBI:45251" name="Arabidopsis neglecta"
cvRef="NCBI-TAXONOMY" />
     </Exclude>
   </Filter>
</DatabaseFilters>


--
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

[Psidev-pi-dev] PSI-PI conference call 4pm UK today

[Jones, A. <And...@li...>]

Hi everyone,

There will be an mzIdentML working group conference call today 4:00pm UK time:

http://www.timeanddate.com/worldclock/fixedtime.html?month=5&day=20&year=2009&hour=16&min=0&sec=0&p1=136

Agenda:

-       Review minutes from last call: http://www.psidev.info/index.php?q=node/415
- Outstanding issues with the CV:

    http://code.google.com/p/psi-pi/source/browse/trunk/cv/psi-ms.obo

- Outstanding schema issues - several minor issues identified: http://code.google.com/p/psi-pi/issues/detail?id=49
- Updates to the example instance docs – problems identified
- Other outstanding items on the issues list.


Please send me any further items for the agenda.

Dial in details:

+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)

access code: 297427

cheers
Andy

[Psidev-pi-dev] NCBO releases services and widgets to deploy in users web sites and applications

[Trish W. <plw...@gm...>]

The National Center for Biomedical Ontology is pleased to announce the
release of several services and widgets that will enable users to include
the NCBO technologies on their own web sites and in their applications.
Please see the following page for details:

http://www.bioontology.org/wiki/index.php/Using_NCBO_Technology_In_Your_Project



Specifically, we have released:

*Ontology Web Services: *All the content that the NCBO BioPortal uses (and
more!) is available via REST services. You can use the NCBO REST Services:

            • to access all BioPortal ontologies, their different versions,
and metadata for those versions

            • to access information about any ontology concept in BioPortal
(its definition, synonyms, and other properties)

            • to search across all ontologies in BioPortal

            • to get hierarchy information for BioPortal ontologies (such as
parents, children, or siblings of a class, roots or leaves of a class
hierarchy)



*Annotator Web Service: *A service that identifies mentions of biomedical
ontology concepts in text that users submit. You can use the annotator
service to tag automatically any item of interest with terms from UMLS and
BioPortal ontologies.

*Ontology Widgets: *Put elements of BioPortal, custom-tailored for your
ontology of interest, on your own Web site or in your Web form. To add these
widgets, you need only to copy simple HTML or Javascript code to your own
Web page (go to the "Ontology Widgets" tab on the page for individual
ontology details to get the code pre-configured for the widgets using your
ontology of interest).  The main kinds of widgets you get are:

            • *Term-selection field on a form*: You can add a text field to
your Web form that will let users enter a term from a controlled vocabulary
(e.g., terms from a single ontology)

            • *Ontology search widget*: You can add to your Web site a
search box that searches a specific BioPortal ontology. When the user
selects the term of interest (with the help of the look-ahead feature), he
can jump to the BioPortal page for the corresponding concept in BioPortal.

            • *Track updates (RSS Feed widget)*: you can put a widget on
your site that will have a live feed of all the changes to your ontology of
interest, such as uploads of a new version, comments from other users, new
mappings for concepts in your ontology.

            • *Ontology visualization widget*: You can put a widget on your
Web site that visualizes your entire ontology of interest, or some part of
it, as on the "Visualize" tab in BioPortal.

Re: [Psidev-pi-dev] [Psidev-ms-dev] Merged CV

[Fredrik L. <Fre...@im...>]

There was also duplication in the following terms, so I've just made the newer terms obsolete there as well:

MS:1001414 MGF scans == MS:1000797 peak list scans
MS:1001415 MGF raw scans == MS:1000798 peak list raw scans

Fredrik

Andreas Bertsch wrote:
> Hi Eric,
>
> I've just commited a number of changes of the PI subtree of the cv  
> today. Hopefully, this will not affect the mzML part.
>
>   
>> Hi everyone, this duplication comes from PI merge. Okay to obsolete  
>> newer,
>> PI-derived terms?
>>
>> i.e., okay to obsolete MS:1001061 and MS:1001416?
>>
>> Any objections?
>>     
>
> Yes, these should be obsoleted. I can do the changes if no one else  
> volunteers. And I also will update the mappings and the structure for  
> the mzIdentML files to validate again.
>
> Best,
> A.
>
> --
> Div. for Simulation of Biological Systems, WSI, University of Tuebingen
> Room C322, Sand 14, 72076 Tuebingen, Germany
> phone: +49-7071-29-70461 fax: +49-7071-29-5152
> http://www-bs.informatik.uni-tuebingen.de
>
>
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>   

Re: [Psidev-pi-dev] [Psidev-ms-dev] Merged CV

[Andreas B. <be...@in...>]

Hi Eric,

I've just commited a number of changes of the PI subtree of the cv  
today. Hopefully, this will not affect the mzML part.

> Hi everyone, this duplication comes from PI merge. Okay to obsolete  
> newer,
> PI-derived terms?
>
> i.e., okay to obsolete MS:1001061 and MS:1001416?
>
> Any objections?

Yes, these should be obsoleted. I can do the changes if no one else  
volunteers. And I also will update the mappings and the structure for  
the mzIdentML files to validate again.

Best,
A.

--
Div. for Simulation of Biological Systems, WSI, University of Tuebingen
Room C322, Sand 14, 72076 Tuebingen, Germany
phone: +49-7071-29-70461 fax: +49-7071-29-5152
http://www-bs.informatik.uni-tuebingen.de

Re: [Psidev-pi-dev] [Psidev-ms-dev] Merged CV

[Eric D. <ede...@sy...>]

Hi everyone, this duplication comes from PI merge. Okay to obsolete newer,
PI-derived terms?

i.e., okay to obsolete MS:1001061 and MS:1001416?

Any objections?

Thanks,
Eric


> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: Wednesday, May 13, 2009 11:46 AM
> To: Mass spectrometry standard development; psidev-pi-
> de...@li...
> Subject: Re: [Psidev-ms-dev] Merged CV
> 
> I found some redundant names after the merge that causes problems with
> pwiz.
> 
> id: MS:1000336
> name: neutral loss
> def: "The loss of an uncharged species during a rearrangement process."
> [PSI:MS]
> is_a: MS:1000445 ! sequential m/z separation method ?
> 
> 
> id: MS:1001061
> 
> name: neutral loss
> def: "Leave this to PSI-MOD?" [PSI:PI]
> is_a: MS:1001055 ! modification parameters
> 
> 
> and
> 
> 
> id: MS:1000796
> name: spectrum title
> def: "A free-form text title describing a spectrum." [PSI:MS]
> comment: This is the preferred storage place for the spectrum TITLE from
> an MGF peak list. This term corresponds to Protein Informatics CV term
> PI:00416
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1000499 ! spectrum attribute
> 
> 
> id: MS:1001416
> name: spectrum title
> def: "Holds the spectrum title from different input file formats, e.g. MGF
> TITLE." [PSI:PI]
> xref: value-type:xsd\:string "The allowed value-type for this CV term."
> is_a: MS:1001405 ! spectrum identification result details
> 
> 
> I'm pretty sure one of each duplicate pair should be obsoleted, which will
> render it more or less invisible to pwiz. Thoughts?
> 
> -Matt
> 
> 
> 
> Pierre-Alain Binz wrote:
> > Fine with me.
> > Yes, the ms-vocab list should be used for this. Request for changes
> > can be done on other lists, but the actual changes should be
> > documented there (not a perfect tracking system, but easy to search).
> > The CV editors must be in the list, and only those in the list are
> > allowed to edit.
> >
> > If the changes are quick, there is probably no need to "lock" the file
> > via a short announce on the vocab list. But if the work to be done is
> > longer (a few hours), it should be mentioned (I start, it's done) on
> > the list
> >
> > Does that sounds ok?
> > If yes, Eric can summarise the process (pragmatism is key here)
> >
> > Pierre-Alain
> >
> > Eric Deutsch wrote:
> >>
> >> Hi everyone, with the merging of the CV, we should probably review
> >> the versioning rules and, assuming we still like them, try to stick
> >> to them.
> >>
> >> According to our spec doc:
> >>
> >> A new psi-ms.obo should then be released by updating the file on the
> >> CVS server without changing the name of the file (this would alter
> >> the propagation of the file to the OBO website and to other ontology
> >> services that rely on file stable URI). For this reason an internal
> >> version number with two decimals (x.y.z) should be increased:
> >>
> >> . x should be increased when a first level term are renamed added
> >> deleted or rearranged in the structure. Such rearrangement is suppose
> >> to be rare and is very likely to have repercussion on the mapping.
> >>
> >> . y should be increased when any other term except the first level
> >> one is altered.
> >>
> >> . z should be increased when there is no term addition or deletion
> >> but just editing on the definitions or other minor changes.
> >>
> >> Are we all still on board with this?
> >>
> >> I made the new merged CV version 2.0.0.
> >>
> >> Since we have more people editing now, it is probably more important
> >> than ever to follow the edit protocol:
> >>
> >> - Grab the latest CV from CVS
> >>
> >> - Edit as necessary relatively quickly
> >>
> >> - Update the internal version number according to the rules above
> >>
> >> - Update the "lastID.txt" file in CVS too
> >>
> >> - Commit changes
> >>
> >> We have a psidev-ms-vocab email list which is rather disused. I
> >> suggest we make sure all the main editors are on it and update things
> >> so that the CVS commit messages go to that list to help us keep
> >> up-to-date. Does this seem good?
> >>
> >> Thanks,
> >>
> >> Erric
> >>
> >> -----------------------------------------------------------------------
> -
> >>
> >> -----------------------------------------------------------------------
> -------
> >> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
> Your
> >> production scanning environment may not be a perfect world - but thanks
> to
> >> Kodak, there's a perfect scanner to get the job done! With the NEW
> KODAK i700
> >> Series Scanner you'll get full speed at 300 dpi even with all image
> >> processing features enabled. http://p.sf.net/sfu/kodak-com
> >> -----------------------------------------------------------------------
> -
> >>
> >> _______________________________________________
> >> Psidev-ms-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> 
> --------------------------------------------------------------------------
> ----
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Comment #7 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

In response to Comment 5.

If we want to keep it I would then prefer if this was moved to
SpectrumIdentificationItem - especially since we got rid of sequenceMass on  
Peptide
(and just kept calculatedMassToCharge on SII). The PI calculation is  
totally software
dependent.





--
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

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Comment #6 on issue 49 by andrewrobertjones: Issues / schema updates prior  
to version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Some minor updates made that shouldn't affect any instance docs, the rest  
of the
issues above still to discuss:

Several attributes made mandatory:
SpectrumIdentificationList_ref on  
ProteinDetection->InputSpectrumIdentification and
on SpectrumIdentification (i.e. SpectrumIdentification must produce results  
and
ProteinDetection must reference an input)
ProteinDetectionList_ref on ProteinDetection i.e. a protein detection  
process must
produce a result
Peptide ->peptideSequence made mandatory (previously agreed on a call but  
not done)

AnalysisSoftwre_ref on SpectrumIdentificationProtocol and  
ProteinDetectionProtocol
AnalysisProtocol and AnalysisProtocolApplication removed – these were  
unreachable and
not used at all in the schema and will not be used in any future extensions.


--
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

[Psidev-pi-dev] Issue 49 in psi-pi: Issues / schema updates prior to version 1 release

[<cod...@go...>]

Comment #5 on issue 49 by delagoya: Issues / schema updates prior to  
version 1 release
http://code.google.com/p/psi-pi/issues/detail?id=49

Hold-over from pepXML. Also not meaningless if you use the information to  
weight paptide spectrum matches
against retention time. No commment of removal, but I would be inclined to  
keep it, since it is part of pepXML

--
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