psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] Proposed mzOntology Changes

[Trish W. <wh...@pc...>]

Hi all,

A Recommendation for PSI Controlled Vocabularies has been drafted by Luisa and 
there are a few things that would need to be changed in the mzOntology to fully 
comply with the Recommendation. One change is in the hierarchy so that it 
includes 'abstract' terms, e.g. Analyzer Description, to simplify the mapping 
from the XML schema to the ontology. As I understand this type of change will 
not negatively effect usage. Is that correct?

Another change that has been proposed is to change the namespace from 
"default_namespace" to "PSI-MS". Does anyone see problems with this change?

It was also mentioned that the term identifier should be changed from 
PSI:0000000 to MS:0000000, however since that change will break existing 
code this recommendation will not be implemented in the upcoming version 
of the mzOntology. As work progresses with the merger of mzData and mzXML, 
this proposed change will be re-examined.

Thanks for your input,
Trish

[Psidev-ms-dev] HUPO-PSI Standard Format Merger Announcement

[Randy J. <rkj...@in...>]

Here is the link:
(http://psidev.sourceforge.net/docstore/download.php?id=79) to the
announcement describing the deliverables and time-lines for the HUPO-PSI
project to merge mzData and mzXML to create a single standard interchange
format for proteomics.

 

Please contact Randy Julian rkj...@in... for additional
information or questions.

 

Thank you.

 

Randy Julian

 

[Psidev-ms-dev] Status of mzData and mzXML merge

[Trish W. <wh...@pc...>]

Hi all,

Can someone provide an update or pointer to the plans for the mzData 
and mzXML merge?

Thanks,
Trish

[Psidev-ms-dev] Nice editorial in Nature Methods

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

For reference. They like us (and MGED, inter alia)  :)

http://www.nature.com/nmeth/journal/v3/n6/index.html#ed

Cheers, Chris.

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

[Psidev-ms-dev] HUPO PSI Proteomics Informatics WG Teleconference - 6 June

[Phil J. <pj...@eb...>]

Hi,

The first telephone conference of the Proteomics Informatics working 
group <http://psidev.sourceforge.net/proteomics-informatics/home.html> 
will be held on:

6th June, 2006 at
http://www.timeanddate.com/worldclock/fixedtime.html?day=6&month=6&year=2006&hour=16&min=0&sec=0&p1=136

Details of this meeting can be found here:
http://psidev.sourceforge.net/proteomics-informatics/Teleconference_2006_06_06.html

(The minutes will be posted to this page after the meeting.)

Agenda:

   1. Logistics for teleconferences
   2. Feedback and additions to the use cases for analysisXML
   3. Feedback and status of the spreadsheet with requirements
   4. Status of sample AnalysisXML in UML format
   5. Proposed time-line.

For phone in details, please contact Phil Jones (details below).

Best regards,

Phil.


-- 
_______________________________________
Phil Jones
Software Engineer
Proteomics Services Team
Sequence Database Group
EMBL-EBI
Wellcome Trust Genome Campus
Hinxton
Cambridge
CB10 1SD
UK

Tel +44 (0)1223 492 610 (Direct Line)
mailto:pj...@eb...
Skype name:philip-jones

[Psidev-ms-dev] RE: Element vs. complexType - mzData schema issue with WSDL using RPC style

[Shawn H. <sh...@xt...>]

Hi Kent,

Thanks for your quick reply. I have some prototype WSDLs generated for
both document and rpc styles using mzData. Please let me know if you
like to take a look at them.

Thanks,
Shawn

-----Original Message-----
From: Kent Laursen [mailto:Ken...@ge...]=20
Sent: Tuesday, April 18, 2006 7:53 PM
To: Shawn Hu; chr...@eb...
Cc: psi...@li...
Subject: RE: Element vs. complexType - mzData schema issue with WSDL
using RPC style

Shawn,

Thank you.  You are correct, and this will be added into our
requirements set.  The need for mzData to fit into the SOA and Grid
worlds has become poignant is recent months.

Regards,

Kent Laursen
PSI-MS

-----Original Message-----
From: Shawn Hu [mailto:sh...@xt...]=20
Sent: Tuesday, April 18, 2006 3:24 PM
To: Kent Laursen; chr...@eb...
Cc: psi...@li...
Subject: Element vs. complexType - mzData schema issue with WSDL using
RPC style

The following issue is based on an assumption that mzData supports Web
service definition (WSDL) for mass spec data transaction.=20

After some testing on WSDLs using mzData.xsd, I found an issue with the
schema regarding its root element. It seems that the current mzData.xsd
does not support WSDL rpc message style.=20

There are two SOAP message styles defined in W3C WSDL specifications:
"document" and "rpc". Basically if a WSDL is defined for a "document"
style, a schema element should be specified. However if a WSDL is
defined for "rpc" style, a schema complexType should be provided.=20

The current schema can only be used for "document" style Web service
since it only has a root element but no global complexType for the root:

<xs:element name=3D"mzData">
	<xs:complexType>
	....

In order to use the schema for both "document" and "rpc" styles, the
root element is better to be defined as:

<xs:element name=3D"mzData" type=3D"mzDataType"/> <xs:complexType
name=3D"mzDataType">
	....
