[Fuge-devel] Fixed units

[Nigel Hardy]

Is there any recommendation or best practice for extending Parameter
and/or AtomicValue to fix the _unit value?

The immediate example is that the NMR people want their magnates in
tesla.My assumption would be build an extended schema which carries a
reference to, says, UO:0000228 in unit.obo and which has this as a
read-only default in and extension to AtomicValue.

Is this how it "should" be done? Are there examples?

Thanks

Nigel

[Miller, Michael D (Rosetta)]

hi nigel,

i don't recall the question coming up before but i think you are on the
right track.

my thought would be to extend OntologyTerm by a TeslaOntologyTerm where
the term and termAccession had the appropriate default values below and
those attributes had 'Is Read Only' set to true, then extend AtomicValue
(or whatever) by TeslaAtomicTerm and extend the Unit association with a
TeslaUnit association to TeslaOntologyTerm.

TeslaOntologyTerm could then be used elsewhere.

then hope that this all makes sense to AndroMDA when it generates the
XML Schema!

cheers,
michael

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Fuge-devel mailing list
Fuge-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuge-devel

[Jones, Andy]

Hi Nigel and Michael,

Michael's proposal looks good and this may work okay with some fixes to the AndroMDA cartridge that generates the schema.

An alternative that you might want to look at is using the mapping file that we have adopted for all PSI formats: http://www.psidev.info/index.php?q=node/304

We are in fact using a simplified FuGE schema in the PSI format which has CVParams with the following structure:

<Modification location="1" residues="M" monoisotopicMassDelta="15.994919">
<cvParam accession="MS:1001524" name="fragment neutral loss" cvRef="PSI-MS" value="63.998291" unitAccession="UO:0000221" unitName="dalton" unitCvRef="UO"/>
</Modification>

The validator software reads the mapping file and checks that "fragment neutral loss" is allowed in this part of the schema, it has the correct data type (xsd:double) and that a unit of Daltons is provided from UO. This obviously has a lot less flexibility than the ontology structure in FuGE but now that we have validation software that can be adapted to all PSI formats very easily, I've come round to this format.

I think the mapping file / validator idea could also be adapted to full FuGE relatively easily, and I'd be happy to help with this if you're interested in taking this route.

Cheers
Andy

[Nigel Hardy]

Andy,

thanks for this (sorry for the summer-time delay).

Can you point us to formal material on the "simplified FuGE schema"? I
can see FuGElight_working.xsd under psi-pi on the Google code repository
but how, logically, was it derived?

Nigel

[Jones, Andy]

Hi Nigel,

At the moment the FuGE-light being used in mzIdentML v1-candidate (PSI-PI) and GelML v1.1 candidate has no formal status with respect to FuGE. A number of changes have been made manually to the XSD to make it simpler to use in practice for building extensions, and for building software around those extensions.

The FuGE v1 schema was designed around UML concepts so that the system works well as long as you're prepared to accept the entire UML/MDA development strategy. If you want to work just with the XSD, this is possible, but the XSD is a bit unwieldy because it uses some XSD structures that attempt to mirror entirely the functionality of UML - every UML class is represented by a global complexType and a global element. UML inheritance is mapped to xsd:extension and xsd:substitutionGroup. Some of these features make writing code for FuGE more complicated than strictly necessary, so some of this has been re-designed in FuGE-light to use more standard XSD design patterns (e.g. replacing substitutionGroups with xsd:group and xsd:choice)

Some other minor(ish) changes have been made:

- Various groups have also reported that the top-level Describable attributes, while useful for in-house extensibility, overly complicate data exchange since it allows too many options for how some information could be encoded, so Describable has been removed from the top-level entirely.
- The format has a much simplified structure for encoding cvParams - the OntologyIndividual / ObjectProperty / DataProperty system is not simple to understand and for 99% of PSI use cases, simpler CVs are fine.
- The attribute "identifier" has been changed to "id" - this appears to be standard encoding of unique IDs in XSD, recognised automatically by various software apps.

The resulting XSD is thus intended to cover only one of the main use cases for FuGE: "(iii) a framework for building new data formats
with a common structure for techniques that have specific requirements.". For building a LIMS or a workflow format to wrap around existing formats standard FuGE v1 should still be used.

It would be simple to write a mapping file to convert FuGE-light XML to FuGE, the alternative mapping would be slightly more difficult because some features have been restricted. The future of FuGE-light isn't completely clear but I would like to explore this as an easier route into using FuGE. The UML approach is fine for groups wanting a heavy-weight system with dedicated people working on it, but is perhaps overly complex for people just wanting to try out building an extension of FuGE and having a working XSD.

I would like to encourage more discussion about this, because I've received feedback from quite a few groups that they'd like to start using FuGE but just don't know how to get going with it.
Cheers
Andy

> >> --------- Enter the BlackBerry Developer Challenge This is your

