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

Simon.Cox at csiro.au Simon.Cox at csiro.au
Thu Aug 2 20:55:58 EDT 2012


Another approach is that one taken by RDF and the semantic web technologies, where incomplete data or subsets is the expectation.

Properties are defined as first-class resources, as well as classes.
But there is no real notion of 'valid' data instances.
Every serialized data instance is 'incomplete' in the sense that the data provider will provide only what it knows, and there is probably more out there somewhere.
No inferences should be drawn from the absence of a property - the information might be out there somewhere, it just isn't included here.

If a property declaration includes rdfs:domain properties, then the presence of such a property carries the implication that the subject is of the type specified by the property domain.
Individuals can be members of more than one class (think set-theory).
But every property that does not have a domain defined can implicitly be associated with _any_ resource.
A class definition may include constraints on the properties that it has (this is the OWL equivalent to UML class definition) but this doesn't force anyone to provide them, it merely triggers a reasoner to infer that someone, somewhere should have this information.

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 Rob.Atkinson at csiro.au
Sent: Friday, 3 August 2012 7:38 AM
To: geosciml at lists.opengeospatial.org
Subject: [ExternalEmail] Re: [GeoSciML] Wellington Meeting Agenda item: "Consistent use of patterns - are there changes required to allow better use between overlapping domains?" [SEC=UNCLASSIFIED]

I think the idea of separating properties from feature types can be done at two levels - in the meta-model and i believe changes to ISO19109 around this are in train, or by modelling an abstract class and domain-specific implementations separately: as per the "Identity-carrier" pattern in http://ijsdir.jrc.ec.europa.eu/index.php/ijsdir/article/viewFile/62/26

The two approaches don't seem to be mutually exclusive, and abstract identity carrier models can be used as an intermediate. So a client wanting to propagate a subset and maintain semantic compatibility with GeoSciML could create an identity-carrier ("we accept these things exist, and want to reference them") as a separate package at a higher level of abstraction than GeoSciML, provide explicit mappings to GeoSciML as a domain-specific implementation - and then import that, not GeoSciML itself.  This is a factoring of the "copy the bits I need" approach into explicit recognition that governance of the imported definitions is different than governance of the new domain model.

Rob

From: geosciml-bounces+rob.atkinson=csiro.au at lists.opengeospatial.org [mailto:geosciml-bounces+rob.atkinson=csiro.au at lists.opengeospatial.org] On Behalf Of Boisvert, Eric
Sent: Thursday, 2 August 2012 10:28 PM
To: A mailing list for GeoSciML
Subject: Re: [GeoSciML] Wellington Meeting Agenda item: "Consistent use of patterns - are there changes required to allow better use between overlapping domains?" [SEC=UNCLASSIFIED]