</xs:complexType>


The syntax of the related WSDL definition is listed below:=20

*	Document message:	use <element> in <message>
	<wsdl:message>
		<wsdl:part name=3D".." element =3D"g1:mzData">
	<wsdl:message>

*	RPC message:		use <type> in <message>
	<wsdl:message>
		<wsdl:part name=3D".." type =3D"g1:mzDataType..">
	<wsdl:message>

Note: g1 is a prefix of the mzData targetNamespace.


Thanks,
Shawn

Shawn Hu, Ph.D.
Xtensible Solutions
sh...@xt...

[Psidev-ms-dev] RE: Element vs. complexType - mzData schema issue with WSDL using RPC style

[Kent L. <Ken...@ge...>]

Shawn,

Thank you.  You are correct, and this will be added into our
requirements set.  The need for mzData to fit into the SOA and Grid
worlds has become poignant is recent months.

Regards,

Kent Laursen
PSI-MS

-----Original Message-----
From: Shawn Hu [mailto:sh...@xt...]=20
Sent: Tuesday, April 18, 2006 3:24 PM
To: Kent Laursen; chr...@eb...
Cc: psi...@li...
Subject: Element vs. complexType - mzData schema issue with WSDL using
RPC style

The following issue is based on an assumption that mzData supports Web
service definition (WSDL) for mass spec data transaction.=20

After some testing on WSDLs using mzData.xsd, I found an issue with the
schema regarding its root element. It seems that the current mzData.xsd
does not support WSDL rpc message style.=20

There are two SOAP message styles defined in W3C WSDL specifications:
"document" and "rpc". Basically if a WSDL is defined for a "document"
style, a schema element should be specified. However if a WSDL is
defined for "rpc" style, a schema complexType should be provided.=20

The current schema can only be used for "document" style Web service
since it only has a root element but no global complexType for the root:

<xs:element name=3D"mzData">
	<xs:complexType>
	....

In order to use the schema for both "document" and "rpc" styles, the
root element is better to be defined as:

<xs:element name=3D"mzData" type=3D"mzDataType"/> <xs:complexType
name=3D"mzDataType">
	....
</xs:complexType>


The syntax of the related WSDL definition is listed below:=20

*	Document message:	use <element> in <message>
	<wsdl:message>
		<wsdl:part name=3D".." element =3D"g1:mzData">
	<wsdl:message>

*	RPC message:		use <type> in <message>
	<wsdl:message>
		<wsdl:part name=3D".." type =3D"g1:mzDataType..">
	<wsdl:message>

Note: g1 is a prefix of the mzData targetNamespace.


Thanks,
Shawn

Shawn Hu, Ph.D.
Xtensible Solutions
sh...@xt...

RE: [Psidev-ms-dev] MS telcon

[Kent L. <Ken...@ge...>]

Hi Chris,

Also see Randy's March 21 email on the subject of the MS track,
excerpted here=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
We have two sessions scheduled on Saturday (one session with a long
coffee break...).

One proposal is to take the first 90 minutes and cover:

00-30: Review of status of mzData 1.05, Feedback, comments and direction
of plans (RJ moderate)
30-60: Discussion of the PSI-MS CV: The OBO file, organization, missing
terms, updating, use of external CV's (RJ moderate)
60-90: Discussion of plans to merge mzData and mzXML: review of
mzData/mzXML features (KL moderate)

break

00-30: Develop concrete plans for mzData/mzXML merge
30-60: WG document review: what documents are needed, Spec, Guide, MIAPE
60-90: Outline assignments, schedule, generate WG report statement

Any other thoughts?

Randy
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
Regards,

Kent
-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Chris
Taylor
Sent: Tuesday, April 11, 2006 3:40 AM
To: PSI MS Dev
Subject: [Psidev-ms-dev] MS telcon

Hiya.

If there is a telcon today, do you think you could settle a final order
for the MS track? Probably that was on your agenda anyway I suppose...

The plenary bits can be sorted out separately, but if we can get that
track in the bag that'd be great. I aim to do the same for GPS and the
mysterious fourth track by midweek.

Cheers, Chris.

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language that extends applications into web and mobile media. Attend the
live webcast and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] MS telcon

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

Hiya.

If there is a telcon today, do you think you could settle a 
final order for the MS track? Probably that was on your agenda 
anyway I suppose...

The plenary bits can be sorted out separately, but if we can get 
that track in the bag that'd be great. I aim to do the same for 
GPS and the mysterious fourth track by midweek.

Cheers, Chris.

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

[Psidev-ms-dev] Model driven XML schema generation

[Shawn H. <sh...@xt...>]

I have to apologize to send this email directly to you because the
psidev-ms-dev email address doesn't work for me for some reason.

=20

Regarding of Philip's email on "Value of common ontology vs common
format", I am wondering if there is any proposal on utilizing model
driven methodology for XML schema generation.=20

=20

An XML schema itself is not necessarily a "standard" but a
representation of a standard. So is it better to start with a standard
such as a UML model which can capture all the details within mzData in
terms of relationships, inheritances, multiplicities, and so on? In this
sense, such UML model is a semantic model which is typically well
defined, extensible, and easy for end users to understand.=20

=20

