[GeoSciML] [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

Laxton, John L. jll at bgs.ac.uk
Wed Jul 4 06:14:55 EDT 2012


Hi Simon,

We need is to be able to deliver location (collar) information and borehole details (index information) for all boreholes, but downhole geometry for only some. The snag with separating off BoreholeCollar as a separate feature is that still leaves the BoreholeDetails which are associated from Borehole. You could move or add associations from BoreholeCollar to BoreholeDetails but that is getting rather messy - BoreholeCollar is any case part of the Borehole, not something separate. Fixing the problem with being able to null the downhole geometry seems the real solution.

John

From: Simon.Cox at csiro.au [mailto:Simon.Cox at csiro.au]
Sent: 02 July 2012 02:24
To: Laxton, John L.; portele at interactive-instruments.de
Cc: robert.tomas at jrc.ec.europa.eu; geosciml at lists.opengeospatial.org; inspire-twg-ge-mr at jrc.ec.europa.eu; michael.lutz at jrc.ec.europa.eu
Subject: RE: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

John -

But that still leaves only Borehole in the regulation, and not Borehole Collar as well.
My understanding is that a feature-type is still required that will not have a mandatory 3D shape.
Isn't that Borehole Collar?

Simon

From: Laxton, John L. [mailto:jll at bgs.ac.uk]
Sent: Friday, 22 June 2012 4:09 PM
To: Clemens Portele
Cc: Cox, Simon (CESRE, Kensington); robert.tomas at jrc.ec.europa.eu<mailto:robert.tomas at jrc.ec.europa.eu>; geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; inspire-twg-ge-mr at jrc.ec.europa.eu<mailto:inspire-twg-ge-mr at jrc.ec.europa.eu>; michael.lutz at jrc.ec.europa.eu<mailto:michael.lutz at jrc.ec.europa.eu>
Subject: RE: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

OK - that sounds like a good plan.

John

From: Clemens Portele [mailto:cportele at googlemail.com] On Behalf Of Clemens Portele
Sent: 21 June 2012 17:56
To: Laxton, John L.
Cc: Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>; robert.tomas at jrc.ec.europa.eu<mailto:robert.tomas at jrc.ec.europa.eu>; geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; inspire-twg-ge-mr at jrc.ec.europa.eu<mailto:inspire-twg-ge-mr at jrc.ec.europa.eu>; michael.lutz at jrc.ec.europa.eu<mailto:michael.lutz at jrc.ec.europa.eu>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

John,

to clarify:

If I understand it correctly what Clemens is proposing is that in the INSPIRE model we remove the specialization of Borehole from SamplingCurve and add a voidable downhole geometry property.

No. My proposal was to do this in the IR text only and just add an open issue statement in the INSPIRE application schema / data spec for now, but otherwise keep the model in sync with GeoSciML.

The text in the IR does not contain everything from the application schema. With my proposed changes to the IR, a borehole instance that is of type SF_SamplingCurve would still comply with the IR, as it meets all requirements.

Then this issue can be resolved in the usual GeoSciML revision process without unhealthy time pressure and we can avoid that too many different model variants are published one way or the other.

Clemens


Am 21.06.2012 um 18:10 schrieb Laxton, John L.:
Hi Simon,

At present in GeoSciML we have a feature OriginPosition with the borehole location and elevation which was actually called BoreholeCollar in a previous incarnation of GeoSciML. However at present the associations to BoreholeDetails and DrillingDetails go from Borehole and we would want to be able to deliver this index information along with the Borehole location.  I guess we could add associations from BoreholeCollar to these data types but then the model is getting rather convoluted, or we could replace the associations with ones from BoreholeCollar but that is making BoreholeCollar the focus of delivery for all boreholes (and is pretty much what I was proposing with an association from Borehole to SamplingCurve).

I think the real problem is that downhole geometry should be nillable in the way any other property of a borehole is, so as far as GeoSciML is concerned I'd be happier to have the sort of generic solution you refer to. I think the only real urgency is for the INSPIRE IR where we need a way of stating that we want downhole geometry to be voidable. If I understand it correctly what Clemens is proposing is that in the INSPIRE model we remove the specialization of Borehole from SamplingCurve and add a voidable downhole geometry property. We have not included the O&M approach to borehole logs in the INSPIRE specification so I don't think we have any loss of information from this. As we are proposing to recommend encoding INSPIRE with GeoSciML in implementation Boreholes will be a type of SamplingCurve (assuming the nillable problem is resolved).

Won't that work?

John

From: Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au> [mailto:Simon.Cox at csiro.au]
Sent: 21 June 2012 16:09
To: portele at interactive-instruments.de<mailto:portele at interactive-instruments.de>; Laxton, John L.
Cc: robert.tomas at jrc.ec.europa.eu<mailto:robert.tomas at jrc.ec.europa.eu>; geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; inspire-twg-ge-mr at jrc.ec.europa.eu<mailto:inspire-twg-ge-mr at jrc.ec.europa.eu>; michael.lutz at jrc.ec.europa.eu<mailto:michael.lutz at jrc.ec.europa.eu>
Subject: RE: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

The relationship between borehole and sampling curve is specialization.
Any knowledge of the domain and object-oriented modeling principles will confirm this.
Replacing a generalization with a simple association is a significant change in meaning.
In my opinion this is the wrong solution.

The discussion has highlighted a generic issue with the modelling and encoding rule.
Specifically, while XML Schema has a 'nillable' mechanism, its default is nillable='false'.
The latter may not meet the requirements for distributing data using the web within at least some of our communities.
I think Clemens agrees with me that there is a generic problem here, and that it would be best to agree on a generic solution asap.

However, there is a solution available to the specific issue that triggered the discussion which doesn't (a) break the model or (b) require us to solve the nillable problem right now.
That is to add a new feature-type to GeoSciML for BoreholeCollar.
It would be a new UML class in the model.
It would not invalidate any existing data, and thus would be a "minor" version.
It would allow data owners to indicate they have a borehole and it can be plotted on a map, but would not require the 3D shape to be provided if it is not available.

From: Clemens Portele [mailto:cportele at googlemail.com] On Behalf Of Clemens Portele
Sent: Wednesday, 20 June 2012 10:21 AM
To: Laxton, John L.
Cc: Robert Tomas; Cox, Simon (CESRE, Kensington); geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; 'TWG Mailing list'; michael.lutz at jrc.ec.europa.eu<mailto:michael.lutz at jrc.ec.europa.eu>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

John,

Clemens/Simon - will this option work for the INSPIRE model (and IR specification)?

My proposal would be:

* Remove the reference to SF_SamplingCurve from the IR and add a voidable property for the borehole path curve.
* For the model update I would wait for how GeoSciML resolves this and then adjust the model accordingly. As far as I can tell, only the IR is a pressing issue right now. For the publication of rc2, maybe just include a statement on the open issue.

Clemens


Am 20.06.2012 um 10:02 schrieb Laxton, John L.:
Hi Robert,

Some comments in red below.

John

From: owner-inspire-twg-ge-mr at jrc.ec.europa.eu<mailto:owner-inspire-twg-ge-mr at jrc.ec.europa.eu> [mailto:owner-inspire-twg-ge-mr at jrc.ec.europa.eu] On Behalf Of Robert Tomas
Sent: 19 June 2012 17:54
To: Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>; geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>; 'TWG Mailing list'
Cc: michael.lutz at jrc.ec.europa.eu<mailto:michael.lutz at jrc.ec.europa.eu>; portele at interactive-instruments.de<mailto:portele at interactive-instruments.de>
Subject: RE: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

Hi all,
thank you for the well founded technical discussion.

There is another aspect - more - strategical like - about the inclusion of borehole log data in the legal text

1) to include borehole log data (limited mainly to lithology, stratigraphy info referring more to geological interpretations then to the first raw measurements) in INSPIRE as a legal obligation (voidable) is very important - it will hopefully create a push to share this data so needed for 3D modelling. This is the domain where we geologists have our strong business opportunities..
As you know we went around and around on this, but in the end the view was that borehole logs are highly useful information that should be made available if possible. The MappedInterval log in the model is pretty basic information which data providers with a digital borehole log database should be able to provide - but if they don't have the data they don't have to provide it.

