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

Simon.Cox at csiro.au Simon.Cox at csiro.au
Mon Jun 13 20:29:18 EDT 2011


1.       I never really liked having 'incrementalDisplacement' as a property of GeologicEvent. It looks like there is a missing specialization here (GeologicEvent <|-- StructureEvent)  I think that makes the problem go away.

2.       Likewise.

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: Monday, 13 June 2011 9:46 PM
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.

Cheers,
Ollie

_______________________________________________________________________

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?
GeoSciMLers:

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?
E.g.
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.

Simon







[cid:image001.gif at 01CC2A6C.667C04A0]

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/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110614/73c9441f/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/73c9441f/attachment.gif>


More information about the GeoSciML mailing list