[GeoSciML] GeoSciML 3 dependencies [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Wed Nov 21 20:37:10 EST 2012


I agree.  A parent geosciml.xsd schema that imports all the 13 component app schemas would be useful.  That way all GeoSciML services can be covered by a single geosciml.xsd in the WFS header.  In fact Clemens Portele created his own personal geosciml.xsd which did this when building his GSML v3 services.

__________________________________________________________________

Ollie Raymond
Senior Geologist  - Information Management  |  Continental Geology Section
Minerals and Natural Hazards Division  |  GEOSCIENCE AUSTRALIA

Oceania Councillor & Interoperability Working Group
IUGS Commission for the Management and Application of Geoscience Information
__________________________________________________________

Phone:  +61 2 6249 9575    Fax:  +61 2 6249 9971
Email:  Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>    Web:  www.ga.gov.au<http://www.ga.gov.au/>
Cnr Jerrabomberra Avenue and Hindmarsh Drive   Symonston   ACT
GPO Box 378   Canberra   ACT   2601   Australia

Applying geoscience to Australia's most important challenges




________________________________
From: geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org [mailto:geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org] On Behalf Of Simon.Cox at csiro.au
Sent: Thursday, 22 November 2012 12:19
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] GeoSciML 3 dependencies

Or perhaps create another 'container' package/schema, which imports just structure and unit, to be used for instances that need these?

Simon

From: geosciml-bounces+simon.cox=csiro.au at lists.opengeospatial.org [mailto:geosciml-bounces+simon.cox=csiro.au at lists.opengeospatial.org] On Behalf Of Bruce.Simons at csiro.au
Sent: Thursday, 22 November 2012 8:29 AM
To: geosciml at lists.opengeospatial.org
Subject: [ExternalEmail] [GeoSciML] GeoSciML 3 dependencies

Hi all,
The current GeoSciML dependencies (see GeoSciML package dependencies (internal)) mean that the GeologicUnit package does not import the GeologicStructure package, and vice versa.
Therefore the GeologicUnit schema does not import the GeologicStructure schema.

Consequently gsml:GeologicFeatureRelation will only provide GeologicEvent (from the EarthMaterial import!) or GeologicUnit as options for the gsml:relatedFeature. See for example the BGS instance document BGS_MappedFeature_GeologicUnit_manualEdit.xml.

Importing http://schemas.geosciml.org/geologicstructure/3.1/geologicStructure.xsd into the instance allows all the GeologicStructure features to be used in the gsml:GeologicFeatureRelation.

Should the UML reflect this dependency? That is, GeologicUnit imports GeologicStructure, and vice versa. Also applies to the other GeoSciML packages.
If so, it creates a circular dependency. This looks bad (and the schema generation via FullMoon will probably fail) but reflects the real world.

This suggests that if we want to express the ability for any GeoSciML package to use any other package in GeoSciML v4 then we have to either allow circular dependencies, or ensure all circular dependencies are contained in the one application schema (ala GeoSciML v2).


Bruce Simons
SDI Information Modeller
Land and Water/ Environmental Information Systems
CSIRO
E bruce.simons at csiro.au<mailto:bruce.simons at csiro.au> T +61 3 9252 6514 M +61 429 177155
PO Box 56, Highett, Victoria, 3190
www.csiro.au<http://www.csiro.au> | www.csiro.au/science/Environmental-Information-Systems<http://www.csiro.au/science/Environmental-Information-Systems>

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
Please consider the environment before printing this email.


Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.
-------------------------------------------------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20121122/6b33c669/attachment.htm>


More information about the GeoSciML mailing list