2) We are already facing some rejections of this idea (to include borehole log data) from some MSs. Metadata is fine, but log data not..

3) I'm also afraid that if we now force them to map their complex borehole databases to generic O&M classes we may get even stronger rejections.. (I have recently experience that during the EuroGeo Conference in Bologna..)
There is nothing in the model forcing complex O&M classes - the only issue is whether by inheriting from SamplingCurve all boreholes (whether with logs or not) have to provide downhole geometry. This issue is separate from any discussion of whether or not we wish to include MappedInterval in the model. Clearly we don't want to mandate downhole geometry for boreholes without logs. I proposed, as a minimalist change to the INSPIRE model, that we removed the inheritance of Borehole from SamplingCurve and replaced it with a voidable association. How this is then encoded in GeoSciML would depend on the resolution of the ongoing discussion in the GeoSciML community.
Clemens/Simon - will this option work for the INSPIRE model (and IR specification)?

4) We have now in the INSPIRE geology model two options:1) using the mapedinterval + geological feature + (geol unit + lithology) or geol. event (for stratigraphy) - this is fine the only problem is that for each log interval you have to provide also the type of a geological unit (which is from a borehole data provider - not always the same provider as the geological map data, at least in Europe  -   point of view strange since they do not have this information - very often)
As Jean-Jacques has pointed out the geologicUnitType property is not an issue as there is a vocabulary value for 'unknown type of GeologicUnit'.

    2) to use the association or specialisation of SF_SamplingFeatureCurve which brings the obligation to provide other information (e.g. shape of the borehole log) which I believe is not the of the prime interest of the majority of future data users.


