psidev-ms-dev

[Psidev-ms-dev] mzML 0.99.0 comments

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

Hi,

My comments on mzML0.99.0 after reading (most of) the posts on the 
mailing list and trying to convert a peak list into the format are as 
follows:

The standard is composed of a schema with little control and a lot of 
cvParams that are controlled by a separate file. Updates to the CV does 
not require schema updates, and the CV rules file should also be stable. 
For the validation of files it would, as pointed out by several people, 
be straightforward to automate generate an XSD which reflect the current 
CV. Otherwise the semantic Java validator also does the job (and also 
have other benefits when it comes to large files). For us it doesn't 
matter which method is used, but the real issue is how to handle 
versions of the CV. As long as nothing is deleted from the CV everything 
should be fine from an implementation point of view though.

A major problem would be if something is added to the CV which breaks 
current parsers. A new compression type could be added to the CV without 
notice, and if someone is using that compression type they're producing 
standard compliant files, but parsers that are supposed to be standard 
compliant would not be able to parse the file correctly. So, there are a 
few places where I think the allowed values should be set under enum 
constraints in the main standard schema, so that a new schema version is 
enforced if these fields are changed. I have the feeling that CV version 
will not be as controlled as the schema version. Fields that I propose 
should be enums are (this is maybe one step back again...):

In binaryDataArray:

compressionType (no compression/zlib compression)
valueType (32-bit float, 64-bit float, 16-bit integer, 32-bit integer or 
64-bit integer)

In spectrum:

spectrumType (centroid, profile).

these parameters could be attributes or cvParams (but under schema 
control) if CV accession numbers are important.


Other comments:

There is also an acquisitionList spectrumType attribute which probably 
could be removed since we have spectrumDescription - 
spectrumRepresentation (spectrumType). Only use would be if the 
acquisitions were in profile mode but the peak picking algorithm that 
worked on the spectra turned them into a centroid peak list and one 
would like to specify this (?).

If the spectrum is a combination of multiple scans (as specified using 
acquistionList) one would normally not use the 'scan' element. The 
question is then how to give the retention time? We did not succeed in 
doing this in a valid way, see 
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/FF_070504_MSMS_5B.mzML 

for a simple (but invalid way of doing it). More correct would be to put 
the cvParam under the acquisition with the retention time, but this is 
not allowed either.

Why not allow softwareParam to be userParam or cvParam or must all 
software that work on mzML be in the CV?

How about having precursor m/z, intensity and charge state as 
non-required attributes to ionSelection? These fields are really used in 
every file.

Final comment is though that all these things are really minor, and that 
getting the standard released is what matters!

Regards

Fredrik

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[frank g. <Fra...@nc...>]

Hi

I have been following this discussion and there seems to be some confusion
about the CV, its use, and development. Using the OBO language this allows
you to record "words" or strings. It does not allow you to model what the
words represent such as restrictions, cardinality or datatypes for values
(such as int, double and xml datatypes). This is a limitation of the chosen
language.

The PSI have developed  "Guidelines for the development of Controlled
Vocabularies" which is a final document and describes the recommendation's
and best practice in designing CVs for the PSI. It includes and described
several issues which have been raised on this list such as what the
relationships of is_a and part_of semanticaly mean. In addition it includes
how to normalise the natural language definitions for each RA, the
maintainance procedures, obselecsing tems and the process for term addition.

The Final document can be found at the following URL
http://psidev.info/index.php?q=node/258


I hope these comments and the information contained within this document is
helpful in the development of the MS CV

Cheers

Frank



On 10/15/07, Fredrik Levander <Fre...@im...> wrote:
>
> Hi,
>
> My comments on mzML0.99.0 after reading (most of) the posts on the
> mailing list and trying to convert a peak list into the format are as
> follows:
>
> The standard is composed of a schema with little control and a lot of
> cvParams that are controlled by a separate file. Updates to the CV does
> not require schema updates, and the CV rules file should also be stable.
> For the validation of files it would, as pointed out by several people,
> be straightforward to automate generate an XSD which reflect the current
> CV. Otherwise the semantic Java validator also does the job (and also
> have other benefits when it comes to large files). For us it doesn't
> matter which method is used, but the real issue is how to handle
> versions of the CV. As long as nothing is deleted from the CV everything
> should be fine from an implementation point of view though.
>
> A major problem would be if something is added to the CV which breaks
> current parsers. A new compression type could be added to the CV without
> notice, and if someone is using that compression type they're producing
> standard compliant files, but parsers that are supposed to be standard
> compliant would not be able to parse the file correctly. So, there are a
> few places where I think the allowed values should be set under enum
> constraints in the main standard schema, so that a new schema version is
> enforced if these fields are changed. I have the feeling that CV version
> will not be as controlled as the schema version. Fields that I propose
> should be enums are (this is maybe one step back again...):
>
> In binaryDataArray:
>
> compressionType (no compression/zlib compression)
> valueType (32-bit float, 64-bit float, 16-bit integer, 32-bit integer or
> 64-bit integer)
>
> In spectrum:
>
> spectrumType (centroid, profile).
>
> these parameters could be attributes or cvParams (but under schema
> control) if CV accession numbers are important.
>
>
> Other comments:
>
> There is also an acquisitionList spectrumType attribute which probably
> could be removed since we have spectrumDescription -
> spectrumRepresentation (spectrumType). Only use would be if the
> acquisitions were in profile mode but the peak picking algorithm that
> worked on the spectra turned them into a centroid peak list and one
> would like to specify this (?).
>
> If the spectrum is a combination of multiple scans (as specified using
> acquistionList) one would normally not use the 'scan' element. The
> question is then how to give the retention time? We did not succeed in
> doing this in a valid way, see
>
> http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/FF_070504_MSMS_5B.mzML
>
> for a simple (but invalid way of doing it). More correct would be to put
> the cvParam under the acquisition with the retention time, but this is
> not allowed either.
>
> Why not allow softwareParam to be userParam or cvParam or must all
> software that work on mzML be in the CV?
>
> How about having precursor m/z, intensity and charge state as
> non-required attributes to ionSelection? These fields are really used in
> every file.
>
> Final comment is though that all these things are really minor, and that
> getting the standard released is what matters!
>
> Regards
>
> Fredrik
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>



-- 
Frank Gibson
Research Associate
Room 2.19, Devonshire Building
School of Computing Science,
University of Newcastle upon Tyne,
Newcastle upon Tyne, NE1 7RU
United Kingdom
Telephone: +44-191-246-4933
Fax: +44-191-246-4905

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Matthew C. <mat...@va...>]

Hi Frank, I read the Guidelines you linked to and also the paper 
describing the Relation Ontology (http://genomebiology.com/2005/6/5/R46) 
which is referenced from the Guidelines. The Relation Ontology does not 
in any way suggest that reliable OBO CVs should be limited to IS_A and 
PART_OF relationships! Rather, it does a good job of defining when IS_A 
and PART_OF should be used and what they really mean. I think if we 
looked closely we could find quite a few cases in the CV where the use 
of IS_A and PART_OF is bogus according to the Relation Ontology 
definition, especially with regard to values being indistinct from 
categories.

Therefore, I take issue with the following text from the Guidelines 
which has no corresponding rationale and which is currently biting us in 
the arse:

11. Relations between RU’s
As the PSI CV will be developed under the OBO umbrella [3], the 
relations created between terms MUST ascribe to the definitions and 
formal requirements provided in the OBO Relations Ontology (RO) paper 
[7], as the relations ‘is_a’ and ‘part_of’.

It is not clear whether the Relation Ontology recommends or discourages 
using OBO to typedef new relationship types into existence (my proposed 
'value of'), but that won't be necessary. I think we can accomplish the 
same effect with the existing relationship, 'instance_of', which IS part 
of the Relation Ontology. In fact, 'instance_of' is a primitive relation 
in the Relation Ontology, whereas 'is_a' is not. Here is the Relation 
Ontology definition for 'instance_of':

p instance_of P - a primitive relation between a process instance and a 
class which it instantiates holding independently of time

That sounds like a pretty good way to distinguish between values 
(instances) and categories (classes) to me! Further, the instance_of 
relationship can be used in addition to the current part_of and is_a 
relationships and it will serve to disambiguate a branch of the CV where 
the actual category that a value belongs to is an ancestor instead of a 
direct parent. For instance:
MS:1000173 "MAT900XP"
is a MS:1000493 "Finnigan MAT"
part of MS:1000483 "Thermo Fisher Scientific"
is a MS:1000031 "model by vendor"
part of MS:1000463 "instrument description"
part of MS:0000000 "MZ controlled vocabularies"
What category does the controlled value "MAT900XP" belong to, i.e. if we 
used cvParam method B, would it look like:
<cvParam cvLabel="MS" categoryName="Finnigan MAT" 
categoryAccession="MS:1000493" accession="MS:1000173" name="MAT900XP"/>
Or would it look like:
<cvParam cvLabel="MS" categoryName="model by vendor" 
categoryAccession="MS:1000031" accession="MS:1000173" name="MAT900XP"/>

Of course I think it should be the latter, but how would you derive that 
from the CV? You can't, unless you add a new relationship or convention, 
so I suggest:
MS:1000173 "MAT900XP"
instance of MS:1000031 "model by vendor"
is a MS:1000493 "Finnigan MAT"
part of MS:1000483 "Thermo Fisher Scientific"
is a MS:1000031 "model by vendor"
part of MS:1000463 "instrument description"
part of MS:0000000 "MZ controlled vocabularies"
It would also be good to get rid of the MS:1000483->MS:1000031 
relationship at that point because "Thermo Fisher Scientific" is NOT an 
instrument model.

I have to disagree with your assertion that OBO does not allow a CV to 
model datatypes and cardinality. I think the trailing modifiers (which 
may have been added since you last looked at the OBO language spec) 
would serve to model those properties quite nicely.

-Matt


frank gibson wrote:
> Hi
>
> I have been following this discussion and there seems to be some 
> confusion about the CV, its use, and development. Using the OBO 
> language this allows you to record "words" or strings. It does not 
> allow you to model what the words represent such as restrictions, 
> cardinality or datatypes for values (such as int, double and xml 
> datatypes). This is a limitation of the chosen language.
>
> The PSI have developed "Guidelines for the development of Controlled 
> Vocabularies" which is a final document and describes the 
> recommendation's and best practice in designing CVs for the PSI. It 
> includes and described several issues which have been raised on this 
> list such as what the relationships of is_a and part_of semanticaly 
> mean. In addition it includes how to normalise the natural language 
> definitions for each RA, the maintainance procedures, obselecsing tems 
> and the process for term addition.
>
> The Final document can be found at the following URL
> http://psidev.info/index.php?q=node/258
>
>
> I hope these comments and the information contained within this 
> document is helpful in the development of the MS CV
>
> Cheers
>
> Frank

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Matthew C. <mat...@va...>]

Oops.  It killed my spaces.  Let me try again.

That sounds like a pretty good way to distinguish between values 
(instances) and categories (classes) to me! Further, the instance_of 
relationship can be used in addition to the current part_of and is_a 
relationships and it will serve to disambiguate a branch of the CV where 
the actual category that a value belongs to is an ancestor instead of a 
direct parent. For instance:

MS:1000173 "MAT900XP"
--is a MS:1000493 "Finnigan MAT"
----part of MS:1000483 "Thermo Fisher Scientific"
------is a MS:1000031 "model by vendor"
--------part of MS:1000463 "instrument description"
----------part of MS:0000000 "MZ controlled vocabularies"

What category does the controlled value "MAT900XP" belong to, i.e. if we 
used cvParam method B, would it look like:
<cvParam cvLabel="MS" categoryName="Finnigan MAT" 
categoryAccession="MS:1000493" accession="MS:1000173" name="MAT900XP"/>
Or would it look like:
<cvParam cvLabel="MS" categoryName="model by vendor" 
categoryAccession="MS:1000031" accession="MS:1000173" name="MAT900XP"/>

Of course I think it should be the latter, but how would you derive that 
from the CV? You can't, unless you add a new relationship or convention, 
so I suggest:

MS:1000173 "MAT900XP"
--instance of MS:1000031 "model by vendor"
--is a MS:1000493 "Finnigan MAT"
----part of MS:1000483 "Thermo Fisher Scientific"
------is a MS:1000031 "model by vendor"
--------part of MS:1000463 "instrument description"
----------part of MS:0000000 "MZ controlled vocabularies"

It would also be good to get rid of the MS:1000483->MS:1000031 
relationship at that point because "Thermo Fisher Scientific" is NOT an 
instrument model.

-Matt

Matthew Chambers wrote:
> That sounds like a pretty good way to distinguish between values 
> (instances) and categories (classes) to me! Further, the instance_of 
> relationship can be used in addition to the current part_of and is_a 
> relationships and it will serve to disambiguate a branch of the CV 
> where the actual category that a value belongs to is an ancestor 
> instead of a direct parent. For instance:
> MS:1000173 "MAT900XP"
> is a MS:1000493 "Finnigan MAT"
> part of MS:1000483 "Thermo Fisher Scientific"
> is a MS:1000031 "model by vendor"
> part of MS:1000463 "instrument description"
> part of MS:0000000 "MZ controlled vocabularies"
> What category does the controlled value "MAT900XP" belong to, i.e. if we
> used cvParam method B, would it look like:
> <cvParam cvLabel="MS" categoryName="Finnigan MAT" 
> categoryAccession="MS:1000493" accession="MS:1000173" name="MAT900XP"/>
> Or would it look like:
> <cvParam cvLabel="MS" categoryName="model by vendor" 
> categoryAccession="MS:1000031" accession="MS:1000173" name="MAT900XP"/>

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Brian P. <bri...@in...>]

(First of all, thanks to Frank for shedding more light on the topic - heat,
we have already!)

Matt,

You're right about OBO not limiting itself to is_a and part_of, but it
appears that PSI has explicitly chosen to do so.  I doubt we have the
political heft to change that now, or that we should want to do so.  Further
contortions to turn CV into something to rival the readily available power
of XSD are misguided, in my opinion.

Frankly it seems to me that the CV doesn't really need to be all that
logically consistent: in its current bogus state it doesn't seem to have
bothered anyone, including the official validator.  PSI clearly never meant
for CV to do things like datatyping and range limiting so we should stop
pushing on that rope and just allow CV to play its proper role in
disambiguating the terms we use in the XSD, by use of accession numbers in
the XSD.  

