[GeoSciML] Changes needed to get qualified lithology query working

Laxton, John L. jll at bgs.ac.uk
Mon Jun 17 04:57:19 EDT 2013


Bruce,

You have to remember that users are not coming to this from the point of view of how complex a query may be to encode in GeoSciML but how simple/basic/useful they perceive it in geological terms. A very common use case is 'find me a unit of xxxx lithology' by which the user means a unit which is predominantly of lithology xxxx, not one which contains 2% xxxx. If they are told GeoSciML can't be queried for this that will lower the credibility of GeoSciML in their eyes. When we used codes for proportions this was an easy query - now we have a QuantityRange it appears to be an impossible query. Unfortunately in designing GeoSciML we have too often departed from the principle that simple things should be simple to do, which hopefully GeoSciML4 may help correct.

John

From: geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org [mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org] On Behalf Of Bruce.Simons at csiro.au
Sent: 17 June 2013 01:28
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] Changes needed to get qualified lithology query working

Re "laugh test": personally, I don't think that a complex query like "find me all units with greater than 25% sandstone" is laugh testable.  While it might be a desirable query, it is a pretty complex query (3 elements in one query).  I think that the simpler "Find me all units containing sandstone" is a query that should be able to pass a laugh test.

The test  "find me all units with greater than 25% sandstone" is a test that should be supported. It is the main reason we have proportion as a numerical value.

Cheers
Bruce Simons
SDI Information Modeller
Environmental Information Systems
CSIRO Land and Water
PO Box 56 Highett,
Graham Road, Highett, Vic 3190

Ph +61-3-92526514 |  Mob +61-429177155
EIS: http://www.csiro.au/science/Environmental-Information-Systems
CLW: www.clw.csiro.au<http://www.clw.csiro.au/>
ACLEP: www.clw.csiro.au/aclep<http://www.clw.csiro.au/aclep>
ASRIS: www.asris.csiro.au<http://www.asris.csiro.au/>



From: geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org<mailto:geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org> [mailto:geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org] On Behalf Of Ollie Raymond
Sent: Saturday, 15 June 2013 10:37 PM
To: Public: A mailing list for GeoSciML
Subject: Re: [GeoSciML] Changes needed to get qualified lithology query working

Hi Marcus,

See comments from me inline below...

Cheers,
Ollie

===============================================================================

On 14 June 2013 23:14, Sen, Marcus A. <mase at bgs.ac.uk<mailto:mase at bgs.ac.uk>> wrote:
I'd like to check my recollection of our conclusions about what is needed to get a useful lithology query working following the St Petersburg meeting.

In summary, for OneGeology we would like to be able to query a WFS server to return something like "all the GeologicUnits which have at least 25% sandstone lithology. This does not seem to be possible currently.

The first factor that seemed to prevent it was as a result of the restricted subset of XPath which FES says implementations are obliged to support. This problem turned out to be soluble in our example although the general problem of more complex queries remains.

Ollie: My understanding is that we had solved this problem by using an appropriate construction of the xpath in the filter text (ie, starting the xpaths for queried tags at a higher level).

The second problem was the fact that we can't extract one of the numbers from a swe:Quantity range to do a numerical comparison on using FES. If the range was encoded with separate tags for upper and lower bounds we could do. At the moment, as we are re-using SWE this possibility is not available. Eric emailed Alexandre Robin to ask whether the SWE working group would consider modifying SWE to allow an encoding of a range with separate tags. Even if they would, I guess that this wouldn't become a published standard for some time.

Ollie: My understanding is that we were going to wait for a reply from Alex Robin to Eric's email before deciding our next move.

I have a vague recollection that we may have mentioned the idea of making a small modification to GeoSciML 3.x so that we could encode a range in separate tags pre-emptively before SWE does if we thought it was going to happen at some stage. This would allow us to pass John Laxton's "laugh test" of being able to do the above query.

Ollie: As Eric mentions, separate tags is returning to the days of CGI_Value.  Funny how things come full circle.  If we can't get a definite and short term solution from SWE and WFS for swe:QuantityRange, them I would definitely support a return to using separate attributes for upper and lower values in GSML v4.  This is not an optimal solution, given that we only started using swe:Quantity in version 3, but unless swe:Quantity is queryable I feel we must abandon it.

To be able to query Porportion values in GSML v3.x, we would need to add 2 optional swe:Quantity attributes (upperPorportion and lowerProportion) to the  GeologicUnit:CompositionPart class.  This could be done, but I'd like to fully explore the results of Eric's email to Alex Robin first.

Re "laugh test": personally, I don't think that a complex query like "find me all units with greater than 25% sandstone" is laugh testable.  While it might be a desirable query, it is a pretty complex query (3 elements in one query).  I think that the simpler "Find me all units containing sandstone" is a query that should be able to pass a laugh test.

(In the longer term we have more general thinking to do about how queryable we expect such services to be, whether we need a separate query profile from the data model to support the queries we want to be able to do etc.)

Ollie: I agree we need to identify those parts of the model that have a definite need to be queryable and make sure that they are.  It is unfortunate that we have to make these decisions based on current technological limitations, but it seems we must.

Could Eric, in particular, confirm whether my summary is correct and could Olly comment on whether modifying GeoSciML 3.x is an idea with any traction or not?

Ollie: see comment above re potential GSML 3.x changes for CompositionPart/proportion.

Any other comments, feel free...

Marcus



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/20130617/99766a5f/attachment-0001.htm>


More information about the GeoSciML mailing list