>1. I like that the old "estimatedProperty link to observation" chestnut (Eric's baby) may be gaining some traction to actually get resolved. Your physicalProperty issue is, in my eyes, the same problem. I don't have a solution right now.

every single time I meet Simon or Rob, I make sure to bug them with this.

Bruce's #4 : adding more attributes to physical property will eventually turn it into a full blown Observation.

essentially ran in the same issues when we started comparing GWML with INSPIRE groundwater model. For INSPIRE modellers, the main issue is that there are way too much properties to deal with that are irrelevant to their domain (even if they are voidable - they are there), and I refer here to "DataType", mostly literals and complex values.

As I see it, the feature model is ok, the property model is the problem becayse it is specific (what property is important and not depends of the use/scope/perspective).  The things that a geologist says about a feature might be not be of interest for the soil scientist, while they both agree this feature exists in both domains.  The way we peppered the properties in the model is causing problem because it forces other communities to assign importance to properties that we tought was important.  A few levels of inheritance like this and you end up with a slew of mixed concerned from the communities you import from  many perspectives.

Maybe the way to solve this is to split the property model from the feature model ?  We already discussed this when I reported that GWML benefited from the *Description structure (MetamorphicDescription, BeddingDescription) where packages of logical properties are group.  They were because some blocks are repeatable, but also it means that can be reused.

attached is a ppt of a model where the properties are split from the

of course, to concur with Ollie, maybe we try too hard to be reusable. Everything you gain in flexibility, you loose in constrain, and therefore you loose in interoperability. Interop is much easier in smaller like minded groups than large communities. so the question is - are there cases of interop between Geology and Soil science or is it an exercise of "not reinventing the wheel". INSPIRE GW modeller explained that GeoSciML brought too much bagage just for the sake of reusing it while they could just "duplicate" the limited set of properties they need from geology and let go the complexity by having a link to GeoSciML (hlink:href). GWML was different because it was done in a purely geological perspective. INSPIRE had water managements that GWML did not cover explicitly (and just pushed to O&M).

my two cents anyway.

Eric

________________________________
De : geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org<mailto:geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org> [mailto:geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org] De la part de Laxton, John L.
Envoyé : 2 août 2012 05:25
À : A mailing list for GeoSciML
Objet : Re: [GeoSciML] Wellington Meeting Agenda item: "Consistent use of patterns - are there changes required to allow better use between overlapping domains?" [SEC=UNCLASSIFIED]
Bruce,

As Ollie says we need to think carefully how generic we want to make GeoSciML, remembering that the more generic the model is the more complicated it will become to use and the more likely it will be to require an agreed profile to ensure interoperability (geology profile, soil profile etc). We had this argument over the 'lithology' property and what you suggest for 'color' is going down the same road - we have to ensure that it is simple to do simple things within the domain GeoSciML was designed for. The main arguments we had over acceptance of GeoSciML in INSPIRE involved folk saying it was too complex.

That said parts of the model have been designed to be extensible to at least other areas of geoscience - sub-typing RockMaterial from CompoundMaterial for example envisages other types of CompoundMaterial, so maybe compositionCategory and geneticCategory could be moved if they are not appropriate for other domains. Likewise MappedFeature is almost generic but not quite, so modifying it along the lines you suggest could be useful, but as Ollie says maybe this should be part of GML rather than GeoSciML.

We had a lot of discussions in INSPIRE with the Soil modellers about how much they could re-use elements of the Geology specification (eg how a Soil Unit related to a Geologic Unit) but in the end we concluded that the real-world objects we were describing were just too different.

John

From: geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org<mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org> [mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org] On Behalf Of Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
Sent: 02 August 2012 08:27
To: geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>
Subject: Re: [GeoSciML] Wellington Meeting Agenda item: "Consistent use of patterns - are there changes required to allow better use between overlapping domains?" [SEC=UNCLASSIFIED]

Hi Bruce,

Interesting. Look up "scope creep" in the dictionary and you'll find a history of GeoSciML development from 2004 to 2012  ;-)

I think you have some very valid issues here, but I think we need to have some philosophical agreement first.  We need to carefully consider how much we want GeoSciML to be used outside of the geology domain.  Is GeoSciML a specifically geological domain model, or do we want it to be a more generic model for any earth-related domain.  O&M is small and generic, and is designed for cross-domain work. In contrast, GeoSciML is large and detailed, and largely designed for a pretty specific domain.  We need to consider where we draw the line with GeoSciML as a cross-domain standard.  Is it more appropriate for other earth science domains to build their own models/schemas using or extending the patterns of GeoSciML, rather than ask that GeoSciML be amended to suit their own domain needs?

But having said that,

1. I like that the old "estimatedProperty link to observation" chestnut (Eric's baby) may be gaining some traction to actually get resolved.  Your physicalProperty issue is, in my eyes, the same problem.  I don't have a solution right now.

2. At first look, I don't have a problem with your colo(u)r and particle geometry solutions.

3. I don't see why compositionCategory and geneticCategory can't be on all CompoundMaterials.  It's just the vocabularies that change depending on the material type.

4. Re MappedFeature - what you describe sounds like a very generic mapped feature.  Maybe what you propose should be pushed up the chain to become a GML construct rather than a GeoSciML construct?

Cheers,
Ollie

__________________________________________________________________

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

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> [mailto:geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org] On Behalf Of Bruce.Simons at csiro.au<mailto:Bruce.Simons at csiro.au>
Sent: Thursday, 2 August 2012 15:21
To: geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>
Subject: [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.

 1.  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.
 2.  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.
 3.  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).
 4.  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.
 5.  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.


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

--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120803/9ac37833/attachment.htm>


More information about the GeoSciML mailing list