The thing to do now is to transfer most of the intelligence in the
ms-mapping.xml schema file (for it is indeed a schema, albeit written in a
nonstandard format) to the XSD file then add the proper datatyping and range
checking.  I was happy to see that this second schema contains the work I
thought we were going to have to generate from the CV itself, although I was
also somewhat surprised to learn of the existence of such a key artifact
this late in the discussion.  Or maybe I just missed it somehow.

As I've said before we should be braver than we have been so far.  The
refusal to put useful content in the XSD file simply for fear of being wrong
about it is just deplorable and doesn't serve the purposes of the community.
And I'm appalled at the disingenuousness of claiming a "stable schema" when
many key parts of the spec are in fact expressed in a schema
(ms-mapping.xml) which is explicitly unstable.

The charge has been leveled on this list that (paraphrasing here) some old
dogs are resisting learning new tricks when it comes to the use of CV.
That's always something to be mindful of, but after careful consideration I
really just don't see the advantage of a CV-centric approach, when all the
added complexity and reinvention still leaves us well short of where proper
use of XSD would get us.  Fully realized XSD that references CV to define
its terms seems like the obvious choice for a system that wants to gain
widespread and rapid adoption.

- Brian

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Matthew
Chambers
Sent: Tuesday, October 16, 2007 8:27 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments

Hi Frank, I read the Guidelines you linked to and also the paper 
describing the Relation Ontology (http://genomebiology.com/2005/6/5/R46) 
which is referenced from the Guidelines. The Relation Ontology does not 
in any way suggest that reliable OBO CVs should be limited to IS_A and 
PART_OF relationships! Rather, it does a good job of defining when IS_A 
and PART_OF should be used and what they really mean. I think if we 
looked closely we could find quite a few cases in the CV where the use 
of IS_A and PART_OF is bogus according to the Relation Ontology 
definition, especially with regard to values being indistinct from 
categories.

Therefore, I take issue with the following text from the Guidelines 
which has no corresponding rationale and which is currently biting us in 
the arse:

11. Relations between RU's
As the PSI CV will be developed under the OBO umbrella [3], the 
relations created between terms MUST ascribe to the definitions and 
formal requirements provided in the OBO Relations Ontology (RO) paper 
[7], as the relations 'is_a' and 'part_of'.

It is not clear whether the Relation Ontology recommends or discourages 
using OBO to typedef new relationship types into existence (my proposed 
'value of'), but that won't be necessary. I think we can accomplish the 
same effect with the existing relationship, 'instance_of', which IS part 
of the Relation Ontology. In fact, 'instance_of' is a primitive relation 
in the Relation Ontology, whereas 'is_a' is not. Here is the Relation 
Ontology definition for 'instance_of':

p instance_of P - a primitive relation between a process instance and a 
class which it instantiates holding independently of time

That sounds like a pretty good way to distinguish between values 
(instances) and categories (classes) to me! Further, the instance_of 
relationship can be used in addition to the current part_of and is_a 
relationships and it will serve to disambiguate a branch of the CV where 
the actual category that a value belongs to is an ancestor instead of a 
direct parent. For instance:
MS:1000173 "MAT900XP"
is a MS:1000493 "Finnigan MAT"
part of MS:1000483 "Thermo Fisher Scientific"
is a MS:1000031 "model by vendor"
part of MS:1000463 "instrument description"
part of MS:0000000 "MZ controlled vocabularies"
What category does the controlled value "MAT900XP" belong to, i.e. if we 
used cvParam method B, would it look like:
<cvParam cvLabel="MS" categoryName="Finnigan MAT" 
categoryAccession="MS:1000493" accession="MS:1000173" name="MAT900XP"/>
Or would it look like:
<cvParam cvLabel="MS" categoryName="model by vendor" 
categoryAccession="MS:1000031" accession="MS:1000173" name="MAT900XP"/>

Of course I think it should be the latter, but how would you derive that 
from the CV? You can't, unless you add a new relationship or convention, 
so I suggest:
MS:1000173 "MAT900XP"
instance of MS:1000031 "model by vendor"
is a MS:1000493 "Finnigan MAT"
part of MS:1000483 "Thermo Fisher Scientific"
is a MS:1000031 "model by vendor"
part of MS:1000463 "instrument description"
part of MS:0000000 "MZ controlled vocabularies"
It would also be good to get rid of the MS:1000483->MS:1000031 
relationship at that point because "Thermo Fisher Scientific" is NOT an 
instrument model.

I have to disagree with your assertion that OBO does not allow a CV to 
model datatypes and cardinality. I think the trailing modifiers (which 
may have been added since you last looked at the OBO language spec) 
would serve to model those properties quite nicely.

-Matt


frank gibson wrote:
> Hi
>
> I have been following this discussion and there seems to be some 
> confusion about the CV, its use, and development. Using the OBO 
> language this allows you to record "words" or strings. It does not 
> allow you to model what the words represent such as restrictions, 
> cardinality or datatypes for values (such as int, double and xml 
> datatypes). This is a limitation of the chosen language.
>
> The PSI have developed "Guidelines for the development of Controlled 
> Vocabularies" which is a final document and describes the 
> recommendation's and best practice in designing CVs for the PSI. It 
> includes and described several issues which have been raised on this 
> list such as what the relationships of is_a and part_of semanticaly 
> mean. In addition it includes how to normalise the natural language 
> definitions for each RA, the maintainance procedures, obselecsing tems 
> and the process for term addition.
>
> The Final document can be found at the following URL
> http://psidev.info/index.php?q=node/258
>
>
> I hope these comments and the information contained within this 
> document is helpful in the development of the MS CV
>
> Cheers
>
> Frank


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Matthew C. <mat...@va...>]

Brian Pratt wrote:
> (First of all, thanks to Frank for shedding more light on the topic - heat,
> we have already!)
>
>   
Heat and light are just different wavelengths on the same spectrum. ;)

> Matt,
>
> You're right about OBO not limiting itself to is_a and part_of, but it
> appears that PSI has explicitly chosen to do so.  I doubt we have the
> political heft to change that now, or that we should want to do so.  Further
> contortions to turn CV into something to rival the readily available power
> of XSD are misguided, in my opinion.
>   
If what you say is true, I at least want to see some rationale of why 
PSI would explicitly limit their CVs to 'is_a' and 'part_of' 
relationships.  I agree that contorting a CV to make it work as an XSD 
is misguided, but it's already been done to a great extent and I just 
want to go that little bit further to finish it.  I was suggesting that 
we should leverage the validation power of XSD by autogenerating an XSD 
from a properly done (contorted!) CV, where maintaining the CV is 
preferable to the XSD primarily because OBO CVs are ubiquitous in the 
life sciences while XSDs are not (AFAIK).  Also, it means only having to 
maintain the CV instead of maintaining both the CV and the XSD 
(autogenerating the CV from the XSD is conceivable, but pointless 
because by then you are putting new accession number straight into the 
XSD along with all the baggage that needs to get passed to the CV but 
isn't really important to the XSD).

> Frankly it seems to me that the CV doesn't really need to be all that
> logically consistent: in its current bogus state it doesn't seem to have
> bothered anyone, including the official validator.  PSI clearly never meant
> for CV to do things like datatyping and range limiting so we should stop
> pushing on that rope and just allow CV to play its proper role in
> disambiguating the terms we use in the XSD, by use of accession numbers in
> the XSD.  
>   
I think you say this because, as things currently are, you don't plan to 
care much about the CV and frankly neither do I.  And there is a 
legitimate reason to not care about a CV if it doesn't specify enough 
semantics of the format to truly and unambiguously define the the 
terms.  The data type of a term is as much a part of its definition as 
the English description of it!  Imagine different users of the CV trying 
to pass around instances of terms using different data types for the 
different instances!  I don't think that constitutes an unambiguous 
controlled vocabulary. :)

> The thing to do now is to transfer most of the intelligence in the
> ms-mapping.xml schema file (for it is indeed a schema, albeit written in a
> nonstandard format) to the XSD file then add the proper datatyping and range
> checking.  I was happy to see that this second schema contains the work I
> thought we were going to have to generate from the CV itself, although I was
> also somewhat surprised to learn of the existence of such a key artifact
> this late in the discussion.  Or maybe I just missed it somehow.
>
> As I've said before we should be braver than we have been so far.  The
> refusal to put useful content in the XSD file simply for fear of being wrong
> about it is just deplorable and doesn't serve the purposes of the community.
> And I'm appalled at the disingenuousness of claiming a "stable schema" when
> many key parts of the spec are in fact expressed in a schema
> (ms-mapping.xml) which is explicitly unstable.
>   
I agree wholeheartedly.  We only disagree about maintaining the fully 
specified XSD.  I think it should be autogenerated from a fixed CV and a 
stable template schema, whereas you think it should be hand rolled.  Let 
me get you to clear something up though: do you want there to be a 
single, ever-changing schema, or would you also accept a basic stable 
schema (without CV-related restrictions) which can be derived from in 
order to create the fully specified schema with the ever-changing 
restrictions?  In the latter case, we can have a schema that is stable 
but doesn't serve for anything more than syntactical validation, and 
also a schema that can be used for full semantic validation, and which 
schema that a program uses is up to the program.

> The charge has been leveled on this list that (paraphrasing here) some old
> dogs are resisting learning new tricks when it comes to the use of CV.
> That's always something to be mindful of, but after careful consideration I
> really just don't see the advantage of a CV-centric approach, when all the
> added complexity and reinvention still leaves us well short of where proper
> use of XSD would get us.  Fully realized XSD that references CV to define
> its terms seems like the obvious choice for a system that wants to gain
> widespread and rapid adoption.
>   
Speaking of learning new tricks, when will the vendors' raw file reading 
libraries return CV accession numbers to describe terms instead of 
ambiguous strings?  That would be nice.  But if that never happens, each 
conversion program has to maintain its own vendor-to-CV mapping.  And if 
a program wants to read both vendor-proprietary formats and the XML 
formats, your mapping problems have become nightmares.

-Matt

> - Brian
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Matthew
> Chambers
> Sent: Tuesday, October 16, 2007 8:27 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments
>
> Hi Frank, I read the Guidelines you linked to and also the paper 
> describing the Relation Ontology (http://genomebiology.com/2005/6/5/R46) 
> which is referenced from the Guidelines. The Relation Ontology does not 
> in any way suggest that reliable OBO CVs should be limited to IS_A and 
> PART_OF relationships! Rather, it does a good job of defining when IS_A 
> and PART_OF should be used and what they really mean. I think if we 
> looked closely we could find quite a few cases in the CV where the use 
> of IS_A and PART_OF is bogus according to the Relation Ontology 
> definition, especially with regard to values being indistinct from 
> categories.
>
> Therefore, I take issue with the following text from the Guidelines 
> which has no corresponding rationale and which is currently biting us in 
> the arse:
>
> 11. Relations between RU's
> As the PSI CV will be developed under the OBO umbrella [3], the 
> relations created between terms MUST ascribe to the definitions and 
> formal requirements provided in the OBO Relations Ontology (RO) paper 
> [7], as the relations 'is_a' and 'part_of'.
>
> It is not clear whether the Relation Ontology recommends or discourages 
> using OBO to typedef new relationship types into existence (my proposed 
> 'value of'), but that won't be necessary. I think we can accomplish the 
> same effect with the existing relationship, 'instance_of', which IS part 
> of the Relation Ontology. In fact, 'instance_of' is a primitive relation 
> in the Relation Ontology, whereas 'is_a' is not. Here is the Relation 
> Ontology definition for 'instance_of':
>
> p instance_of P - a primitive relation between a process instance and a 
> class which it instantiates holding independently of time
>
> That sounds like a pretty good way to distinguish between values 
> (instances) and categories (classes) to me! Further, the instance_of 
> relationship can be used in addition to the current part_of and is_a 
> relationships and it will serve to disambiguate a branch of the CV where 
> the actual category that a value belongs to is an ancestor instead of a 
> direct parent. For instance:
> MS:1000173 "MAT900XP"
> is a MS:1000493 "Finnigan MAT"
> part of MS:1000483 "Thermo Fisher Scientific"
> is a MS:1000031 "model by vendor"
> part of MS:1000463 "instrument description"
> part of MS:0000000 "MZ controlled vocabularies"
> What category does the controlled value "MAT900XP" belong to, i.e. if we 
> used cvParam method B, would it look like:
> <cvParam cvLabel="MS" categoryName="Finnigan MAT" 
> categoryAccession="MS:1000493" accession="MS:1000173" name="MAT900XP"/>
> Or would it look like:
> <cvParam cvLabel="MS" categoryName="model by vendor" 
> categoryAccession="MS:1000031" accession="MS:1000173" name="MAT900XP"/>
>
> Of course I think it should be the latter, but how would you derive that 
> from the CV? You can't, unless you add a new relationship or convention, 
> so I suggest:
> MS:1000173 "MAT900XP"
> instance of MS:1000031 "model by vendor"
> is a MS:1000493 "Finnigan MAT"
> part of MS:1000483 "Thermo Fisher Scientific"
> is a MS:1000031 "model by vendor"
> part of MS:1000463 "instrument description"
> part of MS:0000000 "MZ controlled vocabularies"
> It would also be good to get rid of the MS:1000483->MS:1000031 
> relationship at that point because "Thermo Fisher Scientific" is NOT an 
> instrument model.
>
> I have to disagree with your assertion that OBO does not allow a CV to 
> model datatypes and cardinality. I think the trailing modifiers (which 
> may have been added since you last looked at the OBO language spec) 
> would serve to model those properties quite nicely.
>
> -Matt
>   

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Brian P. <bri...@in...>]

Hi Matt,

Matt,

I can only speculate on the history of PSI CV as a subset of OBO, my guess
is they just wanted to keep it simple as it was never intended to provide
the kind of granularity we need for fully automated semantic validation.

