[Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Wed Mar 3 17:35:35 EST 2010


It was also my impression that building a GML3.1-compliant version of GeoSciML3 would only be used for testing using currently available non-GML3.2-capable software.  The final release of GeoSciML 3.0 would be a GML3.2-compliant schema.

As far as why I built the proxy ISO19115 model, I’ll reply shortly after more fully reviewing all the emails and other resources.

Cheers,
Ollie

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


-----Original Message-----
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: Thursday, 4 March 2010 9:28 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]


Bruce, can you clarify ?.  I understand from the note that the 3.1 would be 'for testing until software is available'.  Your email "  In order that we at least have a chance of setting up GeoSciML 3.0 services I repeat my request in Quebec that GeoSciML remain a GML 3.1 application, with additional 'placeholders' for GML3.2 properties." seems to suggest that you want it to remain (forever) 3.1.1

Only GML 3.1 for testbed purposes so we can actually establish some services. The aim would be to release GeoSciML 3.0 as a GML 3.2 schema, either based on Testbed 4 testing if someone tests the GML3.2 implementation (using Snowflake and/or Coccoon?) or after post Testbed4 testing.
Certainly the change of version numbering to 3 was intended to indicate no backward compatibility, at least in part due to the move to GML3.2.

Cheers
Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

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

Létourneau, François <Francois.Letourneau at RNCan-NRCan.gc.ca>
Sent by: auscope-geosciml-bounces at lists.arcs.org.au

04/03/2010 06:24 AM
Please respond to
auscope-geosciml at lists.arcs.org.au


To

<auscope-geosciml at lists.arcs.org.au>

cc



Subject

Re: [Auscope-geosciml]        RE :  Testbed proposition [SEC=UNCLASSIFIED]










Éric,

As for having a conforming schema in 3.1.1 or 3.2.0, we need to have all the required classmaps as a 3.1 or 3.2 implementation. The, in Fullmoon, when we generate the schemas, we explicitely tell Fullmoon to use v3.1 or v3.2. It is not too difficult to build the missing classmaps, it only takes time, as it requires exhautivity in documenting everything needed.

François


François Létourneau
Professionnel de recherche - géomatique / TI
Institut national de la recherche scientifique
Centre Eau Terre Environnement - Centre Géoscientifique de Québec
490, de la Couronne, bureau 3344
Québec (Québec) G1K 9A9
418 654-3161

________________________________
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Boisvert, Eric
Envoyé : 3 mars 2010 14:14
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml]RE : Testbed proposition [SEC=UNCLASSIFIED]

Ok, looks like the ball stopped bouncing here.

Do we go forward with the instance document from a legend/story ?  Do we have agreement from people who commited to those use cases ?

Do we have someone to build/lend a pretty complete database so we can test serialisation with WFS 1.1.0 and potentially WFS 2.0 for people who wants to take advantage of Snowflakes offer ?

I understand from Simon that having a 3.1.1 and a 3.2.0 conformant schemas is a matter of configuring FullMoon correctly - something we apparently having problem wrapping our minds around.  Is somebody looking into this ?

Regarding Bruce's request to keep GeoSciML 3 as a GML 3.1 application, I read back the twiki notes and it is said:

"BS proposed and it was unaimously agreed that:: "Geosciml v3 release candidates will be based on GML 3.1.1 implementation for testing – the final production release of GeoSciML<outbind://50/twiki/bin/view/CGIModel/GeoSciML> v 3 will wait for commercial and open source software to support both gml 3.2.1 and wfs2 (within that modules of conformance level that the GeoSciML<outbind://50/twiki/bin/view/CGIModel/GeoSciML> community decides it needs) – which will probably second half of 2010. AUSCOPE Geoserver plans to work on WFS2 implementation from the second half of 2010."

Bruce, can you clarify ?.  I understand from the note that the 3.1 would be 'for testing until software is available'.  Your email "  In order that we at least have a chance of setting up GeoSciML 3.0 services I repeat my request in Quebec that GeoSciML remain a GML 3.1 application, with additional 'placeholders' for GML3.2 properties." seems to suggest that you want it to remain (forever) 3.1.1