I personally would prefer the first option to be used as a legal obligation, providing that the Type of Geological Unit generic term geological unit has in the definition something about the borehole interval description or similar etc...
You have to have downhole geometry (usually just a vertical line) if you are delivering a borehole log, and SamplingCurve is the obvious way to do this - the problem arises with the requirement to deliver downhole geometry where you don't have a borehole log (see above). So your options one and two here are not alternatives - you need both to deliver a log.

I would keep the O&M option, explained in the technical guidelines, as an example, community recommendation...

Unfortunately the time is critical now and I believe that the priority is now to place the provision of borehole log data in the legislation in the most easy way for current borehole data providers to accept.
All the best
Robert


--------------------------
Robert TOMAS, PhD
Scientific / Technical Project Officer
<image001.jpg>
European Commission
DG Joint Research Centre
Unit H06-Digital Earth and Reference Data
Via Enrico Fermi, 2749
I-21027 Ispra (VA) Italia
Tel: +39 0332 78 5426
Fax: +39 0332 78 6369
robert.tomas at jrc.ec.europa.eu<mailto:robert.tomas at jrc.ec.europa.eu>
http://ies.jrc.ec.europa.eu<http://ies.jrc.ec.europa.eu/>/


________________________________
From: Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au> [mailto:Simon.Cox at csiro.au]
Sent: Tuesday, June 19, 2012 2:07 PM
To: geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>
Cc: michael.lutz at jrc.ec.europa.eu<mailto:michael.lutz at jrc.ec.europa.eu>; robert.tomas at jrc.ec.europa.eu<mailto:robert.tomas at jrc.ec.europa.eu>; portele at interactive-instruments.de<mailto:portele at interactive-instruments.de>
Subject: RE: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]
Thanks John -

I was able to discuss this with Clemens yesterday, and I think the issue comes down to two concerns.
1.       Another feature type is required in the GeoSciML model - i.e. it's a domain model problem
2.       Too many ways to encode nils is harmful to interoperability - i.e. it's an encoding problem
AFAICT there is no issue with the metamodel (i.e. ubiquitous support for voidable properties is not a problem).