On top of that, some model driven tool has been developed to take a UML
model as input and generate XML schema automatically. As a result,
ambiguities can be usually avoided during schema generation. I guess my
point is to more focus on standard model itself than the representation
of the standard using languages such as XML schema, RDF, or others. =20

=20

Just my two cents ...

=20

=20

Thanks,

Shawn

=20

Shawn Hu, Ph.D.

Xtensible Solutions

=20

[Psidev-ms-dev] Hmm. Call times issue...

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

First thing I wanted to do on the call was report in -- we're up 
to 72 reggies with more to come for certain. 80 is assured, 
maybe more... The money is looking good though; if we keep our 
belts comfortably tight, we'll be in the black (assuming all our 
rooms get taken). Take a look at the meeting page to see the 
latest list -- GE and Cell Signalling Technology _may_ still 
come in -- I'm chasing. I'll have to close the list mid-week 
though so I can get to the printers for the bags in time (14 
days before collection, apparently).

Second, can I urge the MS group to ensure that MIAPE: MSI is in 
a fit state before the meeting (glossary done, all proofed and 
polished) as NBT will 99.9% certainly publish the MIAPE parent, 
plus the MS, MSI and GE modules, in one issue in the very near 
future. This also means that only the contributors will get on 
as authors (rather than an external review process as has been 
done for MS and GE), so we'd be looking to make the most of the 
people in SF so that more names can be added.

Third, keep the scheduling comments coming in so I can make 
revisions as required!

Last issue (under AOB): Vocab. I will this week get time to do 
more on this; I've been too busy up till now but if anyone was 
bothered, rest assured that this is in hand.

Cheers, Chris.

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

RE: [Psidev-ms-dev] PSI-MS conference call 2006-04-04

[Kent L. <Ken...@ge...>]

For some reason a return character was lost in the translation, the two
agenda items I am proposing are:

Features and requirements for future revisions of mzData

Spring 2006 meeting issues at the group's discretion

Regards,

Kent

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Kent
Laursen
Sent: Monday, April 03, 2006 7:52 PM
To: psi...@li...
Subject: [Psidev-ms-dev] PSI-MS conference call 2006-04-04

Dear PSI-MS-ers,

I will start call on Tuesday at the regular time.  We do not currently
have a formal agenda, but I would like to have an open discussion on:

Features and requirements for future revisions of mzData Spring 2006
meeting issues at the group's discretion

Thank you and I'll audibly see you on the call.

Regards,

Kent Laursen,
GenoLogics Life Sciences Software, Inc.
PSI-MS Working Group


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language that extends applications into web and mobile media. Attend the
live webcast and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] PSI-MS conference call 2006-04-04

[Kent L. <Ken...@ge...>]

Dear PSI-MS-ers,

I will start call on Tuesday at the regular time.  We do not currently
have a formal agenda, but I would like to have an open discussion on:

Features and requirements for future revisions of mzData
Spring 2006 meeting issues at the group's discretion

Thank you and I'll audibly see you on the call.

Regards,

Kent Laursen,
GenoLogics Life Sciences Software, Inc.
PSI-MS Working Group

Re: [Psidev-ms-dev] Value of common ontology vs common format

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

I think there are two things here (and I tremble at the thought of 
deploying my meagre wattage on this one but nonetheless...):

Firstly, ontology handling tools and ontologies in general are in a 
pretty awful state. All our mzData-export implementers to my knowledge 
hard code their ontology values; in part this was the lack of a stable 
reference from us, but also I don't get the impression that live lookups 
of ontology references across networks (both the vagueries of networks 
and the potential time delay) are something people are exactly waiting 
to implement. I know caching is a help, but still...