So, I disagree on your point of CV being nearly there as an XSD replacement.
It doesn't seem to have, for example, any means of saying whether an element
or attribute is required or not, or how many times it can occur, etc etc.
That's why that whole crazy xsd-like infrastructure that the java validator
uses was built up (the ms-mapping.xml schema file is attached, for those who
don't want to dig for it), and even that I have already shown to be
inadequate.  I don't want to see us follow previous groups down that rabbit
hole.

I also think that in practice nobody is going to be all that interested in
messing with the CV beyond adding the occasional machine model etc.  I think
a one time determination of the XSD will prove quite durable, and it's
already been largely done between the existing xsd and ms-mapping.xml.

You're right, for the applications I'm personally looking at right now I
think the CV isn't very important.  But your use case of vendor DLLs using
CV to disambiguate their APIs is a perfect example of how CV can improve
things.  I support its development and I think mzML should play well with
it.  Even though the existence of a system that would actually do anything
with the CV info in an mzML file is currently theoretical, it's the right
direction to be heading in and it's worth caring about and doing it right.

- Brian

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Matthew
Chambers
Sent: Tuesday, October 16, 2007 12:20 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments

Brian Pratt wrote:
> (First of all, thanks to Frank for shedding more light on the topic -
heat,
> we have already!)
>
>   
Heat and light are just different wavelengths on the same spectrum. ;)

> Matt,
>
> You're right about OBO not limiting itself to is_a and part_of, but it
> appears that PSI has explicitly chosen to do so.  I doubt we have the
> political heft to change that now, or that we should want to do so.
Further
> contortions to turn CV into something to rival the readily available power
> of XSD are misguided, in my opinion.
>   
If what you say is true, I at least want to see some rationale of why 
PSI would explicitly limit their CVs to 'is_a' and 'part_of' 
relationships.  I agree that contorting a CV to make it work as an XSD 
is misguided, but it's already been done to a great extent and I just 
want to go that little bit further to finish it.  I was suggesting that 
we should leverage the validation power of XSD by autogenerating an XSD 
from a properly done (contorted!) CV, where maintaining the CV is 
preferable to the XSD primarily because OBO CVs are ubiquitous in the 
life sciences while XSDs are not (AFAIK).  Also, it means only having to 
maintain the CV instead of maintaining both the CV and the XSD 
(autogenerating the CV from the XSD is conceivable, but pointless 
because by then you are putting new accession number straight into the 
XSD along with all the baggage that needs to get passed to the CV but 
isn't really important to the XSD).

> Frankly it seems to me that the CV doesn't really need to be all that
> logically consistent: in its current bogus state it doesn't seem to have
> bothered anyone, including the official validator.  PSI clearly never
meant
> for CV to do things like datatyping and range limiting so we should stop
> pushing on that rope and just allow CV to play its proper role in
> disambiguating the terms we use in the XSD, by use of accession numbers in
> the XSD.  
>   
I think you say this because, as things currently are, you don't plan to 
care much about the CV and frankly neither do I.  And there is a 
legitimate reason to not care about a CV if it doesn't specify enough 
semantics of the format to truly and unambiguously define the the 
terms.  The data type of a term is as much a part of its definition as 
the English description of it!  Imagine different users of the CV trying 
to pass around instances of terms using different data types for the 
different instances!  I don't think that constitutes an unambiguous 
controlled vocabulary. :)

> The thing to do now is to transfer most of the intelligence in the
> ms-mapping.xml schema file (for it is indeed a schema, albeit written in a
> nonstandard format) to the XSD file then add the proper datatyping and
range
> checking.  I was happy to see that this second schema contains the work I
> thought we were going to have to generate from the CV itself, although I
was
> also somewhat surprised to learn of the existence of such a key artifact
> this late in the discussion.  Or maybe I just missed it somehow.
>
> As I've said before we should be braver than we have been so far.  The
> refusal to put useful content in the XSD file simply for fear of being
wrong
> about it is just deplorable and doesn't serve the purposes of the
community.
> And I'm appalled at the disingenuousness of claiming a "stable schema"
when
> many key parts of the spec are in fact expressed in a schema
> (ms-mapping.xml) which is explicitly unstable.
>   
I agree wholeheartedly.  We only disagree about maintaining the fully 
specified XSD.  I think it should be autogenerated from a fixed CV and a 
stable template schema, whereas you think it should be hand rolled.  Let 
me get you to clear something up though: do you want there to be a 
single, ever-changing schema, or would you also accept a basic stable 
schema (without CV-related restrictions) which can be derived from in 
order to create the fully specified schema with the ever-changing 
restrictions?  In the latter case, we can have a schema that is stable 
but doesn't serve for anything more than syntactical validation, and 
also a schema that can be used for full semantic validation, and which 
schema that a program uses is up to the program.

> The charge has been leveled on this list that (paraphrasing here) some old
> dogs are resisting learning new tricks when it comes to the use of CV.
> That's always something to be mindful of, but after careful consideration
I
> really just don't see the advantage of a CV-centric approach, when all the
> added complexity and reinvention still leaves us well short of where
proper
> use of XSD would get us.  Fully realized XSD that references CV to define
> its terms seems like the obvious choice for a system that wants to gain
> widespread and rapid adoption.
>   
Speaking of learning new tricks, when will the vendors' raw file reading 
libraries return CV accession numbers to describe terms instead of 
ambiguous strings?  That would be nice.  But if that never happens, each 
conversion program has to maintain its own vendor-to-CV mapping.  And if 
a program wants to read both vendor-proprietary formats and the XML 
formats, your mapping problems have become nightmares.

-Matt

> - Brian
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Matthew
> Chambers
> Sent: Tuesday, October 16, 2007 8:27 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments
>
> Hi Frank, I read the Guidelines you linked to and also the paper 
> describing the Relation Ontology (http://genomebiology.com/2005/6/5/R46) 
> which is referenced from the Guidelines. The Relation Ontology does not 
> in any way suggest that reliable OBO CVs should be limited to IS_A and 
> PART_OF relationships! Rather, it does a good job of defining when IS_A 
> and PART_OF should be used and what they really mean. I think if we 
> looked closely we could find quite a few cases in the CV where the use 
> of IS_A and PART_OF is bogus according to the Relation Ontology 
> definition, especially with regard to values being indistinct from 
> categories.
>
> Therefore, I take issue with the following text from the Guidelines 
> which has no corresponding rationale and which is currently biting us in 
> the arse:
>
> 11. Relations between RU's
> As the PSI CV will be developed under the OBO umbrella [3], the 
> relations created between terms MUST ascribe to the definitions and 
> formal requirements provided in the OBO Relations Ontology (RO) paper 
> [7], as the relations 'is_a' and 'part_of'.
>
> It is not clear whether the Relation Ontology recommends or discourages 
> using OBO to typedef new relationship types into existence (my proposed 
> 'value of'), but that won't be necessary. I think we can accomplish the 
> same effect with the existing relationship, 'instance_of', which IS part 
> of the Relation Ontology. In fact, 'instance_of' is a primitive relation 
> in the Relation Ontology, whereas 'is_a' is not. Here is the Relation 
> Ontology definition for 'instance_of':
>
> p instance_of P - a primitive relation between a process instance and a 
> class which it instantiates holding independently of time
>
> That sounds like a pretty good way to distinguish between values 
> (instances) and categories (classes) to me! Further, the instance_of 
> relationship can be used in addition to the current part_of and is_a 
> relationships and it will serve to disambiguate a branch of the CV where 
> the actual category that a value belongs to is an ancestor instead of a 
> direct parent. For instance:
> MS:1000173 "MAT900XP"
> is a MS:1000493 "Finnigan MAT"
> part of MS:1000483 "Thermo Fisher Scientific"
> is a MS:1000031 "model by vendor"
> part of MS:1000463 "instrument description"
> part of MS:0000000 "MZ controlled vocabularies"
> What category does the controlled value "MAT900XP" belong to, i.e. if we 
> used cvParam method B, would it look like:
> <cvParam cvLabel="MS" categoryName="Finnigan MAT" 
> categoryAccession="MS:1000493" accession="MS:1000173" name="MAT900XP"/>
> Or would it look like:
> <cvParam cvLabel="MS" categoryName="model by vendor" 
> categoryAccession="MS:1000031" accession="MS:1000173" name="MAT900XP"/>
>
> Of course I think it should be the latter, but how would you derive that 
> from the CV? You can't, unless you add a new relationship or convention, 
> so I suggest:
> MS:1000173 "MAT900XP"
> instance of MS:1000031 "model by vendor"
> is a MS:1000493 "Finnigan MAT"
> part of MS:1000483 "Thermo Fisher Scientific"
> is a MS:1000031 "model by vendor"
> part of MS:1000463 "instrument description"
> part of MS:0000000 "MZ controlled vocabularies"
> It would also be good to get rid of the MS:1000483->MS:1000031 
> relationship at that point because "Thermo Fisher Scientific" is NOT an 
> instrument model.
>
> I have to disagree with your assertion that OBO does not allow a CV to 
> model datatypes and cardinality. I think the trailing modifiers (which 
> may have been added since you last looked at the OBO language spec) 
> would serve to model those properties quite nicely.
>
> -Matt
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Matthew C. <mat...@va...>]

Fair points, Brian.  But the XSD attributes for minOccurs, maxOccurs, 
and required can easily be added to the relevant terms in the CV via 
trailing modifiers.  Whatever is necessary to autogenerate the XSD can 
be added to the CV without over complicating it (indeed, doing so would 
only serve to further disambiguate it).  However, I'll grant that the 
more XSD functionality that the CV supports, the less difference there 
is between autogenerating the XSD from the hand-maintained CV and 
hand-maintaining the XSD itself. Half a dozen of one and 6 of another...

-Matt

Brian Pratt wrote:
> Hi Matt,
>
> I can only speculate on the history of PSI CV as a subset of OBO, my guess
> is they just wanted to keep it simple as it was never intended to provide
> the kind of granularity we need for fully automated semantic validation.
>
> So, I disagree on your point of CV being nearly there as an XSD replacement.
> It doesn't seem to have, for example, any means of saying whether an element
> or attribute is required or not, or how many times it can occur, etc etc.
> That's why that whole crazy xsd-like infrastructure that the java validator
> uses was built up (the ms-mapping.xml schema file is attached, for those who
> don't want to dig for it), and even that I have already shown to be
> inadequate.  I don't want to see us follow previous groups down that rabbit
> hole.
>   
>

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Chris T. <chr...@eb...>]

Hiya.

Just a few points:

The CV is deliberately as simple as possible -- just the 
barebones -- enough to find the term you need. In part this is a 
pragmatic outcome from the lack of person-hours, but not 
completely; it is also to avoid the complications of using the 
more complex relationships that are available (roles, for 
example, the benefit of which in this setting is unclear) and 
some of the less standard (=weird) ones.

The CV and the schema should be separable entities imho. Mostly 
this is to allow the use of other CVs/ontologies as they become 
available. If either of these products depends too much on the 
other the result of removing that other would be crippling; this 
is 'bad' bundling, basically. Because they are separate, the 
mapping file for the use of that particular CV with the schema 
is provided. This is a convenience thing for developers, 
basically, which they would be able to figure out for themselves 
given a week, and is no part of any standard. If you recall a 
while ago, the MGED 'ontology' (MO, which is really a CV, hence 
the quotes) got a good kicking in the literature for being 
directly structured around a model/schema (MAGE); there were 
many criticisms voiced there (not all valid, especially the ones 
about process, but nonetheless -- who critiques the critics eh).

On 'other' term sources, consider OBI (the successor to MO, 
inter alia), which is destined ultimately to replace the CVs 
generated by PSI and MGED with a proper ontology supporting all 
sorts of nice things. The OBI dev calls, especially the 
instrument track, would be a _great_ place to redirect this 
enthusiasm to ensure that all is well. Really the PSI CVs as 
they stand are fillers to use while that big job gets done. 
Please I implore you if you really do have major issues/needs, 
go to a few of the OBI calls. For instruments the guy to mail is 
Daniel Schober at EBI (CCed on here); incidentally he also 
handles the needs of the metabolomics community who have 
heee-uge overlaps with PSI (on MS for example) and who will most 
likely use mzML for their MS work also (I co-chair their formats 
WG and have been heavily promoting PSI products to them with an 
eye on the cross-domain integrative thing). Ah synergy.

Clearly we need the basic (and rilly rilly easy to do) syntactic 
validation provided by a fairly rich XML schema. But supporting 
the kinds of functionality discussed (which would mean the CV 
rapidly becoming a 'proper' ontology, which we don't have the 
person-hours to do right btw) is really just a nice to have at 
the moment. True semantic validation is just about feasible but 
_isn't_ practical imho. Certainly for all but the most dedicated 
coders it is a pipe dream. All that can realistically be hoped 
for at the moment is correct usage (i.e. checking in an 
application of some sort that the term is appropriate given its 
usage), for which this wattage of CV is just fine. This is what 
the MIers have done -- a java app uses hard-coded rules to check 
usage (and in that simple scenario the intelligent use of 
class-superclass stuff can bring benefits). But what they're not 
doing is something like (for MS now) I have a Voyager so why on 
earth do I have ion trap data -- sound the klaxon; this can only 
come from something of the sophistication of OBI (or a _LOT_ of 
bespoke coding), which is in a flavour of OWL (a cruise liner to 
OBO's dinghy).

Finally, again on where to draw the separating line; the more 
detail in the schema, the more labile that schema. So the schema 
should be as stable as possible (tend towards simpler). That 
schema should also remain as simple to dumb-validate as possible 
(so someone with barely the ability to run a simple validation 
check can wheel out a standard XSD tool and be done -- again 
tend towards simpler). The rest of the ~needed detail has then 
to be elsewhere in that scenario; in the CV (but that also has 
limits as discussed above) and the mapping file (the mortar 
between the bricks). The point is that although that makes work 
for those who really want to go for it on validation (to the 
point of reasoning in some sense), those developing simpler 
implementations will be able to keep things simple (e.g. person 
X uses a simple library to check for well-formedness and 
validity against the XSD, cares not-a-whole-hell-of-a-lot about 
the CV terms used as they know that most came direct from the 
instrument somehow with no user intervention, and just wants a 
coherent file with some metadata around the data to put in a 
database, which is where the CV matters most -- for retrieval). 
To truly go up a level on validation (excepting the halfway 
house of stating which terms [from a _particular_ source] can go 
where) is unrealistic and currently the benefits are minimal I 
would say (compare the effort of implementing to the benefit of 
the 0.1% of files in which you catch an error by that route, or 
the frequency of searches based on proteins/peptides, or on 
atomic terms (possibly AND/OR-ed), to that of searches truly 
exploiting the power of ontologies).

Not that I'm against powerful ontology-based queries supported 
by systems that reason like a herd of ancient g(r)eeks; it'll 
truly rock when it comes and will be key to the provision of 
good integrated (i.e. cross-domain) resources down the line. But 
the time is not now -- we need OBI first. To forcibly mature the 
MS CV to support such functionality is a waste of effort better 
spent in making OBI all it can be.

WHY can I not write a short email (that was rhetorical...)

Cheers, Chris.

~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Brian P. <bri...@in...>]