1.
Regarding the domain model: I understand that the primary application that people are concerned with is showing borehole collars on a map. The feature type of interest for this application is clearly borehole-collar, not borehole. We have a name for this feature type in the domain of discourse: borehole-collar. So it is not at all artificial to have a feature-type for this. The borehole type (with its shape) is required when you are reporting observations along the borehole (i.e. logs). If there are no observations then there is no need to report a sampling feature.

2.
Regarding the encoding of missing data: yes, it is not nice to have multiple ways to indicate that data that is required by the model is not available, but this may just be the price of dealing with the legacy where we have uncovered that the legacy requirements were incomplete. In GML the standard (legacy) way to enable the standard encoding of nils uses the tagged value 'nillable' or 'voidable'. The default value for this tag is 'false' turns out to be a problem, particularly in the loosely coupled web environment. I.e. the legacy assumption underlying this approach appears to be flawed.

How do we respond to this? Do we ignore the problem? Do we replace the existing method with something different, and therefore not compatible? Or do we (pragmatically) augment it with a convention to allow nils even in a situation where the tagged value was not included in the model? Clearly I advocate the latter, along with any documentation and other technical fixes that are required to get it to work.

There are other or complementary ways to solve the XML encoding issue that would remain schema valid and that we can agree are also semantically valid. For example a 'standard' untyped XML element (i.e. dynamically typed) representing a 'nil' could be used as the content of a property element, as an alternative to the xlink:href approach - this would allow inline-only properties to also play the same game. And there would need to be a method for simple-content types. I don't see a major burden to software support for any documented convention, particularly for client software that already supports nils.

If we accept that this is a genuine requirements, then solving it is just a matter of agreement and documentation.

Simon

From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Laxton, John L.
Sent: Friday, 8 June 2012 11:51 AM
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Cc: Michael Lutz; Robert Tomas
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

Thanks  Simon - that's a really useful summary of the issues. A couple of points:

1.       There is a fourth case of GeoSciML borehole where we genuinely only have the borehole location - either because there is no log available, or because the log is confidential (common), or the log hasn't been digitised. It is still useful to provide information on the location of these boreholes, and conceptually of course they do have a log, but they cannot be delivered.
2.       My understanding of the INSPIRE rules are that if a property has not been made specifically voidable then it has to be provided. As you say having voidable as the default option would probably have been more sensible. Maybe the solution is to modify the INSPIRE model so that Borehole has a voidable association to SamplingCurve but in the encoding rules to GeoSciML say that an OGC nil should be used where there is no borehole geometry?

John

From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>
Sent: 07 June 2012 08:33
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

OK - There  are a few issues to tease out here.
Let me try to separate them.

1.       [Application schema, UML] What is the purpose of the UML model?
2.       [URI, deployment environment] link safety on the web, distributed systems
3.       [UML] Is nillable='true' the only/best way?
4.       [Application schema, UML] Does the GeoSciML model need modifying?
5.       [Application schema, UML] Does the O&M Sampling Feature model need modifying?
6.       [xlink, GML, URI] Would it help if the proposed use of OGC nils was better documented?

1. Is it a UML issue?
UML is used to design and document application schemas because it is both visual and formal. In contrast with much historic use of UML to describe software systems and implementations, when developing Application Schemas UML is used primarily as a Conceptual Schema Language (the title of ISO 19103). We describe the conceptual domain-of-discourse as it is understood by people working in the field. Class names, relationships and their cardinalities reflect our understanding of how they feature in discourse within the community. When developing an application schema we don't fret about implementation constraints, beyond using the agreed UML profile which we know permits an XML implementation into GML.