And I speak as one stuck firmly into the FuGO thing, but that is just 
one effort, of thirty or so maybe, growing admittedly; and many of us 
are on a steep, steep learning curve. To handle large bodies of 
descriptors requires that the engineering is strong and that is 
non-trivial. Even in the magic circle of ontology there isn't consensus. 
Now a CV will get you a long way if a lookup (essentially acting I 
suppose as some sort of two-way API if that's not nonsense) is all 
you're after but the management problems with such entities grow 
non-linearly with size to say the least.

Second thing is that the XML really _is_ part of the ontology, although 
not in the literal sense (for example for the CPAS people, where they 
are obligated to build a structured CV rather than a real 'purist' 
ontology because every descriptor, from RDF or a table, has [IIRC] to go 
into the CV -- convenience classes are the problem there (straddling 
concepts for instance, spawning multiple inheritance problems). But 
anyway the point is that some of the ontology already is in a sense 
manifest as the XML. It's the bit of ontology that is settled, made 
flesh; and the reason that is the case is because of the lack of tools 
for ontology use mandates it.

The practical benefit is obviously that we can then exploit those 
semantic labels to do (some of) exactly the kinds of transformations and 
sophisticated data handling that you describe (but not all); while we 
can keep the competition down there won't be many many-to-many XML 
maintenance nightmares, mostly it's into and out of RDBs for now, and 
for analysis tools to feed on. It's better than just having more general 
types, and tables for trees, like HTML (or in a sense FuGE in it's raw 
form in a world without ontologies).

Basically I agree with the general sentiment in many ways, but in 
advance of there being decent ways to do the ontology-based thing, and 
with the ontologies being there (and stable), standardising (in effect) 
some of the ontology as schema elements give us some of the benefits 
while we wait for the situation to change.

There's another issue also, which is about keeping an eye on the ease of 
implementation of all this standards stuff for the funding/coder-poor. 
Hacking up an XML-based analysis pipeline on the cheap is not out of the 
reach of some 'small players', but adding the cost of a variety of XMLs 
to handle, with for example decent knowledge of XSL being required and 
the ability to write ontology-based tools that aren't even really there 
yet, will cut some out of the picture.

If much of that came off as stating the obvious, sorry. The obvious is 
kind of the level I'm at currently with a lot of this stuff but I have 
logorrhea  :\

Cheers, Chris.


Kent Laursen wrote:
> Philip,
> 
> Thank you very much for your thoughtful posting.  I will decline your
> challenge and choose rather to engage in a dialog (actually n-log).  The
> assumptions you are challenging may not actually exist, and I think you
> will find that we have much more common ground than the somewhat
> detached cyber world reveals at first glance.
> 
> My view of a succesful standard (in today's terms) is that it would
> 
> - Be a substantial aid to the science and researchers it addresses
> 
> - Define its value and usage understandably
> 
> - Define enough structure via its format (XML Schema or other mechanism)
> to provide data interchange for a reasonable cross section of use cases
> as put forth by the communities seeking this interchange
> 
> - Provide a consistent and robust mechanism for ontological
> extension/annotation
> 
> - Provide an appropriated scoped, accurate and complete ontology for its
> domain
> 
> - Provide a process and community for evolvement, interoperability and
> extension.
> 
> - Be implementable and/or provide meaningful implementation(s)
> 
> Reaching a "unified standard" is about providing a cohesive and
> consumable offering (balancing the bespoke aspects in time) supported by
> community governance and involvement that does its best to meet the
> needs of its domain while providing a way to move forward.  
> 
> So yes, a standard is much more than XML Schema.  Being, among other
> things, an old smalltalker and oodbms guy, I have never had a great
> affection for XML Schema.  However the rubber being on the road takes an
> incremental approach given the variety of timings, interests and
> pragmatic issues a standards body faces.  So I look forward to the
> community working together towards the more semantically rich and
> machine processable world we are seeking in the life sciences.  As your
> posting implies, along with recent activities in a variety of standards
> groups, this goal is becoming more realistic every day.
> 
> Thank you once again.
> 
> Regards,
> 
> Kent Laursen
> PSI-MS Working Group
> 
> 
> -----Original Message-----
> From: psi...@li...
> [mailto:psi...@li...] On Behalf Of Philip
> Doggett
> Sent: Wednesday, March 29, 2006 9:58 PM
> To: psi...@li...
> Subject: [Psidev-ms-dev] Value of common ontology vs common format
> 
> I would like to challenge the assumptions behind the need to put a great
> deal of work into developing a "common" XML format - or, indeed, any
> "standard" XML format at all - for the storage and interchange of mass
> spec data.
> 
> An XML format is a syntax into which we embed semantics.  The semantics
> is obtained from an ontology.  It is best to have one ontology that is
> shared by all who create XML syntaxes.  It does not matter whether one
> or many syntaxes exist as long as each embeds semantics from a common
> ontology.
> 
> The reasons why is does not matter include:
> - any syntax will be unable to satisfy the data and workflow
> requirements of all potential users, ergo many syntaxes will exist
> anyway
> - the cost of converting any XML syntax to any other XML syntax is
> negligible, given embedded semantics from a common ontology
> 
> 
> The element and attribute names used in an XML format include some
> amount of semantic content.  That semantic content, however, is usually
> dependent upon a processing or workflow context shared by a project team
> but no farther.  The development of an ontology and a method to include
> ontology links in the XML format provide a powerful method of extending
> the semantic content across all potential consumers of the data,
> independent of processing and workflow contexts.
> 
> An XML format is often developed not only to contain data but also to
> make processing and workflows more efficient.  This suggests that any
> XML format designed to be "common" across many or all projects will most
> often be suboptimal with respect to efficiency of processing and
> workflow of any one project.
> 
> When data is encoded in a binary (non-ASCII/non-Unicode) format, that
> format is usually tied to a particular processor, eg big-endian vs
> little-endian, 32-bit vs 64-bit, etc.  The cost of writing a data
> converter to change data from binary format A to binary format B is
> high.  A programming language that provides bit-level manipulation - eg
> C/C++, Java - is required, as is precise documentation of the 'from' and
> 'to' formats.  Any conversion application will likely be fragile, unable
> to handle the slightest change in the definition of the 'from' or 'to'
> format.  Given the high cost and high fragility, the need for strong
> data format standards is high.
> 
> I would like to suggest that with today's tools for manipulating XML
> documents - eg, Xalan, Saxon (both open source) - the cost of developing
> XML format converters is almost negligible and is decreasing.  I also
> suggest that when the next generation of schema definition standards is
> released, support for schema-embedded ontology links will enable fully
> automatable XML format conversion - all that will be required is the
> 'from' schema, the 'to' schema and the common ontology.
> 
> If there is zero cost to convert your XML format to my XML format and my
> XML format is optimised (and extended) for my processing and workflow
> requirements, then I don't care what your XML format is except that it
> includes links to a common ontology.  You don't care (and don't know)
> what my XML format is.  What both of us depend upon is the ontology that
> imbues our data with a common semantics that allows the *data* rather
> than the *format* to be exchanged and shared.
> 
> Rather than embarking on a project to merge mzXML and mzData into a
> single standard XML format, I suggest it is much more important and cost
> effective to merge the ontologies into a single standard.  I further
> suggest that the development and maintenance of this standard ontology
> become one of PSI's highest priorities.
> 
> 
> Philip Doggett
> 
> (The above comments are mine alone and do not necessarily reflect the
> views of Proteome Systems Limited.)
>  
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language that extends applications into web and mobile media. Attend the
> live webcast and join the prime developer group breaking into this new
> coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Chris Taylor (ch...@eb...)
  HUPO PSI: GPS -- psidev.sf.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RE: [Psidev-ms-dev] Value of common ontology vs common format

[Kent L. <Ken...@ge...>]

Philip,

Thank you very much for your thoughtful posting.  I will decline your
challenge and choose rather to engage in a dialog (actually n-log).  The
assumptions you are challenging may not actually exist, and I think you
will find that we have much more common ground than the somewhat
detached cyber world reveals at first glance.

My view of a succesful standard (in today's terms) is that it would

- Be a substantial aid to the science and researchers it addresses

- Define its value and usage understandably

- Define enough structure via its format (XML Schema or other mechanism)
to provide data interchange for a reasonable cross section of use cases
as put forth by the communities seeking this interchange

- Provide a consistent and robust mechanism for ontological
extension/annotation

- Provide an appropriated scoped, accurate and complete ontology for its
domain

- Provide a process and community for evolvement, interoperability and
extension.

- Be implementable and/or provide meaningful implementation(s)

Reaching a "unified standard" is about providing a cohesive and
consumable offering (balancing the bespoke aspects in time) supported by
community governance and involvement that does its best to meet the
needs of its domain while providing a way to move forward. =20

So yes, a standard is much more than XML Schema.  Being, among other
things, an old smalltalker and oodbms guy, I have never had a great
affection for XML Schema.  However the rubber being on the road takes an
incremental approach given the variety of timings, interests and
pragmatic issues a standards body faces.  So I look forward to the
community working together towards the more semantically rich and
machine processable world we are seeking in the life sciences.  As your
posting implies, along with recent activities in a variety of standards
groups, this goal is becoming more realistic every day.

Thank you once again.

Regards,

Kent Laursen
PSI-MS Working Group


-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Philip
Doggett
Sent: Wednesday, March 29, 2006 9:58 PM
To: psi...@li...
Subject: [Psidev-ms-dev] Value of common ontology vs common format

I would like to challenge the assumptions behind the need to put a great
deal of work into developing a "common" XML format - or, indeed, any
"standard" XML format at all - for the storage and interchange of mass
spec data.

An XML format is a syntax into which we embed semantics.  The semantics
is obtained from an ontology.  It is best to have one ontology that is
shared by all who create XML syntaxes.  It does not matter whether one
or many syntaxes exist as long as each embeds semantics from a common
ontology.

The reasons why is does not matter include:
- any syntax will be unable to satisfy the data and workflow
requirements of all potential users, ergo many syntaxes will exist
anyway
- the cost of converting any XML syntax to any other XML syntax is
negligible, given embedded semantics from a common ontology


The element and attribute names used in an XML format include some
amount of semantic content.  That semantic content, however, is usually
dependent upon a processing or workflow context shared by a project team
but no farther.  The development of an ontology and a method to include
ontology links in the XML format provide a powerful method of extending
the semantic content across all potential consumers of the data,
independent of processing and workflow contexts.

An XML format is often developed not only to contain data but also to
make processing and workflows more efficient.  This suggests that any
XML format designed to be "common" across many or all projects will most
often be suboptimal with respect to efficiency of processing and
workflow of any one project.

When data is encoded in a binary (non-ASCII/non-Unicode) format, that
format is usually tied to a particular processor, eg big-endian vs
little-endian, 32-bit vs 64-bit, etc.  The cost of writing a data
converter to change data from binary format A to binary format B is
high.  A programming language that provides bit-level manipulation - eg
C/C++, Java - is required, as is precise documentation of the 'from' and
'to' formats.  Any conversion application will likely be fragile, unable
to handle the slightest change in the definition of the 'from' or 'to'
format.  Given the high cost and high fragility, the need for strong
data format standards is high.

I would like to suggest that with today's tools for manipulating XML
documents - eg, Xalan, Saxon (both open source) - the cost of developing
XML format converters is almost negligible and is decreasing.  I also
suggest that when the next generation of schema definition standards is
released, support for schema-embedded ontology links will enable fully
automatable XML format conversion - all that will be required is the
'from' schema, the 'to' schema and the common ontology.

If there is zero cost to convert your XML format to my XML format and my
XML format is optimised (and extended) for my processing and workflow
requirements, then I don't care what your XML format is except that it
includes links to a common ontology.  You don't care (and don't know)
what my XML format is.  What both of us depend upon is the ontology that
imbues our data with a common semantics that allows the *data* rather
than the *format* to be exchanged and shared.

Rather than embarking on a project to merge mzXML and mzData into a
single standard XML format, I suggest it is much more important and cost
effective to merge the ontologies into a single standard.  I further
suggest that the development and maintenance of this standard ontology
become one of PSI's highest priorities.


Philip Doggett

(The above comments are mine alone and do not necessarily reflect the
views of Proteome Systems Limited.)
=20


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language that extends applications into web and mobile media. Attend the
live webcast and join the prime developer group breaking into this new
coding territory!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] Value of common ontology vs common format

[Philip D. <Phi...@pr...>]

I would like to challenge the assumptions behind the need to put a great
deal of work into developing a "common" XML format - or, indeed, any
"standard" XML format at all - for the storage and interchange of mass
spec data.

An XML format is a syntax into which we embed semantics.  The semantics
is obtained from an ontology.  It is best to have one ontology that is
shared by all who create XML syntaxes.  It does not matter whether one
or many syntaxes exist as long as each embeds semantics from a common
ontology.

The reasons why is does not matter include:
- any syntax will be unable to satisfy the data and workflow
requirements of all potential users, ergo many syntaxes will exist
anyway
- the cost of converting any XML syntax to any other XML syntax is
negligible, given embedded semantics from a common ontology


The element and attribute names used in an XML format include some
amount of semantic content.  That semantic content, however, is usually
dependent upon a processing or workflow context shared by a project team
but no farther.  The development of an ontology and a method to include
ontology links in the XML format provide a powerful method of extending
the semantic content across all potential consumers of the data,
independent of processing and workflow contexts.

An XML format is often developed not only to contain data but also to
make processing and workflows more efficient.  This suggests that any
XML format designed to be "common" across many or all projects will most
often be suboptimal with respect to efficiency of processing and
workflow of any one project.

When data is encoded in a binary (non-ASCII/non-Unicode) format, that
format is usually tied to a particular processor, eg big-endian vs
little-endian, 32-bit vs 64-bit, etc.  The cost of writing a data
converter to change data from binary format A to binary format B is
high.  A programming language that provides bit-level manipulation - eg
C/C++, Java - is required, as is precise documentation of the 'from' and
'to' formats.  Any conversion application will likely be fragile, unable
to handle the slightest change in the definition of the 'from' or 'to'
format.  Given the high cost and high fragility, the need for strong
data format standards is high.

I would like to suggest that with today's tools for manipulating XML
documents - eg, Xalan, Saxon (both open source) - the cost of developing
XML format converters is almost negligible and is decreasing.  I also
suggest that when the next generation of schema definition standards is
released, support for schema-embedded ontology links will enable fully
automatable XML format conversion - all that will be required is the
'from' schema, the 'to' schema and the common ontology.

If there is zero cost to convert your XML format to my XML format and
my XML format is optimised (and extended) for my processing and workflow
requirements, then I don't care what your XML format is except that it
includes links to a common ontology.  You don't care (and don't know)
what my XML format is.  What both of us depend upon is the ontology that
imbues our data with a common semantics that allows the *data* rather
than the *format* to be exchanged and shared.

