[auscope-geosciml] Opportunities for re-factoring GeoSciML? [SEC=UNCLASSIFIED]

Simon.Cox at csiro.au Simon.Cox at csiro.au
Mon Jun 13 20:25:46 EDT 2011

The reason for re-factoring is that GeoSciML altogether is fiendishly elaborate and complicated.
Putting stuff in separate packages/namespaces allows for implementation/conformance testing at the level of those packages.

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Laxton, John L.
Sent: Monday, 13 June 2011 9:52 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] Opportunities for re-factoring GeoSciML? [SEC=UNCLASSIFIED]

Hi Ollie,

I think there has to be a very good reason for doing this which I'm not entirely convinced of. I agree we must try and ensure GeoSciML is not a moving target any more but my inclination is to leave it as it is and try get v3 finished as quickly as possible.


From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au
Sent: 13 June 2011 14:46
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] Opportunities for re-factoring GeoSciML? [SEC=UNCLASSIFIED]

There are a couple of mutual dependency glitches to iron out before Simon's suggestion could be done:

1. GeoSciMLCore-GeologicEvent <-> GeologicStructure-DisplacementValue = mutual dependency between GeoSciML-Core and GeologicStructure

2. (GeologicStructure-GeologicStructure -> GeoSciML-Core-GeologicFeature) + (GeoSciMLCore-GeologicEvent -> GeologicStructure-DisplacementValue) = mutual dependency between GeoSciML-Core and GeologicStructure

Apart from the above dependency glitches which would need remodelling, we are a long way down the track of version 3 now.  I'm currently putting the finishing touches to the v3 rc3 schemas and was hoping that this RC would be the last one.  A refactor at this stage (with 3 new app schemas and namespaces) would be a pretty major reconstruction of what we've been working on with v3 RC's to date (and Francois and I will effectively discard our last week's work on generating/checking the v3 rc3 schemas if we want to refactor GeoSciML now).

I would love to say "Put this off until version 4".  However, I am loathe to give anyone a further chance to label GeoSciML as a "moving target" with yet another refactoring at version 4.  So if we want to do any more package refactoring, I would strongly urge that we do it now or not at all.  If the GeoSciML team is amenable to Simon's refactoring suggestions, Francois and I would stop work on the current v3 rc3 schemas and we'll generate a new set of schemas after the model is refactored.

Given the implications of Simon's suggestion, could I ask for comments from all of the GeoSciML team with some urgency.  My personal feeling is one of ambivalence to further splitting up of the GeoSciML-Core application schema.  I'm not convinced of the need for it, but I would not be opposed to the idea if the majority of the GeoSciML community was for it.



Ollie Raymond

Project Leader
National Geological Maps and Data Standards Project
Geoscience Australia

Interoperability Working Group
IUGS Commission for the Management and Application of Geoscience Information

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: +61 2 62499575  |  Fax: +61 2 624799917 |  Email: oliver.raymond at ga.gov.au<mailto:oliver.raymond at ga.gov.au>

--- This message was created with 100% recycled electrons ---

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au
Sent: Monday, 13 June 2011 4:51 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] Opportunities for re-factoring GeoSciML?

Following the recent changes to the model relating to relations and derivations, I'd like to ask if this opens up (again) the opportunity for some package refactoring?
i . make GeoSciML-core just contain the GeologicFeature, GeologicRelation and GeologicAge leaf packages (this makes sense as geology is a historical science) and
ii, iii, iv., move GeologicMaterial, GeologicUnit and GeologicStructure,  into their own Application Schemas.

DefiningStructure and BoundaryRelationship should be moved in GeologicStructure, but otherwise I think the dependencies are pretty clean now.


[cid:image001.gif at 01CC2A6C.A8BF5DD0]

Simon Cox | Research Scientist
CSIRO Earth Science and Resource Engineering
ARRC, PO Box 1130, Bentley WA 6102, Australia
Tel +61 8 6436 8639 | Mob +61 403 302 672
Email simon.cox at csiro.au<mailto:simon.cox at csiro.au> | Web http://www.csiro.au<http://www.csiro.au/>

This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110614/3f50027b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3627 bytes
Desc: image001.gif
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110614/3f50027b/attachment.gif>

More information about the GeoSciML mailing list