MOLES Workshop

Venue:  MRC

Time: 10.00 -> 16.30

Original Agenda

  • 10.00-10.30 Bryan: Reprise: MOLES agenda, aims, context within the NERC Science Implementation Strategy, and wider? (Where we are and what we might want).
  • 10.30-11.00 Simon: Summary of MOLES3.2 (looking at some examples)
  • 11.00-11.20 Spiros: Suggested migration to MOLES 3.3
  • 11.20-11.40 Simon: Update on ISO19156 (O&M) (What has happened and might happen).
  • 11.40-12.00 Andrew: Possible futures for MOLES information mode
  • 12.00-13.00 All: Working Lunch/Discussion?
  • 13.00-14.00 Tooling, options and design (from Hollow-World to FullMoon?, to Geoserver, to GeoDjango? and other ORMs? What tools are available? What is Simon's group doing? Given that the UML will move around as we add detail, how can we build something which can be automagically updated.
  • 14.00-15.00 How can we build a prototype tool for editing, persisting and querying MOLES documents? (Who can do what, when with existing funding ... what would need future funding). Are other folks doing things we can leverage?
  • 15.00-15.30 How could we most quickly exploit this tool within the NERC context (what low hung fruit could be gained with an early robust prototype)? What would the roadmap be for more improvements? What if any low hung fruit can Simon get from this work?
  • 15.30-15.45 What options have we to do this with European Funding?
  • 15.45-16.00 AOB including, if time, relationship between ISO19115-part2 and SensorML. Cerif?
  • 16.00 Is where we aim to finish, but we have 30 minutes slack, since we said we have a 16.30 finish.

Actual Agenda from coffee

(In order to take advantage of Beth's attendance, leaving at noon, we had an emergency coffee break and an agenda juggle)

  • 10.50-11.10: Quick summary of the big picture of MOLES, Simon and Bryan, major components, relationship to ISO
  • 11.10-11.30: MOLES infrastructure that needs to exist
  • 11.30-11.45: Opportunities to work with EOF
  • 11.45-12.00: Relationship with other funding programmes and other activities
  • 12.50-13.20 Spiros: Suggested migration to MOLES 3.3
  • 13.20-13.40 Simon: Update on ISO19156 (O&M) (What has happened and might happen).
  • 13.40-14.10 What have we learnt from the examples we built (Olly)? Where to take the information model.
  • 14.10 Onwards:
    • technology components: what needs to exist
    • technology components: what's available
    • roadmap
    • how can we fund specific things
  • 16.00 Other:
    • Discovery Service and MOLES
    • Data Services and MOLES
    • Simulations and MOLES
    • ISO19115 problems ... who can do this ...
    • Annex 3 experts

Meeting Notes

Attendees: Beth, Bryan, Nathan, James, Andrew, Olly, Roy, Simon, Tim. Apologies: Nic.


  • Simon: We are nearly always trying to "measure" ("observe", "understand") something big by actually measuring (etc) something small: key role for "sampling features".
  • Andrew: Most MOLES entities will be INSPIRE data entities, by virtue of their describing things that INSPIRE considers to be data (i.e. INSPIRE definition of data is not just the observational results themselves, the observing system descriptions are data too).
  • MEDIN might consider adopting MOLES at a later date if it proves successful.

EOF Notes

  • EOF is the way the UK will implement SEIS
  • Key questions from EOF point of view:
    • All at a less detailed technical level than we might want to record using MOLES.
  • Direct child of "Living with Environmental Change", LWEC.
  • Andrew imagines that MOLES and EOF could be extended specialisations of what is needed for EMF.
    • Or, when we see how these things pan out, we export EMF documents from MOLES. We needn't angst over these two futures. We work for MOLES and EMF tight relationship, but export is ok too.
  • EOF to be a centralised database.
    • But we note that whether or not the EOF database is centralised, NERC needs the information with which to populate it, which means we need the same information content somewhere in the NERC information systems, and MOLES is the logical place.
  • EOF wants to build tools to manipulate this database.
  • We eventually agreed that MOLES should be a superset of EOF, with the relationship to EMF tbd.
    • This means MOLES needs to address much more detail in the project space.
  • There is significant interest in thrid party data "held for NERC"
  • Timescale:
    • Beth: This time next year we need to tell folks what EOF wants, and what format it should be in.
  • Timeline:
    1. EOF information structure identified by Andrew
    2. Need to create MOLES entities to hold that informatoin
    3. Need to build a prototype tool to populate and view that information


  • ISO19115 not in a fit state to deal with "Project" metadata: people and responsible parties not well handled.
  • ISO19115 about to go into a review phase, now would be the time to suggest changes.
  • No one (internationally) seems to want to take this on.


General agreement that Spiros' ideas look good, we need to take the following one at a time through an "approval process". Send explicit proposal to the list, and get them accepted and then move them into the trunk step by step.

  1. Union to composition (looks good)
  2. Sampling Feature associated with acquisition should really be a location.
  3. Do we really need a MO_SamplingFeature? What does it add? How does it compare to a CMSL_SamplingFeature or the unadorned base class?
  4. Delete MO_Platform
  5. ... there may be more ...
  6. Parse and replace the examples to be consistent.

Action: Andrew and Spiros to discuss and report on the relationship between CSML V3 and MOLES and O&M.

Lessons learned from Olly:

  • Clearer relationships between projects and subprojects needed, particularly when the same "cruise" forms part of multiple projects which themselves may or may not be hierarchically related. We need to revisit this.

O&M Changes

  • Changes to times (as proposed by us)
  • Association between observations added.
  • Hosted procedure added (not so sure we like that now, even though we had a hand in it's inception).
    • Need to work out the ramifications for acquisition. Could be suppressed in our specialisation of O&M in favour of location for acquistion
  • Soon to become a DIS (the step from DIS to FDIS ought to be editorial only).

Annex 3 Deadline

14 December:

  • Action: To nominate Spiros for MOLES and atmospheres



  • There is a UML to relational database tool in the new versions of  HollowWorld. It's a Rob thing we think. What is it, and how does it work?
    • Ideally we go via an ORM, so we can potentially add middleware (ORM to ORM) to go to any database with object entry and retrieval concepts.
  • Bryan keen on building a MOLES prototype using  django, with potentially the first  model being built by hand, but ideally with a tool (modified from the  HollowWorld one if necessary) generating the model automatically from UML at a later date.
  • Discussed WFS for MOLES.
    • Very hard work for clients.
    • Probably easier for clients if we use RDF ...
    • but EMF would reuqire WFS ... but who would build portals to this?
    • Conclusion: restful interface to MOLES XML instances based on relational implementation, followed by, or simultaneous with an RDF and SPARQL implementation.


  • Want to migrate from using GML dictionaries in our serialisation to using SKOS entries
    • Noted that we need the concept of "prototype", the classical exemplar specimen, which is more than just an "altlabel" "preflabel" concept.
  • Netmar funding Roy to do ontology work in this space ...
  •  Gemet API needs to support sparql, Simon on the case.
  • Ontologies need the equivalent of ISO19118. ISO19150 should be doing this, but it appears to be stalled.

Service Issues

  • URIs versus URLS ...
    • We'd need a NERC wide resolver service ...
    • xlink:href is equivalent to rdf:resource

Timescales moving forward

  • Jan: V3.3 (Spiros to propose one at a time)
  • Feb: Next Meeting: Everyone to provide instance examples as object diagrams, and to consider the relationships with SEIS, EMF and EOF.
  • Mar: V3.4 EOF ready
    • Need a prototype to be built based on this.
  • Apr-Jun: BAS to build an implementation prototype.
  • V3.5 ISO19156 compliant (DIS expected in six months)

 Trac Powered
Site hosted at the
British Atmospheric Data Centre
for the