Hi Chris,

Most helpful to have some more background, thanks.  Especially in light of
the idea that the PSI CVs as they stand are fillers to use while OBI gets
done, your term "bad bundling" is appropriate.

If we go with a fully realized xsd wherein each element definition has a CV
reference, when OBI comes to fruition we just tweak the xsd.  It's a small
change to the "foo" element definition, which is already declared to have
the meaning found at "MS:12345", to declare it as also having the meaning
found at "OB:54321".  The point is that it's still a foo element so all
existing mzML files remain valid, and all those mzML parsers out there don't
have to be changed.  In the currently contemplated mzML you'd have to go
through all parsers in existence and update them to understand that <cvParam
accession="OB:54321"/> is the same as <cvParam accession="MS:12345"/>, and
of course older systems just won't understand it at all.  Bad bundling
indeed!  The xsd approach is in fact the more stable one.  

It's odd, to say the least, to have the "mortar" of this project (the
mapping file) not be part of the official standard.  It's the only artifact
we have at the moment, as far as I can see, that attempts to define the
detailed structure of an mzML file.  It's the de facto standard, and "de
facto" has been identified as a Bad Thing on this list.

So, to recap this and previous posts, the current proposal employs an
unnecessarily elaborate, nonstandard, inflexible, sneaky, and inadequate way
to couple mzML to the CV.  This is readily corrected by moving the mapping
file content to the xsd which actually forms the standard, then adding
detail so that, for example, it is clear that a scan window must have both a
low mz and high mz but dwell time is optional.

Using the CV to define terms is important, but mostly what both vendors and
users really want from a data format standard is to not be forever tweaking
readers and writers to adjust to "valid" but unexpected usages.  This is
only achieved by the standard being extremely clear on what "valid" means,
something the current proposal largely flinches from doing.  As currently
proposed, mzML feels like a big step backwards.

Brian


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Chris
Taylor
Sent: Wednesday, October 17, 2007 2:27 AM
To: Mass spectrometry standard development
Cc: Daniel Schober
Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments

Hiya.

Just a few points:

The CV is deliberately as simple as possible -- just the 
barebones -- enough to find the term you need. In part this is a 
pragmatic outcome from the lack of person-hours, but not 
completely; it is also to avoid the complications of using the 
more complex relationships that are available (roles, for 
example, the benefit of which in this setting is unclear) and 
some of the less standard (=weird) ones.

The CV and the schema should be separable entities imho. Mostly 
this is to allow the use of other CVs/ontologies as they become 
available. If either of these products depends too much on the 
other the result of removing that other would be crippling; this 
is 'bad' bundling, basically. Because they are separate, the 
mapping file for the use of that particular CV with the schema 
is provided. This is a convenience thing for developers, 
basically, which they would be able to figure out for themselves 
given a week, and is no part of any standard. If you recall a 
while ago, the MGED 'ontology' (MO, which is really a CV, hence 
the quotes) got a good kicking in the literature for being 
directly structured around a model/schema (MAGE); there were 
many criticisms voiced there (not all valid, especially the ones 
about process, but nonetheless -- who critiques the critics eh).

On 'other' term sources, consider OBI (the successor to MO, 
inter alia), which is destined ultimately to replace the CVs 
generated by PSI and MGED with a proper ontology supporting all 
sorts of nice things. The OBI dev calls, especially the 
instrument track, would be a _great_ place to redirect this 
enthusiasm to ensure that all is well. Really the PSI CVs as 
they stand are fillers to use while that big job gets done. 
Please I implore you if you really do have major issues/needs, 
go to a few of the OBI calls. For instruments the guy to mail is 
Daniel Schober at EBI (CCed on here); incidentally he also 
handles the needs of the metabolomics community who have 
heee-uge overlaps with PSI (on MS for example) and who will most 
likely use mzML for their MS work also (I co-chair their formats 
WG and have been heavily promoting PSI products to them with an 
eye on the cross-domain integrative thing). Ah synergy.

Clearly we need the basic (and rilly rilly easy to do) syntactic 
validation provided by a fairly rich XML schema. But supporting 
the kinds of functionality discussed (which would mean the CV 
rapidly becoming a 'proper' ontology, which we don't have the 
person-hours to do right btw) is really just a nice to have at 
the moment. True semantic validation is just about feasible but 
_isn't_ practical imho. Certainly for all but the most dedicated 
coders it is a pipe dream. All that can realistically be hoped 
for at the moment is correct usage (i.e. checking in an 
application of some sort that the term is appropriate given its 
usage), for which this wattage of CV is just fine. This is what 
the MIers have done -- a java app uses hard-coded rules to check 
usage (and in that simple scenario the intelligent use of 
class-superclass stuff can bring benefits). But what they're not 
doing is something like (for MS now) I have a Voyager so why on 
earth do I have ion trap data -- sound the klaxon; this can only 
come from something of the sophistication of OBI (or a _LOT_ of 
bespoke coding), which is in a flavour of OWL (a cruise liner to 
OBO's dinghy).

Finally, again on where to draw the separating line; the more 
detail in the schema, the more labile that schema. So the schema 
should be as stable as possible (tend towards simpler). That 
schema should also remain as simple to dumb-validate as possible 
(so someone with barely the ability to run a simple validation 
check can wheel out a standard XSD tool and be done -- again 
tend towards simpler). The rest of the ~needed detail has then 
to be elsewhere in that scenario; in the CV (but that also has 
limits as discussed above) and the mapping file (the mortar 
between the bricks). The point is that although that makes work 
for those who really want to go for it on validation (to the 
point of reasoning in some sense), those developing simpler 
implementations will be able to keep things simple (e.g. person 
X uses a simple library to check for well-formedness and 
validity against the XSD, cares not-a-whole-hell-of-a-lot about 
the CV terms used as they know that most came direct from the 
instrument somehow with no user intervention, and just wants a 
coherent file with some metadata around the data to put in a 
database, which is where the CV matters most -- for retrieval). 
To truly go up a level on validation (excepting the halfway 
house of stating which terms [from a _particular_ source] can go 
where) is unrealistic and currently the benefits are minimal I 
would say (compare the effort of implementing to the benefit of 
the 0.1% of files in which you catch an error by that route, or 
the frequency of searches based on proteins/peptides, or on 
atomic terms (possibly AND/OR-ed), to that of searches truly 
exploiting the power of ontologies).

Not that I'm against powerful ontology-based queries supported 
by systems that reason like a herd of ancient g(r)eeks; it'll 
truly rock when it comes and will be key to the provision of 
good integrated (i.e. cross-domain) resources down the line. But 
the time is not now -- we need OBI first. To forcibly mature the 
MS CV to support such functionality is a waste of effort better 
spent in making OBI all it can be.

WHY can I not write a short email (that was rhetorical...)

Cheers, Chris.

~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Matthew C. <mat...@va...>]

If the consensus is that the CV should be left simple like it is now, 
then I must agree with Brian.  The current schema is incapable of doing 
real validation, and the ms-mapping file is worse than a fleshed-out CV 
or XSD (it's more confusing, it takes longer to maintain, and it's 
non-standard).

I still want Brian to clarify if he wants a one-schema spec or a 
two-schema spec.  I support the latter approach, where one schema is a 
stable, syntactical version and the other inherits from the first one 
and defines all the semantic restrictions as well.  It would be up to 
implementors which schema to use for validation, and of course only the 
syntactical schema would be "stable" because the semantic restrictions 
in the second schema would change to match the CV whenever it was updated.

-Matt


Brian Pratt wrote:
> Hi Chris,
>
> Most helpful to have some more background, thanks.  Especially in light of
> the idea that the PSI CVs as they stand are fillers to use while OBI gets
> done, your term "bad bundling" is appropriate.
>
> If we go with a fully realized xsd wherein each element definition has a CV
> reference, when OBI comes to fruition we just tweak the xsd.  It's a small
> change to the "foo" element definition, which is already declared to have
> the meaning found at "MS:12345", to declare it as also having the meaning
> found at "OB:54321".  The point is that it's still a foo element so all
> existing mzML files remain valid, and all those mzML parsers out there don't
> have to be changed.  In the currently contemplated mzML you'd have to go
> through all parsers in existence and update them to understand that <cvParam
> accession="OB:54321"/> is the same as <cvParam accession="MS:12345"/>, and
> of course older systems just won't understand it at all.  Bad bundling
> indeed!  The xsd approach is in fact the more stable one.  
>
> It's odd, to say the least, to have the "mortar" of this project (the
> mapping file) not be part of the official standard.  It's the only artifact
> we have at the moment, as far as I can see, that attempts to define the
> detailed structure of an mzML file.  It's the de facto standard, and "de
> facto" has been identified as a Bad Thing on this list.
>
> So, to recap this and previous posts, the current proposal employs an
> unnecessarily elaborate, nonstandard, inflexible, sneaky, and inadequate way
> to couple mzML to the CV.  This is readily corrected by moving the mapping
> file content to the xsd which actually forms the standard, then adding
> detail so that, for example, it is clear that a scan window must have both a
> low mz and high mz but dwell time is optional.
>
> Using the CV to define terms is important, but mostly what both vendors and
> users really want from a data format standard is to not be forever tweaking
> readers and writers to adjust to "valid" but unexpected usages.  This is
> only achieved by the standard being extremely clear on what "valid" means,
> something the current proposal largely flinches from doing.  As currently
> proposed, mzML feels like a big step backwards.
>
> Brian
>
>
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Chris
> Taylor
> Sent: Wednesday, October 17, 2007 2:27 AM
> To: Mass spectrometry standard development
> Cc: Daniel Schober
> Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments
>
> Hiya.
>
> Just a few points:
>
> The CV is deliberately as simple as possible -- just the 
> barebones -- enough to find the term you need. In part this is a 
> pragmatic outcome from the lack of person-hours, but not 
> completely; it is also to avoid the complications of using the 
> more complex relationships that are available (roles, for 
> example, the benefit of which in this setting is unclear) and 
> some of the less standard (=weird) ones.
>
> The CV and the schema should be separable entities imho. Mostly 
> this is to allow the use of other CVs/ontologies as they become 
> available. If either of these products depends too much on the 
> other the result of removing that other would be crippling; this 
> is 'bad' bundling, basically. Because they are separate, the 
> mapping file for the use of that particular CV with the schema 
> is provided. This is a convenience thing for developers, 
> basically, which they would be able to figure out for themselves 
> given a week, and is no part of any standard. If you recall a 
> while ago, the MGED 'ontology' (MO, which is really a CV, hence 
> the quotes) got a good kicking in the literature for being 
> directly structured around a model/schema (MAGE); there were 
> many criticisms voiced there (not all valid, especially the ones 
> about process, but nonetheless -- who critiques the critics eh).
>
> On 'other' term sources, consider OBI (the successor to MO, 
> inter alia), which is destined ultimately to replace the CVs 
> generated by PSI and MGED with a proper ontology supporting all 
> sorts of nice things. The OBI dev calls, especially the 
> instrument track, would be a _great_ place to redirect this 
> enthusiasm to ensure that all is well. Really the PSI CVs as 
> they stand are fillers to use while that big job gets done. 
> Please I implore you if you really do have major issues/needs, 
> go to a few of the OBI calls. For instruments the guy to mail is 
> Daniel Schober at EBI (CCed on here); incidentally he also 
> handles the needs of the metabolomics community who have 
> heee-uge overlaps with PSI (on MS for example) and who will most 
> likely use mzML for their MS work also (I co-chair their formats 
> WG and have been heavily promoting PSI products to them with an 
> eye on the cross-domain integrative thing). Ah synergy.
>
> Clearly we need the basic (and rilly rilly easy to do) syntactic 
> validation provided by a fairly rich XML schema. But supporting 
> the kinds of functionality discussed (which would mean the CV 
> rapidly becoming a 'proper' ontology, which we don't have the 
> person-hours to do right btw) is really just a nice to have at 
> the moment. True semantic validation is just about feasible but 
> _isn't_ practical imho. Certainly for all but the most dedicated 
> coders it is a pipe dream. All that can realistically be hoped 
> for at the moment is correct usage (i.e. checking in an 
> application of some sort that the term is appropriate given its 
> usage), for which this wattage of CV is just fine. This is what 
> the MIers have done -- a java app uses hard-coded rules to check 
> usage (and in that simple scenario the intelligent use of 
> class-superclass stuff can bring benefits). But what they're not 
> doing is something like (for MS now) I have a Voyager so why on 
> earth do I have ion trap data -- sound the klaxon; this can only 
> come from something of the sophistication of OBI (or a _LOT_ of 
> bespoke coding), which is in a flavour of OWL (a cruise liner to 
> OBO's dinghy).
>
> Finally, again on where to draw the separating line; the more 
> detail in the schema, the more labile that schema. So the schema 
> should be as stable as possible (tend towards simpler). That 
> schema should also remain as simple to dumb-validate as possible 
> (so someone with barely the ability to run a simple validation 
> check can wheel out a standard XSD tool and be done -- again 
> tend towards simpler). The rest of the ~needed detail has then 
> to be elsewhere in that scenario; in the CV (but that also has 
> limits as discussed above) and the mapping file (the mortar 
> between the bricks). The point is that although that makes work 
> for those who really want to go for it on validation (to the 
> point of reasoning in some sense), those developing simpler 
> implementations will be able to keep things simple (e.g. person 
> X uses a simple library to check for well-formedness and 
> validity against the XSD, cares not-a-whole-hell-of-a-lot about 
> the CV terms used as they know that most came direct from the 
> instrument somehow with no user intervention, and just wants a 
> coherent file with some metadata around the data to put in a 
> database, which is where the CV matters most -- for retrieval). 
> To truly go up a level on validation (excepting the halfway 
> house of stating which terms [from a _particular_ source] can go 
> where) is unrealistic and currently the benefits are minimal I 
> would say (compare the effort of implementing to the benefit of 
> the 0.1% of files in which you catch an error by that route, or 
> the frequency of searches based on proteins/peptides, or on 
> atomic terms (possibly AND/OR-ed), to that of searches truly 
> exploiting the power of ontologies).
>
> Not that I'm against powerful ontology-based queries supported 
> by systems that reason like a herd of ancient g(r)eeks; it'll 
> truly rock when it comes and will be key to the provision of 
> good integrated (i.e. cross-domain) resources down the line. But 
> the time is not now -- we need OBI first. To forcibly mature the 
> MS CV to support such functionality is a waste of effort better 
> spent in making OBI all it can be.
>
> WHY can I not write a short email (that was rhetorical...)
>
> Cheers, Chris.
>
>   

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Chris T. <chr...@eb...>]

