[GeoSciML] [ExternalEmail] Wellington Meeting Agenda item: "Consistent use of patterns - are there changes required to allow better use between overlapping domains?"

Simon.Cox at csiro.au Simon.Cox at csiro.au
Thu Aug 2 04:51:05 EDT 2012


Bruce -

I think I agree with your proposals for 1, 3, 4 and 5.
(I don't have an opinion about 2 and 6, they are probably good too.)

Related to 5. the current proposal for the revision of ISO 19109 underway augments the General Feature Model with an association class (also a metaclass) on the carrier-of-characteristics association, called 'ValueAssignment'.
OM_Observation is indicated as one potential <<instanceOf>> this metaclass. The goal is to provide a hook for the observation-related property-value metadata.

In the XML, the expectation is that xlinks could be used. As we know, they are generally already available on complex-content properties, but not on simple-content properties, like Measure, Category, etc. This is also an issue for using the xlink=nilURI mechanism for default nils, so I would support creating these types in the background XML support.

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, 2 August 2012 1:21 PM
To: geosciml at lists.opengeospatial.org
Subject: [ExternalEmail] [GeoSciML] Wellington Meeting Agenda item: "Consistent use of patterns - are there changes required to allow better use between overlapping domains?"

Hi all,
The GeoSciML meeting in Wellington has the agenda item: Wednesday 12:00 - 12:40 is "Consistent use of patterns - are there changes required to allow better use between overlapping domains?".

This arose from my work in non-geology domains. Below are some observations on the difficulties that GeoSciML may cause to other domains. I am circulating this to aid discussion at the Wellington GeoSciML meeting, and to encourage those who are unable to attend to contribute via the mailing list or wiki.

As part of EarthResourceML and OzSoilML development, I have attempted to re-use both the modelling patterns and specific features established as part of GeoSciML. In some cases decisions made by us, based on a geology-centric viewpoint, have made re-use outside the geoscience domain difficult or impractical.
I have identified below, those that immediately come to mind. The GroundWaterML community may also have examples.
Some of these may be able to be resolved within the GeoSciML community, and should be considered as part of GeoSciML 4 development. However, an appropriate way forward may be to set up, if one doesn't already exist, a 'cross-domain' OGC working group with the intention to ensure/facilitate interoperability and re-use between the domains.


1.       MappedFeature - The 'MappedFeature' feature is a very useful construct. However the mandatory 'specification' property binding it to a 'GeologicFeature' largely prevents its use outside GeoSciML. As such, EarthResourceML created a "MiningFeatureOccurrence" feature and OzSoilML a "SpatialEntity" feature, whereas some INSPIRE proposals just use a geometry property, missing out on the advantages MappedFeature brings.  If MappedFeature were associated to a "GFI_Feature" (property = 'specification') then it could be readily re-used. The GeoSciML profile would indicate that the GFI_Feature must be a GeologicFeature.

2.       EarthMaterial:color - This property is in the NADM conceptual model, but is not appropriate for the "Void" subtype they had included. In addition, the simplistic colour as value fails to allow describing the state of the material (moist, dry) when the colour (color) assessment was made, important for the soil community.  Remove this property and use the PhysicalProperties:PhysicalDescription class.

3.       CompoundMaterial:compositionCategory and CompoundMaterial:geneticCategory - CompoundMaterial provides a mechanism to combine EarthMaterials that could be used by other domains, such as for example "SoilMaterial". However, these two properties are 'rock' specific and don't make sense from a soil perspective. Move both these properties to RockMaterial.

4.       PhysicalProperty - this is a soft-typing that readily allows re-use by other domains. It could be improved by a tighter linking to O&M (somehow? - see 5) to include the metadata O&M provides (method, date parameters etc).

5.       estimatedProperty procedures - Similar to PhysicalProperty, there is a generic issue that it may be appropriate to provide the methodology, error etc with any estimated property. For example the soil particle size and proportion could be estimated based on the field texture classification. This is different to a measured value using sieves. Delivering this as part of ConstituentPart does not allow specifying the process used to calculate the grain sizes and percentages. A set of OGC generic 'Observation' Measure/Quantity, Category, QuantityRange data types that includes optional links to the O&M metadata and can be used by all domains is required.

6.       particleGeometry and constituent:ConstituentPart:particleGeometry - there is inherent ambiguity in which to use, and therefore how to query. The principle is if there is only one particle type then use 'CompoundMaterial:particleGeometry', if more than one then for each constituent use 'CompoundMaterial:constituent:ConstituentPart:particleGeometry'. Remove CompoundMaterial-particleGeometry association and where there is only one constituent ConstituentPart:role = "sole constituent".
No doubt there are other areas that we may wish consider changing to improve the cross-domain usability of GeoSciML.
I welcome your feedback.

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

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


More information about the GeoSciML mailing list