Telecon: 2007 03 16
From Genomic Standards Consortium
2 pm GMT, March 16, 2007
CAMERA requirements for MIGS/MIMS - 1st of regular Friday telecons - focus on GML and FuGE
Present: Aaron (A), Nelson (N), Rekha, Norman (NM), Andy Jones (AJ), Renzo, Tanya, Dawn
AGENDA
RK: GML
All: review of the sum CAMERA proposed changes (doc and XML schema) - bring items to completion
Notes:
Precirculation of notes about FuGE by Aaron prompted us to invite Andy Jones, lead FuGE developer to this call
Renzo to summarize GML
N: we should cover again the changes we want to the requirements doc, Aaron was tasked with updating the schema and realized we hadn't really finalized some of our thinking, could we do that at the end
DF - have you had a chance to edit the main requirements doc, two of the 4 items seemed to be clear now
A: yes, it is getting clearer, but for example for ontology property we can do this as in FuGE or by RDFa
DF: okay, we will, return to this at the end in order of GML, FuGE, requirements doc
Renzo circulated his doc again - can't resolve the wiki pages in Germany, CAMERA no problem will test
RK: let's go to chapter 3 - trying to break this down to schema changes, the role of GML could be to make clear when discussing biosource / biomaterial that the first physical sample (water, soil etc) is the first point of any investigation, in GML this is a feature that should be georeferenced - we need to get this conceptual point clear
A: use of GML is only necessary when we have a georeference
RK: I'm saying that GML should be used for the Biomaterial - could be adapted for other things - like the standardization of measurement; GML does not model an investigation with many steps and protocols; GML focuses on describing some physical entity on earth and then for investigation FuGE comes into play
AJ: yes, everything you are discussing sounds like a core FuGE case study with the exception of geographic location
N: Renzo, your examples suggest we should be able to map the geospatial information in MIGS/MIMS to GML documents
RK: yes
DF: went to NSF MO meeting and saw a presentation on the Alpine MO - concept it to record environment (x, y, z) and then information about a sample (adds t). I think this is related to Renzo's point about whether environment is parent or child; asked about how CAMERA data is currently held as it was useful to think about modelling this data as a relational schema
N: postgres / Java - but not in a structured way; priority: we need a standard that the community agrees upon; that what the communities defines as a description of a metagenomic study can be used to implement; this will facilitate input and output
AJ: technical detail, should be implementation independent and this is the benefit of an object model
DF: yes, of course agreed
N: if you have a sample in MIGS; the question is if we ask for geographic location to be required and someone defines it in GML, will it be sufficient; if so then the notion of a GML features needs to be an optional element in a MIGS schema
RK: should require x, y, z, t; but GML doesn't require this - could be an arbitrary name to a location; we need this to make data comparable
N: "track" example was of interest; we have discussed this too; this is more precisely the way the data was collected, but we haven't modelled it this way can't provide it with a simple x, y, z and t
NM: is this not a collection of x, y's, could it be derived
RK: yes, there is a concrete example in the doc
N: our concept of path in MIGS is just x, y's, no concept of time
AJ: keep the requirements in the checklist - what is needed to support it can be more flexible in the data model - the XML and allow optional fields
Consensus -
- need for x, y, z, t in MIGS (not just a place name, for example);
- we should make it clear that our geographic location can be mapped to GML; and provide some examples
- we accept that GML has far more complexity and richness than we need in the biological-centric view; e.g. tracks are not relevant (yet!) to any genomic or metagenomic samples (with exception of GOS)
- let's keep it simple
Okay let's switch to FuGE:
A: has been reading about FuGE, I found the following two documents to be useful when examining how we
might utilize FuGE:
FuGE in Plain English: http://fuge.sourceforge.net/dev/fugeInPlainEnglish.pdf
Nature community document: http://www.nature.com/nbt/consult/pdf/Jones.pdf
AJ: We are currently putting the FuGE specifications through the PSI document
process (http://www.psidev.info/index.php?q=node/265) to standardize on a
version 1, so the latest docs are there rather than at our own site.
Feel free to comment on the specs at the PSI site (the specs are currently in public comment period).
AJ: from the FuGE side, when other domains take FuGE it can be done in two ways; use it as is or extend it Assay is a ProtocolApplication; if it's really important what you name it, you could extend from there as 'Assay'
DF: is not Assay a ProtocolApplication in I/S/A thinking?
AJ: in RSBI model; Assay is a set of ProtocolApplications linking the data and material together; FuGE is a guide for building a standard
N: DF - how does this fit into your plans; should we try to go with FuGE for ontology property
DF: yes, if we want to be moving to FuGE-compliance, and that would be great
DF: we have discussed retrofitting the MIGS/MIMS checklist and XML schema to FuGE-OM to be compliant and since both are still malleable to see what we can learn about how to structure MIGS in the process; yes we are keen; Allyson Lister has offered in the past to lead this; are you willing to lead this
AJ: feel free to email me and we can work on specific examples
N: are you willing to lead this
AJ: need to get familiar with checklist and XML schema, but we now have a lot of practice with this and it shouldn't take more than a few days
Consensus: we should try to make MIGS/MIMS FuGE-compliant - Andy agreed to lead this
N: maybe we can also be email finish up the proposed changes to MIGS/MIMS - by next Friday
DF: okay, let's try