Hiya.

So your solution can, if I understand correctly, be 
characterised as formalising the mapping file info in an XSD 
that happens (for obvious reasons) to inherit from the main 
schema? If so, then as long as everyone likes it, I see that as 
a nice, neat, robust solution.

Funnily enough I was chatting to a fellow PSIer yesterday about 
the mapping file(s) (this is cross-WG policy stuff you see) and 
enquired as to the current nature of the thing. I think if there 
is a clamour to formalise the map then hopefully there will be a 
response. To qualify the current state of affairs though, this 
was not meant to be a formal part of the standard -- more 
something akin to documentation (it didn't exist at all at one 
point -- bridging the gap was something done in the CV, which is 
not a great method for a number of reasons).

Cheers, Chris.


Matthew Chambers wrote:
> If the consensus is that the CV should be left simple like it is now, 
> then I must agree with Brian.  The current schema is incapable of doing 
> real validation, and the ms-mapping file is worse than a fleshed-out CV 
> or XSD (it's more confusing, it takes longer to maintain, and it's 
> non-standard).
> 
> I still want Brian to clarify if he wants a one-schema spec or a 
> two-schema spec.  I support the latter approach, where one schema is a 
> stable, syntactical version and the other inherits from the first one 
> and defines all the semantic restrictions as well.  It would be up to 
> implementors which schema to use for validation, and of course only the 
> syntactical schema would be "stable" because the semantic restrictions 
> in the second schema would change to match the CV whenever it was updated.
> 
> -Matt
> 
> 
> Brian Pratt wrote:
>> Hi Chris,
>>
>> Most helpful to have some more background, thanks.  Especially in light of
>> the idea that the PSI CVs as they stand are fillers to use while OBI gets
>> done, your term "bad bundling" is appropriate.
>>
>> If we go with a fully realized xsd wherein each element definition has a CV
>> reference, when OBI comes to fruition we just tweak the xsd.  It's a small
>> change to the "foo" element definition, which is already declared to have
>> the meaning found at "MS:12345", to declare it as also having the meaning
>> found at "OB:54321".  The point is that it's still a foo element so all
>> existing mzML files remain valid, and all those mzML parsers out there don't
>> have to be changed.  In the currently contemplated mzML you'd have to go
>> through all parsers in existence and update them to understand that <cvParam
>> accession="OB:54321"/> is the same as <cvParam accession="MS:12345"/>, and
>> of course older systems just won't understand it at all.  Bad bundling
>> indeed!  The xsd approach is in fact the more stable one.  
>>
>> It's odd, to say the least, to have the "mortar" of this project (the
>> mapping file) not be part of the official standard.  It's the only artifact
>> we have at the moment, as far as I can see, that attempts to define the
>> detailed structure of an mzML file.  It's the de facto standard, and "de
>> facto" has been identified as a Bad Thing on this list.
>>
>> So, to recap this and previous posts, the current proposal employs an
>> unnecessarily elaborate, nonstandard, inflexible, sneaky, and inadequate way
>> to couple mzML to the CV.  This is readily corrected by moving the mapping
>> file content to the xsd which actually forms the standard, then adding
>> detail so that, for example, it is clear that a scan window must have both a
>> low mz and high mz but dwell time is optional.
>>
>> Using the CV to define terms is important, but mostly what both vendors and
>> users really want from a data format standard is to not be forever tweaking
>> readers and writers to adjust to "valid" but unexpected usages.  This is
>> only achieved by the standard being extremely clear on what "valid" means,
>> something the current proposal largely flinches from doing.  As currently
>> proposed, mzML feels like a big step backwards.
>>
>> Brian
>>
>>
>> -----Original Message-----
>> From: psi...@li...
>> [mailto:psi...@li...] On Behalf Of Chris
>> Taylor
>> Sent: Wednesday, October 17, 2007 2:27 AM
>> To: Mass spectrometry standard development
>> Cc: Daniel Schober
>> Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments
>>
>> Hiya.
>>
>> Just a few points:
>>
>> The CV is deliberately as simple as possible -- just the 
>> barebones -- enough to find the term you need. In part this is a 
>> pragmatic outcome from the lack of person-hours, but not 
>> completely; it is also to avoid the complications of using the 
>> more complex relationships that are available (roles, for 
>> example, the benefit of which in this setting is unclear) and 
>> some of the less standard (=weird) ones.
>>
>> The CV and the schema should be separable entities imho. Mostly 
>> this is to allow the use of other CVs/ontologies as they become 
>> available. If either of these products depends too much on the 
>> other the result of removing that other would be crippling; this 
>> is 'bad' bundling, basically. Because they are separate, the 
>> mapping file for the use of that particular CV with the schema 
>> is provided. This is a convenience thing for developers, 
>> basically, which they would be able to figure out for themselves 
>> given a week, and is no part of any standard. If you recall a 
>> while ago, the MGED 'ontology' (MO, which is really a CV, hence 
>> the quotes) got a good kicking in the literature for being 
>> directly structured around a model/schema (MAGE); there were 
>> many criticisms voiced there (not all valid, especially the ones 
>> about process, but nonetheless -- who critiques the critics eh).
>>
>> On 'other' term sources, consider OBI (the successor to MO, 
>> inter alia), which is destined ultimately to replace the CVs 
>> generated by PSI and MGED with a proper ontology supporting all 
>> sorts of nice things. The OBI dev calls, especially the 
>> instrument track, would be a _great_ place to redirect this 
>> enthusiasm to ensure that all is well. Really the PSI CVs as 
>> they stand are fillers to use while that big job gets done. 
>> Please I implore you if you really do have major issues/needs, 
>> go to a few of the OBI calls. For instruments the guy to mail is 
>> Daniel Schober at EBI (CCed on here); incidentally he also 
>> handles the needs of the metabolomics community who have 
>> heee-uge overlaps with PSI (on MS for example) and who will most 
>> likely use mzML for their MS work also (I co-chair their formats 
>> WG and have been heavily promoting PSI products to them with an 
>> eye on the cross-domain integrative thing). Ah synergy.
>>
>> Clearly we need the basic (and rilly rilly easy to do) syntactic 
>> validation provided by a fairly rich XML schema. But supporting 
>> the kinds of functionality discussed (which would mean the CV 
>> rapidly becoming a 'proper' ontology, which we don't have the 
>> person-hours to do right btw) is really just a nice to have at 
>> the moment. True semantic validation is just about feasible but 
>> _isn't_ practical imho. Certainly for all but the most dedicated 
>> coders it is a pipe dream. All that can realistically be hoped 
>> for at the moment is correct usage (i.e. checking in an 
>> application of some sort that the term is appropriate given its 
>> usage), for which this wattage of CV is just fine. This is what 
>> the MIers have done -- a java app uses hard-coded rules to check 
>> usage (and in that simple scenario the intelligent use of 
>> class-superclass stuff can bring benefits). But what they're not 
>> doing is something like (for MS now) I have a Voyager so why on 
>> earth do I have ion trap data -- sound the klaxon; this can only 
>> come from something of the sophistication of OBI (or a _LOT_ of 
>> bespoke coding), which is in a flavour of OWL (a cruise liner to 
>> OBO's dinghy).
>>
>> Finally, again on where to draw the separating line; the more 
>> detail in the schema, the more labile that schema. So the schema 
>> should be as stable as possible (tend towards simpler). That 
>> schema should also remain as simple to dumb-validate as possible 
>> (so someone with barely the ability to run a simple validation 
>> check can wheel out a standard XSD tool and be done -- again 
>> tend towards simpler). The rest of the ~needed detail has then 
>> to be elsewhere in that scenario; in the CV (but that also has 
>> limits as discussed above) and the mapping file (the mortar 
>> between the bricks). The point is that although that makes work 
>> for those who really want to go for it on validation (to the 
>> point of reasoning in some sense), those developing simpler 
>> implementations will be able to keep things simple (e.g. person 
>> X uses a simple library to check for well-formedness and 
>> validity against the XSD, cares not-a-whole-hell-of-a-lot about 
>> the CV terms used as they know that most came direct from the 
>> instrument somehow with no user intervention, and just wants a 
>> coherent file with some metadata around the data to put in a 
>> database, which is where the CV matters most -- for retrieval). 
>> To truly go up a level on validation (excepting the halfway 
>> house of stating which terms [from a _particular_ source] can go 
>> where) is unrealistic and currently the benefits are minimal I 
>> would say (compare the effort of implementing to the benefit of 
>> the 0.1% of files in which you catch an error by that route, or 
>> the frequency of searches based on proteins/peptides, or on 
>> atomic terms (possibly AND/OR-ed), to that of searches truly 
>> exploiting the power of ontologies).
>>
>> Not that I'm against powerful ontology-based queries supported 
>> by systems that reason like a herd of ancient g(r)eeks; it'll 
>> truly rock when it comes and will be key to the provision of 
>> good integrated (i.e. cross-domain) resources down the line. But 
>> the time is not now -- we need OBI first. To forcibly mature the 
>> MS CV to support such functionality is a waste of effort better 
>> spent in making OBI all it can be.
>>
>> WHY can I not write a short email (that was rhetorical...)
>>
>> Cheers, Chris.
>>
>>   
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Matthew C. <mat...@va...>]

I'm glad we're getting good participation and discussion of this issue 
now!  Chris, your characterization is a reasonable one for the 
two-schema approach I described.

To respond to qualification of the current state of affairs, I'll quote 
something you said the other day:
> Clearly we need the basic (and rilly rilly easy to do) syntactic 
> validation provided by a fairly rich XML schema.
This is not clear to me.  I do not see a clear advantage to validating 
syntax and not validating semantics.  In my experience, reading a file 
with invalid semantics is as likely to result in a parser error as 
reading a file with invalid syntax (although I admit that implementing 
error handling for semantic errors tends to be more intuitive).

> But supporting 
> the kinds of functionality discussed (which would mean the CV 
> rapidly becoming a 'proper' ontology, which we don't have the 
> person-hours to do right btw) is really just a nice to have at 
> the moment. True semantic validation is just about feasible but 
> _isn't_ practical imho.
I think you misunderstood the functionality I was suggesting to be added 
to the CV.  I was not suggesting significant logic changes in the CV, 
only a simple instance_of relationship added to every controlled value 
to link it to its parent category: "LTQ" is a controlled value, and it 
should be an 'instance_of' an "instrument model", which is a controlled 
category.  In my view, the distinction between controlled values and 
categories in the CV is crucial and it doesn't come close to making the 
CV any more of a 'proper' ontology (i.e. that machines can use to gain 
knowledge about the domain without human intervention).  It would, 
however, mean that a machine could auto-generate a schema from the CV, 
which is what I was aiming for. :)  I don't really agree with the idea 
that the PSI MS CV should be a filler which gets replaced by the OBI CV 
whenever it comes about, but if that's the consensus view then that 
would be reason enough to give up the idea of using the CV to 
auto-generate the schema.

> Certainly for all but the most dedicated 
> coders it is a pipe dream. All that can realistically be hoped 
> for at the moment is correct usage (i.e. checking in an 
> application of some sort that the term is appropriate given its 
> usage), for which this wattage of CV is just fine.This is what 
> the MIers have done -- a java app uses hard-coded rules to check 
> usage (and in that simple scenario the intelligent use of 
> class-superclass stuff can bring benefits).
It seems here you DO suggest validating semantics, but instead of doing 
it with the CV/schema it must be implemented manually by hard-coding the 
rules into a user application.  Right now, there is no way (short of 
parsing the ms-mapping file and adopting that format) to get that kind 
of validation without the hard-coding you mention.  Brian and I both 
think that a proper specification should include a way to get this kind 
of validation without hard-coding the rules, even if applications choose 
not to use it.

> But what they're not 
> doing is something like (for MS now) I have a Voyager so why on 
> earth do I have ion trap data -- sound the klaxon; this can only 
> come from something of the sophistication of OBI (or a _LOT_ of 
> bespoke coding), which is in a flavour of OWL (a cruise liner to 
> OBO's dinghy).
It's true, AFAIK, that validating (for example) the value of the "mass 
analyzer" category based on the value provided for the "instrument 
model" category is not possible with the current CV/schema.  It is not 
even possible after the extensions proposed by Brian or me.  Such 
functionality would require a much more interconnected CV (and the XSD 
schema would be so confusing to maintain that it would almost certainly 
have to be auto-generated from the CV).  I don't think anybody 
particularly expects this functionality either, so we needn't worry 
about it. :)

-Matt