About WFS service : Do we need to prepare test request or is it essentially a serialization exercise ?

Eric
________________________________
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Rob.Atkinson at csiro.au
Envoyé : 1 mars 2010 21:49
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

Re

" the model itself in an ideal situation would not be constrained by implementation details. In practice though it is ..."

the reality is that the underlying agreement about semantics is partially driven by what people are motivated and able to implement - its the realpolitik of semantic governance that the level of abstraction of the conceptual model is variable according to the complexity and maturity of the domain.

The CGI model is trying to find the right balance between the mess of multiple similar implementations and the unbounded nature of a top-down description of the real world. Over time we hope to see some guidance and best practice emerge as to how to find the right level of abstraction, but from my experience across multiple domains:

1) you cant extend the model beyond the combination existing systems and specific interoperability requirements you can define test cases for. (and in many cases existing systems may need to support structural and semantic matching to realise these)
2) The conceptual model should be abstracted around the concept of object identity - not the specific set of attributes you might attach to a concept

I think the CGI model has some way to go - its still a reverse engineering activity, starting to explore the actual interoperability requirements. Its a good place, in that care is being taken to establish test cases, and its getting less of an implementation flavour each iteration.

Rob Atkinson
Research Scientist, Water Informatics
CSIRO Land & Water
Ph (mobile) +61 419 202 973

________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Robert.Woodcock at csiro.au
Sent: Tuesday, 2 March 2010 1:32 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [ExternalEmail] Re: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

> Fine with me, but this is more testing available mapping technologies than testing the model itself. Unless WFS and/or RDBMS constrains becomes model design requirements.

AuScope are keen to ensure that we have some decent tests for WFS serving GML application schemas. The current OGC cite tests in this regard are lacking. This is one of the drivers behind the “unit tests” Bruce Simons is referring too. GeoSciML being one of the more mature GML application schemas provides a useful basis for such testing for both WFS compliance and for the GeoServer technology. We hope to feed the test suite back into the OGC compliance process. So, yes, it is more about testing the standards and mapping technologies rather than the model itself though it will serve both purposes.

The second comment regarding the WFS or the RDBMS becoming constraints on the model design requirements is interesting. In my view these already are, or should be, lest the model itself become something that cannot be implemented or managed in practice. I include “managed” as the community of practice around GeosciML also uses HollowWorld for model management plus vocab management tools etc. It’s a complete system that is required.

Please don’t misunderstand me, the model itself in an ideal situation would not be constrained by implementation details. In practice though it is and whilst the WFS middleware is immature relative to the modelling process the model runs the risk of getting ahead of the implementations and becoming not implementable/manageable – my concerns about WFS CITE tests relates to this, so does the Geoserver development which we are earnestly trying to complete the foundation work for GeoSciML support before WFS 2.0 and GeoSciML 3 arrive. The separate, but related, developments that make up the community of practice that is using GeoSciML needs to remain in loose synchronisation and not get to far ahead or behind one another for the varying parts of the system. So far so good.

> Actually, this also begs the question.. Are we restricted to classical RDBMS or is it more about currently available softwares ?

In my view it is more about currently available software. I built a WFS using XMML (roughly an early version of GeoSciML Borehole) using an Object Oriented database some years back. Full 3D support, web delivery etc. Somewhat bespoke for that particular OO database but there was nothing in the XMML model that seems restrictive to RDBMS – in fact it was somewhat easier than the RDBMS mapping process used in Geoserver as the OO database was “Feature” based in the first place so a much closer match to the GML model.

Regards,

Rob

Dr Robert Woodcock
CSIRO
ARRC (Australian Resources Research Centre)
26 Dick Perry Avenue, Kensington WA 6151, Australia
PO Box 1130, Bentley WA 6102, Australia
Ph: 08 6436.8780 | E: Robert.Woodcock at csiro.au<mailto:Robert.Woodcock at csiro.au> | W: 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 Boisvert, Eric
Sent: Monday, 1 March 2010 6:12 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] RE : Testbed proposition [SEC=UNCLASSIFIED]