Rather than embarking on a project to merge mzXML and mzData into a
single standard XML format, I suggest it is much more important and cost
effective to merge the ontologies into a single standard.  I further
suggest that the development and maintenance of this standard ontology
become one of PSI's highest priorities.


Philip Doggett

(The above comments are mine alone and do not necessarily reflect the
views of Proteome Systems Limited.)
 

[Psidev-ms-dev] Sean L Seymour/FOS/PEC is out of the office.

[Sean L S. <Sey...@ap...>]

I will be out of the office starting  03/28/2006 and will not return until
04/05/2006.

[Psidev-ms-dev] Soliciting feature requests prior to Spring meeting

[Kent L. <Ken...@ge...>]

Dear PSI-MS subscribers,

At the HUPO PSI Spring meeting, April 21st-23rd) one of the subjects of
the MS track will be the evolution of the mzData standard, including
presentation and dialog on a merger between mzData and mzXML towards a
unified mass spectrometry data interchange format.  Part of this
movement forward involves delineating new features that currently might
not be addressed by either format.

If you have feature requests or requirements you wish to see addressed
by mzData, please send these to me at ken...@ge...
<mailto:ken...@ge...> .  I will collate these for use
during our discussions in San Francisco.

Thank you for your participation and input.  See you in SF.

Regards,

