psidev-pi-dev Mailing List for Proteomics Standards Initiative (Page 133)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Martin,

> ad 1) I can create an XSD from the UML (I followed the step-by-step
> instructions on http://wiki.ficcs.org/ficcs/FuGE-to-XSD with Angels
> folder copied to my system and some modifications to XmlSchema.vsl ;-) ).

Okay thankfully this process is getting simpler. We are currently testing a software toolkit that can be checked out from the FuGE website using SVN. For now you still need to have Java and Maven2 installed on your system but most of the other downloads are done automatically. 

We are working on the documentation, the current version is here: http://fuge.sourceforge.net/stks/xsd-stk/fuge-books/fuge-xsd/index.html. 

The toolkit has in-built JaxB2 support so you can load up sample XML files, the data is read into a Java model, it can be modified, validated and output again. You may want to subscribe to the FuGE developers list so you can see the most recent developments? https://lists.sourceforge.net/lists/listinfo/fuge-devel

Cheers
Andy

> -----Original Message-----
> From: Martin Eisenacher [mailto:mar...@ru...]
> Sent: 14 February 2008 10:14
> To: Jones, Andy
> Cc: pj...@eb...; dc...@ma...; fuge-
> de...@li...; psi...@li...
> Subject: Re: FW: [Fuge-devel] FuGE-light...
> 
> Hi Andy,
> 
> thanks for forwarding this.
> 
> ad 1) I can create an XSD from the UML (I followed the step-by-step
> instructions on http://wiki.ficcs.org/ficcs/FuGE-to-XSD with Angels
> folder copied to my system and some modifications to XmlSchema.vsl ;-) ).
> 
> Indeed, the creation is not the simplest thing at the moment...
>  From my point of view AnalysisXML is nearly completed except the
> quantitation section, CV/onotology and documentation.
> 
> 
> ad 2) It might be true, that extensibility is not used yet, but for me
> that does not mean, it is not WANTED. AnalysisXML definitely uses the
> FuGE Collections and the Classes from FuGE:Common:Ontology.
> 
> 
> IF there is the danger of a hand-crafted XSD, I think 1) WOULD be a
> stronger reason for that than 2).
> 
>    I hope that helps
>      bye
>        Martin
> 
> 
> 
> Jones, Andy schrieb:
> 
> > Hi Phil / Martin / David,
> >
> > Not sure if you subscribe to the FuGE list so I’m forwarding on our discussion,
> please forward on to other analysisXML developers. As I understand it, there is a
> move to drop the FuGE extension and hand craft an XSD for analysisXML. As I
> understand it, the reasons are:
> >
> > 1)      No-one other than Angel is capable of turning the UML into XSD in the
> group
> >
> > 2)      The extensibility of the format i.e. all the inherited elements, are not
> wanted in analysisXML.
> >
> > Is this a fair summary? We are discussing on the FuGE list whether there is any
> benefit in releasing a version of FuGE that is stripped of some of the extensibility.
> FYI there is also a lot of work going on to simplify the UML to XSD conversion.
> >
> >
> >
> > Cheers
> >
> > Andy
> >
> >
> >
> >
> >
> >
> >
> > From: fug...@li... [mailto:fuge-devel-
> bo...@li...] On Behalf Of Hermida, Leandro
> > Sent: 08 February 2008 12:32
> > To: fug...@li...
> > Subject: Re: [Fuge-devel] FuGE-light...
> >
> >
> >
> > Hi,
> >
> >
> >
> > I agree with Allyson – after reading that they might drop FuGE I would really like
> to understand why.  I  have been planning to implement analysisXML as part of my
> software implementation since we have a mass spec facility here L
> >
> >
> >
> > -Leandro
> >
> >
> >
> >
> >
> > From: fug...@li... [mailto:fuge-devel-
> bo...@li...] On Behalf Of Allyson Lister
> > Sent: Friday, February 08, 2008 13:20
> > To: fug...@li...
> > Subject: Re: [Fuge-devel] FuGE-light...
> >
> >
> >
> > Hi all,
> >
> > It seems a serious problem for the analysisXML people. Can they present their
> problems to the fuge-devel list, and perhaps we can have a wider discussion about
> it?
> >
> > On Feb 8, 2008 11:58 AM, Jones, Andy <And...@li...>
> wrote:
> >
> > Hi Michael,
> >
> >
> >
> > I had a quick look in the mailing list archive because I remember this was
> discussed in the past. I see that I conceded to leave Describable as it is (mail
> 2006-10-06)  so I guess I'll have to concede again on this since I believe in
> following standardisaton processes... All I would say is that I anticipated a potential
> problem, summarised as – some data formats should not be extensible, and now
> we're getting this feedback. For example, AnalysisXML may end up ditching their
> FuGE based model because they don't want a super-extensible format, and will
> hand craft an XSD instead – this seems like a shame to me.
> >
> >
> >
> > Cheers
> >
> > Andy
> >
> >
> >
> > From: fug...@li... [mailto:fuge-devel-
> bo...@li...] On Behalf Of Miller, Michael D (Rosetta)
> > Sent: 08 February 2008 00:27
> >
> >
> > To: fug...@li...
> > Subject: Re: [Fuge-devel] FuGE-light...
> >
> >
> >
> > hi andy,
> >
> >
> >
> > i just downloaded the latest addition of XMLSpy partly because i've been
> meaning to and partially i was curious about its UI.
> >
> >
> >
> > (from andy)
> >
> > "most people use XMLSpy..."
> >
> >
> >
> > using the Schema/WSDL view, i found this version very friendly, the extra
> elements didn't really bother me, plus once you close down the inherited branch
> from Describable, it remains closed when viewing other elements.
> >
> >
> >
> > "i.e. it is supposed to make things easier not more difficult!"
> >
> >
> >
> > i don't really believe that the Describable element is responsible for making it
> more difficult, perhaps it's baggage to some people but it sits in its little
> encapsulated corner and i don't see how it makes extending from FuGE harder or
> easier.
> >
> >
> >
> > (from allyson)
> >
> > "IMHO, community extension developers should also be knowledgeable enough
> about XSDs and XML to know that you don't need to fill in every single element of
> an XSD, including the Describable elements."
> >
> >
> >
> > i very much agree with allyson here and with her other points, and in terms of
> development, whether the Describable element is present or extracted in a lite
> version, for the most part it's still not directly visible in terms of extending from the
> FuGE model.
> >
> >
> >
> > (from allyson)
> >
> > "I think providing a standard method of displaying FuGE-ML is better than trying
> to develop multiple versions of FuGE."
> >
> >
> >
> > yes, this is where are efforts should be concentrated.  and in terms of using
> third party tools to create forms or view FuGE, i would imagine some creative
> XSLT scripts could help a great deal, i think it would be easy to remove the
> associations from Describable and perhaps remove Describable entirely if one
> wants.  note that this would be useful only for no-extension use.
> >
> >
> >
> > cheers,
> >
> > michael
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 	From: fug...@li... [mailto:fuge-devel-
> bo...@li...] On Behalf Of Jones, Andy
> > 	Sent: Thursday, February 07, 2008 1:47 AM
> > 	To: fug...@li...
> > 	Subject: Re: [Fuge-devel] FuGE-light...
> >
> > 	Hi Ally,
> >
> > 	Quick response...
> >
> >
> >
> > 	My point wasn't about the readability of XML as such, more that developers
> find the resulting XSD difficult to manage – most people use XMLSpy or
> something similar to view XSD, and every element appears with loads of optional
> attributes. We have to remember that some groups work pretty much only in XML,
> and just see the UML as a very roundabout way of designing XML Schema. If
> there is an impression that it's easier to design a complex XML schema from
> scratch rather than using FuGE, we've failed in one of the stated FuGE goals:
> >
> >
> >
> > 	"To provide a framework for building new data models with a common
> structure for techniques that have specific requirements, to facilitate the creation
> of new data standards"
> >
> >
> >
> > 	i.e. it is supposed to make things easier not more difficult!
> >
> >
> >
> > 	Cheers
> >
> > 	Andy
> >
> >
> >
> > 	From: fug...@li... [mailto:fuge-devel-
> bo...@li...] On Behalf Of Allyson Lister
> > 	Sent: 06 February 2008 21:45
> > 	To: fug...@li...
> > 	Subject: Re: [Fuge-devel] FuGE-light...
> >
> >
> >
> > 	Hi all,
> >
> > 	My initial response to Andy's comment about how the describable info
> "makes even the simplest entities look quite complex" is this: XML isn't meant to be
> human-readable. Exclamation point. :)
> >
> > 	I completely understand that Andy's just passing on what users and
> potential users want, and in that sense we need to look into solutions, but as a
> developer of FuGE for my own purposes, I will *never* let my end-users see
> FuGE-ML, so there is absolutely no problem - they won't see any xml elements at
> all, because they've told me they don't want to :). IMHO, community extension
> developers should also be knowledgeable enough about XSDs and XML to know
> that you don't need to fill in every single element of an XSD, including the
> Describable elements. Adding describable elements is optional, and that should be
> enough.
> >
> > 	As for generating web forms directly from the XSD (and I assume its the
> sort of thing like the GSC is doing), it's hard to design a good web interface that
> just auto-generates from an XSD. Most XSDs are not designed for ideal web form
> interfaces, and shouldn't be - it's conflating two types of design decisions. Having
> said that, the GSC website is very good, and they're doing quite a lot of interesting
> stuff with XSD-to-web-form. Further, it is very appealing to do that sort of GUI
> design. However, I don't think that just removing Describable would be enough to
> make a auto-generated web form look right. I've in the past tried out the auto-
> generate web form feature within Andromda, and that ends up way more complex
> than dropping Describable would solve. Further, I'm running into GUI difficulties
> now with SyMBA - it is quite a complex job to get a nice, simple layout of FuGE
> experiments (I know it sounds contradictory, but it's true!) I'm working with some
> GUI people in Uni
>  of York, and hopefully we can get a collaboration going that will not only result in a
> nice-fuge view of the data for SyMBA, but perhaps even something that may
> translate into a FuGE tool.
> >
> > 	This isn't to say that we should try to make things look simpler: I agree with
> Andy's users completely there. However, from the discussion at the FuGE
> workshop it seemed the consensus was to develop standard Java methods or jars
> that would take all the work out of doing 1) a simple HTML/XHTML static display of
> a FuGE experiment, and 2) a slightly more complex, interactive display of a FuGE
> experiment (perhaps with Ajax?). (Other, more involved standalone create-update
> GUIs for FuGE experiment building were also discussed as a slightly longer-term
> thing). I think providing a standard method of displaying FuGE-ML is better than
> trying to develop multiple versions of FuGE.
> >
> > 	Sorry for the slightly long email, but I do get a little bit of a bee in my
> bonnet when I hear about human-readable XML ;)
> >
> > 	Thanks!
> >
> > 	On Feb 6, 2008 5:16 PM, Jones, Andy <And...@li...>
> wrote:
> >
> > 	in the FuGE XSD the DescribableType element defines the associations,
> so those are only defined once in one place.  there is a bit of a bloat for each type
> that derives from Describable nested in the tag but it is surrounding the
> associations or association ends that don't go away so i don't think much is gained
> in terms of the XSD (but i'm not the expert here).
> >
> >
> >
> > 	Agreed, there is no real bloat at all in the actual XSD. However, most users
> of XSD don't view the raw text but view a processed version which shows all
> possible attributes, including those inherited – it makes even the simplest entities
> look quite complex. Also, several users generate forms directly from the XSD for
> data entry – again, even simple elements look complex. Of course visualisation
> issues should not be tied to schema design but in the academic world fairly basic
> software is sometimes used.
> >
> >
> >
> > 	if the database generation isn't generating a Describable table which each
> class that derives from Describable has a foreign key to it, then it's severely
> breaking normalization.  so the issue should be these foreign key columns.
> there's nothing wrong with an organization deciding to get rid of these and to
> update the parse into their database to ignore saving these associations without
> needing a new XSD.  that's how PSMs are supposed to work.
> >
> >
> >
> > 	Many database developers will not create their database from the UML but
> instead directly from the XSD. Either way, it is not currently possible for a PSM to
> do away with a foreign key to a Describable table since users may send them data
> using these attributes – if it's there in the XML schema some people will use it.
> >
> >
> >
> > 	And in response to Ugis...
> >
> >
> >
> > 	> I've been very silent here, just occasionally following the discussion,
> >
> > 	> but in this case feel like I should
> >
> > 	> support Michael. I think there is no relation between XSD and what
> >
> > 	> databases choose to support or not
> >
> > 	> to support. If some database chooses to recognize e.g. only Protocol in
> >
> > 	> FuGE documents, that's fine -
> >
> > 	> there's no need to have another XSD. There may be other arguments for
> a
> >
> > 	> simpler alternative XSD, but
> >
> > 	> this is not one.
> >
> >
> >
> > 	Okay fair point, but the reality is that we want to build XML Schemas that
> do not have this level of flexibility. It would be great if we could use FuGE not only
> to build super-extensible formats, but really tight data formats with very little
> flexibility. At the moment, there is a view that FuGE is too heavyweight for some
> groups. This is for two reasons:
> >
> > 	1)      Extension developers would like to choose when an element is
> extensible; it should not be forced on every single element
> >
> > 	2)      The complexity of the AndroMDA machinery to convert UML in XSD
> >
> >
> >
> > 	We are working on solving 2 so that it's relatively painless to get everything
> set up. In terms of 1) without a FuGE light there is no obvious solution. As it
> stands every single element, in every FuGE extensions could be associated with
> an audit trail, security details, URIs, additional ontological annotations, description
> text and NVT. To give a real example, in the GelML specifications, I wrote the
> following phrase:
> >
> >
> >
> > 	"Such additional annotations of free text, controlled vocabulary terms or
> user-defined parameters SHOULD NOT be used for reporting required
> information unless the model contains no other structures that could be used to
> capture the information."
> >
> >
> >
> > 	Given that most people don't read the spec document, I would have much
> preferred just to get rid of Describable. It's easy to add extensibility back in where
> it is required in the model.
> >
> >
> >
> > 	Cheers
> >
> > 	Andy
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 	From: fug...@li... [mailto:fuge-devel-
> bo...@li...] On Behalf Of Miller, Michael D (Rosetta)
> > 	Sent: 06 February 2008 16:32
> >
> >
> > 	To: fug...@li...
> > 	Subject: Re: [Fuge-devel] FuGE-light...
> >
> >
> >
> > 	hi andy,
> >
> >
> >
> > 	in the FuGE XSD the DescribableType element defines the associations,
> so those are only defined once in one place.  there is a bit of a bloat for each type
> that derives from Describable nested in the tag but it is surrounding the
> associations or association ends that don't go away so i don't think much is gained
> in terms of the XSD (but i'm not the expert here).
> >
> >
> >
> > 	in the actual FuGE documents based on the XSD there is no necessity to
> refer to Describable or its associations at all so no need for 'bloat' there.
> >
> >
> >
> > 	"If Describable is part of the XSD, it means that databases have to commit
> to implementing it"
> >
> >
> >
> > 	if the database generation isn't generating a Describable table which each
> class that derives from Describable has a foreign key to it, then it's severely
> breaking normalization.  so the issue should be these foreign key columns.
> there's nothing wrong with an organization deciding to get rid of these and to
> update the parse into their database to ignore saving these associations without
> needing a new XSD.  that's how PSMs are supposed to work.
> >
> >
> >
> > 	this argument holds even if the associations are being duplicated in the
> tables for the derived classes.
> >
> >
> >
> > 	but as i said before, losing Description.text i feel is a huge mistake.
> >
> >
> >
> > 	if they write back out to FuGE, it will be perfectly valid even having thrown
> away this information.
> >
> >
> >
> > 	cheers,
> >
> > 	michael
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 		From: fug...@li... [mailto:fuge-
> dev...@li...] On Behalf Of Jones, Andy
> > 		Sent: Wednesday, February 06, 2008 7:42 AM
> > 		To: fug...@li...
> > 		Subject: Re: [Fuge-devel] FuGE-light...
> >
> > 		Hi all,
> >
> >
> >
> > 		I think I need to clarify slightly what I was proposing. We release an
> additional UML model (perhaps only intended for XSD generation), that does not
> have Describable at all. The complete FuGE version 1 would still remain available
> to extension developers, so this would have zero affect on MAGE2 development
> plans.
> >
> >
> >
> > 		The difference comes for groups who want to focus on a smaller,
> compact XSD representation without the bloat of all the extensibility provided by
> the Describable hierarchy. If Describable is part of the XSD, it means that
> databases have to commit to implementing it – and I know for a fact that several
> database providers do not want to.
> >
> >
> >
> > 		I agree there is a potential issue that will arise when groups want to
> put together data from various extensions: but these kinds of "power-users"
> should be able to handle putting together some models that use Describable with
> some that don't. Let's suppose PSI chooses for its formats to extend from FuGE-
> light. If a database wishes to accept data from MAGE2 and PSI formats, this will be
> no problem – the database can assume that all data could potentially have
> Describable attributes, only none of the XML instances from PSI formats will
> actually use this feature.
> >
> >
> >
> > 		In terms of writing a FuGE parser, I admit I haven't worked out all
> the implications yet but at the moment our plans extend only to creating an STK for
> the FuGE core (i.e. FuGE complete). Extension developers have to create their
> own software – so this is not an issue from our perspective.
> >
> >
> >
> > 		Since Ally and Leandro are most actively working on FuGE based
> software just now, I'd be interested to hear their opinions... Would we open up a
> load of new problems if some extensions have an XML Schema that does not
> inherit from Describable?
> >
> >
> >
> > 		Cheers
> >
> > 		Andy
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 		From: fug...@li... [mailto:fuge-
> dev...@li...] On Behalf Of Angel Pizarro
> > 		Sent: 06 February 2008 13:33
> > 		To: fug...@li...
> > 		Subject: Re: [Fuge-devel] FuGE-light...
> >
> >
> >
> > 		On Feb 5, 2008 8:19 PM, Miller, Michael D (Rosetta)
> <Mic...@ro...> wrote:
> >
> > 			hi angel,
> >
> >
> >
> > 			"In the long history of MAGE there has been one and only
> one semi-legitimate usage of the NVT or other describable elements..."
> >
> >
> >
> > 			not particularly true.  for one thing, i think we can't do
> without the association to Description and its text attribute.  This is very much in
> use in MAGE-ML submissions to ArrayExpress.  the free text descriptions add a
> lot of clarity to the objects they describe.  BibliographicReference also gets much
> use in ArrayExpress associated with Experiment.
> >
> >
> >
> > 			and even the much maligned NVTs were used to good
> effect by Imperial College's MiMiR application among others.
> >
> >
> >
> > 			it is also naive to think that academia is the only place that
> MAGE is used.  tracking data becomes very import in industrial settings.  our
> customers want to know when things were created (audit), often want to assign
> who initially can see the data (security) and assign annotations that aren't
> necessarily characteristics.
> >
> >
> > 		meh.. difference of opinion.  let's leave it at.
> >
> >
> >
> > 			but i also digress
> >
> >
> >
> > 			"So the only choice before us is to release a subset of the
> FuGE XSD that is not the official V1, but a subset of the functionality so that a
> parser written for full FuGE would be OK with this lite format, but the reverse
> would not hold true."
> >
> >
> >
> > 			perhaps this could work but i'm not seeing how the parser
> (or the autogenerated application the parser is calling to create the in-memory
> model) would easily go from the lite version to reconstruct the inheritance
> hierarchy of the official version.
> >
> >
> > 		You may be right. But we won't know until we try.
> > 		-a
> >
> >
> >
> >
> > 	-------------------------------------------------------------------------
> > 	This SF.net email is sponsored by: Microsoft
> > 	Defy all challenges. Microsoft(R) Visual Studio 2008.
> > 	http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > 	_______________________________________________
> > 	Fuge-devel mailing list
> > 	Fug...@li...
> > 	https://lists.sourceforge.net/lists/listinfo/fuge-devel
> >
> >
> >
> >
> > 	--
> > 	Thanks,
> > 	Allyson :)
> >
> > 	Allyson Lister
> > 	Research Associate
> > 	Centre for Integrated Systems Biology for Ageing and Nutrition
> > 	Newcastle University
> > 	http://www.cisban.ac.uk
> > 	School of Computing Science
> > 	Newcastle University
> > 	Newcastle upon Tyne, NE1 7RU
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Fuge-devel mailing list
> > Fug...@li...
> > https://lists.sourceforge.net/lists/listinfo/fuge-devel
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Fuge-devel mailing list
> > Fug...@li...
> > https://lists.sourceforge.net/lists/listinfo/fuge-devel