Chris Taylor wrote:
> Hiya.
>
> So your solution can, if I understand correctly, be 
> characterised as formalising the mapping file info in an XSD 
> that happens (for obvious reasons) to inherit from the main 
> schema? If so, then as long as everyone likes it, I see that as 
> a nice, neat, robust solution.
>
> Funnily enough I was chatting to a fellow PSIer yesterday about 
> the mapping file(s) (this is cross-WG policy stuff you see) and 
> enquired as to the current nature of the thing. I think if there 
> is a clamour to formalise the map then hopefully there will be a 
> response. To qualify the current state of affairs though, this 
> was not meant to be a formal part of the standard -- more 
> something akin to documentation (it didn't exist at all at one 
> point -- bridging the gap was something done in the CV, which is 
> not a great method for a number of reasons).
>
> Cheers, Chris.
>
>
> Matthew Chambers wrote:
>   
>> If the consensus is that the CV should be left simple like it is now, 
>> then I must agree with Brian.  The current schema is incapable of doing 
>> real validation, and the ms-mapping file is worse than a fleshed-out CV 
>> or XSD (it's more confusing, it takes longer to maintain, and it's 
>> non-standard).
>>
>> I still want Brian to clarify if he wants a one-schema spec or a 
>> two-schema spec.  I support the latter approach, where one schema is a 
>> stable, syntactical version and the other inherits from the first one 
>> and defines all the semantic restrictions as well.  It would be up to 
>> implementors which schema to use for validation, and of course only the 
>> syntactical schema would be "stable" because the semantic restrictions 
>> in the second schema would change to match the CV whenever it was updated.
>>
>> -Matt
>>
>>     
>

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Chris T. <chr...@eb...>]

Hiya.

Matthew Chambers wrote:
> I'm glad we're getting good participation and discussion of this issue 
> now!  Chris, your characterization is a reasonable one for the 
> two-schema approach I described.
> 
> To respond to qualification of the current state of affairs, I'll quote 
> something you said the other day:
>> Clearly we need the basic (and rilly rilly easy to do) syntactic 
>> validation provided by a fairly rich XML schema.
> This is not clear to me.  I do not see a clear advantage to validating 
> syntax and not validating semantics.  In my experience, reading a file 
> with invalid semantics is as likely to result in a parser error as 
> reading a file with invalid syntax (although I admit that implementing 
> error handling for semantic errors tends to be more intuitive).

The only thing I'd say here is that there is a minimum effort 
option available for implementers who cannot or choose not to 
validate content -- i.e. the 'core' schema is there to allow 
syntactic validation only, the extended schema you suggested 
would then allow the Brians and yourselves of this world to do 
more. Seems a neat solution. That said I don't contest your 
assertion that the more thorough the validation, the more likely 
one is to catch the subtle errors as well as the gross ones.

>> But supporting 
>> the kinds of functionality discussed (which would mean the CV 
>> rapidly becoming a 'proper' ontology, which we don't have the 
>> person-hours to do right btw) is really just a nice to have at 
>> the moment. True semantic validation is just about feasible but 
>> _isn't_ practical imho.
> I think you misunderstood the functionality I was suggesting to be added 
> to the CV.  I was not suggesting significant logic changes in the CV, 
> only a simple instance_of relationship added to every controlled value 
> to link it to its parent category: "LTQ" is a controlled value, and it 
> should be an 'instance_of' an "instrument model", which is a controlled 
> category.  In my view, the distinction between controlled values and 
> categories in the CV is crucial and it doesn't come close to making the 
> CV any more of a 'proper' ontology (i.e. that machines can use to gain 
> knowledge about the domain without human intervention).  It would, 
> however, mean that a machine could auto-generate a schema from the CV, 
> which is what I was aiming for. :)  I don't really agree with the idea 
> that the PSI MS CV should be a filler which gets replaced by the OBI CV 
> whenever it comes about, but if that's the consensus view then that 
> would be reason enough to give up the idea of using the CV to 
> auto-generate the schema.

Thing here is that I heard several people assert (not on here) 
that defining terminating endpoints is storing up trouble and 
instances are therefore hostages to fortune; you'll just end up 
making a new class and deprecating the instance. Obviously there 
are clear endpoints (is there only one variant of an LTQ btw? is 
  it a child or a sib to have an LTQ-FT?) but there are also 
going to be mistakes made -- rope to hang ourselves (overly 
dramatic phrase but nonetheless).

Then there is the case where people _want_ to use a more generic 
parent (not sure how many there are in the CV tbh as it is quite 
flat iirc but still there are many ontologies in the world where 
the nodes are used as much as the leaves). A (simple-ish) 
example off the top of my head (not necessarily directly 
applicable, just for the principle) would be where someone has a 
machine not yet described and just wants to say something about it.

>> Certainly for all but the most dedicated 
>> coders it is a pipe dream. All that can realistically be hoped 
>> for at the moment is correct usage (i.e. checking in an 
>> application of some sort that the term is appropriate given its 
>> usage), for which this wattage of CV is just fine.This is what 
>> the MIers have done -- a java app uses hard-coded rules to check 
>> usage (and in that simple scenario the intelligent use of 
>> class-superclass stuff can bring benefits).
> It seems here you DO suggest validating semantics, but instead of doing 
> it with the CV/schema it must be implemented manually by hard-coding the 
> rules into a user application.  Right now, there is no way (short of 
> parsing the ms-mapping file and adopting that format) to get that kind 
> of validation without the hard-coding you mention.  Brian and I both 
> think that a proper specification should include a way to get this kind 
> of validation without hard-coding the rules, even if applications choose 
> not to use it.

I think in the absence of an ontology to afford this sort of 
functionality (and with one expected), hard coding is not an 
awful solution (the workload for your suggestion wouldn't be 
orders of magnitude different would it, bearing in mind this is 
a temporary state of affairs so not subject to years of 
maintenance?). The MI group certainly went this route straight 
off the bat...

At the risk of becoming dull, I'd restate that this is why I 
like the separable schemata you suggested, as we get the best of 
both worlds no?

>> But what they're not 
>> doing is something like (for MS now) I have a Voyager so why on 
>> earth do I have ion trap data -- sound the klaxon; this can only 
>> come from something of the sophistication of OBI (or a _LOT_ of 
>> bespoke coding), which is in a flavour of OWL (a cruise liner to 
>> OBO's dinghy).
> It's true, AFAIK, that validating (for example) the value of the "mass 
> analyzer" category based on the value provided for the "instrument 
> model" category is not possible with the current CV/schema.  It is not 
> even possible after the extensions proposed by Brian or me.  Such 
> functionality would require a much more interconnected CV (and the XSD 
> schema would be so confusing to maintain that it would almost certainly 
> have to be auto-generated from the CV).  I don't think anybody 
> particularly expects this functionality either, so we needn't worry 
> about it. :)

Well I'm kind of hoping we will ultimately be able to get this 
from OBI, which is being built in a very thorough and extensible 
(in terms of the richness of relations between classes) manner.

Cheers, Chris.


> -Matt
> 
> 
> Chris Taylor wrote:
>> Hiya.
>>
>> So your solution can, if I understand correctly, be 
>> characterised as formalising the mapping file info in an XSD 
>> that happens (for obvious reasons) to inherit from the main 
>> schema? If so, then as long as everyone likes it, I see that as 
>> a nice, neat, robust solution.
>>
>> Funnily enough I was chatting to a fellow PSIer yesterday about 
>> the mapping file(s) (this is cross-WG policy stuff you see) and 
>> enquired as to the current nature of the thing. I think if there 
>> is a clamour to formalise the map then hopefully there will be a 
>> response. To qualify the current state of affairs though, this 
>> was not meant to be a formal part of the standard -- more 
>> something akin to documentation (it didn't exist at all at one 
>> point -- bridging the gap was something done in the CV, which is 
>> not a great method for a number of reasons).
>>
>> Cheers, Chris.
>>
>>
>> Matthew Chambers wrote:
>>   
>>> If the consensus is that the CV should be left simple like it is now, 
>>> then I must agree with Brian.  The current schema is incapable of doing 
>>> real validation, and the ms-mapping file is worse than a fleshed-out CV 
>>> or XSD (it's more confusing, it takes longer to maintain, and it's 
>>> non-standard).
>>>
>>> I still want Brian to clarify if he wants a one-schema spec or a 
>>> two-schema spec.  I support the latter approach, where one schema is a 
>>> stable, syntactical version and the other inherits from the first one 
>>> and defines all the semantic restrictions as well.  It would be up to 
>>> implementors which schema to use for validation, and of course only the 
>>> syntactical schema would be "stable" because the semantic restrictions 
>>> in the second schema would change to match the CV whenever it was updated.
>>>
>>> -Matt
>>>
>>>     
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Brian P. <bri...@in...>]

Hey All,

It's true that in practice most day to day consumers of mzML files will not
bother with validation.  The value of the detailed validation capability of
a fully realized xsd is largely seen during the *development* of the readers
and writers, not in their day to day operation.  (Of course it's also seen
in their day to day operation because they work properly, having been
written properly.)

Ideally we would test every conceivable combination of writer and reader,
but since we can't expect to do that (we can't start until everybody
finishes, and imagine the back and forth!) we instead have to make it
possible for the writers to readily check their work in syntactic and
semantic detail, and for the readers to not have to make a lot of guesses
about what they're likely to see.  The fully realized xsd helps on both
counts - ready validation for the writers, and a clear spec for the readers.
It also gives the possibility of automatically generated code as a jumping
off point for the programmers of both readers and writers, which can reduce
defect rates.

Matt asks if I envision one schema or two.  We need to go out the gate with
one schema that expresses everything we know we want to say today (includes
any intelligence in the current mapping file, plus more detail).  The
anticipated need for vendors to extend the schema independent of the
official schema release cycle (our "stability" goal) is then handled by
schemas the vendors create, which inherit from and extend the standard
schema.   The proposed idea of a second schema from the get-go just to layer
on the CV mappings is unwarranted complexity.  These belong in the core xsd
as (optional) attributes of the various elements, when that one-time OBI
event comes we'll just update the core xsd to add attributes that indicate
relationships from elements to the new CV as well.  It's far enough away not
to threaten the appearance of stability in the spec, and in any case won't
break backward compatibility.

The important point about hard coding rules vs expressing relationships and
constraints in the xsd is one of economies of scale.  It was asked whether
hard coding was any more work than getting the schema right: the answer is
yes, as it has to be done repeatedly, once per validating reader
implementation (not everyone uses Java, or is even allowed to use open
source code in their product).  Why make everyone reinvent the wheel and
probably get it wrong, when we have a nice, standard, language independent
means of expressing those constraints? 

It just comes down to KISS:  Keep It Simple, Stupid! (not calling names
here, that's just the acronym as I learned it).  We're here to deal with MS
raw data transfer, not to design new data format description languages.
More than once on this list I've seen snarky asides about coders who aren't
up to muscling through these proposed convolutions, but a truly competent
coder is professionally lazy (managers prefer "elegant").  Moreover, a
standards effort is supposed to consolidate the efforts of the community so
its individuals can get on with their real work - we shouldn't be blithely
proposing things that create more individual work than they absolutely need
to.

- Brian

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Chris
Taylor
Sent: Thursday, October 18, 2007 9:37 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments

Hiya.

Matthew Chambers wrote:
> I'm glad we're getting good participation and discussion of this issue 
> now!  Chris, your characterization is a reasonable one for the 
> two-schema approach I described.
> 
> To respond to qualification of the current state of affairs, I'll quote 
> something you said the other day:
>> Clearly we need the basic (and rilly rilly easy to do) syntactic 
>> validation provided by a fairly rich XML schema.
> This is not clear to me.  I do not see a clear advantage to validating 
> syntax and not validating semantics.  In my experience, reading a file 
> with invalid semantics is as likely to result in a parser error as 
> reading a file with invalid syntax (although I admit that implementing 
> error handling for semantic errors tends to be more intuitive).

The only thing I'd say here is that there is a minimum effort 
option available for implementers who cannot or choose not to 
validate content -- i.e. the 'core' schema is there to allow 
syntactic validation only, the extended schema you suggested 
would then allow the Brians and yourselves of this world to do 
more. Seems a neat solution. That said I don't contest your 
assertion that the more thorough the validation, the more likely 
one is to catch the subtle errors as well as the gross ones.

>> But supporting 
>> the kinds of functionality discussed (which would mean the CV 
>> rapidly becoming a 'proper' ontology, which we don't have the 
>> person-hours to do right btw) is really just a nice to have at 
>> the moment. True semantic validation is just about feasible but 
>> _isn't_ practical imho.
> I think you misunderstood the functionality I was suggesting to be added 
> to the CV.  I was not suggesting significant logic changes in the CV, 
> only a simple instance_of relationship added to every controlled value 
> to link it to its parent category: "LTQ" is a controlled value, and it 
> should be an 'instance_of' an "instrument model", which is a controlled 
> category.  In my view, the distinction between controlled values and 
> categories in the CV is crucial and it doesn't come close to making the 
> CV any more of a 'proper' ontology (i.e. that machines can use to gain 
> knowledge about the domain without human intervention).  It would, 
> however, mean that a machine could auto-generate a schema from the CV, 
> which is what I was aiming for. :)  I don't really agree with the idea 
> that the PSI MS CV should be a filler which gets replaced by the OBI CV 
> whenever it comes about, but if that's the consensus view then that 
> would be reason enough to give up the idea of using the CV to 
> auto-generate the schema.

Thing here is that I heard several people assert (not on here) 
that defining terminating endpoints is storing up trouble and 
instances are therefore hostages to fortune; you'll just end up 
making a new class and deprecating the instance. Obviously there 
are clear endpoints (is there only one variant of an LTQ btw? is 
  it a child or a sib to have an LTQ-FT?) but there are also 
going to be mistakes made -- rope to hang ourselves (overly 
dramatic phrase but nonetheless).

Then there is the case where people _want_ to use a more generic 
parent (not sure how many there are in the CV tbh as it is quite 
flat iirc but still there are many ontologies in the world where 
the nodes are used as much as the leaves). A (simple-ish) 
example off the top of my head (not necessarily directly 
applicable, just for the principle) would be where someone has a 
machine not yet described and just wants to say something about it.

>> Certainly for all but the most dedicated 
>> coders it is a pipe dream. All that can realistically be hoped 
>> for at the moment is correct usage (i.e. checking in an 
>> application of some sort that the term is appropriate given its 
>> usage), for which this wattage of CV is just fine.This is what 
>> the MIers have done -- a java app uses hard-coded rules to check 
>> usage (and in that simple scenario the intelligent use of 
>> class-superclass stuff can bring benefits).
> It seems here you DO suggest validating semantics, but instead of doing 
> it with the CV/schema it must be implemented manually by hard-coding the 
> rules into a user application.  Right now, there is no way (short of 
> parsing the ms-mapping file and adopting that format) to get that kind 
> of validation without the hard-coding you mention.  Brian and I both 
> think that a proper specification should include a way to get this kind 
> of validation without hard-coding the rules, even if applications choose 
> not to use it.