Kent Laursen
GenoLogics Life Sciences Software, Inc.
PSI-MS Working Group

Re: [Psidev-ms-dev] Sequence tagging and mzIdent / analysisXML

[Angel P. <an...@ma...>]

Hi David,
Yes, mzIdent has been renamed to analysisXML and its role has been 
expanded to include mroe than just ms search results.
There is an example analysisXML, but it is very likely to change under 
you in the next month or so, as actual development of analysisXML is 
about to get underway as part of a new PSI working group. Would you like 
to join ;) ? Seriously though, if you want input into the process, there 
is the PSI spring meeting in San Fran the end of April (more info on the 
web site).

The example analysisXML (which will change very soon, but you can get 
the gist of what is in it) is here:

http://psidev.sourceforge.net/docstore/download.php?sess=0&parent=19&expand=1&order=name&sortname=ASC&binary=1&id=61

-angel

David L. Tabb wrote:

> Hello, all.  Have there been efforts to discern how results from 
> sequence tagging (rather than database search) should be stored in 
> analysisXML files?
>
> I've seen mention of mzIdent along with analysisXML.  Is it 
> appropriate to think of analysisXML as the successor to mzIdent?  Are 
> there example files of Sequest results translated to this format?
>
> Dave Tabb
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev



-- 