When we model in UML we accept UML semantics. So if something is mandatory (cardinality [1..*]) then this means what it says - the definition of the class requires that this attribute or association-end be present, and its type is correct, else it is not an instance of that class. No argument from me there. However, we do not deploy systems as UML. No data transferred as UML objects. The elements, types, relations and constraints described in UML are the design, but in deployment we don't use UML. We choose an implementation platform and map from the UML model to the implementation. With GML the language is XML and with W*S the deployment environment is the web, and non-local relations use URIs.

When we map components designed in UML into components to be deployed in XML we design a set of rules for how to match the designed elements to deployed objects. In GML we map UML Class definitions to XML Schema element declarations, and both attribute and associations share a common implementation pattern with (in general) both inline or byReference modes being supported. When all is well, these work together to give us the familiar pattern, either striped where an element with the name of the target class is nested inside an element with the name of the attribute or association-role, or indirect where the element with the name of the attribute of association-role carries a reference to an external resource.

But all these patterns are conventions. Of course there is nothing intrinsic about a fragment of XML that makes it represent a 'curve' - it is a convention that we have adopted. We can easily adopt a convention that some particular URI represents a resource of any required type. So when Clemens says "http://www.opengis.net/def/nil/OGC/0/unknown is not an instance of type GM_Curve" I say "it is if we agree that it is", in the same way that a particular XML fragment starting <gm:Curve> is an instance of type GM_Curve because we have agreed that is.

So I am pushing back on Clemens assertion that this is a modelling issue and not an implementation issue. Rather I say it is precisely an implementation issue since it only crops up when we have moved out of the UML world and into an implementation.

2. Distributed systems
What guarantees do we have about the target of a URI reference?

On the web we cannot expect more than a best effort on the part of the data supplier to link to something useful. So if they have the data to describe the object then they can create a suitable GML object. If the data is in a system that does not make that possible, then the supplier may provide a link to a non-GML resource. If the data is not available at all, they should link to a resource that explains what they do or do not have in the way of data. The OGC 'nil' URIs are a standard option available for providers who want to use them for this last purpose. And it should not be hard to enhance GML client software to detect and trap this case, given that is based on a reliable URI pattern.

The web is not an enterprise system, so we do not have control of all aspects, and therefore have to live with inconsistencies and a lower level of overall system integrity than within the enterprise. We expect things to sometimes break, and therefore plan for it. Don't bring enterprise assumptions to distributed systems, particularly loosely-coupled distributed systems. The convention I propose (and has been used on and off for years now in communities I've been working in) is a pragmatic, standard way to make this easier for a case that we anticipate will occur from time to time, allowing a provider to flag that the information is incomplete and they know it, even in a situation where they know that there is an expectation that they supply it.

3. Local vs. general rules
In my view we need such a method that can be applied universally. The 'nillable/voidable' flag is nice enough, but in practice in many schemas it needs to be present on most elements. 'Non-nillable' might be more practical, as those properties will be fewer than the ones we know we can live without for some uses of the data.

I'm really suggesting that the default requirement is probably 'nillable'. So, rather than have to litter every application schema with the nillable flag, it is smarter to adopt a general solution at a level above the individual application schema design, i.e. a general GML pattern. Without this we will have to reject a lot of potentially useful data. Allowing data to be omitted only for those properties where the application schema says nillable=true sets the bar too high. It tells willing data providers who do not (yet) have perfect data to just go away until they do.

4. GeoSciML borehole
My starting position was that, since observation borehole was one of the inspirations for the SF_SamplingCurve class, it would be perverse to not now derive Borehole from Sampling Curve (it is even shown informatively in ISO 19156!). Having said all this, let's not be completely stubborn about the GeoSciML Schema. Firstly, you should only model a feature as a specialization of SamplingFeature if the purpose for describing it is because it hosts observations. If there are not any related observations then we are in the wrong place anyway. But if observations are in scope, I can still think of three solutions straight away that don't require us to break the specialization relationship:
(i)                  there are some applications of boreholes, such as production  wells, for which once they are in operation the 3D shape is practically irrelevant and only the collar location matters. If these are the troublesome features, then maybe we need a different class for 'production well' (etc) with just a point geometry.
(ii)                We could keep production wells and true boreholes in the same place by making the borehole class a specialization of SpatialSamplingFeature which has a generic 'shape' property with any kind of geometry, and then choose the most suitable geometry
(iii)               However, what I suspect is the case is that there is a geometry model for most of these boreholes - it is a simple line string defined by the collar and a point vertically below at the same 2D location but offset by the borehole length. Yes, we know that in the real world most boreholes are not actually straight and vertical, but in the application world we appear to be happy to work with a simplified geometry. So what is required to describe this geometry is either (a) to compute the 3D position of the bottom of the borehole, or (b) to use a line representation based on collar, direction (vertical) and offset (length). In conversation with Steve Richard today he confirmed that this is probably the common case.

