Menu
▾
▴
Re: [Psidev-pi-dev] FW: [Fuge-devel] FuGE-light...
|
From: Martin E. <mar...@ru...> - 2008-02-14 10:14:16
|
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:fug...@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:fug...@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:fug...@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:fug...@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:fug...@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:fug...@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:fug...@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:fug...@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 |