I think in the absence of an ontology to afford this sort of 
functionality (and with one expected), hard coding is not an 
awful solution (the workload for your suggestion wouldn't be 
orders of magnitude different would it, bearing in mind this is 
a temporary state of affairs so not subject to years of 
maintenance?). The MI group certainly went this route straight 
off the bat...

At the risk of becoming dull, I'd restate that this is why I 
like the separable schemata you suggested, as we get the best of 
both worlds no?

>> But what they're not 
>> doing is something like (for MS now) I have a Voyager so why on 
>> earth do I have ion trap data -- sound the klaxon; this can only 
>> come from something of the sophistication of OBI (or a _LOT_ of 
>> bespoke coding), which is in a flavour of OWL (a cruise liner to 
>> OBO's dinghy).
> It's true, AFAIK, that validating (for example) the value of the "mass 
> analyzer" category based on the value provided for the "instrument 
> model" category is not possible with the current CV/schema.  It is not 
> even possible after the extensions proposed by Brian or me.  Such 
> functionality would require a much more interconnected CV (and the XSD 
> schema would be so confusing to maintain that it would almost certainly 
> have to be auto-generated from the CV).  I don't think anybody 
> particularly expects this functionality either, so we needn't worry 
> about it. :)

Well I'm kind of hoping we will ultimately be able to get this 
from OBI, which is being built in a very thorough and extensible 
(in terms of the richness of relations between classes) manner.

Cheers, Chris.


> -Matt
> 
> 
> Chris Taylor wrote:
>> Hiya.
>>
>> So your solution can, if I understand correctly, be 
>> characterised as formalising the mapping file info in an XSD 
>> that happens (for obvious reasons) to inherit from the main 
>> schema? If so, then as long as everyone likes it, I see that as 
>> a nice, neat, robust solution.
>>
>> Funnily enough I was chatting to a fellow PSIer yesterday about 
>> the mapping file(s) (this is cross-WG policy stuff you see) and 
>> enquired as to the current nature of the thing. I think if there 
>> is a clamour to formalise the map then hopefully there will be a 
>> response. To qualify the current state of affairs though, this 
>> was not meant to be a formal part of the standard -- more 
>> something akin to documentation (it didn't exist at all at one 
>> point -- bridging the gap was something done in the CV, which is 
>> not a great method for a number of reasons).
>>
>> Cheers, Chris.
>>
>>
>> Matthew Chambers wrote:
>>   
>>> If the consensus is that the CV should be left simple like it is now, 
>>> then I must agree with Brian.  The current schema is incapable of doing 
>>> real validation, and the ms-mapping file is worse than a fleshed-out CV 
>>> or XSD (it's more confusing, it takes longer to maintain, and it's 
>>> non-standard).
>>>
>>> I still want Brian to clarify if he wants a one-schema spec or a 
>>> two-schema spec.  I support the latter approach, where one schema is a 
>>> stable, syntactical version and the other inherits from the first one 
>>> and defines all the semantic restrictions as well.  It would be up to 
>>> implementors which schema to use for validation, and of course only the 
>>> syntactical schema would be "stable" because the semantic restrictions 
>>> in the second schema would change to match the CV whenever it was
updated.
>>>
>>> -Matt
>>>
>>>     
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Chris T. <chr...@eb...>]

But with namespaces and all surely what is in physical reality 
two schemata can be operated as one anyway? So does it really 
make a huge difference? I'm actually asking rather than being 
rhetorical...

Despite all the arguments I perceive 'proper' standards as being 
completely static apart from through (infrequent) versions (XML 
Schema itself, for example). Maybe I have a biased notion of 
standards but should we not be making a core thing that is 
static and keeping the volatile stuff in the second one?

And I do still see a tie to one CV as bundling for no reason -- 
it's a short term gain (a year or so, which means that just at 
the point that we have good implementations, it'll be change-o 
time).

I dunno. I'm as I said just throwing in opinions I've heard 
elsewhere mostly. On balance it really comes down to pragmatism 
versus kind/strength of assurance (to third parties). I'm gonna 
pull my head in now anyway  :)

Cheers, Chris.


Brian Pratt wrote:
> Hey All,
> 
> It's true that in practice most day to day consumers of mzML files will not
> bother with validation.  The value of the detailed validation capability of
> a fully realized xsd is largely seen during the *development* of the readers
> and writers, not in their day to day operation.  (Of course it's also seen
> in their day to day operation because they work properly, having been
> written properly.)
> 
> Ideally we would test every conceivable combination of writer and reader,
> but since we can't expect to do that (we can't start until everybody
> finishes, and imagine the back and forth!) we instead have to make it
> possible for the writers to readily check their work in syntactic and
> semantic detail, and for the readers to not have to make a lot of guesses
> about what they're likely to see.  The fully realized xsd helps on both
> counts - ready validation for the writers, and a clear spec for the readers.
> It also gives the possibility of automatically generated code as a jumping
> off point for the programmers of both readers and writers, which can reduce
> defect rates.
> 
> Matt asks if I envision one schema or two.  We need to go out the gate with
> one schema that expresses everything we know we want to say today (includes
> any intelligence in the current mapping file, plus more detail).  The
> anticipated need for vendors to extend the schema independent of the
> official schema release cycle (our "stability" goal) is then handled by
> schemas the vendors create, which inherit from and extend the standard
> schema.   The proposed idea of a second schema from the get-go just to layer
> on the CV mappings is unwarranted complexity.  These belong in the core xsd
> as (optional) attributes of the various elements, when that one-time OBI
> event comes we'll just update the core xsd to add attributes that indicate
> relationships from elements to the new CV as well.  It's far enough away not
> to threaten the appearance of stability in the spec, and in any case won't
> break backward compatibility.
> 
> The important point about hard coding rules vs expressing relationships and
> constraints in the xsd is one of economies of scale.  It was asked whether
> hard coding was any more work than getting the schema right: the answer is
> yes, as it has to be done repeatedly, once per validating reader
> implementation (not everyone uses Java, or is even allowed to use open
> source code in their product).  Why make everyone reinvent the wheel and
> probably get it wrong, when we have a nice, standard, language independent
> means of expressing those constraints? 
> 
> It just comes down to KISS:  Keep It Simple, Stupid! (not calling names
> here, that's just the acronym as I learned it).  We're here to deal with MS
> raw data transfer, not to design new data format description languages.
> More than once on this list I've seen snarky asides about coders who aren't
> up to muscling through these proposed convolutions, but a truly competent
> coder is professionally lazy (managers prefer "elegant").  Moreover, a
> standards effort is supposed to consolidate the efforts of the community so
> its individuals can get on with their real work - we shouldn't be blithely
> proposing things that create more individual work than they absolutely need
> to.
> 
> - Brian
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Chris
> Taylor
> Sent: Thursday, October 18, 2007 9:37 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments
> 
> Hiya.
> 
> Matthew Chambers wrote:
>> I'm glad we're getting good participation and discussion of this issue 
>> now!  Chris, your characterization is a reasonable one for the 
>> two-schema approach I described.
>>
>> To respond to qualification of the current state of affairs, I'll quote 
>> something you said the other day:
>>> Clearly we need the basic (and rilly rilly easy to do) syntactic 
>>> validation provided by a fairly rich XML schema.
>> This is not clear to me.  I do not see a clear advantage to validating 
>> syntax and not validating semantics.  In my experience, reading a file 
>> with invalid semantics is as likely to result in a parser error as 
>> reading a file with invalid syntax (although I admit that implementing 
>> error handling for semantic errors tends to be more intuitive).
> 
> The only thing I'd say here is that there is a minimum effort 
> option available for implementers who cannot or choose not to 
> validate content -- i.e. the 'core' schema is there to allow 
> syntactic validation only, the extended schema you suggested 
> would then allow the Brians and yourselves of this world to do 
> more. Seems a neat solution. That said I don't contest your 
> assertion that the more thorough the validation, the more likely 
> one is to catch the subtle errors as well as the gross ones.
> 
>>> But supporting 
>>> the kinds of functionality discussed (which would mean the CV 
>>> rapidly becoming a 'proper' ontology, which we don't have the 
>>> person-hours to do right btw) is really just a nice to have at 
>>> the moment. True semantic validation is just about feasible but 
>>> _isn't_ practical imho.
>> I think you misunderstood the functionality I was suggesting to be added 
>> to the CV.  I was not suggesting significant logic changes in the CV, 
>> only a simple instance_of relationship added to every controlled value 
>> to link it to its parent category: "LTQ" is a controlled value, and it 
>> should be an 'instance_of' an "instrument model", which is a controlled 
>> category.  In my view, the distinction between controlled values and 
>> categories in the CV is crucial and it doesn't come close to making the 
>> CV any more of a 'proper' ontology (i.e. that machines can use to gain 
>> knowledge about the domain without human intervention).  It would, 
>> however, mean that a machine could auto-generate a schema from the CV, 
>> which is what I was aiming for. :)  I don't really agree with the idea 
>> that the PSI MS CV should be a filler which gets replaced by the OBI CV 
>> whenever it comes about, but if that's the consensus view then that 
>> would be reason enough to give up the idea of using the CV to 
>> auto-generate the schema.
> 
> Thing here is that I heard several people assert (not on here) 
> that defining terminating endpoints is storing up trouble and 
> instances are therefore hostages to fortune; you'll just end up 
> making a new class and deprecating the instance. Obviously there 
> are clear endpoints (is there only one variant of an LTQ btw? is 
>   it a child or a sib to have an LTQ-FT?) but there are also 
> going to be mistakes made -- rope to hang ourselves (overly 
> dramatic phrase but nonetheless).
> 
> Then there is the case where people _want_ to use a more generic 
> parent (not sure how many there are in the CV tbh as it is quite 
> flat iirc but still there are many ontologies in the world where 
> the nodes are used as much as the leaves). A (simple-ish) 
> example off the top of my head (not necessarily directly 
> applicable, just for the principle) would be where someone has a 
> machine not yet described and just wants to say something about it.
> 
>>> Certainly for all but the most dedicated 
>>> coders it is a pipe dream. All that can realistically be hoped 
>>> for at the moment is correct usage (i.e. checking in an 
>>> application of some sort that the term is appropriate given its 
>>> usage), for which this wattage of CV is just fine.This is what 
>>> the MIers have done -- a java app uses hard-coded rules to check 
>>> usage (and in that simple scenario the intelligent use of 
>>> class-superclass stuff can bring benefits).
>> It seems here you DO suggest validating semantics, but instead of doing 
>> it with the CV/schema it must be implemented manually by hard-coding the 
>> rules into a user application.  Right now, there is no way (short of 
>> parsing the ms-mapping file and adopting that format) to get that kind 
>> of validation without the hard-coding you mention.  Brian and I both 
>> think that a proper specification should include a way to get this kind 
>> of validation without hard-coding the rules, even if applications choose 
>> not to use it.
> 
> I think in the absence of an ontology to afford this sort of 
> functionality (and with one expected), hard coding is not an 
> awful solution (the workload for your suggestion wouldn't be 
> orders of magnitude different would it, bearing in mind this is 
> a temporary state of affairs so not subject to years of 
> maintenance?). The MI group certainly went this route straight 
> off the bat...
> 
> At the risk of becoming dull, I'd restate that this is why I 
> like the separable schemata you suggested, as we get the best of 
> both worlds no?
> 
>>> But what they're not 
>>> doing is something like (for MS now) I have a Voyager so why on 
>>> earth do I have ion trap data -- sound the klaxon; this can only 
>>> come from something of the sophistication of OBI (or a _LOT_ of 
>>> bespoke coding), which is in a flavour of OWL (a cruise liner to 
>>> OBO's dinghy).
>> It's true, AFAIK, that validating (for example) the value of the "mass 
>> analyzer" category based on the value provided for the "instrument 
>> model" category is not possible with the current CV/schema.  It is not 
>> even possible after the extensions proposed by Brian or me.  Such 
>> functionality would require a much more interconnected CV (and the XSD 
>> schema would be so confusing to maintain that it would almost certainly 
>> have to be auto-generated from the CV).  I don't think anybody 
>> particularly expects this functionality either, so we needn't worry 
>> about it. :)
> 
> Well I'm kind of hoping we will ultimately be able to get this 
> from OBI, which is being built in a very thorough and extensible 
> (in terms of the richness of relations between classes) manner.
> 
> Cheers, Chris.
> 
> 
>> -Matt
>>
>>
>> Chris Taylor wrote:
>>> Hiya.
>>>
>>> So your solution can, if I understand correctly, be 
>>> characterised as formalising the mapping file info in an XSD 
>>> that happens (for obvious reasons) to inherit from the main 
>>> schema? If so, then as long as everyone likes it, I see that as 
>>> a nice, neat, robust solution.
>>>
>>> Funnily enough I was chatting to a fellow PSIer yesterday about 
>>> the mapping file(s) (this is cross-WG policy stuff you see) and 
>>> enquired as to the current nature of the thing. I think if there 
>>> is a clamour to formalise the map then hopefully there will be a 
>>> response. To qualify the current state of affairs though, this 
>>> was not meant to be a formal part of the standard -- more 
>>> something akin to documentation (it didn't exist at all at one 
>>> point -- bridging the gap was something done in the CV, which is 
>>> not a great method for a number of reasons).
>>>
>>> Cheers, Chris.
>>>
>>>
>>> Matthew Chambers wrote:
>>>   
>>>> If the consensus is that the CV should be left simple like it is now, 
>>>> then I must agree with Brian.  The current schema is incapable of doing 
>>>> real validation, and the ms-mapping file is worse than a fleshed-out CV 
>>>> or XSD (it's more confusing, it takes longer to maintain, and it's 
>>>> non-standard).
>>>>
>>>> I still want Brian to clarify if he wants a one-schema spec or a 
>>>> two-schema spec.  I support the latter approach, where one schema is a 
>>>> stable, syntactical version and the other inherits from the first one 
>>>> and defines all the semantic restrictions as well.  It would be up to 
>>>> implementors which schema to use for validation, and of course only the 
>>>> syntactical schema would be "stable" because the semantic restrictions 
>>>> in the second schema would change to match the CV whenever it was
> updated.
>>>> -Matt
>>>>
>>>>     
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[Brian P. <bri...@in...>]

Hi Chris,