5. Inheritance from OMXML
I'm aware that one version of the story is that it was somehow a mistake inherited from OMXML, in which I foolishly did not make 'shape' nillable. I disagree with this story on the grounds explained in 1. above. SpatialSamplingFeatures have a shape. It is mandatory else what's the point of this specialization of SamplingFeature.

6. Documentation
Finally, I agree that, even if it is a good idea and has been used in the past, we are now well and truly out of the experimental phase and into deployment and (in Europe) regulation. So everything we do must be backed by proper documentation. This pattern of using OGC 'nil' URIs in the xlink:href to indicate void/nil values has not been properly documented, and this is now clearly an issue and potential barrier to the use of the pattern, whatever its merits. I'm happy to draft a note explaining this and introduce it to OGC as a best practice, standard, CR to GML, OGC-NA policy document, whatever is most appropriate, if that would help.

Simon

From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Clemens Portele
Sent: Friday, 1 June 2012 12:34 PM
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

Simon,

it is not an implementation issue. What you describe may work in OWL, but it doesn't work in UML and the O&M and GeoSciML models are normatively specified in UML. http://www.opengis.net/def/nil/OGC/0/unknown is not an instance of type GM_Curve.

It is also inconsistent: GeoSciML explicitly models which properties might be nil - and by implication which cannot be nil. If every property can in practice be nil, why bother with this in the model?

>From an implementation point - and I am talking about software, not XML instances here - I would also raise the concern that this http://www.opengis.net/def/nil pattern is neither documented in GML, OM XML or GeoSciML (the only formal documentation that I know is in the UML and XSDs). Is it realistic to expect that software, and I am mostly thinking about software reading the data, will understand this? I think the answer is "no".

Note that I am not saying that the GeoSciML model is conceptually in error or should change (at least if it considers the borehole curve geometry mandatory for boreholes).

It is just that with the current sampling curve requirements in O&M I do not see how the borehole in INSPIRE could be defined as a generalisation of SF_SamplingCurve in the implementing rule, if it wants to support boreholes for which only the location of the borehole collar is known, but not the curve. So, this could mean that INSPIRE will have come up with a different model for boreholes than GeoSciML. This could be done, for example, by splitting it into separate feature types for the borehole collar and an associated borehole shaft (which would be a sampling curve). There are many valid ways to model boreholes, it just depends on the Universe of Discourse (to use the 19100 term).

Have a save trip! Unfortunately I won't be there next week - it would be nice to continue this discussion over a beer.

Clemens


Am 01.06.2012 um 11:33 schrieb <Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>>:
No. If we leave Borehole as a generalisation of SamplingCurve we are merely stating that every borehole has a geometry. How you deal with the fact that you don't always have a description of the geometry it is an implementation issue, but there is no fault with the model.

IMO Using the indirection handle to point to a either a concrete geometry or to a null resource is consistent with the model. The argument would be that http://www.opengis.net/def/nil/OGC/0/unknown identifies a resource whose type is the superset of all concrete resource types. If you like, it assumes the type appropriate to where it is found, but its key characteristic is that the concrete description of the expected resource is explicitly unknown. Ur-classes and complementary types like this are common in logic systems. For example, in OWL there is a class owl:Nothing which is a subClassOf the base class owl:Thing.
Seems barmy at first glance, but is actually allowed for in the conceptual framework and is introduced allow many useful things to be said that would not be possible otherwise. The http://www.opengis.net/def/nil resources fall into this kind of basket.