> >> chance to win up to $100,000 in prizes! For a limited time, vendors
> >> submitting new applications to BlackBerry App World(TM) will have the
> >> opportunity to enter the BlackBerry Developer Challenge. See full
> >> prize details at: http://p.sf.net/sfu/Challenge
> >> _______________________________________________
> >> Fuge-devel mailing list
> >> Fuge-...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/fuge-devel
> >>
> >
> > ----------------------------------------------------------------------

> > -------- Enter the BlackBerry Developer Challenge This is your chance

> > to win up to $100,000 in prizes! For a limited time, vendors
> > submitting new applications to BlackBerry App World(TM) will have the
> > opportunity to enter the BlackBerry Developer Challenge. See full
> > prize details at: http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > Fuge-devel mailing list
> > Fuge-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/fuge-devel
> >

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july

[Nigel Hardy]

Andy,

thanks for that. I will experiment with FuGE-light on that basis.

Two points have already come up.

1. Am I correct that there is no "top level" element (c.f. <FuGE>)
and that this is created as part of a specialisation (e.g.
mzIdentML in mzIdentML_working.xsd)
2. I cannot get mzIdentML_working to work because of the use of
<unique> elements as the targets of <keyref> elements. I am
working with XMLSchema 1.0 tools. Is this part of 1.1?

[Jones, Andy]

Hi Nigel,

> Two points have already come up.
>
> 1. Am I correct that there is no "top level" element (c.f. <FuGE>)
> and that this is created as part of a specialisation (e.g.
> mzIdentML in mzIdentML_working.xsd)

Correct, FuGE-light could be viewed as a library of useful structures to use only in other formats.

> 2. I cannot get mzIdentML_working to work because of the use of
> <unique> elements as the targets of <keyref> elements. I am
> working with XMLSchema 1.0 tools. Is this part of 1.1?

mzIdentML uses key and keyrefs to check that foreign keys have been used correctly (FuGE leaves this checking to applications or extensions in case references are given to objects in a different file or in a database). Key and keyref is recommended way to check foreign keys in XML. I can't find the XSD 1.0 specifications - what tools are you using?

Cheers
Andy

> -----Original Message-----
> From: Nigel Hardy [mailto:n...@aber.ac.uk]
> Sent: 07 August 2009 10:06
> To: fuge-...@lists.sourceforge.net
> Subject: Re: [Fuge-devel] Fixed units
>

[Nigel Hardy]

Jones, Andy wrote:
>> 2. I cannot get mzIdentML_working to work because of the use of
>> <unique> elements as the targets of <keyref> elements. I am
>> working with XMLSchema 1.0 tools. Is this part of 1.1?
>>
>
> mzIdentML uses key and keyrefs to check that foreign keys have been used correctly (FuGE leaves this checking to applications or extensions in case references are given to objects in a different file or in a database). Key and keyref is recommended way to check foreign keys in XML. I can't find the XSD 1.0 specifications - what tools are you using?
>

Yes, this is an excellent step forward. You will remember that we argued
for typed constraints in FuGE to remove the ambiguities of untyped
ID/IDREFS - I think it was AndromMDA which prevented this.

My problem now is that despite hard reading of the 1.0 spec, I cannot be
sure whether the refer attribute of a <keyref> element can be the name
of a <unique> element. I had always worked with <key> elements and the
1.0 tutorial clearly suggests that this must be so. The formal 1.0
"structure" specification is, of course, tough going and I cannot see a
specific answer.

To take specific extracts from mzIdentML, we have

<xsd:unique name="PK_SEQ">
<xsd:selector xpath="./psi-pi:SequenceCollection/*"/>
<xsd:field xpath="@id"/>
</xsd:unique>

and (as an example)

<xsd:keyref name="FK_SII_PEP" refer="psi-pi:PK_SEQ">
<xsd:selector
xpath="./psi-pi:DataCollection/psi-pi:AnalysisData/psi-pi:SpectrumIdentificationList/psi-pi:SpectrumIdentificationResult/SpectrumIdentificationItem"/>
<xsd:field xpath="@Peptide_ref"/>
</xsd:keyref>

I would have expected to see

<xsd:key name="PK_SEQ">
<xsd:selector xpath="./psi-pi:SequenceCollection/*"/>
<xsd:field xpath="@id"/>
</xsd:key>

because I thought only keys could be the target of keyrefs.

My first attempt with the schema was to translate it to rng (I am still
an emacs fan, there is an excellent XML mode there driven by rng). The
rngconv program complained that the targets of all keyrefs were not
keys. Editing all the <unique> elements to be <key> elements solved the
problem.

Since you reply I have tried xmllint and NetBeans (not sure which parser
that uses) and they both accept the original schema. xmllint detects
illegal values of (as an example)
SpectrumIdentificationItem/@Peptide_ref, but while NetBeans (6.1) checks
the schemas we know that it does not check referential integrity anyway.

So I was surprised. Perhaps a <unique> is a legal target for a <keyref>.
I will try to look further and/or read the 1.0 spec again.

Nigel

[Nigel Hardy]

Yep - mea cupla - unique is fine.

rngconv is rather an annoyance for me!

Nigel