Angel Pizarro
Director, Bioinformatics Facility
Institute for Translational Medicine and Therapeutics
University of Pennsylvania
806 BRB II/III
421 Curie Blvd.
Philadelphia, PA 19104-6160

P: 215-573-3736
F: 215-573-9004

[Psidev-ms-dev] Sequence tagging and mzIdent / analysisXML

[David L. T. <dav...@va...>]

Hello, all.  Have there been efforts to discern how results from 
sequence tagging (rather than database search) should be stored in 
analysisXML files?

I've seen mention of mzIdent along with analysisXML.  Is it appropriate 
to think of analysisXML as the successor to mzIdent?  Are there example 
files of Sequest results translated to this format?

Dave Tabb

RE: [Psidev-ms-dev] PSI-MS 7 March Teleconference minutes - Call today 1600 GMT

[Kent L. <Ken...@ge...>]

This looks pretty good to me.  I'm also interested in moving towards
cross-standard approaches and factorings towards pre-existing goals of
extensibility and domain partitioning/specificity.  Use of external CV's
is an important subject in this vein.  Even such mundane topics as where
contact info is found in a format could be made more consistent.  FuGE
plays a role in this discussion.  Not sure how much time we'll have to
address the layering and reuse of shared concepts, but not a ball we
should drop.

Regards,

Kent

-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of Randy
Julian
Sent: Tuesday, March 21, 2006 5:25 AM
To: PSI MS Dev
Subject: [Psidev-ms-dev] PSI-MS 7 March Teleconference minutes - Call
today 1600 GMT

The minutes from the 7 March PSI MS teleconference are available.

http://psidev.sourceforge.net/docstore/download.php?&id=3D75

Today (1600 GMT - contact rkj...@in... if you need dialing
info) we should finalize the schedule for the PSI-MS session scheduled
for the SF meeting.

We have two sessions scheduled on Saturday (one session with a long
coffee break...).

One proposal is to take the first 90 minutes and cover:

00-30: Review of status of mzData 1.05, Feedback, comments and direction
of plans (RJ moderate)
30-60: Discussion of the PSI-MS CV: The OBO file, organization, missing
terms, updating, use of external CV's (RJ moderate)
60-90: Discussion of plans to merge mzData and mzXML: review of
mzData/mzXML features (KL moderate)

break

00-30: Develop concrete plans for mzData/mzXML merge
30-60: WG document review: what documents are needed, Spec, Guide, MIAPE
60-90: Outline assignments, schedule, generate WG report statement

Any other thoughts?

Randy

--
NOTICE:  This message may contain confidential or privileged information
and is for the sole use of the intended recipient.  Any unauthorized
review, use, disclosure, copying or distribution is strictly prohibited.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
Psidev-ms-dev mailing list
Psi...@li...
https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

[Psidev-ms-dev] PSI-MS 7 March Teleconference minutes - Call today 1600 GMT

[Randy J. <rkj...@in...>]

The minutes from the 7 March PSI MS teleconference are available.

http://psidev.sourceforge.net/docstore/download.php?&id=75

Today (1600 GMT - contact rkj...@in... if you need dialing 
info) we should finalize the schedule for the PSI-MS session scheduled 
for the SF meeting.

We have two sessions scheduled on Saturday (one session with a long 
coffee break...).

One proposal is to take the first 90 minutes and cover:

00-30: Review of status of mzData 1.05, Feedback, comments and direction 
of plans (RJ moderate)
30-60: Discussion of the PSI-MS CV: The OBO file, organization, missing 
terms, updating, use of external CV's (RJ moderate)
60-90: Discussion of plans to merge mzData and mzXML: review of 
mzData/mzXML features (KL moderate)

break

00-30: Develop concrete plans for mzData/mzXML merge
30-60: WG document review: what documents are needed, Spec, Guide, MIAPE
60-90: Outline assignments, schedule, generate WG report statement

Any other thoughts?

Randy

-- 
NOTICE:  This message may contain confidential or privileged information and is for the sole use of the intended recipient.  Any unauthorized review, use, disclosure, copying or distribution is strictly prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Re: [Psidev-ms-dev] Reworking the MS vocab

[Randy J. <rkj...@in...>]

All,

I agree with the idea here - while the terms themselves are established 
by an external standards group - there is little or no organization or 
grouping to them.  I thought of doing this in terms of adding 
'connecting' terms - which presumably would be the same as names of the 
bins - or perhaps subdivisions.

In editing names we need to be aware of both practical use as well as 
standardization efforts by other groups.  I think we can decide on 
separator characters, and if there are other editorial ideas we should 
discuss them.