> It will also serve for 'unit tests' when testing middkleware such as GeoServer for WFS1.1 compliance.  In order to test the mapping and transformation it shouldn't be a database that looks like GeoSciML, but rather like one of our pre-GeoSciML databases with any missing components added to it.

Fine with me, but this is more testing available mapping technologies than testing the model itself. Unless WFS and/or RDBMS constrains becomes model design requirements.  Actually, this also begs the question.. Are we restricted to classical RDBMS or is it more about currently available softwares ?

Eric


________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Bruce.Simons at dpi.vic.gov.au
Date: dim. 2010-02-28 17:06
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] Testbed proposition [SEC=UNCLASSIFIED]

Hi all,
I'm happy to use instance documents to test the model if services aren't available. However, we need to be careful that the modelling does not get too far ahead of the implementation, which is what can happen with this strategy, and has in the past.  In order that we at least have a chance of setting up GeoSciML 3.0 services I repeat my request in Quebec that GeoSciML remain a GML 3.1 application, with additional 'placeholders' for GML3.2 properties if necessary.

Eric proposed:

My suggestion for this portion of the testbed is
1- Come with a series of legend descriptions, or stories for each of the relevant use cases. Different regions and languages is obviously encouraged. Agree. But I would also like to see a 'test' database established (see below).

2- Have people to generate instance document based on selected stories. The interesting bit is when more than one person attempts to serialise the same stories. We already know that there is a lot of assumptions in legend description and it will be interesting to see how this materialise on a rigid GeoSciML document.
Although this is is good it is not sufficient.  we also need to commit to ensuring that the different instance documents are compared to ensure consistency between them. We have not fully done this in previous testbeds, as it can be quite onerous and time-consuming.

An issue with this approach is that it will only include data we have in our production databases, or in a particular legend.  This does not fully test the model. I suggest that one of the Testbed participants (any volunteers?) also create a 'dummy' database which contains all properties that we wish to test (complete GeoSciML).  We then use this as a guide to craft the instance documents, and our own databases to establish the services.  It will also serve for 'unit tests' when testing middkleware such as GeoServer for WFS1.1 compliance.  In order to test the mapping and transformation it shouldn't be a database that looks like GeoSciML, but rather like one of our pre-GeoSciML databases with any missing components added to it.

Cheers
Bruce

GeoScience Victoria
AuScope Grid
Australian Spatial Research Data Commons

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155
<Oliver.Raymond at ga.gov.au>
Sent by: auscope-geosciml-bounces at lists.arcs.org.au

26/02/2010 08:50 AM


Please respond to
auscope-geosciml at lists.arcs.org.au



To

<auscope-geosciml at lists.arcs.org.au>

cc



Subject

Re: [Auscope-geosciml] Testbed proposition [SEC=UNCLASSIFIED]













I agree too.

Personally, I am keen to see the process applied to geochemistry data too, mainly because O&M “result” is of type “Any”, meaning that currently users can encode their assay data using any of several available methods (eg, swe:Quantity, gml:measure, etc).  Having a best practice XML example of a geochemistry ‘story’ is essential.

Cheers,
Ollie



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

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


-----Original Message-----
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
Sent: Friday, 26 February 2010 1:39 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] Testbed proposition

> I really like the idea of adding real XML examples to a specification document.

Ditto for me, I think it's the most readable form.

If I understand the current trend up there at ISO/OGC, looks like the UML spec and XML encoding will now be published in two separates documents (to avoid making amendment to the UML+XML spec when only changes to XML is needed and to have UML spec independent of implementation).  The "instance" in the UML spec are often shown as UML instance diagram that all looks like a freak accident in Legoland if you ask me.

Eric


________________________________


De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Guillaume.Duclaux at csiro.au
Envoyé : 25 février 2010 09:34
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] Testbed proposition
I really like the idea of adding real XML examples to a specification document.

<<Some specification document (O&M “banana” examples come to mind) had those examples and they were extremely useful to ‘grasp’ the concept, specially when showing them to non-technical people. >>
+1 --> The example helped me probably more than the spec document itself for the NVCL o&m work I started and improved with Bruce and Alistair.

