[Auscope-geosciml] Proposed GeologicSpecimen amendments following Quebec [SEC=UNCLASSIFIED]

Guillaume.Duclaux at csiro.au Guillaume.Duclaux at csiro.au
Wed Oct 7 03:51:02 EDT 2009

Hi all,

As I missed all discussions I'm very pleased to read your email Ollie, thanks.

1: Indeed, but GeologicSpecimen has always been a specialization of sa:LocatedSpecimen, isn't it? see attachment below (version from March 2009)

[cid:464061906 at 07102009-309F]

2: I'm maybe wrong but in the case of a specialization relationship, shouldn't  the materialClass property defined in GeologicSpecimen simply overwrite the one inherited one from sa: Specimen? If so, this property will not be a new one, but just a more constrained one.
I'm not sure I fully get the difference in term of ' content' between the so called properties GeologicSpecimen:materialClass and  :geologicSpecimenType... I might be dumb.
Also, instead of creating a new property, couldn't we overwrite the sa:materialClass and define its type to "ScopedName"?

3. Agree, and it still works fine if we define it as GeologicSpecimen/materialClass/ScopedName.

4. I initially looked at creating the GeologicSpecimen class for Groundwater chemistry data management. This explains the values in the provenanceType Codelist. Apologize for any confusion this part of the model may have caused during the meeting.. I can't even use the "French" excuse as the French speaking community was well represented. I need to dig in my files and check why I created this CodeList. It might indeed be useless.. I'll check this.

5. As for point 2, as GeologicSpecimenParent is a specialization of /SamplingFeatureRelation, the role type is overwriting the sa:SamplingFeatureRelation/role property Type. In the case of a GeologicSpecimen the only possible attribute value for role is "parent". This is the reason why we constrained the sa:SamplingFeatureRelation/role/GenericName and renamed SamplingFeatureRelation to GeologicSpecimenParent in the specialization.

6. It made sense to me to record the information (data) related to the parent/child specimens' relation in the equivalent of sa:SamplingFeatureRelation instead of at the specimen level. Does the "preparation procedure" need to be an attribute of a featureType?

One important think you haven't discussed here Ollie, is the cardinality of the links between SamplingFeature and SamplingFeatureRelation versus GeologicSpecimen and GeologicSpecimenParent. We did change the arrow types, and the cardinality of the GeologicSpecimen end-member of the GeologicSpecimen - GeologicSpecimenParent relationship.
In the sa:: model, only one sa:SamplingFeature can derive from a SamplingFeatureRelation: It doesn't allow to "split in three a parent". This may be a major issue for recording geochemistry data.

Hope these comments will help!




Dr Guillaume Duclaux
Structural Geologist /  Modeller
CSIRO Exploration and Mining
Visiting address: ARRC, 26 Dick Perry Av., Kensington WA 6151
Postal address: PO Box 1130, Bentley WA 6102, Australia
Ph: + 61 8 6436 8728    Fax: + 61 8 6436 8555    Web: www.csiro.au<http://www.csiro.au/>

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, 7 October 2009 10:26 AM
To: auscope-geosciml at lists.arcs.org.au
Cc: Neal.Evans at ga.gov.au; Keith.Sircombe at ga.gov.au; Terry.Mernagh at ga.gov.au; Richard.Lane at ga.gov.au
Subject: [Auscope-geosciml] Proposed GeologicSpecimen amendments following Quebec [SEC=UNCLASSIFIED]

Hi Gilly et al,

Following discussions at Quebec, there are a few issues to be addressed with the proposed GeologicSpecimen model - mostly they concern the use of existing generic O&M/Sampling elements.  I have attached a class diagram with notes which summarises the points below.

1.  GeologicSpecimen should be a specialisation of sa:LocatedSpecimen.

2.  If GeologicSpecimen was a specialisation of LocatedSpecimen, it would inherit the materialClass property from sa:Specimen, so there is no need for a new GeologicSpecimen/materialClass property.

3.  sa:LocatedSpecimen/materialClass is a GenericName (effectively ScopedName) which means we can control it with a controlled vocabulary, so there is no need for the GeologicSpecimen/materialClass/materialClassCode codelist.

In the absence of any scope notes, there is a lack of clarity as to exactly what sa:materialClass means.  I prefer that it describes strictly only the type of earth material that is being sampled (eg; whole rock, mineral, glass, groundmass, sediment, restite, solid inclusion, fluid inclusion, melt inclusion, pore water, surface water, vapour, etc).

Then we can use a new property, called GeologicSpecimenType, to describe the gamut of specialised geological specimen types (eg: outcrop specimen, float specimen, drill core, rock chips, drilling mud, dredge sample, thin section, powder, mineral separate, mineral grain, mineral grain mount, probe burn spot, etc)

4.  There was a little confusion at Quebec as to exactly what you meant by ProvenanceType (apparently not a widely used terminology globally?).  Almost all the provenance examples you give (windmill, water bore, monitoring bore, RC drill hole, outcrop) are SamplingFeatures and thus can be related to the GeologicSpecimen by the generic sa:relatedSamplingFeature/SamplingFeatureRelation.  But this doesn't work for relating specimens to non-SamplingFeature features, like a mine site.  We could use the sa:sampledFeature association like we have already done for Specimens -> GeologicUnits.  But I don't know if this is a good solution for mine sites - I'd prefer that EarthResourceML schema model a link from EarthResourceML features (like EarthResource or MiningFeature, or both) to Boreholes and GeologicSpecimens.  Bruce, what do you think? - this would allow you to discover boreholes and specimens from a mineral deposit or mine.

5.  The new GeologicSpecimenParent class is not needed.  The generic sa:relatedSamplingFeature/SamplingFeatureRelation/../Specimen handles this already, with role = "parent specimen".

6.  The property GeologicSpecimenParent/preparation is also not needed because it is already handled by sa:Specimen/samplingMethod.  For example, your example of "parent sample is split in three" is handled by using a sa:Specimen/samplingMethod = "one-third sample split of parent specimen".  Sampling methods should be modelled as extensions of the existing ProcessModel class.

So, in summary, only one extra class (GeologicSpecimen) and one property (GeologicSpecimenType) are needed.

Could I have comments (agree or disagree) from everyone as soon as possible please so I can get the GeologicSpecimen package bedded down for GSML v3 beta.


Ollie Raymond
National Advice,  Maps and Standards Project
Geoscience Australia

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: (02) 62499575 | Fax: (02) 62499992 | Email: Oliver.Raymond at ga.gov.au
Web:  http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp<http://www.ga.gov.au/geoscience/national>

Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>

-- This message was created with 100% recycled electrons --

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091007/88d786db/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook.jpg
Type: image/jpeg
Size: 219297 bytes
Desc: Outlook.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091007/88d786db/attachment.jpg>

More information about the GeoSciML mailing list