[auscope-geosciml] GeoSciML v3 RC1 Borehole Testbed 4 issues [SEC=UNCLASSIFIED]

Wed Jun 15 01:59:04 EDT 2011

Looking much better.  I agree with all your points but will need to test 
the proposal.  I gather the relatedSamplingFeature will provide the link 
between Borehole and SF_Specimen.

A minor niggle. You have boreholeMateialCustodian as 1..* in the diagram 
but 0..* in your notes.  I suggest removing this property from Borehole if 
the SF_Specimen:currentLocation can be used to provide the material 
custodian information. 

----------------------------------------------------
Bruce Simons
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons
Level 9, 55 Collins St
PO Box 4440
Melbourne, Victoria, 3001
Australia

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155

From:   <Oliver.Raymond at ga.gov.au>
To:     <auscope-geosciml at lists.arcs.org.au>
Date:   15/06/2011 11:11 AM
Subject:        Re: [auscope-geosciml] GeoSciML v3 RC1 Borehole Testbed 4 
issues [SEC=UNCLASSIFIED]
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au

Ok, I have been a bit slow on the uptake, but I think I get it now (thanks 
Bruce and John).  I propose a update #2 on Bruce’s model…

1.      DrillingDetails (ie, those BoreholeDetails attributes that vary 
down hole) has a link to GM_Object (not MappedFeature) to deliver the 
“from and to” interval location.  I prefer it this way because Bruce’s 
model links DrillingDetails to MappedFeature which would force a mandatory 
“specification/GeologicFeature” link for DrillingDetails which is 
undesirable.

2.      Bruce’s BoreholeSamples class is covered by the existing 
Borehole/relatedSamplingFeature/SF_Specimen model.  SF_Specimen has a 
samplingLocation/GM_Object link in it already which can link a specimen to 
its location within a borehole.

3.      I have proposed a 0..* multiplicity for 
boreholeMaterialCustodian.  This does not specifically identify which 
parts of a borehole are housed where, but it is a simple model that I 
think would cover both John’s and Bruce’s needs.  If you need to 
specifically link some borehole material (ie, specimen) to a particular 
custodian, then there is already SF_Specimen/currentLocation.

4.      John’s idea for multiple Collar Locations is not logical to me – a 
borehole has only one collar. 

5.      I’ve also added “voidable” stereotypes just to indicate where 
links are nillable.

Cheers,
Ollie

_______________________________________________________________________

Ollie Raymond

Project Leader
National Geological Maps and Data Standards Project
Geoscience Australia

Interoperability Working Group
IUGS Commission for the Management and Application of Geoscience 
Information

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email: 
oliver.raymond at ga.gov.au  |  Google Map 
_______________________________________________________________________

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

From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Bruce.Simons at dpi.vic.gov.au
Sent: Wednesday, 15 June 2011 9:51 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeoSciML v3 RC1 Borehole Testbed 4 issues 
[SEC=UNCLASSIFIED]

Hi all, 

>In most cases boreholes have a single set of DrillingDetails and it 
shouldn’t be necessary to have to associate them with every MappedInterval 
down the borehole 

Indeed. However, my proposal doesn't require this. It allows any 
DrillingDetails to have an associated MappedInterval, not require every 
MappedInterval to have DrillingDetails (Ollie's proposal that I disagree 
with). 

>put the DrillingDetails properties into CollarLocation 
CollarLocation is a specific concept about the spud location and unrelated 
to DrillingDetails, so this would be inappropriate. 

>DrillingDetails doesn’t have to coincide with a change in MappedInterval 
(which it normally wouldn’t) 

The proposal is to continue to use MappedInterval to map linear features, 
be they GeologicFeatures (via gsml:specification) in a Borehole or a 
mapped section, Borehole length, cored interval, drill diameter, drilling 
method etc.  None of these properties should actually be on the 
MappedInterval, just as we don't have any geologicFeature properties on 
MappedFeature. 

Cheers 

----------------------------------------------------
Bruce Simons 
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons 
Level 9, 55 Collins St 
PO Box 4440 
Melbourne, Victoria, 3001 
Australia 

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155 

From:        "Laxton, John L." <jll at bgs.ac.uk> 
To:        "auscope-geosciml at lists.arcs.org.au" 
<auscope-geosciml at lists.arcs.org.au> 
Date:        14/06/2011 06:42 PM 
Subject:        Re: [auscope-geosciml] GeoSciML v3 RC1 Borehole Testbed 4  
     issues        [SEC=UNCLASSIFIED] 
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au 

Folks, 

My concern here is that (as too often with GeoSciML) it is making it 
difficult to do something simple. In most cases boreholes have a single 
set of DrillingDetails and it shouldn’t be necessary to have to associate 
them with every MappedInterval down the borehole. 

Wouldn’t it be simpler to put the DrillingDetails properties into 
CollarLocation and allow a borehole to have multiple CollarLocations – the 
DrillingDetails aren’t constantly changing, they change at particular 
points down the borehole which could be represented by distinct 
CollarLocations. This also means a change of DrillingDetails doesn’t have 
to coincide with a change in MappedInterval (which it normally wouldn’t). 

John 

From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Bruce.Simons at dpi.vic.gov.au
Sent: 14 June 2011 04:59
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] GeoSciML v3 RC1 Borehole Testbed 4 issues 
[SEC=UNCLASSIFIED] 