Conveniently the approach also does not upset the XML validation framework, so requires no change to either model or encoding rule.

Perhaps there is some other implementation consequence that I'm unaware of. If so, it would be helpful to know about it. But I don't accept that this method of handling unknowns is conceptually wrong, or that GeoSciML is conceptually in error.

Simon

From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Laxton, John L.
Sent: Friday, 1 June 2012 5:04 PM
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

Hi Simon,

I think the urgency is from the INSPIRE side rather than GeoSciML as the INSPIRE IR are in the process of being formulated - I agree that any change in GeoSciML needs to be fully considered before being made. For INSPIRE though as I understand it if we leave Borehole as a generalisation of SamplingCurve we will be stating in the legislation that downhole geometry must be provided for all boreholes - which we definitely don't want!

John

From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>
Sent: 01 June 2012 09:51
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

John, Clemens - I do not necessarily accept Clemens assessment about the sins that I am suggesting. But that largely implementation details. I more strongly object to the suggestion that the relationship between borehole and sampling-curve is something other than generalization, or at least that it be changed in a hurry at this stage. I'm about to head out the door to go pack and then get on a plane, so can't lay out my arguments now. But please do not treat this as a done-deal.

The discussions at Redlands were not in full view of the GeoSciML development group.
There is a more thorough process to be followed in this forum before significant changes to the shared model are contemplated.

Simon


From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Laxton, John L.
Sent: Friday, 1 June 2012 4:44 PM
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

So where does this leave us?

I think for INSPIRE we have to make the model change I proposed as otherwise the Implementing Rules will state that downhole geometry is mandatory for all boreholes, which we don't want. The question then is whether this is compatible with encoding INSPIRE in GeoSciML if that is left unchanged. The answer seems to be 'Yes' in practice (with a hack), as far as the schema is concerned, but 'No' conceptually as far as the GeoSciML model is concerned. Is that a correct summary?

This suggests the GeoSciML model needs to be changed but there is a question of whether it needs to be done as a matter of urgency or can be left until the next planned upgrade (which might be a while).

John

From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Clemens Portele
Sent: 01 June 2012 08:05
To: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

Simon,

A more logically correct way to handle this is

<sams:shape xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown"/<http://www.opengis.net/def/nil/OGC/0/unknown%E2%80%9D/>>

No change to the schema required.

I am going to disagree with you, on two levels.

1. Conceptual: Let's forget about XML for a moment and just look at the conceptual model. This has a requirement that "The association Geometry shall link a SF_SpatialSamplingFeature to a GM_Object that describes its shape." This is both expressed in the model as well as additionally in the normative statement in the text. Even without the statement the model is very clear that the value of shape must be GM_Curve. I think we will all agree that "http://www.opengis.net/def/nil/OGC/0/unknown" is not of type GM_Curve. So the above does not conform to O&M.

2. Encoding: GML already specifies a way to declare nil values, using xsi:nil (see 8.2.3.2). Inventing yet another mechanism for doing the same thing is not a good idea in my opinion, in particular since XML Schema already specifies a standard way for this. Do we expect that software will support several ways to encode nil values? Also, the OM XML standard uses xsi:nil when it wants to make properties nillable, e.g. sam:sampledFeature. To me, using xlink:href is a hack to represent a nil value where no nil value is allowed, but where it would be handy.

If the shape property is intended to be nillable in GeoSciML this needs to be corrected in O&M first (and OM XML should be updated, too). Until this is done, I do not see a way to have a conformant sampling curve feature without an actual curve.

Clemens


Am 01.06.2012 um 02:15 schrieb <Simon.Cox at csiro.au<mailto:Simon.Cox at csiro.au>>:
That would not be conformant GML.
There is a normative constraint in the GML spec that requires either element content or xlinks.
The constraint cannot be detected by XSD 1.0, but that reflects a weakness of XSD not GML.