Gilly
________________________________________________

Dr Guillaume Duclaux
CSIRO Earth Science and Resource Engineering
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 Boisvert, Eric
Sent: Thursday, 25 February 2010 9:05 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] Testbed proposition

Guys,
A significant portion of use cases we have listed in Quebec is about testing new and altered elements of GeoSciML v3. In the past we tested those changes with instance documents and created a series of testbed to test the serialisation from a database. I think it’s important to emphasise the difference between testing the model and testing the serialisation. Instance document allowed us to test the model with real cases. Creating WFS from a database allowed us to test the feasibility of turning our respective databases into GeoSciML (we tested the mapping between our databases and GeoSciML and its queriability using WFS). In principle, when we are testing the serialisation, the model should already be tested.

In NADM, we tested the model with a real case example from a legend description of a geological map of Arizona:
Harald Drewes. 1998,. ARIZONA. Geologic map of the Bartlett Mountain Quadrangle, Pima and Santa Cruz counties, Arizona, I-2624. Lat 31 deg 22'30" to 31 deg 30', long 111 deg 15' to 111 deg 22'30". Scale 1:24,000 (1 inch = 2,000 feet). Sheet 43 by 39 1/2 inches.

The text of the legend read as follow :
Dacitic Vent Breccia (Miocene) -Light-medium-gray, finely porphyritic dacitic rock containing inclusions of Jurassic or Proterozoic granite and Jurassic rhyolite (welded tuff?) as much as 20 m in diameter. The subcircular outcrop mass of breccia probably is a volcanic vent or throat. A halo of strongly saussuritized rock 0.3 -0.5 km wide (delineated on map) surrounds this vent. The dacitic matrix consists of phenocrysts (25-35%, as much as 2 mm in length) set in a cryptocrystalline granular groundmass. Phenocrysts included albitized(?) plagioclase (12-18%), chloritized biotite (2-5%), uralized amphibole (2-10%), magnetite (trace to 2%), and apatite (trace). Quartz is present as a secondary mineral, filing vugs.

At that time, the data model was a RDBMS implementation, therefore the ‘instance’ document was a description of the table content: see: http://ngmdb.usgs.gov/www-nadm/dmdt/pdf/CORDLink_Variant_Example.pdf

What I found interesting in this exercise was that we tested the model from a real case. Some specification document (O&M “banana” examples come to mind) had those examples and they were extremely useful to ‘grasp’ the concept, specially when showing them to non-technical people. What I propose as a testbed (at least for that portion of the use cases that are relevant) is to have similar exercises. The added benefit is to produce material, coupled with an updated document like OneGeology Cookbook #2, that can be used in discussion with new comers and non-technical people.

My suggestion for this portion of the testbed is
1- Come with a series of legend descriptions, or stories for each of the relevant use cases. Different regions and languages is obviously encouraged.

2- Have people to generate instance document based on selected stories. The interesting bit is when more than one person attempts to serialise the same stories. We already know that there is a lot of assumptions in legend description and it will be interesting to see how this materialise on a rigid GeoSciML document.

Eric

================================================================
Eric Boisvert
Spécialiste TI-GI / IT-IM specialist
Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur
418-654-2615
490, rue de la Couronne, Québec (Québec), G1K 9A9
490, rue de la Couronne, Quebec, Quebec, G1K 9A9

Laboratoire de cartographie numérique et de photogrammétrie (LCNP)
Digital Cartography and Photogrammetry Laboratory (DCPL)
Commission géologique du Canada (Québec) / Geological Survey of Canada (Quebec)
Ressources naturelles Canada / Natural Resources Canada
Gouvernement du Canada / Government of Canada
http://cgc.rncan.gc.ca/org/quebec
http://cgc.rncan.gc.ca/dir/index_f.php?id=4186 / http://cgc.rncan.gc.ca/dir/index_e.php?id=4186

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml_______________________________________________
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����⪛"ͭ㓝)󧮊
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100304/f3cdfef5/attachment.htm>


More information about the GeoSciML mailing list