>
Borehole/downholeDrillingDetails/DrillingDetails/logElement/MappedInterval 
and Borehole/logElement/MappedInterval are 2 different paths to get to the 
same place.   

Different paths for different purposes. You can also get to MappedInterval 
from GeologicFeature/occurrence/MappedInterval in order to specify the 
GeologicUnit/classifier and GeologicUnit/.../lithology properties. 

The issue you raise is if I have a Borehole that is drilled using one 
method and nominal diameter (most of them) then you'd need to repeat the 
MappedInterval for the Borehole and for the DrillingDetails. I don't have 
a problem with that, I think its a good thing.  The Borehole 
MappedInterval serves a different purpose to the DrillingDetails 
MappedInterval. 

Re BoreholeSampleType, examples are "core', "cuttings", "sidewall core". I 
think this is more useful than the current  coredInterval (and on 
reflection I think boreholeMaterialCustodian should be a property of 
BoreSamples.) 

Cheers 

----------------------------------------------------
Bruce Simons 
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons 
Level 9, 55 Collins St 
PO Box 4440 
Melbourne, Victoria, 3001 
Australia 

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155 

From:        <Oliver.Raymond at ga.gov.au> 
To:        <auscope-geosciml at lists.arcs.org.au> 
Date:        14/06/2011 01:46 PM 
Subject:        Re: [auscope-geosciml] GeoSciML v3 RC1 Borehole Testbed 4 
issues [SEC=UNCLASSIFIED] 
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au 

Hi Bruce, 

I’ll evaluate your 4 points in a little while, but I can say right now 
that I am really against multiple paths to one class.  eg; 
Borehole/downholeDrillingDetails/DrillingDetails/logElement/MappedInterval 
and Borehole/logElement/MappedInterval are 2 different paths to get to the 
same place.  Not interoperable modelling in my book. 

Cheers, 
Ollie 

_______________________________________________________________________ 

Ollie Raymond 

Project Leader 
National Geological Maps and Data Standards Project 
Geoscience Australia 

Interoperability Working Group 
IUGS Commission for the Management and Application of Geoscience 
Information 

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039 

Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email: 
oliver.raymond at ga.gov.au  |  Google Map 
_______________________________________________________________________ 

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

From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Bruce.Simons at dpi.vic.gov.au
Sent: Tuesday, 14 June 2011 1:39 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] GeoSciML v3 RC1 Borehole Testbed 4 issues 

Just to provide a visual example of where I'm thinking: 

----------------------------------------------------
Bruce Simons 
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons 
Level 9, 55 Collins St 
PO Box 4440 
Melbourne, Victoria, 3001 
Australia 

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155 
Notice:
This email and any attachments may contain information that is personal, 
confidential,
legally privileged and/or copyright. No part of it should be reproduced, 
adapted or communicated without the prior written consent of the copyright 
owner. 
It is the responsibility of the recipient to check for and remove viruses. 

If you have received this email in error, please notify the sender by 
return email, delete it from your system and destroy any copies. You are 
not authorised to use, communicate or rely on the information contained in 
this email. 
Please consider the environment before printing this email. 

 _______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml 
㓽‑[1]ȳ{ch'‑SLSN˲9CC⎅G?N5;"ͭ8ԟiǀ&Nzfݪ|֜gɚɊ'w讦텫bڕʧ~'^ؚ
ez*kzjw(*ₛ㓔㓽‑[1]کjh~+luz趧‑uZם(kƭy߅8ԅ8ԟiǀ&«a뭅꫊?zw(ǧ텧
(*ₛh·SO?ϼSNȳ{aN57ڱૉH+-Ʝ'&▫razۨr+jwkzj/zǬSO?ϼSM⪛"ͭ*.ޭ瞊zf)ޮ
+W騶'?zw^z۫隊W^랊׫l2צjw]z˫&Ɋ)똢櫺z-j롢yۨǜi'ꫭ鲢{az)ߢ*'r޶)톫
‑SO?S}‑[1]ʥ4?,ޘ^jǜ{"uꭅ秾*螧)트-+‑SO?S}‑[1]ȳ{oŸԧnʿ 

-- 
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. 
_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
"D卌#9ߓM4Ÿԅ8Ԭ7㓽‑[1]8b隊Vu򪛚rۦk'(֢)ߢ*'ʞʧjW(z{bjPQ蚖\+╨‑uݾ
ܢmSLSM⪓h.֞ꫡۜy֝j^vܢi'翔㓔㓽‑[1]*+¸霢{‑ڟm ޯ񎵿ŸԿ<񎵻"ͭ8ԟi
ǀ&"جzʨțXʇ텪޲*bz{mȞrG譩ݭ騽뢮랳񎵿ŸԿ<񎵷ڱૉl7!zz+޶آ隊Xz讙^jǧ؟ʘ
^靺򭫮wj)]zWz+_ꬊ˞ݵ뭮'('b騵Ⱨm랲xjרʉ텨~檘ʧyاzf񎵿ϼSM⪗(҈{c幫‑r쉗y
֞~ަ)඘zf񎵿ϼSM⪛"ͭ㓝)󧮊
_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110615/d4d3e5d7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 89886 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110615/d4d3e5d7/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 39345 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110615/d4d3e5d7/attachment.gif>