A more logically correct way to handle this is

<sams:shape xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown"/>

No change to the schema required.

From: auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf OfOliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
Sent: Friday, 1 June 2012 6:53 AM
To: jll at bgs.ac.uk<mailto:jll at bgs.ac.uk>; steve.richard at azgs.az.gov<mailto:steve.richard at azgs.az.gov>
Cc: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Re: [auscope-geosciml] Borehole sampling curve [SEC=UNCLASSIFIED]

Hi John, Steve,

If I remember correctly, our issue with Borehole being a generalisation of SF_SamplingCurve, rather than just an association, was that it meant that there was a mandatory "shape" (ie, curve) element - which is data that many legacy boreholes do not have.  I was testing Borehole XML instances at GA yesterday and noticed that although the "shape" element is mandatory, it can be left empty and the XML is still valid.

Does this allay our concerns about the mandatory "shape" element for boreholes, without having to change the GeoSciML model?

Cheers,
Ollie

__________________________________________________________________

Ollie Raymond
Section Leader  |  National Geological Maps and Data Standards 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 9917
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: Laxton, John L. [mailto:jll at bgs.ac.uk]
Sent: Friday, 1 June 2012 01:51
To: Raymond Oliver
Cc: auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>
Subject: Borehole sampling curve

Hi Ollie,

Following on from our discussions in Redlands regarding the relationship between Borehole and SF_SamplingCurve I have changed this in the INSPIRE geology model to be a directed association rather than generalisation (see below). However, as we discussed, something equivalent should be implemented in GeoSciML, particularly as we now intend to mandate GeoSciML encoding for INSPIRE Geology. Should there be a v3.1 to address this?

John

(the diagram seemed to get scrambled via the mail list - here it is again!)

<image001.jpg>

John Laxton
British Geological Survey
Murchison House
West Mains Rd
Edinburgh, EH9 3LA
United Kingdom

Tel: +44 (0)131 667 1000
Fax: +44 (0)131 668 1535
email: jll at bgs.ac.uk<mailto:jll at bgs.ac.uk>
Web site: www.bgs.ac.uk<http://www.bgs.ac.uk>
Internet Shop: www.thebgs.co.uk<http://www.thebgs.co.uk>






--
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<mailto:auscope-geosciml at lists.arcs.org.au>
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

--
Clemens Portele
portele at interactive-instruments.de<mailto:portele at interactive-instruments.de>
+49 228 9141073 (office)
+49 151 15298497 (mobile)

interactive instruments Gesellschaft für Software-Entwicklung mbH
Trierer Str. 70-72, 53115 Bonn, Germany
Geschäftsführer: Reinhard Erstling, Karla Hinzer, Clemens Portele, Bernd Weidner
Amtsgericht Bonn, HRB 3872


--
Clemens Portele
portele at interactive-instruments.de<mailto:portele at interactive-instruments.de>
+49 228 9141073 (office)
+49 151 15298497 (mobile)

interactive instruments Gesellschaft für Software-Entwicklung mbH
Trierer Str. 70-72, 53115 Bonn, Germany
Geschäftsführer: Reinhard Erstling, Karla Hinzer, Clemens Portele, Bernd Weidner
Amtsgericht Bonn, HRB 3872


--
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<mailto:auscope-geosciml at lists.arcs.org.au>
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

--
Clemens Portele
portele at interactive-instruments.de<mailto:portele at interactive-instruments.de>
+49 228 9141073 (office)
+49 151 15298497 (mobile)

interactive instruments Gesellschaft für Software-Entwicklung mbH
Trierer Str. 70-72, 53115 Bonn, Germany
Geschäftsführer: Reinhard Erstling, Karla Hinzer, Clemens Portele, Bernd Weidner
Amtsgericht Bonn, HRB 3872


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


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


--
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/20120704/1285fbb9/attachment.htm>


More information about the GeoSciML mailing list