[auscope-geosciml] The status of GeoSciML v3 - repackaging [SEC=UNCLASSIFIED]

Thu Jun 16 00:02:23 EDT 2011

I'm not convinced GeologicAge belongs in Geologic-Core. I'd rather see it 
managed separately to GeologicRelation.

I can't see GeologicUnit in the dependency diagram. Am I missing 
something?

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

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

From:   <Simon.Cox at csiro.au>
To:     <auscope-geosciml at lists.arcs.org.au>
Date:   16/06/2011 01:50 PM
Subject:        Re: [auscope-geosciml] The status of GeoSciML v3 - 
repackaging [SEC=UNCLASSIFIED]
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au

I just wanted to check there are no cycles in the dependencies. 
Looks OK. Will be better still if GeolAge collapsed into Core. 

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: Thursday, 16 June 2011 10:37 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] The status of GeoSciML v3 - repackaging 
[SEC=UNCLASSIFIED]

Happy to leave GeologicAge in Core.  What do others think about the 
re-packaging?

  >> What does the package dependency diagram look like? 

Like the work of a demented spider on crack.  (and that’s without showing 
any of the ISO/SWE schema dependencies!)

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: Wednesday, 15 June 2011 5:13 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] The status of GeoSciML v3 - repackaging 
[SEC=UNCLASSIFIED]

Sweet. 

4. ‘Collection’ is a convenience class (and package) that is not really a 
conceptual class so does not belong in GeoSciML Core. 
It should have its own package, like you found. 

5., 6. I’d be inclined to leave GeologicAge inside the core. Geology is a 
fundamentally historical science, with events and ages at its core. 

Otherwise, it looks a big improvement to me. 
What does the package dependency diagram look like? 

Simon 

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: Wednesday, 15 June 2011 2:59 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] The status of GeoSciML v3 - repackaging 
[SEC=UNCLASSIFIED]

Hi Simon,

I’m OK with handling the repackaging proposals.  I have spent most of the 
afternoon going over the options, and here are my findings...

1.      Bruce’s repackaging proposal of separating GeologicRelation and 
GeologicFeature, won’t work because of mutual dependency between 
GeologicFeatureRelation and GeologicFeature (the GeologicFeatureRelation 
association class is encoded as having links both to and from 
GeologicFeature).  This makes the GeologicFeature and GeologicRelation 
packages inseparable.

2.      Separating out the GeologicUnit package from GeoSciML-Core is no 
problem.
3.      Simon and Bruce’s repackaging proposal to separate 
GeologicStructure from GeoSciML-Core will work if we make a small 
amendment to the model to insert a GeologicStructure:DisplacementEvent 
class as a subtype of GeologicAge:GeologicEvent  (something that looks 
eerily like what we had in GSML v2)

4.      Simon’s proposal to separate EarthMaterial from 
GeoSciML-Core:(GeologicAge & Collection) has a mutual dependency hitch. 
GeoSciML-Core:Collection:GSMLItem imports EarthMaterial, and 
EarthMaterial:(metamorphicDescription & alterationDescription) imports 
GeoSciML-Core:GeologicEvent. 
a.      I looked at moving metamorphicDescription and 
alterationDescription to another package like GeologicUnit, but that just 
introduces problems with dependencies for GeologicUnit.
b.      Separating out the Collection package from GeoSciML-Core would 
allow EarthMaterial to be made into a valid separate schema.
5.      The GeologicAge package can validly sit outside of GeoSciML-Core 
only if EarthMaterial is also outside of GeoSciML-Core.
6.      GeologicAge can sit inside or outside of GeoSciML-Core if 
EarthMaterial as a separate schema outside of GeoSciML-Core
7.      The picture below shows what it would look like if GeoSciML-Core 
was split to the full.  The package dependencies for this model structure 
are all valid.

_______________________________________________________________________

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 62479992  |  Email: 
oliver.raymond at ga.gov.au  |  Google Map 
_______________________________________________________________________

--- 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: Wednesday, 15 June 2011 1:22 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] The status of GeoSciML v3 
[SEC=UNCLASSIFIED]

Ollie – 

Do you need me to fully complete the re-packaging proposal, or can you 
work from my suggestions? 

Simon

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: Wednesday, 15 June 2011 10:17 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] The status of GeoSciML v3 [SEC=UNCLASSIFIED]

Hi all,

The continued discussions around various parts of GeoSciML v3 this close 
to Edinburgh indicate to me that we still have issues with v3, and I have 
stopped doing any work on the current v3 RC3 schemas.  Generating a new 
set of schemas at this point (eg, after finalising 
discussion/acceptance/modelling of Simon and Bruce’s suggestions) would 
take us almost right up to Edinburgh.  I realise that the v3 schemas have 
been a long time in gestation, but the testing of the RC1 and RC2 release 
candidates, and use of the GSMLv2 and O&Mv2 schemas in production 
environments have raised some valid points that needed addressing before 
final release of v3 .

I propose that the model discussions for v3 be halted once and for all at 
Edinburgh in 2 weeks time.  I will compose the model meeting agenda so 
that we draw a line under absolutely everything with the model at 
Edinburgh.  Any model changes not finalised at Edinburgh will be TOO LATE, 
so if you want issues dealt with, please submit fully modelled solutions 
to your issue immediately. 

Francois and I have a pretty good system for generating and checking 
schemas now (only editing the nillable tags on non-feature classes still 
takes up some time) and we could have new RC3 schemas done by the end of 
July.  The RC3 schemas will be designed to be the final release schemas 
for v3.0.0.

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 62479992  |  Email: 
oliver.raymond at ga.gov.au  |  Google Map 
_______________________________________________________________________

--- This message was created with 100% recycled electrons ---
 _______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110616/1deb0458/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 38157 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110616/1deb0458/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 18119 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110616/1deb0458/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 34882 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110616/1deb0458/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 46922 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110616/1deb0458/attachment-0003.jpeg>