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

Bruce.Simons at dpi.vic.gov.au Bruce.Simons at dpi.vic.gov.au
Mon Jun 13 19:03:28 EDT 2011

Last year I suggested moving GeologicUnit and GeologicStructure out of 
GeoSciML-Core, but received no support then. Clearly I am in favour of an 
improved refactoring but there is potentially considerable discussion 
required to determine what should be in GeoSciML-Core.  Simon has 
suggested one option, I'd prefer to see EarthMaterial, GeologicFeature, 
Collection remain in GeoSciML-Core, with GeologicUnit, GeologicStructure, 
GeologicAge and GeologicRelation have their own package.

Given how close the Edinburgh meeting is, and the need to determine how to 
refactor I think we have missed the opportunity and will need to leave it 
to an OGC DWG.

Regarding instance documents, like Eric I have not produced any yet - none 
of the current GeoSciML v3 ones validate in Altova XMLSpy so AFAIC we do 
not yet have a valid schema.  As such any decision will not set back work 
I have done (trying to fix gsml:Borehole).

Bruce Simons
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons
Level 9, 55 Collins St
PO Box 4440
Melbourne, Victoria, 3001

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155

From:   "Boisvert, Eric" <Eric.Boisvert at RNCan-NRCan.gc.ca>
To:     <auscope-geosciml at lists.arcs.org.au>
Date:   14/06/2011 03:13 AM
Subject:        Re: [auscope-geosciml] Opportunities for re-factoring 
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au

It depends if there is a strong requirement to have that version of the 
schema before Edinburgh meeting for testing.  Honestly, I just started to 
work on instance documents so I don't have a large backlog to deal with. 
Changes to the schema at this point (and if I understand correctly) is 
mostly rework the schemaLocation, namespaces (and prefixes) of the same 
instance documents and not a change to the model itself so it's not a 
moving target as far as the model is concerned.  In short, if the work on 
RC3 schemas instance is meant to provide input for final version in 
Edinburgh and those instance are about the same model (minus the packaging 
artefacts), I don't see it as a big problem (exclusing the fact that we 
will punish those who made their instances / services early and reward 
procrastinators like me) - we can still use those instance has a way to 
test the model.  On the other hand, if this actually changes a significant 
part of the model that was meant to be tested and the schema are delayed 
up to the eleventh hour.. I think it's too late.  If we count repackaging, 
and generating / testing schemas involving 2 persons 13 time zones apart, 
we are looking probably at one week before the schemas are ready.
BTW. is there a plan to put into place a formal RC (request change) 
mechanism à la OGC or is this question to be lumped into a bigger 
discussion about having GeoSciML as a formal OGC DWG ?

De : auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de 
Oliver.Raymond at ga.gov.au
Envoyé : 13 juin 2011 09:46
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] Opportunities for re-factoring 

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 

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 

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

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


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 | Web http://www.csiro.au
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110614/c320362e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3627 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110614/c320362e/attachment.gif>

More information about the GeoSciML mailing list