Quite right, with namespaces and all a combination of related schema
operates as one, it's just a bit more complex to deal with mentally.  I just
don't want any unwarranted complexity.

If there are aspects of MS raw data specification that are known to be
volatile then moving them to a child schema might make sense, but so far I'm
not sure what these are.  I do know I see things in the mapping file that
are clearly not volatile, like scan window.  This picture will no doubt
become clearer as things get moved into the xsd.

I don't think anyone means to tie the xsd to a single CV, it's just that at
the moment there's only one CV we're aware of that's useful in this context.
The idea is that each element points at a CV entry, which doesn't have to be
in the MS CV necessarily.  When OBI is ready, we can update the xsd to point
there as well.  It won't destabilize any systems already using mzML, so I
think it still meets your test of a proper standard.  Third parties aren't
really so interested in the assurance of a schema with an unchanging version
number as they are in the assurance of not having to revisit their code
every other week.  

It's extremely useful to hear what you're heard elsewhere, thanks for
sticking your neck out!

Brian

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Chris
Taylor
Sent: Thursday, October 18, 2007 12:19 PM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments

But with namespaces and all surely what is in physical reality 
two schemata can be operated as one anyway? So does it really 
make a huge difference? I'm actually asking rather than being 
rhetorical...

Despite all the arguments I perceive 'proper' standards as being 
completely static apart from through (infrequent) versions (XML 
Schema itself, for example). Maybe I have a biased notion of 
standards but should we not be making a core thing that is 
static and keeping the volatile stuff in the second one?

And I do still see a tie to one CV as bundling for no reason -- 
it's a short term gain (a year or so, which means that just at 
the point that we have good implementations, it'll be change-o 
time).

I dunno. I'm as I said just throwing in opinions I've heard 
elsewhere mostly. On balance it really comes down to pragmatism 
versus kind/strength of assurance (to third parties). I'm gonna 
pull my head in now anyway  :)

Cheers, Chris.


Brian Pratt wrote:
> Hey All,
> 
> It's true that in practice most day to day consumers of mzML files will
not
> bother with validation.  The value of the detailed validation capability
of
> a fully realized xsd is largely seen during the *development* of the
readers
> and writers, not in their day to day operation.  (Of course it's also seen
> in their day to day operation because they work properly, having been
> written properly.)
> 
> Ideally we would test every conceivable combination of writer and reader,
> but since we can't expect to do that (we can't start until everybody
> finishes, and imagine the back and forth!) we instead have to make it
> possible for the writers to readily check their work in syntactic and
> semantic detail, and for the readers to not have to make a lot of guesses
> about what they're likely to see.  The fully realized xsd helps on both
> counts - ready validation for the writers, and a clear spec for the
readers.
> It also gives the possibility of automatically generated code as a jumping
> off point for the programmers of both readers and writers, which can
reduce
> defect rates.
> 
> Matt asks if I envision one schema or two.  We need to go out the gate
with
> one schema that expresses everything we know we want to say today
(includes
> any intelligence in the current mapping file, plus more detail).  The
> anticipated need for vendors to extend the schema independent of the
> official schema release cycle (our "stability" goal) is then handled by
> schemas the vendors create, which inherit from and extend the standard
> schema.   The proposed idea of a second schema from the get-go just to
layer
> on the CV mappings is unwarranted complexity.  These belong in the core
xsd
> as (optional) attributes of the various elements, when that one-time OBI
> event comes we'll just update the core xsd to add attributes that indicate
> relationships from elements to the new CV as well.  It's far enough away
not
> to threaten the appearance of stability in the spec, and in any case won't
> break backward compatibility.
> 
> The important point about hard coding rules vs expressing relationships
and
> constraints in the xsd is one of economies of scale.  It was asked whether
> hard coding was any more work than getting the schema right: the answer is
> yes, as it has to be done repeatedly, once per validating reader
> implementation (not everyone uses Java, or is even allowed to use open
> source code in their product).  Why make everyone reinvent the wheel and
> probably get it wrong, when we have a nice, standard, language independent
> means of expressing those constraints? 
> 
> It just comes down to KISS:  Keep It Simple, Stupid! (not calling names
> here, that's just the acronym as I learned it).  We're here to deal with
MS
> raw data transfer, not to design new data format description languages.
> More than once on this list I've seen snarky asides about coders who
aren't
> up to muscling through these proposed convolutions, but a truly competent
> coder is professionally lazy (managers prefer "elegant").  Moreover, a
> standards effort is supposed to consolidate the efforts of the community
so
> its individuals can get on with their real work - we shouldn't be blithely
> proposing things that create more individual work than they absolutely
need
> to.
> 
> - Brian
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Chris
> Taylor
> Sent: Thursday, October 18, 2007 9:37 AM
> To: Mass spectrometry standard development
> Subject: Re: [Psidev-ms-dev] mzML 0.99.0 comments
> 
> Hiya.
> 
> Matthew Chambers wrote:
>> I'm glad we're getting good participation and discussion of this issue 
>> now!  Chris, your characterization is a reasonable one for the 
>> two-schema approach I described.
>>
>> To respond to qualification of the current state of affairs, I'll quote 
>> something you said the other day:
>>> Clearly we need the basic (and rilly rilly easy to do) syntactic 
>>> validation provided by a fairly rich XML schema.
>> This is not clear to me.  I do not see a clear advantage to validating 
>> syntax and not validating semantics.  In my experience, reading a file 
>> with invalid semantics is as likely to result in a parser error as 
>> reading a file with invalid syntax (although I admit that implementing 
>> error handling for semantic errors tends to be more intuitive).
> 
> The only thing I'd say here is that there is a minimum effort 
> option available for implementers who cannot or choose not to 
> validate content -- i.e. the 'core' schema is there to allow 
> syntactic validation only, the extended schema you suggested 
> would then allow the Brians and yourselves of this world to do 
> more. Seems a neat solution. That said I don't contest your 
> assertion that the more thorough the validation, the more likely 
> one is to catch the subtle errors as well as the gross ones.
> 
>>> But supporting 
>>> the kinds of functionality discussed (which would mean the CV 
>>> rapidly becoming a 'proper' ontology, which we don't have the 
>>> person-hours to do right btw) is really just a nice to have at 
>>> the moment. True semantic validation is just about feasible but 
>>> _isn't_ practical imho.
>> I think you misunderstood the functionality I was suggesting to be added 
>> to the CV.  I was not suggesting significant logic changes in the CV, 
>> only a simple instance_of relationship added to every controlled value 
>> to link it to its parent category: "LTQ" is a controlled value, and it 
>> should be an 'instance_of' an "instrument model", which is a controlled 
>> category.  In my view, the distinction between controlled values and 
>> categories in the CV is crucial and it doesn't come close to making the 
>> CV any more of a 'proper' ontology (i.e. that machines can use to gain 
>> knowledge about the domain without human intervention).  It would, 
>> however, mean that a machine could auto-generate a schema from the CV, 
>> which is what I was aiming for. :)  I don't really agree with the idea 
>> that the PSI MS CV should be a filler which gets replaced by the OBI CV 
>> whenever it comes about, but if that's the consensus view then that 
>> would be reason enough to give up the idea of using the CV to 
>> auto-generate the schema.
> 
> Thing here is that I heard several people assert (not on here) 
> that defining terminating endpoints is storing up trouble and 
> instances are therefore hostages to fortune; you'll just end up 
> making a new class and deprecating the instance. Obviously there 
> are clear endpoints (is there only one variant of an LTQ btw? is 
>   it a child or a sib to have an LTQ-FT?) but there are also 
> going to be mistakes made -- rope to hang ourselves (overly 
> dramatic phrase but nonetheless).
> 
> Then there is the case where people _want_ to use a more generic 
> parent (not sure how many there are in the CV tbh as it is quite 
> flat iirc but still there are many ontologies in the world where 
> the nodes are used as much as the leaves). A (simple-ish) 
> example off the top of my head (not necessarily directly 
> applicable, just for the principle) would be where someone has a 
> machine not yet described and just wants to say something about it.
> 
>>> Certainly for all but the most dedicated 
>>> coders it is a pipe dream. All that can realistically be hoped 
>>> for at the moment is correct usage (i.e. checking in an 
>>> application of some sort that the term is appropriate given its 
>>> usage), for which this wattage of CV is just fine.This is what 
>>> the MIers have done -- a java app uses hard-coded rules to check 
>>> usage (and in that simple scenario the intelligent use of 
>>> class-superclass stuff can bring benefits).
>> It seems here you DO suggest validating semantics, but instead of doing 
>> it with the CV/schema it must be implemented manually by hard-coding the 
>> rules into a user application.  Right now, there is no way (short of 
>> parsing the ms-mapping file and adopting that format) to get that kind 
>> of validation without the hard-coding you mention.  Brian and I both 
>> think that a proper specification should include a way to get this kind 
>> of validation without hard-coding the rules, even if applications choose 
>> not to use it.
> 
> I think in the absence of an ontology to afford this sort of 
> functionality (and with one expected), hard coding is not an 
> awful solution (the workload for your suggestion wouldn't be 
> orders of magnitude different would it, bearing in mind this is 
> a temporary state of affairs so not subject to years of 
> maintenance?). The MI group certainly went this route straight 
> off the bat...
> 
> At the risk of becoming dull, I'd restate that this is why I 
> like the separable schemata you suggested, as we get the best of 
> both worlds no?
> 
>>> But what they're not 
>>> doing is something like (for MS now) I have a Voyager so why on 
>>> earth do I have ion trap data -- sound the klaxon; this can only 
>>> come from something of the sophistication of OBI (or a _LOT_ of 
>>> bespoke coding), which is in a flavour of OWL (a cruise liner to 
>>> OBO's dinghy).
>> It's true, AFAIK, that validating (for example) the value of the "mass 
>> analyzer" category based on the value provided for the "instrument 
>> model" category is not possible with the current CV/schema.  It is not 
>> even possible after the extensions proposed by Brian or me.  Such 
>> functionality would require a much more interconnected CV (and the XSD 
>> schema would be so confusing to maintain that it would almost certainly 
>> have to be auto-generated from the CV).  I don't think anybody 
>> particularly expects this functionality either, so we needn't worry 
>> about it. :)
> 
> Well I'm kind of hoping we will ultimately be able to get this 
> from OBI, which is being built in a very thorough and extensible 
> (in terms of the richness of relations between classes) manner.
> 
> Cheers, Chris.
> 
> 
>> -Matt
>>
>>
>> Chris Taylor wrote:
>>> Hiya.
>>>
>>> So your solution can, if I understand correctly, be 
>>> characterised as formalising the mapping file info in an XSD 
>>> that happens (for obvious reasons) to inherit from the main 
>>> schema? If so, then as long as everyone likes it, I see that as 
>>> a nice, neat, robust solution.
>>>
>>> Funnily enough I was chatting to a fellow PSIer yesterday about 
>>> the mapping file(s) (this is cross-WG policy stuff you see) and 
>>> enquired as to the current nature of the thing. I think if there 
>>> is a clamour to formalise the map then hopefully there will be a 
>>> response. To qualify the current state of affairs though, this 
>>> was not meant to be a formal part of the standard -- more 
>>> something akin to documentation (it didn't exist at all at one 
>>> point -- bridging the gap was something done in the CV, which is 
>>> not a great method for a number of reasons).
>>>
>>> Cheers, Chris.
>>>
>>>
>>> Matthew Chambers wrote:
>>>   
>>>> If the consensus is that the CV should be left simple like it is now, 
>>>> then I must agree with Brian.  The current schema is incapable of doing

>>>> real validation, and the ms-mapping file is worse than a fleshed-out CV

>>>> or XSD (it's more confusing, it takes longer to maintain, and it's 
>>>> non-standard).
>>>>
>>>> I still want Brian to clarify if he wants a one-schema spec or a 
>>>> two-schema spec.  I support the latter approach, where one schema is a 
>>>> stable, syntactical version and the other inherits from the first one 
>>>> and defines all the semantic restrictions as well.  It would be up to 
>>>> implementors which schema to use for validation, and of course only the

>>>> syntactical schema would be "stable" because the semantic restrictions 
>>>> in the second schema would change to match the CV whenever it was
> updated.
>>>> -Matt
>>>>
>>>>     
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://mibbi.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

Re: [Psidev-ms-dev] mzML 0.99.0 comments

[sneumann <sne...@ip...>]

On Mi, 2007-10-17 at 12:49 -0700, Brian Pratt wrote:
...
> something the current proposal largely flinches from doing.  As currently
> proposed, mzML feels like a big step backwards.

Hi,

greetings from one of the "lurkers" on this list.
We are operating a number of different MS.

Currently, we have used Eclipse EMF to auto-generate=20
Java classes from the mzData.xsd, and from there=20
we connect to a database, using an auto-generated schema
through an Object-relational Mapping ORM. The raw=20
data is read by the RAMP parser inside the Bioconductor XCMS package.

I have the feeling that a data model with very little structure
and a well-structured Ontology would put a lot of burden=20
on tool and database developers.=20

I expected mzML to be mainly a merger of mzXML and mzData,
keeping the best of both worlds, and improving vendor=20
and tools support for a merged standard. In that light=20
I followed the Index, Binary and Wrapper Schema discussion,
not responding because I saw that whatever way mzML settled,
I'd be able to adopt by ignoring those features or modifying=20
our tools. At the beginning of the mzML (when it was called dataXML)=20
discussion I also remembered the idea of having a place to store
the Chromatograms, I am not sure what happened to this.

Starting with the CV discussion I felt that mzML is drifting away
from its mz[Data|XML] parents. The rationale behind this discussion is=20
to keep up with ever-changing requirements.=20

But hey, mzData started in 2005, and will likely be applicable=20
to the majority of use cases another (at least?) 1-2 years.=20

I am not sure whether those use cases not covered by mzData=20
can easily be covered with mzML+complexCV, but for a speedy=20
adoption by both vendors please keep simplicity in mind.
Remember people will be writing mzML readers in Java, C++,
C# and Mono, perl, Bioconductor, Python, ... and It might turn=20
into a bad reputation for mzML if these implementations
are buggy and/or incomplete merely because mzML tries to
do too much and people end up hacking the parsers=20
just for their own machine and use case.

Yours,
Steffen

--=20
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409