2006	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (5)	Aug (4)	Sep (4)	Oct (10)	Nov (1)	Dec (1)
2007	Jan	Feb	Mar (2)	Apr	May	Jun	Jul (4)	Aug	Sep	Oct (1)	Nov	Dec
2008	Jan	Feb (2)	Mar (2)	Apr (8)	May (40)	Jun (30)	Jul (61)	Aug (21)	Sep (12)	Oct (56)	Nov (99)	Dec (83)
2009	Jan (3)	Feb (9)	Mar (1)	Apr (5)	May (88)	Jun (43)	Jul (60)	Aug (54)	Sep (4)	Oct (18)	Nov (9)	Dec (5)
2010	Jan	Feb (3)	Mar (1)	Apr (8)	May (10)	Jun (8)	Jul (10)	Aug (18)	Sep (11)	Oct (19)	Nov (14)	Dec (26)
2011	Jan (27)	Feb (38)	Mar (50)	Apr (128)	May (54)	Jun (116)	Jul (79)	Aug (163)	Sep (21)	Oct (14)	Nov (19)	Dec (9)
2012	Jan (7)	Feb (34)	Mar (34)	Apr (50)	May (70)	Jun (23)	Jul (8)	Aug (24)	Sep (35)	Oct (40)	Nov (276)	Dec (34)
2013	Jan (25)	Feb (23)	Mar (12)	Apr (59)	May (31)	Jun (11)	Jul (21)	Aug (7)	Sep (18)	Oct (11)	Nov (12)	Dec (18)
2014	Jan (37)	Feb (22)	Mar (9)	Apr (10)	May (38)	Jun (20)	Jul (15)	Aug (4)	Sep (4)	Oct (3)	Nov (8)	Dec (5)
2015	Jan (13)	Feb (34)	Mar (27)	Apr (5)	May (12)	Jun (10)	Jul (12)	Aug (3)	Sep (1)	Oct (13)	Nov	Dec (6)
2016	Jan (1)	Feb (1)	Mar (17)	Apr (139)	May (120)	Jun (90)	Jul (10)	Aug	Sep	Oct (11)	Nov (6)	Dec (2)
2017	Jan (24)	Feb (8)	Mar (7)	Apr (2)	May (5)	Jun (11)	Jul (5)	Aug (9)	Sep (6)	Oct (4)	Nov (2)	Dec (4)
2018	Jan (7)	Feb	Mar (4)	Apr (6)	May (10)	Jun (6)	Jul (7)	Aug	Sep (7)	Oct (5)	Nov (3)	Dec (3)
2019	Jan (3)	Feb	Mar (4)	Apr (3)	May (2)	Jun (6)	Jul (3)	Aug (2)	Sep	Oct (2)	Nov (12)	Dec (1)
2020	Jan (3)	Feb (1)	Mar (2)	Apr	May	Jun	Jul	Aug (1)	Sep	Oct (1)	Nov	Dec
2021	Jan	Feb	Mar	Apr (3)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

psidev-pi-dev Mailing List for Proteomics Standards Initiative (Page 133)

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