[GeoSciML] GeoSciML 3 dependencies [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Wed Nov 21 22:12:14 EST 2012

Hi Bruce,

"Should the UML reflect this dependency?"  It's not actually a dependency of GeologicFeatureRelation on GeologicStructure.  GeologicFeatureRelation points to (ie, depends on) GeologicFeature.  GeolUnit and GeolStructure are extensions of GeologicFeature which allows them to be used in a GeologicFeatureRelation if you import their respective schemas, but there is no dependency  of GeologicFeatureRelation on GeolUnit or GeolStructure.

This is the same situation as OM_Observation -> result -> Any.  You can import any object from any schema to be the result of an observation.  But OM_Observation does have dependencies on all schemas.


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 Bruce.Simons at csiro.au
Sent: Thursday, 22 November 2012 11:29
To: geosciml at lists.opengeospatial.org
Subject: [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
E bruce.simons at csiro.au T +61 3 9252 6514 M +61 429 177155
PO Box 56, Highett, Victoria, 3190
www.csiro.au | www.csiro.au/science/Environmental-Information-Systems

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/de220777/attachment.htm>

More information about the GeoSciML mailing list