We have gone back and forth between Excel and OBO (and there are many 
who want RDF or OWL).  If putting things back into a spreadsheet helps 
arrive at a better CV then we should do it, as long as the final result 
ends up in some better format than excel.  I got flak for the CV only 
being available as a spreadsheet - or a 'list of terms' when it was 
first posted.

The general action #1 listed below can also be done directly off the OBO 
file using OBO-Edit (from sourceforge), but again whatever works let's 
do it.

As far as #2 is concerned, is there a formal body (like the ASMS or IMS 
or IUPAC) working on FUGO as was done on the MS terms?  I don't think we 
should change central terms of the CV for mzData if they are not drawn 
from an equivalent authority or community.

Unless there are other suggestions, I would recommend having Chris 
proceed and then look at the spreadsheet.

Thanks,
Randy

Chris Taylor wrote:
> Hi all.
>
> In examining the MS CV (as part of an exercise to evolve the 
> Functional Genomics Ontology) I have come across some real problems, 
> in terms of naming, use of relationships and overall structure. To 
> resolve these issues, and to provide a solid working model for gel 
> terms etc. as they come along I'd like to propose the following:
>
> [Chris' action #1] I can provide an Excel spreadsheet developed by 
> completely flattening the 1.6 OBO and re-binning all the terms, 
> editing names etc. as necessary on the fly
> [General action #1] People then need to properly scrutinise that 
> spreadsheet, to offer opinions on (1) whether the bins themselves are 
> sensible and (2) whether the binning is correct.
>
> [Chris' action #2] #1 having been closed as an item, I can then 
> provide two things -- a set of terms tightly linked to mzData and 
> something approximating a 'proper' ontology (i.e. all relationships 
> bulletproof, all terms correct in all senses); this ontology will 
> borrow heavily from FuGO's parallel evolution (anticipating insertion 
> of those terms there). That having been done and signed off on, we can 
> then follow that model for gels etc.
>
> [Chris' action #3, unless someone else wants it...] Ensuring that the 
> association between the suggested (assuming all the above appeals) 2.0 
> MS CV and (partial) ontology and all previous versions is established 
> and verified, allowing back-propagation of terms into old data files 
> (all of which are I think in PRIDE only).
>
> I appreciate that some of this is a bit hard to think about without 
> examples in hand -- I'm already having a go at my action #1 (Excel); 
> the results of this should be available later today of anyone wants a 
> look. Whatever though, do please offer an opinion on all of the above, 
> so that we can be sure that any changes happen sooner rather than later.
>
> Cheers, Chris.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~
>  chr...@eb...
>  http://psidev.sf.net/
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>

-- 
NOTICE:  This message may contain confidential or privileged information and is for the sole use of the intended recipient.  Any unauthorized review, use, disclosure, copying or distribution is strictly prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

[Psidev-ms-dev] Reworking the MS vocab

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

Hi all.

In examining the MS CV (as part of an exercise to evolve the 
Functional Genomics Ontology) I have come across some real 
problems, in terms of naming, use of relationships and overall 
structure. To resolve these issues, and to provide a solid 
working model for gel terms etc. as they come along I'd like to 
propose the following:

[Chris' action #1] I can provide an Excel spreadsheet developed 
by completely flattening the 1.6 OBO and re-binning all the 
terms, editing names etc. as necessary on the fly
[General action #1] People then need to properly scrutinise that 
spreadsheet, to offer opinions on (1) whether the bins 
themselves are sensible and (2) whether the binning is correct.

[Chris' action #2] #1 having been closed as an item, I can then 
provide two things -- a set of terms tightly linked to mzData 
and something approximating a 'proper' ontology (i.e. all 
relationships bulletproof, all terms correct in all senses); 
this ontology will borrow heavily from FuGO's parallel evolution 
(anticipating insertion of those terms there). That having been 
done and signed off on, we can then follow that model for gels etc.

[Chris' action #3, unless someone else wants it...] Ensuring 
that the association between the suggested (assuming all the 
above appeals) 2.0 MS CV and (partial) ontology and all previous 
versions is established and verified, allowing back-propagation 
of terms into old data files (all of which are I think in PRIDE 
only).

I appreciate that some of this is a bit hard to think about 
without examples in hand -- I'm already having a go at my action 
#1 (Excel); the results of this should be available later today 
of anyone wants a look. Whatever though, do please offer an 
opinion on all of the above, so that we can be sure that any 
changes happen sooner rather than later.

Cheers, Chris.

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

[Psidev-ms-dev] PSI-MS 21 Feb 2006 Teleconference Minutes

[Randy J. <rkj...@in...>]

The minutes from the 21 Feb 2006 PSI-MS teleconference are in the psi 
docstore:

http://psidev.sourceforge.net/docstore/download.php?sess=0&id=72

The agenda for the 7 March 2006 Teleconference will be as follows:

1. San Francisco PSI meeting

<< This may take all of the time >>

2. Review of proposals for Working Group chairs and Steering Group 
membership
3. Update on analysisXML plan
4. Publication plan for mzData - think of the author list for an 
informational paper...

other items suggested but accidentally left out?

-- 
NOTICE:  This message may contain confidential or privileged information and is for the sole use of the intended recipient.  Any unauthorized review, use, disclosure, copying or distribution is strictly prohibited.  If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.